View unanswered posts | View active topics It is currently Sat May 26, 2018 8:44 pm



Reply to topic  [ 95 posts ]  Go to page Previous  1, 2, 3, 4, 5, 6 ... 10  Next
 Doom64 DS 
Author Message

Joined: Thu Jul 02, 2009 1:19 pm
Posts: 349
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.


Thu May 03, 2012 3:33 pm
Profile

Joined: Thu Jul 02, 2009 1:19 pm
Posts: 349
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.


Thu May 03, 2012 3:43 pm
Profile

Joined: Thu Feb 03, 2011 10:47 pm
Posts: 210
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.


Thu May 03, 2012 3:58 pm
Profile

Joined: Wed Apr 25, 2012 4:44 am
Posts: 38
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.


Thu May 03, 2012 7:25 pm
Profile

Joined: Thu Feb 03, 2011 10:47 pm
Posts: 210
Look here and you can see how texture palettes are allocated.

You probably want:
Code:
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:
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.


Thu May 03, 2012 7:38 pm
Profile

Joined: Wed Apr 25, 2012 4:44 am
Posts: 38
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.


Thu May 03, 2012 8:20 pm
Profile

Joined: Thu Feb 03, 2011 10:47 pm
Posts: 210
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.


Thu May 03, 2012 8:28 pm
Profile

Joined: Wed Apr 25, 2012 4:44 am
Posts: 38
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.


Thu May 03, 2012 8:38 pm
Profile

Joined: Thu Feb 03, 2011 10:47 pm
Posts: 210
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.


Thu May 03, 2012 8:50 pm
Profile

Joined: Thu Jul 02, 2009 1:19 pm
Posts: 349
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.


Thu May 03, 2012 9:19 pm
Profile
Display posts from previous:  Sort by  
Reply to topic   [ 95 posts ]  Go to page Previous  1, 2, 3, 4, 5, 6 ... 10  Next

Who is online

Users browsing this forum: Bing [Bot] and 1 guest


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
  Powered by phpBB® Forum Software © phpBB Group
Designed by ST Software.
Get devkitPro at SourceForge.net. Fast, secure and Free Open Source software downloads