Doom64 DS

[mtheall]

I got it working with the latest SDK. I will provide a patch to you.

[mtheall]

Actually the diff is too complicated to be resolved by a simple diff. There is some directory moving and such. So I just stuck it in an archive for you to download here.

In addition, I set up the makefile to compile everything as ARM code and with -O3 to squeeze out some performance. After this gets into the svn repository, I will have additional changes to make.

[Kaiser]

Tried both waiting for the right VCOUNT value as well as setting REG_VCOUNT to 192 for each 64k of data I dma to the VRAM. Still got flickering unfortunately but at this point now, I can live with just 256kb of data to work with.

You can't set it to 192, you can only write values from 202 to 212 inclusive while the register is still within that range. It's intended for syncing multiplayer games so they're on the same frame. Maybe you can work out a size to DMA that completes within that range & reset vcount as you go?

So let's say I wait for REG_VCOUNT to be within 202/212 and then after that I do a for loop where only 32kb of data is DMA'ed to VRAM (it loops 16 times until all 512kb of data has been sent). In between the DMA'ing I set the VCOUNT to 202-215, depending on what it was before I start the DMA again?

[WinterMute]

Personally I'd just set it back to 202 after each DMA until all the data is transferred, probably tweaking the DMA size until it takes about 8 scanlines. I'd probably also make use of the vcount interrupt to start it off rather than hanging around waiting for the scanline to be reached.

[Kaiser]

Okay, that makes a lot of sense then.

Seems like I can get away with DMA'ing 16kb of data (32 loop count) without experiencing any issues. I am also able to get away without waiting for the scanline to be reached either. So in my current test build, I basically wait for vblank, call DC_FlushAll, lock VRAM banks and then do my DMA'ing (which I set REG_VCOUNT to 202 after DMA'ing the data). Then I unlock the banks and invoke GFX_FLUSH. Framerate isn't perfect (25fps instead of 30) but it's something I can probably live with unless I can find ways to improve it.

[Discostew]

So the VCount setting (LYC) shouldn't be set to a value other than 202 - 212? I read in the specs that for proper syncing with linked DSs that it should only be in that range, but what about if you aren't doing that? Would it be a problem? If it does, then my idea of beginning VRAM writing right after the last rendered line is buffered wouldn't go over well.

Sorry for going a little off-topic here.

[Kaiser]

I don't see this as off-topic. Though I kinda questioned myself about writing only 202-212 to VBLANK though. What's funny is that I even wrote 192 and I gained back a smooth 30 fps and still haven't experienced any flickering/tearing, etc. So now I am able to leverage all 512kb of VRAM and still maintain the same performance I had before.

The final code for I_FinishFrame is something like this now:

Code: Select all

//
// I_FinishFrame
//

void I_FinishFrame(void)
{
    int i;
    byte* buff;
    byte* vram;
    
    I_CheckGFX();
    
    swiWaitForVBlank();
    DC_FlushAll();

    buff = (byte*)gfx_tex_buffer;
    vram = (byte*)VRAM_A;

    vramSetBankA(VRAM_A_LCD);
    vramSetBankB(VRAM_B_LCD);
    vramSetBankC(VRAM_C_LCD);
    vramSetBankD(VRAM_D_LCD);

    // transfer 16kb of data at a time
    for(i = 0; i < 32; i++)
    {
        dmaCopyWords(0, (uint32*)buff, (uint32*)vram, 0x4000);
        buff += 0x4000;
        vram += 0x4000;
        REG_VCOUNT = 192;
    }

    vramSetBankA(VRAM_A_TEXTURE);
    vramSetBankB(VRAM_B_TEXTURE);
    vramSetBankC(VRAM_C_TEXTURE);
    vramSetBankD(VRAM_D_TEXTURE);

    frametic++;

    GFX_FLUSH = 1;
}

[Kaiser]

Latest SVN update has full working HUD and other overlay effects. Made several cleanup to the code and optimization to looking up data files in the IWAD. Also for those who are interested, I've uploaded a gameplay video showcasing it's current state: http://www.youtube.com/watch?v=PwdXsDyQV9o


I am not sure if this requires it's own thread but since it's still related to this project I figured I bring it up here but I've been looking into data compression and I haven't found much documentation on the bios routines such as swiDecompressLZSSVram, etc. Is there any existing library written in C that performs either LZSS or Huffman compression to use in libnds?

[WinterMute]

gbalzss and grit will both produce lzss compressed data, they're included with devkitARM. Source is in the devkitPro git repositories (gbatools for gbalzss & grit for grit)

[Kaiser]

Hey, it's been a while but I want to say that Doom64 DS is done and I've been having some people do some play testing on their own DS. However this one 3DS user is getting constant crashes while normal DS/DS Lite users are not. When the exception screen comes up, it's referring to memory addresses within the 0x90**** range on his 3DS. Unfortunately there is no way for me to debug this since my DS' memory is all within the 0x20**** range. Does anyone know a workaround for this so I can pinpoint what's causing the crash on his 3DS?