64Doom: Classic Doom on N64

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

Share this post


Link to post

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!

Share this post


Link to post

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)

Share this post


Link to post

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

Share this post


Link to post
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.

Share this post


Link to post

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

Share this post


Link to post
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.

Share this post


Link to post

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

I thought this had been done already.

Share this post


Link to post
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.

Share this post


Link to post

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?

Share this post


Link to post
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.

Share this post


Link to post

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/

Share this post


Link to post



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.

Share this post


Link to post

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. :)

Share this post


Link to post

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.

Share this post


Link to post
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).

Share this post


Link to post

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.

Share this post


Link to post
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.

Share this post


Link to post
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.

Share this post


Link to post
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.

Share this post


Link to 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.

Share this post


Link to post
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.

Share this post


Link to post
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.

Share this post


Link to post

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

Share this post


Link to post

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.

Share this post


Link to post

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 ;)

Share this post


Link to post

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!


Register a new account

Sign in

Already have an account? Sign in here.


Sign In Now