Doom64 DS

elhobbs
Posts: 358
Joined: Thu Jul 02, 2009 1:19 pm

Re: Doom64 DS

Post by elhobbs » Thu May 03, 2012 3:33 pm

you are alternating texture banks each frame, but what about the palettes? cheretic uses a single 8 bit palette so I did not have to worry about this. are you reloading the entire palette vram each frame? if the palette vram is not available when the hardware needs it (ie you have it unlocked for writing), then you will get black lines.

elhobbs
Posts: 358
Joined: Thu Jul 02, 2009 1:19 pm

Re: Doom64 DS

Post by elhobbs » Thu May 03, 2012 3:43 pm

just thought I would mention that dma copy is the fastest method for copying from main memory to vram. yes, even faster than ldmia/stmia in this situation. however, it is not good for main memory to main memory copy - I think ldmia/stmia is best in this case. there are threads if you want to search. I say this because you mention lag on dma copy.

mtheall
Posts: 210
Joined: Thu Feb 03, 2011 10:47 pm

Re: Doom64 DS

Post by mtheall » Thu May 03, 2012 3:58 pm

Is your entire source somewhere public? I personally like github. Then we could make modifications and suggest them to you. Plus it would give us more context.

Kaiser
Posts: 38
Joined: Wed Apr 25, 2012 4:44 am

Re: Doom64 DS

Post by Kaiser » Thu May 03, 2012 7:25 pm

elhobbs wrote:you are alternating texture banks each frame, but what about the palettes? cheretic uses a single 8 bit palette so I did not have to worry about this. are you reloading the entire palette vram each frame? if the palette vram is not available when the hardware needs it (ie you have it unlocked for writing), then you will get black lines.
Unlike other Doom engines, Doom64 uses a palette for each texture and sprite. All textures and small sprites contains a 16-color palette while larger sprites (monsters, weapon sprites, etc) uses a external 256 color palette. So basically each time I load in a texture I also load in the palette belonging to it.

The only time I lock/unlock VRAM_E is when I DMA the data.

On a unrelated note, I tried using VRAM_F for texture palette as well but that doesn't seem to work at all. I am under the impression that I can only use VRAM_E to store palettes.

mtheall
Posts: 210
Joined: Thu Feb 03, 2011 10:47 pm

Re: Doom64 DS

Post by mtheall » Thu May 03, 2012 7:38 pm

Look here and you can see how texture palettes are allocated.

You probably want:

Code: Select all

vramSetBanks_EFG(VRAM_E_TEX_PALETTE,
                 VRAM_F_TEX_PALETTE_SLOT4,
                 VRAM_G_TEX_PALETTE_SLOT5);
which would look like this (look at the bottom).

Edit: I mean unless you are also wanting to do palette swapping. In that case you need to use

Code: Select all

if(gametic & 1)
  vramSetBanks_EFG(VRAM_E_LCD,
                   VRAM_F_TEX_PALETTE_SLOT0,
                   VRAM_G_TEX_PALETTE_SLOT1);
else
  vramSetBanks_EFG(VRAM_E_TEX_PALETTE,
                   VRAM_F_TEX_LCD,
                   VRAM_G_TEX_LCD);
or something similar. Of course, you should note that on (gametic&1) you can only use 32KB (banks F+G) for palettes where you can use 64KB (bank E) otherwise.

Instead of swapping I would just only reset the palette pointer every two frames (i.e. use the code at the top). This way you can effectively use ~48KB for palette per frame. Of course if you use less during the first frame you can use more during the second and vice versa, and you aren't limited to 32KB on the odd frames while possibly wasting space in the even frames.

Kaiser
Posts: 38
Joined: Wed Apr 25, 2012 4:44 am

Re: Doom64 DS

Post by Kaiser » Thu May 03, 2012 8:20 pm

Ah, okay, seems like both banks E and F were conflicted then. I didn't even realized that I was suppose to map slot 4 for bank F.

mtheall
Posts: 210
Joined: Thu Feb 03, 2011 10:47 pm

Re: Doom64 DS

Post by mtheall » Thu May 03, 2012 8:28 pm

Yup. I figured you tried out VRAM_F_TEX_PALETTE which actually maps to slot 0. I try to avoid the #define's which are not specific.

Kaiser
Posts: 38
Joined: Wed Apr 25, 2012 4:44 am

Re: Doom64 DS

Post by Kaiser » Thu May 03, 2012 8:38 pm

Yeah, they're not. Now since I know how to properly utilize banks F and G, I just might have enough room to cache the palettes of all textures and sprites without having to worry about doing double buffer swaps on them like with texture data. This should help simplify things in the code too.

mtheall
Posts: 210
Joined: Thu Feb 03, 2011 10:47 pm

Re: Doom64 DS

Post by mtheall » Thu May 03, 2012 8:50 pm

The only problem I can see is when you reset the palette pointer. You don't want to accidentally run into the data from the previous frame, so it might be better to reset the pointer to 0 offset on one frame and then set it to 48KB offset on the next frame and just keep swapping and stop at 48KB worth of palette. Then you can work exactly like the bank swapping without actually swapping banks. It's like pretending you have two banks and each is 48KB.

elhobbs
Posts: 358
Joined: Thu Jul 02, 2009 1:19 pm

Re: Doom64 DS

Post by elhobbs » Thu May 03, 2012 9:19 pm

you have the palette vram unlocked for the whole texture load to vram. unless you are in vblank this will cause black lines - the wait for vblank avoids this issue. one potential solution would be to load the palette during vblank interrupt. I am not saying it is a good or bad solution - something to try though.

Post Reply

Who is online

Users browsing this forum: Ahrefs [Bot], Google [Bot] and 12 guests