64Doom: Classic Doom on N64

Well, I had no idea this even existed...

Weird. Very weird.

But I can dig it. More info in the video description, I guess. Or here: http://www.assemblergames.com/forums/showthread.php?52471-Doom-for-Nintendo-64

64Doom on GitHub can be found at:
https://github.com/jnmartin84/64doom

It's just a homebrew port of the original source code release. What's so surprising about this?

I always thought it would have been a good idea to have Ultimate Doom on the N64, back in the day I mean. From a practical point of view, this doesn't serve much purpose, but just as a fun project, this is awesome. Hope he gets further with it, and customizable controls like in Doom64 are a must!

The other day, I was playing Doom with a N64 controller hooked up to my computer. This port gives me another reason to buy an Everdrive64 to play games. (the first reason being GoldenEye X)

I wonder if it's going to be open source. So far it is not.

Quasar said:

I wonder if it's going to be open source. So far it is not.

The author said: I will be releasing source code as soon as I get it more feature complete.

I hope he won't lose it.

How is this possible with the N64's minuscule texture cache?

axdoom1 said:

The author said: I will be releasing source code as soon as I get it more feature complete.

I hope he won't lose it.

Every time I've heard that from a project, that's precisely what happens. If it's not completely lost, then the author loses interest and disappears.

So people have only started work on this recently?
That is weird.

I thought this had been done already.

Ed said:

How is this possible with the N64's minuscule texture cache?

The cache is not used. The software renderer has to get every pixels from the textures that are stored in the RAM to draw them to the screen, which is very slow.

Have the sounds been modified somehow? For some reason everything sounds more beefy and satisfying yet I can't notice any changes in the sounds.

Am I going nuts?

Marnetmar said:

Have the sounds been modified somehow? For some reason everything sounds more beefy and satisfying yet I can't notice any changes in the sounds.

Am I going nuts?

I think, by virtue of them being played back at a lower rate, this is what's making things sound "beefier." Explosions and gunfire will sound bassier, since their "pitch" is shifting down towards the lower ends of the audio spectrum.

I'm the developer of this port.

Just want to clarify that I don't keep the only copy of the code on my desktop.

It is version-ed in a revision control system, and regular backups of that are stored off-site ("the cloud" I guess?).

I am actively working on it.

That video posted is a few weeks out of date.

It runs just about full speed, with the original data files (either Ultimate Doom, Doom 2 or shareware Doom).

The only reason the publicly available builds and videos are all shareware is because it is against the law for me to provide ROM files with the commercial game data files built in.

I am still working out an easy system for end-users to package their own ROM with the game data.

Any more questions, let me know. Now that my account was approved, I will check in from time to time.

I usually post at the following two locations:
http://krikzz.com/forum/index.php?topic=1886.new#new
assemblergames.com/forums/showthread.php?52471-Doom-for-Nintendo-64/

Doom 2 running on Nintendo 64, with full sound, music.

Any of the games supported by the original source code release will work with this port.

Another system, another Doom port. Good stuff. :)

I know there are probably some obvious things stopping it but is there a way that the commercial WADs could be 'injected' in a similar way that hackers use for Wii virtual console titles?

Regardless, good luck with future development. :)

I have a rudimentary toolkit that can take the binary executable file, which is game-agnostic but not in a form that will run on the console yet, and appends the WAD file along with a game identifier tag, producing a V64 file for use with a backup unit/flash cart like the Everdrive64. The only issue with it currently is that it requires a lot of dependencies to be already installed that the average end-user probably wouldn't have. That is one of the issues I am ironing out for when I do an official release. I am still looking for somewhere to host the project at the moment.

Ed said:

How is this possible with the N64's minuscule texture cache?

I am bypassing the dedicated rendering hardware entirely. I use the CPU to lookup the original 8-bit pixels from memory, do a look-up into a color table, then write the pixel directly into the area of memory set in the video registers as the current frame buffer.

It is quick enough that the act of rendering the display to screen doesn't cause the game to run any slower than it does with the display turned off (that is, just running the game logic with no video output).

Hey, I was waiting for your account request to get approved. I wanted to suggest taking a look at the Jaguar Doom source if you've not, as it contains a few console optimizations that you might could adapt if you're still looking to squeeze out more speed.

A simple obvious example is to avoid multiplies where possible (shift by nearest lesser power of two and add in a remainder, for example):

 x*5 == (x << 2 + x)

If your compiler is good (better than the one that came with the consoles' SDKs >_>) it may be doing that for you already, of course.

A more advanced example is having a pre-baked lookup table of sprites and their rotations to lump numbers, instead of scanning the wad directory for them at startup, which makes R_Init take less time. This might be a bit harder to do when supporting multiple IWADs though, as you'd need one such table for each supported IWAD. It'd also screw with mod support if you have any plans for the ability to merge those into image builds.

Still might be some stuff in there though. You might also talk to Kaiser, who reverse engineered Doom 64. While it works completely differently, it might also have a few nice tricks hiding in it that could be applicable.

jnmartin84 said:

The only reason the publicly available builds and videos are all shareware is because it is against the law for me to provide ROM files with the commercial game data files built in.

Actually, to be on the safe side, not even the shareware IWAD should be distributed outside its original installation form (aka two floppies, DOS installer and all, or the Doom95 installer). At least I ceased distributing it with my port quite early, due to concerns.

Quasar said:

If your compiler is good (better than the one that came with the consoles' SDKs >_>) it may be doing that for you already, of course.

It would be best to explicitly check if it already is doing this before resorting to such microoptimisations that obscure the code.

Maes said:

Actually, to be on the safe side, not even the shareware IWAD should be distributed outside its original installation form (aka two floppies, DOS installer and all, or the Doom95 installer). At least I ceased distributing it with my port quite early, due to concerns.

Good to know... I had a sneaking suspicion that was probably true.

I will have to accelerate the timeline on that "doom builder" toolkit I mentioned in a previous post.

fraggle said:

It would be best to explicitly check if it already is doing this before resorting to such microoptimisations that obscure the code.

For one specific example, GCC is already changing power-of-2 mults and divs into bit-shifts for MIPS (d = t*128 becomes sll $d, $t, 7). I've looked at the assembly output.

Quasar said:

A more advanced example is having a pre-baked lookup table of sprites and their rotations to lump numbers, instead of scanning the wad directory for them at startup, which makes R_Init take less time. This might be a bit harder to do when supporting multiple IWADs though, as you'd need one such table for each supported IWAD. It'd also screw with mod support if you have any plans for the ability to merge those into image builds.

Honestly, processing time at startup is negligible to nonexistent. R_init is basically instantaneous. You can see in the video how long it takes from the entry point of the code on the cart until the game starts drawing, its under a few seconds.

jnmartin84 said:

Honestly, processing time at startup is negligible to nonexistent. R_init is basically instantaneous. You can see in the video how long it takes from the entry point of the code on the cart until the game starts drawing, its under a few seconds.

Cool. No need for gross hacks then.

Interesting. Though I am curious to see how the resources where managed on the N64 hardware...

Kaiser said:

Interesting. Though I am curious to see how the resources where managed on the N64 hardware...

If you have a more specific question/questions, let me know and I will be happy to provide details.

See: http://krikzz.com/forum/index.php?topic=1886.msg20328#msg20328
and: http://krikzz.com/forum/index.php?topic=1886.msg20329#msg20329

I have been busy at work on this over the last few weeks.

Game speed is better than before, sound and music work well, no save game support yet though.

http://www.mediafire.com/download/5z7dqkl4jdd6pcy/BUILD_YOUR_OWN_64DOOM.zip

This has a shell script and dependencies for running on Windows. All you have to do is run the script/bat file, enter the number of the game you want to build a ROM for, and it does all of the work. No editing files manually.

Have you thought about coming up with a distinct name for your port? Might make it more memorable and easier to find. I wanted to ask before we create a wiki article on doomwiki.org ;)

Ultra Doom Engine? Nintendoom 64?

This is awesome, great work!