Doom for Nintendo 64

No worries, it is a common mistake.

 

I've picked up working on this again. I am implementing "network" multiplayer using the USB port on the 64Drive to communicate with a network bridge based on ZeroMQ. I'm working out the communication protocol now and have stubbed out the USB send/recv in the 64Doom codebase. If the Everdrive 64 allows programmer access to send and receive data over USB, I should be able to implement it for that cart as well, and it would be compatible with the 64Drive version out-of-the-box seamlessly due to the PC bridge interface being identical for any platform that can send and receive arbitrary buffers of data over an arbitrary comms interface to a PC. More soon.

 

Wow! Does it mean PC player VS N64 players?

 

Not in a way that will be enjoyable. In order to get functioning multiplayer working in 64Doom I had to hack it into the original iD GPL-release Linux Doom code. To get that playable I did a bunch of code hacks to make it build in Cygwin. To test it, you have to run Windows in 256-color mode to force Cygwin/X server to run in 8-bit color mode and the color palette doesn't work correctly so it looks stupidly ugly as in the attached screenshot above. Also there is no sound.

I needed to get it working on the PC side as quickly as possible for development and testing purposes, so those issues will never be resolved.

 

However, my networking protocol is simple and based on open-source technologies so it wouldn't be impossible for someone to implement it on a better port's codebase as long as it isn't one that breaks compatibility with the last official version (1.10?).

I'm really only interested in the 64Drive-to-64Drive use case personally anyway to stsrt. If I get that working and can get some sample USB comms code for the Everdrive64 I will implement it for that platform as well so that at least people with those USB-capable carts can play together.

All of my source is open and available due to working on a GPL2 code base anyway so anyone is free to take it and make it do more things in the future.

 

I got bored so I did this.

 

Note: This is never going to be a real project with a release. I needed something to refocus my energy because the 64Doom networking stuff was going nowhere. I ported Genesis emulator code I wrote for Dreamcast in 2002 to see if it works. Sprites don't and it runs at seconds per frame. Just a late night boredom diversion.

 

USB multiplayer went nowhere.

However, I pulled together much faster (5x) versions of memcpy and memset that made a huge performance improvement. Game play in low detail mode is faster than any pre-Xbox home console port at this point, rivals playing Doom on a Pentium computer now. Working on releasing a new binary after I fix the broken controller pak save game code.

 

Very nice.

 

Just grabbed a fresh-from-Github copy of g_game.c, re-writing the entire save game stack.

Again.

 

New release is available at Github now. Only updated the ROM Builder and 64DOOM_README.TXT files. Source will follow in the next couple of weeks.

https://github.com/jnmartin84/64doom/blob/master/64DOOM_BUILDER.zip?raw=true

 

Save games are still iffy, sometimes an exception is thrown when you save a game and then later try to load a game (you'll know if this happens because you'll see a blue screen with white text of a full register dump). If that happens, reset the console and try loading it again. Something about the way save and load interact, some memory is getting corrupted and I haven't finished tracking down the issue yet.

 

Hey Borman how's it going

 

Very well I dont have my 64 out right now, otherwise Id be making a video for you hah

 

Good to hear dude

 

Just got to the point where my new computer is up and running and I am building the N64 cross-compiler toolchain with libdragon's "build" script. Here we go!

 

I'm currently working on a PSX Doom style hardware renderer utilizing the RDP.

I've intercepted the Doom rendering core (R_DrawColumn / R_DrawSpan) and will use the information provided through their setup to hardware render with the RDP a textured quad for each column and span to be drawn. These quads are all 1 pixel by N pixels in dimension (N wide for spans, N tall for columns).

My first test to make sure I had hooked in the correct places software-rendered a solid colored line onto the screen using the first color of the pixel for all columns and spans. I've attached three pictures. The first two are taken from MESS. The first was columns only, the second both.

The third is cell phone camera snap of it running colums and spans on a real N64 on my TV.


I am now working to implement RDP rendered solid colored quads per column / span to mimic the software rendered examples above. I will then add textures into the mix.

 

Software-textured quads for columns and spans.

Do not have scaling accounted for in the columns yet. Getting completely wrong texels in the span textures currently and also not scaling it properly.