Doom for Nintendo 64

Tonight, we have digital sound. Only issue is that it is choppy, and I do not know if that is an emulation artifact or a problem with the way I am handling the output.

 

the sound is choppy on real hardware, too ^^
and the startup is very slow

edit: the game itself is slow as hell, too. much slower than in Bormans last video.
edit2: it seems like there is a sound update function triggered in the same loop as the controller inputs, maybe it's not threaded at all? i can "feel" how the skull before jumping in the menu is waiting for the sound to finish more or less.

did you know, that you have to do at least a minimal sleep on real hardware between reading the controller inputs? :> sleep(10)

 

Undocumented feature: press the L and R triggers simultaneously and the internal clock tic rate will change and the game will get faster.

There are no threads in the sense of multi-threading. libdragon doesn't provide them. I am still in the process of writing my own lightweight thread support to hopefully fix the sound.

The slowness at startup, I'm not sure if something libdragon's DFS does is just really inefficient for lots of small reads/seeks in a file, or if ROM is really that slow after all. The data file in the game is only ~4 megabytes so it would have to be floppy disk slow to explain how long it takes to load. Even in MESS it takes about 2 to 4 minutes to load everything from the wad.

There is a sleep happening after each screen refresh.

 

A non-blocking audio ring buffer implementation that replaces libdragon's AI queue / Conle

http://code.google.com/p/gnuboy64/source/browse/trunk/pcm_ring_buf.c

 

Thanks. One issue with the sound was Doom uses a buffer length of 512 samples unmodified, and libdragon was giving me a 440 sample buffer... I didn't want to do too much work because I only had an hour or two to tinker last night.

 

So I thought I was doing a sleep on each iteration of the game loop. I think that was a false statement. I have a function for doing it, but it wasn't being called. I will have to update that and see how results change. I need to hurry up and get an everdrive64 (or whatever the good, popular flash cart is)... :/

 

Hello,
Thanks for your work!
Maybe you should update the original post and copy/paste videos link, controlls button and shareware links.
You can also provide a paypal adress, I'm sure that a lot of people are willing to send you a few bucks to buy an Everdrive.
Regards.

 

You make a good point about re-organizing this thread. Gonna try and work on that now.

Thanks.

 

I updated the first post in the thread to have up to date info on where to get the latest v64 build, the controller mapping, some video clips, and a list of bugs/issues.

 

If anyone reading this thread has experience or knowledge with the code of Doom engine and any of the various source ports, I am trying to figure out how the older software-rendered ports rendered the game at higher resolution (640x480 and higher) without just scaling the screen up. If you know anything about it, please let me know.

 

Got any examples for how to use this? I'm going to look around the source code repo its a part of, but any pointers are welcome.

Also I checked out a copy of the project from svn to poke around.

 

So, I knew my port ran like crap but I didn't realize just how bad it was. Just fired up Ultimate Doom in DOSBox and now my port looks like the SNES version in comparison.

 

Awesome work. Good to see DOOM is still getting the love it deserves.

 

First off, thanks for making it, I love projects like this and enjoy trying them on real hardware.

Next, I suppose its too late to ask if it's possible to find a MIPS source-port of Doom for reference or if Doom64 itself can help any?

 

Honestly the Jaguar Doom code is probably the most helpful for trying to figure out how to get it running well on a resource constrained platform.

 

I've been following this thread since I found it on krikzz.com support forums, and I registered here just to say that I'm super excited to see this progress! I tried out the first shareware version you posted earlier in the week, and it was like watching history in the making! Thank you for your work!

 

Got a link to that thread?

 

http://krikzz.com/forum/index.php?topic=1886.0

 

Thanks. I should register and post over there later after work.

 

Doom uses raycasting for the rendering. The original game code did a loop over the columns from 0 to 319. As a ray was cast and intersected a segment, the height of the segment was calculated using the distance, and scaled to make it fit a 200 (or later 240) tall display. For high resolution, they merely changed the raycasting to be from 0 to however wide the screen is, with the sin/cos table being divided more finely to allow for more rays per screen. Then the height is scaled for whatever the screen height is rather than 200. Very simple, and gives a nice result. Software rendered raycasters use point-sample scaling - some pixels are skipped to make things smaller, and some are repeated to make things bigger. OpenGL versions work quite a bit differently.

As to dragonfs speed, the rom filesystem uses memcpy to move the data from the rom to ram. It's not really a great filesystem as far as speed goes. If you look into the source, it uses 256 byte "sectors" with one long from each sector used as a singly linked list of sectors for the file, and the other 252 bytes holding data. That blows as the most you can load at a time is 252 bytes, and any seeking requires it to go through the entire linked list of sectors every time. That's probably why it's so slow - the seeking is making it take forever.

What I'd do if I were you is pad the executable to a set length, then append the WAD file directly. Inside the game, use the DMA to read the data. You know where the WAD file is in the cart, then add the offset you need inside the wad file. That would be blazingly fast. If you have other files besides the wad file and they don't matter so much for speed (like maybe GUS instruments for the music), you might use dfs just for those, and again append the wad file to the end and DON'T use dfs for the wad file.

I've worked on Doom on quite a few platforms (Amiga, AROS, Linux/SDL, PSP, Dreamcast), so don't hesitate to ask if you need some help.