Doom64 DS

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

Re: Doom64 DS

Post by Kaiser » Tue May 08, 2012 5:03 pm

The problem is that most sprites after padding are at 128x128. The majority of the sprites are usually around ~72-90 in width, which results in a lot of wasted space after padding. So for example, the pinkie demon's first frame is 68x82 (roughly). Breaking it up into several tiles (64x64, 8x64, 64x32, 8x32) will only be 6912 bytes compared to 16384 bytes if I were to just pad the entire sprite to 128x128. The N64 version does this as well but not as aggressive as my approach.

This would also allow me to keep the cached textures in gfx_tex_buffer longer.

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

Re: Doom64 DS

Post by elhobbs » Tue May 08, 2012 5:30 pm

how are you on triangle count? you can only render 2048 triangles per frame.

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

Re: Doom64 DS

Post by Kaiser » Tue May 08, 2012 7:12 pm

Some scenes are pushing it, but I know where to look to for optimizations. I can render linedefs instead of segs and for leafs, I can possibly merge vertices that lies on perpendicular edges of the subsector. I could start off with just splitting up the sprite columns at first just to see how much triangles I can get away with. I think it may not be necessary to split up the sprite's rows. I think tiling the sprite textures is needed because of the wasted space after padding though I've tried looking into scaling the sprites as well but I can't seem to find a cheap and simple C library that does this (I am too lazy to do this myself...).

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

Re: Doom64 DS

Post by mtheall » Tue May 08, 2012 7:34 pm

A C library to resize the sprites? for example from 70x70 to 64x64

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

Re: Doom64 DS

Post by Kaiser » Tue May 08, 2012 7:38 pm

More or less, yeah. It depends on the dimensions though. If the sprite is 72x80, then I want it resized to 64x64. If the sprite is 80x112, then I want it resized to 64x128 and so forth. Basically rounding width or height to the nearest or highest power of two.

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

Re: Doom64 DS

Post by mtheall » Tue May 08, 2012 7:42 pm

Yeah that might be awkward, especially to maintain the aspect ratio and make it not look weird.

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

Re: Doom64 DS

Post by Kaiser » Wed May 09, 2012 2:00 am

Been thinking though, it would be nice to be able to leverage all VRAM banks. There has to be a way to use them and at the same time, wait for the frame to finish drawing before using the banks again.

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

Re: Doom64 DS

Post by elhobbs » Wed May 09, 2012 3:39 am

vblank for 3d is really small - only 23 lines. I want to say that it takes about 43 lines to load 1 vram with dma. for cquake I just load textures when needed regardless of vblank - only unlocking the bank while a single texture loads. there are a few black lines and it is not too noticable. I tried the same approach with heretic and the sreen was a mess of black lines. I even tried loading during hblank - but that does not appear to work for 3d.

Discostew
Posts: 103
Joined: Sun Mar 08, 2009 7:24 pm

Re: Doom64 DS

Post by Discostew » Wed May 09, 2012 5:53 am

elhobbs wrote:vblank for 3d is really small - only 23 lines. I want to say that it takes about 43 lines to load 1 vram with dma. for cquake I just load textures when needed regardless of vblank - only unlocking the bank while a single texture loads. there are a few black lines and it is not too noticable. I tried the same approach with heretic and the sreen was a mess of black lines. I even tried loading during hblank - but that does not appear to work for 3d.
Not even the idea I brought up about starting a copy after the last line is buffered?

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

Re: Doom64 DS

Post by mtheall » Wed May 09, 2012 7:29 am

Even though the vblank for 3D is only those 23 lines, you should still be able to load your textures before vcount=213. I would do this (pseudocode):

1. gather inputs
2. process everything
3. flush your 3D commands
4. update your textures for the upcoming frame (i.e. copy to vram)
5. if you didn't make it to vblank yet (i.e. vcount < 192), wait for vblank, else don't wait for vblank (you are already in it)
6. swap vram
7. repeat

You need to make sure you get step 6 before vcount=213 to avoid trash. Maybe this will help, maybe not. But probably it will help spark an idea.

Post Reply

Who is online

Users browsing this forum: No registered users and 13 guests