Doom64 DS

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

Re: Doom64 DS

Post by elhobbs » Thu May 03, 2012 11:46 pm

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

Re: Doom64 DS

Post by Kaiser » Fri May 04, 2012 5:45 am

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

Re: Doom64 DS

Post by elhobbs » Fri May 04, 2012 2:51 pm

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

Re: Doom64 DS

Post by Kaiser » Fri May 04, 2012 4:38 pm

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

Re: Doom64 DS

Post by Kaiser » Sun May 06, 2012 4:19 am

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

Re: Doom64 DS

Post by elhobbs » Sun May 06, 2012 7:33 am

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

Re: Doom64 DS

Post by Kaiser » Sun May 06, 2012 8:16 pm

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

Re: Doom64 DS

Post by elhobbs » Mon May 07, 2012 1:19 am

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

Re: Doom64 DS

Post by Kaiser » Mon May 07, 2012 6:29 am

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

Re: Doom64 DS

Post by elhobbs » Mon May 07, 2012 2:31 pm

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

Post Reply

Who is online

Users browsing this forum: Google [Bot] and 15 guests