What N64 could Jaguar have handled?

[Ite]

I was playing WCW/nwo World Tour and the grafix in that weren't very impressive at all lol. I wonder how close Jag could have come to replicating that.

 

Any other games you can think of the top of your head Jag could have handled?

[Atari_Owl]

I was playing WCW/nwo World Tour and the grafix in that weren't very impressive at all lol. I wonder how close Jag could have come to replicating that.

 

Any other games you can think of the top of your head Jag could have handled?

 

Phear

[Gregory DG]

Doom.

[promethea]

Dodonpachi

[+Sauron]

Superman?

 

[ovalbugmann]

007

[walter_J64bit]

Namco Museum "Atari Classics"

[Gorf]

Depending on what you were willing to sacrifice probably a bunch of the N64 games with

much lower poly counts and less detail but all the game logic and action should be of no

concern. There would be a lot of G-shading used as much as possible. but there would

also be textures. And you'd be runing a frame or two slower. but playable. The Jag is

not a susper strong poly pusher like the N64 is. It can push em but not as many but

the rest of the ame will be no problem.....thre will be some title that would be tough

on the Jaguar, but most would be doable with sacrifices.

[kool kitty89]

007

 

Which one?

(there's the best selling Goldeneye, and The World is Not Enough, which I actually find superior for multiplayer)

 

 

As for the original question, it really depends on what you mean, if you mean a letter perfect N64 game on the Jag, probably not. If you mean an equivelent game, or port that plays to the Jag's strengths, possibly. (ie maximum use of gouraud shaded polygons, mimal textures, 2D objects suplementing 3D, etc) It would also depend on what you mean on the Jag's part, like if you're using the 68k, or programming in assembly with the J-RISCs (mainly GPU, though I think some things might be advantageous to handel with the DSP, maybe 3D calculations), optimizing and working around the bugs. Or also if you're including the Jag CD or not. (or if you're allowing cartidges past 6 MB)

 

I think some games that the Jag could do at least as well as the N64 (not sure sound wise) ould be the Hand full of 2D titles, like Yoshi Story or the couple Rampage games. (can't think of any others off the top of my head) Though the ROM size issue comes into play again, but that has more to do with cost than anything else, I don't think bank switching would really be too much of an issue, using the Jag CD might fix things too, though then you get into other things like RAM limitations. (Yoshi Story was a 128 Mbit/16 MB game)

 

 

Then there's some pretty impressive (at very least visualy) games like those by Factor 5+Lucas Arts (Rogue Squadron, Battle For Naboo, Indiana Jones, granted the former 2 require the RAM expansion pak to trule demonstrate this), but these really pushed the hardware and Factor 5 wrote their own custom microcode to accomplish this, quite a feat considering this was a feature that Nintendo didn't support for some stupid reason meaning most developers were stuck with the restrictive standard microcode. (I think some of RARE's games featured something like this too)

Of course BattleSphere is often sites as something most contemporary systems couldn't do because of the complex AI. (I'm not entirely sure on the specifics, but I'd certainly beleive the networking feature's increasing AI intelegence would trump what comtemporaries could do, even with Saturn's Dual processors, or the N64's being more than 3x as fast -at least clock wise)

 

Then there's some games that use/require the 4 MB expansion PAK (8 MB total), but most if not all of those are the ones that are pushing the hardware and well above average development work. (the kind of thing the Jag would have only gotten had it been popular and lasted longer, with the exception of BattleSphere, and maybe a couple others -thoguh I don't know if any other than BS was done all in assembly)

 

Of course there's other things the Jag's better at, particularly 2D. (though who knows what the N64 might have been capable of had a microcode been written specifically optimized for 2D)

 

Namco Museum "Atari Classics"

 

Or other arcade compilations like the midway ones (very similar to Williams' Greatest Arcade Hits that also were on Playstation, Saturn, Super Nintendo, and Genesis -though Robotron2084 isn't very much fun on the 3-button genesis pad)

 

 

 

Oh, and back to the main topic, Hexen would probably have been fine too.

Edited August 9, 2009 by kool kitty89

[4Ks]

Blast Corps. could probably work, with some sacrifices made to the grafx. One game that would simply not work is Pokemon Snap. That game would be impossible to shoehorn onto a system like the Jaguar.

[Ite]

Namco Museum "Atari Classics"

 

Wow why the heck didn't they release one of these for the Jag. It would have been perfect! Playing the old Atari games on the new machine.

[+Zeptari]

Replying to: What N64 games could Jaguar have handled?

 

 

Asteriods Hyper 64

Command & Conquer

F-Zero X (scaled back in the GFX dept?)

Micro Machines 64 Turbo

Road Rash 64 (scaled back in the GFX dept?) I was surprised, the n64 version is pretty good!

Robotron 64

 

Lots more i'm sure...

 

 

Tetrisphere >>> Phear... yup, we should have got this one!

[kool kitty89]

Namco Museum "Atari Classics"

 

Wow why the heck didn't they release one of these for the Jag. It would have been perfect! Playing the old Atari games on the new machine.

 

Yeah, I wondered that too, particularly with Williams' Greatest Arcade Hits (which I have on SNES, so I assumed it sould have been well within the Jag's lifetime), then I checked and realized it came out in 1996, later on some other consoles, with a bunch of other retro compilations coming out even later. (Namco Museum came out in '99 on the N64)

 

Replying to: What N64 games could Jaguar have handled?

 

Asteriods Hyper 64

 

Robotron 64

 

There's an N64 version of Space Invaders too, pretty simple poligonal stuff, the Jag could probably do (and a lto that didn't have, or at least didn't need textures), that and replace any of the 3D background stuff with 2D. (you really can't tell that much)

 

As for Robotron, well maybe if you scaled it back and altered some things (this game definitely could be done well with minimal textureing, the N64 game had relatively few already), the PlayStation version (RobotronX) was absolute crap though, awful framerate, poor perspecitve, and not alternate perspective options. (X give only a partial view of the screen/board, in a 3/4 angled perspective, 64 allows traditional overhead, full board 3/4 view, and front/horizontal view) The style is oddly reminiscent of Tempest 2000. (particularly the retro+techno feel)

If you cut back the size/poly count of some of the models and suplimented some of the 3D stuff with 2D (scaled sprites), it might have been able to be done well. (ie better than the crap PSX version) It's not an overly graphis intensive game in the first place, so you might not have to cut that much (again, depending on how the Jag is being utilized and other things like frame rate), I'm kind of surprised the PlayStation version is so poor, maybe it's just a sloppy port rather than technical limitations.

[+selgus]

There's an N64 version of Space Invaders too, pretty simple poligonal stuff, the Jag could probably do (and a lto that didn't have, or at least didn't need textures), that and replace any of the 3D background stuff with 2D. (you really can't tell that much)

I did the 3D engine for the N64 Space Invaders, and it was full featured. Production called for not having any real camera movements, to be able to utilize more of the engine. The invaders and objects are full 3D models (at one point, I had the environment rotating, with the invaders swarming in... but that wasn't the design Activision wanted).

 

You could do this game on the Jag (we also released it in the PSX) with the current design. The N64 wasn't great at pushing lots of polygons, you had to make the most of the polygons you did render, with use of the RDP.

--Selgus

[walter_J64bit]

Namco Museum "Atari Classics"

 

Wow why the heck didn't they release one of these for the Jag. It would have been perfect! Playing the old Atari games on the new machine.

 

Yeah, I wondered that too, particularly with Williams' Greatest Arcade Hits (which I have on SNES, so I assumed it sould have been well within the Jag's lifetime), then I checked and realized it came out in 1996, later on some other consoles, with a bunch of other retro compilations coming out even later. (Namco Museum came out in '99 on the N64)

 

Yep, you would think that Namco Museum would had been the pack in Cart for the Jag. One of the Jag's strengths is "Perfect Classics Arcade Quality" games who needs MAME all we needed was Tramiel's to use Atari's retro Arcade Classics, hell the in house Jag developers at the time could have done this standing on their heads. but anyway!

[Gorf]

There's an N64 version of Space Invaders too, pretty simple poligonal stuff, the Jag could probably do (and a lto that didn't have, or at least didn't need textures), that and replace any of the 3D background stuff with 2D. (you really can't tell that much)

I did the 3D engine for the N64 Space Invaders, and it was full featured. Production called for not having any real camera movements, to be able to utilize more of the engine. The invaders and objects are full 3D models (at one point, I had the environment rotating, with the invaders swarming in... but that wasn't the design Activision wanted).

 

You could do this game on the Jag (we also released it in the PSX) with the current design. The N64 wasn't great at pushing lots of polygons, you had to make the most of the polygons you did render, with use of the RDP.

--Selgus

 

 

What we were doing in Gorf 3D was a full 3D AstroBattles which is similar to Space Invaders.

The camera moves along with your ship(it does a catch up to the player kind of deal.)

We have 24 invaders as did the original Gorf and we are still getting no lower than 30 FPS.

We'll most likely triple the poly count once the new renderer is done. The frame rate should

be a constant 60 no problem.....G- shaded models of course. We were also thinking of using

a voxel landscape underneath it. The poly scape was putting ahurt on the JAg with the old

smple Atari renderer.

 

We are doing similar in the Galaxian stage which also has 24 alien ships attacking but no need

for a land scape which helps but the models have more facets than the Astro Battles aliens do.

so with the Atari sample renderer we are still getting 30-60 annd when busy enough we drop

to about 24...still respectible considering.

 

The problem with the Atari sample renderer is in its implementation.It is highly unoptimized.

It has some really nice featuresalong with lighting and a very nice camera interface.

 

We are only getting these frame rates due to the fact the Scott removed all 68k code parts

and replaced the code with GPU code. The other problem is it does all it's work in word sized

values. When you have a 32 bit cpu and a 64 bit bus, that is seriously wasting the BW.

 

We intend to correct that in our renderer which will hopefully look more like an open GL

interface. Build a list of object and then flush 'em! Except this will be where the GPU and

blitter using an elaborate interruption scheme will burn through a nice list of polies, lines

and points and no bus interruption other than an occasional sound channel buffer load

from the DSP. It's really quire a balancing act to get more polies on the screen with the

Jaguar.

[kool kitty89]

There's an N64 version of Space Invaders too, pretty simple poligonal stuff, the Jag could probably do (and a lto that didn't have, or at least didn't need textures), that and replace any of the 3D background stuff with 2D. (you really can't tell that much)

I did the 3D engine for the N64 Space Invaders, and it was full featured. Production called for not having any real camera movements, to be able to utilize more of the engine. The invaders and objects are full 3D models (at one point, I had the environment rotating, with the invaders swarming in... but that wasn't the design Activision wanted).

 

You could do this game on the Jag (we also released it in the PSX) with the current design. The N64 wasn't great at pushing lots of polygons, you had to make the most of the polygons you did render, with use of the RDP.

--Selgus

 

That's neat.

I also realized that the backgrounds already are 2D/stills.

 

As I understand it, the big restriction on the N64 was the standard microcode with lots of additional graphical effects/filters applied that weren't always necessary, with some rarely being useful at all. (with only the restricting standard one available, tools for programming customized microcode not being supported, and alternate microcodes actually available to Nintendo/SGI being restricted/discouraged, specifically the "turbo 3D" one) Seems like they kind of squandered the programable microcode, which should have been a prominent feature. (granted some developers like factor 5 actually took it upon themselves to write their own custom microcode with the limited tools available, but that is the exception to the rule)

[+selgus]

As I understand it, the big restriction on the N64 was the standard microcode with lots of additional graphical effects/filters applied that weren't always necessary, with some rarely being useful at all. (with only the restricting standard one available, tools for programming customized microcode not being supported, and alternate microcodes actually available to Nintendo/SGI being restricted/discouraged, specifically the "turbo 3D" one) Seems like they kind of squandered the programable microcode, which should have been a prominent feature. (granted some developers like factor 5 actually took it upon themselves to write their own custom microcode with the limited tools available, but that is the exception to the rule)

All true. RSP microcode space was very limited, so all of the code couldn't be resident in its memory space at the same time. The early microcodes weren't the most optimal.

 

I did get access to the microcode SDK towards the end of my time working on the N64, but the problem was it could only be used on the Indys. By that point, we had moved all our development off the SGI's and onto PC with Partner-64's. I was adding a different lighting method of a game we were doing (hemispherical lighting), but that never got released.

--Selgus

[+save2600]

Tetrisphere

[Atari_Owl]

Tetrisphere

 

Testrisphere = Phear (Post #2 )

[Pocket]

Tetrisphere

 

Testrisphere = Phear (Post #2 )

 

Each time I play it on 64 I'm glad I found it but I'm angry it wasn't released on Jag

[sd32]

There's an N64 version of Space Invaders too, pretty simple poligonal stuff, the Jag could probably do (and a lto that didn't have, or at least didn't need textures), that and replace any of the 3D background stuff with 2D. (you really can't tell that much)

I did the 3D engine for the N64 Space Invaders, and it was full featured. Production called for not having any real camera movements, to be able to utilize more of the engine. The invaders and objects are full 3D models (at one point, I had the environment rotating, with the invaders swarming in... but that wasn't the design Activision wanted).

 

You could do this game on the Jag (we also released it in the PSX) with the current design. The N64 wasn't great at pushing lots of polygons, you had to make the most of the polygons you did render, with use of the RDP.

--Selgus

 

 

What we were doing in Gorf 3D was a full 3D AstroBattles which is similar to Space Invaders.

The camera moves along with your ship(it does a catch up to the player kind of deal.)

We have 24 invaders as did the original Gorf and we are still getting no lower than 30 FPS.

We'll most likely triple the poly count once the new renderer is done. The frame rate should

be a constant 60 no problem.....G- shaded models of course. We were also thinking of using

a voxel landscape underneath it. The poly scape was putting ahurt on the JAg with the old

smple Atari renderer.

 

We are doing similar in the Galaxian stage which also has 24 alien ships attacking but no need

for a land scape which helps but the models have more facets than the Astro Battles aliens do.

so with the Atari sample renderer we are still getting 30-60 annd when busy enough we drop

to about 24...still respectible considering.

 

The problem with the Atari sample renderer is in its implementation.It is highly unoptimized.

It has some really nice featuresalong with lighting and a very nice camera interface.

 

We are only getting these frame rates due to the fact the Scott removed all 68k code parts

and replaced the code with GPU code. The other problem is it does all it's work in word sized

values. When you have a 32 bit cpu and a 64 bit bus, that is seriously wasting the BW.

 

We intend to correct that in our renderer which will hopefully look more like an open GL

interface. Build a list of object and then flush 'em! Except this will be where the GPU and

blitter using an elaborate interruption scheme will burn through a nice list of polies, lines

and points and no bus interruption other than an occasional sound channel buffer load

from the DSP. It's really quire a balancing act to get more polies on the screen with the

Jaguar.

 

Everything sounds awesome Gorf, keep up the good work guys!

[+selgus]

We intend to correct that in our renderer which will hopefully look more like an open GL

interface. Build a list of object and then flush 'em!

That is pretty similar to how I did my engines on the N64-- build basically two types of display lists, one set that are totally static, where none of the information for the RDP would need to change. These are handled either by an off-line application or during initialization from a compact data structure. The second type are display lists where some part of the packet is dynamic. These too can be created off-line and have specific functions that could "update" the binary constructed display lists to change things like texture, UVs (STs), matrices, etc.

--Selgus

[Gorf]

We intend to correct that in our renderer which will hopefully look more like an open GL

interface. Build a list of object and then flush 'em!

That is pretty similar to how I did my engines on the N64-- build basically two types of display lists, one set that are totally static, where none of the information for the RDP would need to change. These are handled either by an off-line application or during initialization from a compact data structure. The second type are display lists where some part of the packet is dynamic. These too can be created off-line and have specific functions that could "update" the binary constructed display lists to change things like texture, UVs (STs), matrices, etc.

--Selgus

 

The whole open GL type structure just makes it much simpler to follow as well and to me anyway, it makes

much more sense. Im willing to bet is a lot less hell implementing it on a machine like the N64. I do dig the

flashable microcode....That would haev been sweet for the GPU. I would only elimiate a few of the current

instructions and add just a few I think are needed.

 

I think most issues with most Jag apps besides choking the bus with the 68k, is the fact that the examples of

use given by Atari are almost useless. Instead of using the interrupt structure in TOM between the GPU,

OPL and Blitter...everybody seems to 'waits' for one processor to finish. There is absolutely no reason for this

vial waste of precious cycles.

 

The GPU can be running in its local preparing SOMETHING for the next frame while the blitter draws away, and

interrupts the GPU for it's next command. Just about every piece of source release from the official game do a

lot of waiting a lot of the time. Granted the interrupts on the Jag are bugged but not broken. I do not say it would

be simple to work around these issues but it is possible and the result would be quite worth the effort. Im willing

to bet that even the Atari supplied sample renderer would have performed better had it no need to load the local

so many times and actually used an interrupt system instead of one processor waiting on the next.

 

Scott a least dropped the load to the local to two from several....I think it was loading 4 or 5. We also moved the points

data stuff out in main. Instead of wasting time buffering in a small handfull of points at a time, we found the hit keeping

them out in main was nothingg compared to the hit of maintaing a buffer for them in the local. Also gave Scott back

enough room to fit all in to two....the rendering is all in one and only a 256 byte or so block has to be reloaded. That could

be moved to main and then no more cycle hogging blits to the local just to run a bit fasterand still lose anyway.

However, Scott will start from scratch and from another point of view.

 

The less you wait and the less you use the 68k and balance the power horses on the bus, the more performance

you will wring out from the Jaguar.

[spiffyone]

I was playing WCW/nwo World Tour and the grafix in that weren't very impressive at all lol. I wonder how close Jag could have come to replicating that.

 

Any other games you can think of the top of your head Jag could have handled?

 

The thing about those AKI/Asmik wrestling games you have to keep in mind is that they were 4 player, iirc, and the animation was actually very extensive and very, very smooth. So while they looked like straight ass even then, they were actually putting the N64 hardware to much, much better use than most games, clipping polygon models aside.