Doom64 DS

[elhobbs]

looking at the code in the svn (which may be old) I noticed that you are calling irqInit in I_Init (ds.c line 169). unless you are using a really old version of libnds then you should not call this function for the arm9 (you do need to call it for arm7). irqInit is being called by the crt startup code before main is entered. calling it again yourself causes problems and could possiblely explain your vblank wait lag.

[Kaiser]

New version is up in case anyone is interested

Doom64DS: http://doom64ex.svn.sourceforge.net/vie ... /Doom64DS/
Wadgen (Needed to generate game data): http://doom64ex.svn.sourceforge.net/vie ... DS/wadgen/

There's still some issues though, one of them is performance issues in some levels (Beginning of Map18 is a good example) and a exception crash in Map28 (still investigating). The double buffer technique is working out pretty well but I still had better performance from my older version (using glBindTexture, etc).

[elhobbs]

a few comments:
memcpy32 is missing from svn
asm not compatible with current/latest devkitarm (see here)
wadgen was hard to compile (me just whining here - but is that a visual studio 6 project?)

for other people trying to get this running (and this it probably obvious to everyone else) - do not use the wadgen binary for the pc version as it is not compatible.

I was able to get it running and it looks nice. The load everything approach is a little slower in average cases. however, it is very consistent and does not drop down as badly when all the textures/sprites need to be replaced. It also eliminates vram fragmentation and having to search for space to free/allocate in vram. this may be less of an issue for doom 64 with 4bit textures.

[Kaiser]

Whoops, I forgot to include the tonic library which contains the asm for memcpy32. And also, yeah Wadgen is Visual Studio 6 (the original Doom64EX project was all in MSVC 6.0 and I just never bothered to upgrade Wadgen to the latest MSVC).

The frame rate issues is coming from textures/sprites being copied to gfx_tex_buffer because the current system isn't smart enough to know what textures/sprites should be replaced or not and instead just copies everything per frame.

[Kaiser]

Made some more updates (http://doom64ex.svn.sourceforge.net/vie ... /Doom64DS/)

I've made some modifications to the zone system which allows me to only copy new textures to gfx_tex_buffer if needed and free a block when not used in the last couple of frames. Though it has somewhat helped performance a little bit but as a result, the top half of the screen constantly flickers. I am still looking into why its doing that but all of this is experimental for now. The swiWaitForVBlank calls is still hurting the overall performance though.

Feedback is welcomed.

[elhobbs]

I have not had a chance to look at the changes, but I noticed that there are situations where if it is running very quickly (if you are standing in front of a closed door or a wall) there will be lots of screen flicker (i disabled the vblank wait in the old version). It is possible that it is running too quickly and the texture VRAM is still in use?

[Kaiser]

Yeah, I've seen that too. I've tried toying around with swiWaitForVBlank but seems like I keep getting that flicker that covers the top half of the screen. It actually gets worse when there's more stuff to DMA, so it gradually gets worse as you progress through the level.

I am thinking about reverting back to what I had before but still need to find ways to avoid copying everything each frame as it's way too slow. I might look into optimizing other things as well. I know that I need to borrow some optimization code for monster sight checks from PRBoom which seems to be the biggest performance hitter in my DS port.

[elhobbs]

keeping wall and floor textures resident in vram is not a problem. keeping the sprites resident is the obstacle. they have different angles and cycle animation frames for different actions. how often can they be reused? i think that 1/4 or 1/8 scale sprites (16 or 32 pixels wide) for objects that are beyond a certain point would make this easier.

[Kaiser]

I think I am able to achieve desirable performance thanks to a update to the sight checking code, however once again, it affects the VBlank as it gets worse when performance increases. It's also affected by how large the data is when I call dmaCopyWords. Unfortunately swiWaitForVBlank doesn't help at all regardless of when or where it's called. Seems like it occurs on one frame, then the next frame it's fine but then occurs again on the next.

[elhobbs]

I think this may be related to how GFX_FLUSH works on the DS - it does not take effect (geometry buffers are swapped) until the next vblank starts on scan line 192. so, I think if you are in vblank when GFX_FLUSH is set then I think it will not take effect until the following vblank.gbatek SWAP_BUFFERS