Doom64 DS

[elhobbs]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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.