I've never had any problems running this on my everdrive. I bought it around 2 years ago, but it's a v2 and has the latest OS installed (2.04). What board version is yours? What OS version are you running?
v2 with 2.04 OS. Using a MicroSDHC 16gb. My N64 motherboard is NUS-CPU-09 which I wouldn't assume that would be a problem, but its possible. I have a NUS-CPU-04 N64 I'll pull out later and try it on that.
Sorry guys, I haven't had time to work on this, spun up on a big new project at work and have been keeping busy outside of the office as well. I personally noticed that the game locked up fairly often when running it through emulation and assumed it probably had the same problems on real hardware. Looks like mixed results from those of you that have tested it? I never finished instrumenting the code-base to figure out where it hangs, but that was something I was working on the last time I hacked on it. Last thing I attempted was to get the sound code going, but it would de-reference null pointers and hang. Hence the instrumentation work. If anyone has any suggestions for debugging (being able to set breakpoints/single-step code) with an emulator, I'm all ears.
I am going to bundle up the source code and build files so that anyone else who may want to work on this can go ahead and do so.
Please find attached the latest source code I have. I cleaned up all the compiler warnings and made sure it still builds and runs. You will need to provide shareware data files to make a running V64/rom image though (they should be placed under the "filesystem" directory; the files located in there are zero byte placeholders). Enjoy. View attachment 10727
So I think I over-flowed a very big number into a very negative number due to a signed-vs-unsigned error in get_TimeCount and that caused a conditional in CalcTics to never be met, which is what causes the game to freeze up after a certain amount of time. Testing a fix.
I made a few changes in the tic computation and now it will run through attract/demo mode for hours without hanging up. It used to run for about 3 or 4 minutes and hang up in the same spot every time.
Is it possible to modify the source code so that it takes the sprites in 128x128 instead of 64x64? If so we could use the Jaguar/3DO/Mac sprites. Here is an example: http://www.spriters-resource.com/other_systems/wolfenstein3djaguar/sheet/55864/ Here is also the source to the Mac Version of Wolfenstein 3D: https://github.com/Blzut3/Wolf3D-Mac
I wouldn't know. I just did a port of a port of a port... the code started out as the original Wolf source, then was ported to Linux/SDL, then I ported it to Dreamcast a few years back, then I used that Dreamcast port as the basis of my N64 port. If it is an easy change to the original source, and someone can present me with a simple patch to do it, then so be it. Otherwise, it is unlikely I will be doing it. I am still working on getting sound working, then saving/loading game progress.
I still had the conversion from n64 ticks to wolf3d ticks wrong. I now have them right. Feels a bit slower when I play in MESS now but the enemies move at normal speed instead of instantly. Still debugging sound and random crash issue.
I have adlib "sound effects" working although they sound bad right now. Digital sound isn't working due to some "invalid page request" bug I keep running up against. Apparently my old DC port had the same problem. Don't know if I broke the code in the past.
So I noticed in the work I've been doing on my Doom port in the last few days that the memcpy/memmove implementations that came with the compiler/newlib whatever that I have been using to build my code and libdragon weren't really working right in all situations. I don't know if it was memory alignment issues or whatever. I used my replacements in a rebuild of the wolf port and I heard more adlib stuff (music maybe?). It sounds really bad, like the wrong pitch, but it is working a little better. Might have music working soon hopefully. Still looking into the work needed to do save games properly. Need to compress save states after writing them to a buffer/decompress after reading them.