Atari Jaguar vs the Nintendo 64

[JagChris]

I have not run across a version of final Doom in good condition with long box for $10. Wow. For the PSX I'd grab it for my cousin.

[JagChris]

He said the PSX had better horizontal rez which I agree with. Better lighting I disagree with in a big way.

 

Then I pointed out some of its pluses.

But yes the PSX version is very good. And I LOVE the ambient music to it. Way better than the original. Those babies wailing off somewhere in the background... eeriiiee...

 

 

I certainly don't mean to diss the Jag version of DOOM, because it's really quite good. But the PSX version is **EXCELLENT** and very fast, smooth, and with great lighting. I have no recollection of "scaling and animation chunking up." I have the Sega Saturn and 32X and those versions are remarkably-inferior to the PSX version, just as a matter of comparison. It's fine to prefer the Jag version, as it it's fine to prefer any other version. But there's no need to crap on the PSX version, as it's really quite excellent, the controls are excellent, and there's also the "Final DOOM" variant released later. Both can be had for probably $10, and a PSX can be had for $10. For $30, you can get a PSX, DOOM, and Final DOOM, and it's all quite well-done to the impartial observer.

[+wood_jl]

I also like the Jag version of Wolfenstein 3D, and I'm having trouble remembering if it ever came out for any other consoles, at all.

[OldSchoolRetroGamer]

I also like the Jag version of Wolfenstein 3D, and I'm having trouble remembering if it ever came out for any other consoles, at all.

 

MS-DOS, Mac OS, Amiga 1200, AmigaOS 4, Apple IIGS, Acorn Archimedes, NEC PC-9801, SNES, Jaguar, GBA, 3DO, Windows Mobile, iOS, PlayStation 3, Xbox 360

 

According to the Wiki anyways...........

[Andromeda Stardust]

I also like the Jag version of Wolfenstein 3D, and I'm having trouble remembering if it ever came out for any other consoles, at all.

Yes, it did. Here's the definitive SNES remake:

http://www.joystiq.com/2014/01/13/christian-themed-shooter-super-noahs-ark-3d-returns-to-snes/

Edited January 16, 2014 by stardust4ever

[atarian63]

MS-DOS, Mac OS, Amiga 1200, AmigaOS 4, Apple IIGS, Acorn Archimedes, NEC PC-9801, SNES, Jaguar, GBA, 3DO, Windows Mobile, iOS, PlayStation 3, Xbox 360

 

According to the Wiki anyways...........

Also Atari ST

[Chilly Willy]

Thanks for the write up. I would love to see what N64 homebrew could do, but so far there are zero homebrew games worth playing that I know of (if someone knows of any N64 'brews, please send me a link if that's allowed), and until a few years ago (2005-2006) N64 hacking was non-existent. Toad's tool 64 allows for making custom Mario 64 hacks, and several enterprising hackers have gone the extra mile to create new levels with new geometries as well. Ditto for Mario Kart 64. The problem is the hacks require expanding the M64 ROMs from 8 to 24 megabytes, and even those expanded ROMs do not work on real hardware, so 99% of Mario 64 hacks won't run on an Everdrive or real hardware, at all. Lastly, N64 used a serial ROM interface which would require an FPGA or custom microcontroller interface to produce Repros, since EPROMs and flash chips simply don't exist with the proper interface to work with original PCBs. Henceforth you would almost need an Everdrive 64 or something just as expensive simply to do a one off reproduction. Compound that with a lockout chip that hasn't been cracked yet (to my knowledge), and you still need a donor cart if for nothing else than a lockout chip. Combine that with the smallish library, few or no homebrews, hacks, or repros that run on real hardware, and I have little use for an Everdrive 64, yet...

 

That said, I would love to see N64 homebrews produced someday. It can't be half as convoluted to program for as the Jag platform, and despite being an inferior and less powerful system, the Jag has tons of homebrew available for it. Why not N64?

 

I believe the nostalgia train for N64 hasn't quite hit yet. The games were quite pricey when I started collecting in 2003ish, but they since have gone down, and only the highly desirable titles (1st party and RARE) are going back up. NES and SNES are hugely popular, but many modern gamers still consider the N64 to be blurry and gut-wrenching (5th gen is in a similar position currently to 2nd gen, in other words the 3D is a little too primitive for some folks much like 2nd gen 2D with Atari, etc). If someone could create a viable HDMI N64 clone, the upscaled graphics can be gorgeous even if a little blocky.

 

Yes, the N64 cart bus is a bit "messy" to deal with. There are now a few different flash carts for the N64, and the games that didn't work with the common CIC chips in those carts now have patches that remove the protection. The Everdrive64 is a fine cart for the N64, being fast, inexpensive, and handling 99% of games without patching. You need to patch those games that use the oddball CIC chips, but the patch is built into the menu now, making it easy to play the games.

 

The main home brew you see for the N64 are demos - people showing off lots of tricks and such. Those were all done with the Nintendo devkit. A lot of hacks (like for Mario 64) don't work on real hardware - it's pretty much like a lot of old hacks for the Genesis: the people doing the hacks test them on emulators rather than real hardware. With the advent of good CHEAP flash carts for the N64, I hope some of the folks working on N64 hacks get one and fix the issues with their hack. Again, like on the Genesis, the primary issue is having data on odd addresses. The MIPS requires you to use special instructions to access data on odd addresses (if not accessing as individual bytes).

 

I have been helping work on making libdragon better. That's a nice SDK for the N64 that uses no Nintendo code, and works on real hardware. It's a bit low-level for most N64 emulators. You can run libdragon based home brew using MESS. I made a music player called SMP, and did a port of Yeti3D Pro. I'll be doing some other stuff when I get some time. I'm working on something for the 32X at the moment.

[+Gemintronic]

Can you point me to the best links for a N64 C compiler and your libraries Chilly Willy?

[Andromeda Stardust]

Chilly, glad to see someone working on it. I would love to see something done for N64. Even if cart homebrews are unfeasible, I would still love to see something released for Everdrive owners. SNES and Genesis homebrews are finally catching up to the 8-bit scene, and I can only hope the N64 will follow. It really is a powerhouse and some new 2D brews would be really cool.

[Chilly Willy]

Can you point me to the best links for a N64 C compiler and your libraries Chilly Willy?

 

Hmm - seems most of my latest N64 stuff was on fileden... which is gone now. I'll have to repost some of that on my MediaFire account.

 

Anywho, here's the homepage for libdragon: http://www.dragonminded.com/n64dev/

 

I'll try to put together some updated arcs for my N64 stuff. You can find my thread on the Yeti3D Pro port here: http://www.neoflash.com/forum/index.php/topic,7454.0.html

 

That archive IS on mediafire, so you can get it. I was also able to compile scummvm for the N64, but the existing port is a little old. Working on an update with the latest scummvm code is on my TODO list.

[Rick Dangerous]

Chilly, glad to see someone working on it. I would love to see something done for N64. Even if cart homebrews are unfeasible, I would still love to see something released for Everdrive owners. SNES and Genesis homebrews are finally catching up to the 8-bit scene, and I can only hope the N64 will follow. It really is a powerhouse and some new 2D brews would be really cool.

 

How cool would a homebrew cart for the N64 be? I'm guessing the reason the homebrew scene isn't better for Nintendo is because the company is still around and people are worried about legal hassles? I have seen a few, like a Zelda remake for the NES, but not nearly as strong as the ATARI scene.

 

 

In response to the original click bait question lol.... The N64 is more powerful with many more good games, but I will say the Jag has a lot going for it to set it apart from the N64 right now:

 

1. Different library than the N64, well worth experiencing.

2. CD Unit, ability to play burned homebrews, and VLM for audio CD's

3. Robust Homebrew community producing awesome stuff; the Jaguar lives!!

[Thorsten Günther]

Computer Spele Museum in Berlin lets you play a whole bunch of games, even a Computer Space! on Mondays (",)

 

No Jaguars were hooked up when I was there though...

 

Yep, I like that museum. IIRC monday afternoon is "play the exhibits" time there, I suppose they lack the necessary personnel to supervise it during the rest of the week. Another retro gaming opportunity in Germany is the Kieler Museumsnacht once a year (last time, I exhibited an SMS w/ 3D glasses and Light Phazer and an Interton VC4000 there).

 

The Museum I strongly dislike for having all their exhibits sitting dead on their tables is the upper level of the computer museum in Kiel (agreed, this mainly focuses on Zuse and other mainframes from the 50s to 70s, but the upper level is reserved for home computers etc.).

[Andromeda Stardust]

 

How cool would a homebrew cart for the N64 be?

 

I'm guessing the reason the homebrew scene isn't better for Nintendo is because the company is still around and people are worried about legal hassles?

1) One word Answer: Awesome!

 

2) Doesn't matter since Nintendo isn't actively marketing the system anymore. As long as the homebrew doesn't recycle game code or IP, it's fair game. People have long been making homebrews for GBA and DS, so N64 is long overdue.

[+Gemintronic]

I think Chilly Willy explained the development situation with the N64. My take from his words is that developers were discouraged from using anything but Nintendos APIs. Homebrewers can't use Nintendos toolchain and still be legal.

[Chilly Willy]

I think Chilly Willy explained the development situation with the N64. My take from his words is that developers were discouraged from using anything but Nintendos APIs. Homebrewers can't use Nintendos toolchain and still be legal.

 

Nintendo tends to ignore most demos. Most people can't run them, and they really aren't a game. If you made a game using the Nintendo SDK that you tried to sell, then they'd probably call in the lawyers.

 

There are a number of flash carts for the N64 now, so homebrew can be done. Now it's a matter of getting rid of the Nintendo SDK. ScummVM for the N64 doesn't use it, for example, so there's really nothing Nintendo can say about it.

[Andromeda Stardust]

And unless you're making a 2D game engine using nothing but scaled bitmaps, you'll have to model your own 3D character animations. I can't imagine that would be feasible for a one man "team".

Edited February 22, 2014 by stardust4ever

[VladR]

And unless you're making a 2D game engine using nothing but scaled bitmaps, you'll have to model your own 3D character animations. I can't imagine that would be feasible for a one man "team".

It is year 2014. There were plenty free low-poly meshes on the internet 8-10 yrs ago. Now, there's way more.

Same goes for textures and animations. He doesn't really need a dedicated artist - although it would certainly help him to reduce the workload.

 

So, it's not only feasible, it's actually not a problem at all. Few weekends is all that is needed to find, import, adjust the character meshes you can search for.

[Andromeda Stardust]

It is year 2014. There were plenty free low-poly meshes on the internet 8-10 yrs ago. Now, there's way more.

Same goes for textures and animations. He doesn't really need a dedicated artist - although it would certainly help him to reduce the workload.

 

So, it's not only feasible, it's actually not a problem at all. Few weekends is all that is needed to find, import, adjust the character meshes you can search for.

And what modelling software allows to to "export" 3ds or wavefont objects into whatever native object format n64 uses? Then add said objects into your workflow? Someone will need to create a compiler first. How does the system handle character animations and morph targets?

 

Basically 2D homebrew will have to be created first, before people figure out how to import meshes. Then you created "demos" with solid objects floating in space. Build up a scene. Then figure out collision detection. Then make it do something "fun". Not to mention even the most basic PD character models are likely too detailed for N64, and will need to be simplified using a modeing software of some type.

Edited February 22, 2014 by stardust4ever

[108 Stars]

To be honest, my guess is that the N64 just fell by the wayside due to both popularity and the difficulty in developing for it. For one, I don't see the N64 having a die-hard fanbase. It marked Nintendo's fall from grace during its original lifespan, and even today people seem to care more about systems like the NES, SNES or the post-2000 handhelds. It's one of Nintendo's least popular systems. Of course the PS1 and PS2 don't have a lot going on either, despite them being much more successful. So it can't be only that.

 

Another point is that homebrewers want their work to be seen. With the few really dedicated N64-fans who would care for hommebrews and shell out cash for a flashcart, it may just seem much more rewarding to do homebrews for other devices. The PSP, DS and 3DS can easily play homebrew and have a much bigger user base. You can do stuff on the same scale or better than on N64 for those, and millions are able to actually play.

 

And lastly, and this imo is the key difference to any Atari system: Atari is dead. And it has been dead for almost two decades now. People have gotten used to doing stuff themselves if they want to play on their Ataris. And adding to that is that many Atarians were also hobby coders since the company had a rich history in home computers. So there is both a bigger pool of fans who can at least program to some degree, and the habit of relying on homebrew is old because there hasn't been official support since 1996. Coding the N64 is not easy and not very attractive.

Edited February 22, 2014 by 108 Stars

[82-T/A]

 

MS-DOS, Mac OS, Amiga 1200, AmigaOS 4, Apple IIGS, Acorn Archimedes, NEC PC-9801, SNES, Jaguar, GBA, 3DO, Windows Mobile, iOS, PlayStation 3, Xbox 360

 

According to the Wiki anyways...........

 

 

Damn... Apple 2GS? I can only imagine how bad it must have been. The PC one was the defacto, and probably one of the best, but the one for the Jaguar is definitely the best... side by side comparisons show they definitely put some effort into it.

[Bill Loguidice]

 

Damn... Apple 2GS? I can only imagine how bad it must have been. The PC one was the defacto, and probably one of the best, but the one for the Jaguar is definitely the best... side by side comparisons show they definitely put some effort into it.

 

The IIGS version is actually quite good and far from the worst version, though it does need an accelerator to run at a decent window size. The Jaguar version is definitely my favorite, though, because it improves the visuals without being gaudy or breaking any of the gameplay, something many updates/ports fail to do.

[Osgeld]

pc gets credit for being the defacto version but really when it came out think of what systems people used, 286 bare bones VGA and no sound for the most part, taken for what it was at the time not its ability to use a then few thousand dollar PC it was a pretty meh game except for OMG 3DSSS

 

ran on average for the time hardware its one of the worst versions that you could play, 5 years later when Playsation was starting to form and a MPC 486 was starting to become the norm, its still average for the game.

[VladR]

And what modelling software allows to to "export" 3ds or wavefont objects into whatever native object format n64 uses?

Oh my god. If you, as a programmer, are so incompetent, as to be unable to write a simple function to convert one binary/ascii format into another format, then don't even bother with coding an entire 3d game !

 

When I was starting doing 3d engine coding, over a decade ago, it took me maybe a day, since I was also switching to C++ at that time. Now, it's rarely question of more than 2 hrs. You spend more time reading the docs on the format description and testing than actually coding it !

Just think about it - how many elements do you need for your 3d character data ?

Vertices, UVs, Normals, Indices - that's all.

 

 

Then add said objects into your workflow?

Uhm, you just load the character animation into your own PC-based loader. You don't have one for testing ? Are you seriously implying you want to see the first/latest revision of the character mesh only after deploying it to the target HW ?

Yeah, with that kind of approach, you're not getting anywhere in next decade, that's for sure...

 

Your artist needs to have at least a simple loader from you (both for props and characters), so he can see he is exporting the mesh properly, with all elements, that the normals are not inverted, that the texture is OK and that the scale suddenly didn't change in the middle of animation and about 10 other things.

The loader takes about a half day to write. It's paid off after you import about 10 objects. Yes, 10 objects is nothing in a 3d game.

 

How does the system handle character animations and morph targets?

Well, you code one ! That's what your tools / loaders are for, aren't they ? A simple tweening animation between 2 frames is brutally simple to code - you calculate a percentage based on time elapsed from last frame and just lerp between the vertices/normals. That's hardly a day's worth of work for first time. But that's just the start.

 

Now, the whole animation component, supporting multiple animations of same type (e.g. idle / attack), different timings and blending between different animations, that is going to take quite a bit more work and that is fine. Tying it to AI and input is also going to take some time to debug and test it.

 

 

But yeah, it's perfectly doable for a single individual with a proper motivation.

 

Now, I haven't seen N64's SDK, so I do not know what it supports right out of the box. Rendering a triangle list (and playing a sound - since audio components are just too boring to code from scratch) is all you need from it, really (and even those are relatively easy to whip up in ASM, if needed). I presume there is a C/C++ compiler ?

 

 

 

If I was about to start developing a 3D engine for N64, I would just do it on PC first (say, with OpenGL), limit the framerate artificially to, say, 60 fps, and then [when things run stable] just replace the rendering calls with something N64-specific.

 

There's just too much work involved in real-time debugging of the higher-level components that you simply do not want to do via on-screen debug display on target HW or 'guessing'. You do need to be able to hit a breakpoint and see what is really going on.

 

Unless the deployment takes under 5 seconds **AND** the dev environment allows you to hit a breakpoint in some IDE, I'd seriously entertain the idea of a PC-first development (you'd be easily an order of magnitude more productive, at least) and only when things run stable, without crashing (lots of pointers), then start implementing the N64-specific audio-input-render-paths (via a simple #define in your project) ...

[sh3-rg]

 

totally the same, sure.

[VladR]

totally the same, sure.

And your experience with writing multiplatform 3D engines from scratch is what exactly ?

 

I'm asking, since my previous game had a single source code that was deployable into 3 different HW SKUs (selectable via a simple switch) and they all had their own separate input/audio/video paths, using 3 different control methods, the UI/3d scene scaled across 3 different aspect ratios and visuals had to scale too from non-shader through basic shaders into uber-shader techniques.

 

Performance differential between the HW platforms was roughly 2 orders of magnitude.

 

Yet it all worked from a single codebase. If I wanted, I could spend about a week, and get it running (and scaling properly) on 5 additional HW platforms, but that's not really important for me right now.

 

So, I think I have a bit of experience to relate to it.

 

 

So, please explain to me, how is not developing it first on PC a more sane and productive solution. I see it on many other retro boards and other platforms. People start coding something, but it takes ages since the deployment is way slower and usually there's no devkit, thus there is no direct debugging. Of course, they loose motivation, since it's clearly not getting anywhere with only so many deployments feasible in given timeframe.

 

 

Please, brother - resist the oh-so-funny pictures and write something substantial. I know you can, if you want.