Doom64 DS

[Kaiser]

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]

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

[Kaiser]

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]

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

[Kaiser]

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]

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

[Kaiser]

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]

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]

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]

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.