Jump to content
IGNORED

the atari Jaguar theory


2600problems

Recommended Posts

the system was touted as 64 bit but the games were on par with other consoles.

 

my theory: the two Processors on the system were only capable of limited math Processing. 2D games were easy. 3D games used more complex Formulas and thus required more processing power, thus the 3D capabilities were weaker. BattleMorph could've been better had it used fewer Details. it would've looked like shit but would've played better.

 

had Alien vs Predator been given a graphical update using the full power of both processors, it could've been less of a slow paced game and more of a fast paced shooter.

 

the problem lies with the processors, not just atari. too weak to be used efficiently and atari was too stupid to se the flaw.

 

thoughts?

Link to comment
Share on other sites

the system was touted as 64 bit but the games were on par with other consoles.

 

my theory: the two Processors on the system were only capable of limited math Processing. 2D games were easy. 3D games used more complex Formulas and thus required more processing power, thus the 3D capabilities were weaker. BattleMorph could've been better had it used fewer Details. it would've looked like shit but would've played better.

 

had Alien vs Predator been given a graphical update using the full power of both processors, it could've been less of a slow paced game and more of a fast paced shooter.

 

the problem lies with the processors, not just atari. too weak to be used efficiently and atari was too stupid to se the flaw.

 

thoughts?

 

 

Having never developed for the Jaguar... I can't say I know. But I always hear that the processors were never fully utilized. That said... it didn't have any kind of real 3D processor... not really sure what the "blitter" chip did specifically with graphics. I think it was well intentioned, but they hadn't really considered the shift in games that occurred from the early to mid 90s. I think they intended to really compete with what would eventually replace the Super Nintendo and the Sega Genesis... meaning, the Jaguar was sort of one of the first in that new genre of systems.

 

The PS1 and the Saturn were just far more advanced systems.

 

Other systems like the Amiga CD-32, and the 3DO weren't really all that different. 3DO had a 3d processor I have to assume... that was the whole big thing about it.

  • Like 1
Link to comment
Share on other sites

I believe one of the most important things about a console is the controller design. I don't understand how Nintendo had 6 buttons with the SNES, and later Genesis comes out with 6 button controller to compete with that, and then the Jaguar when it comes out way after has a 3 button controller at launch(and no, the keypad buttons don't count). To me that was just plain stupid putting a system out to compete with those 2 systems and even next gen later but take a step back from them on controller design. As far as graphics, speed, etc. I have no clue because I never bought one to play due to the controller design. Bought a Genesis instead.

  • Like 1
Link to comment
Share on other sites

That's what I've heard as well. I'm no programmer so all I can do is quote what I've heard, taking on faith that it's true.

 

I think 4Play (Battlesphere) wrote a bit about how it was hard to synchronize the Tom and Jerry processors, and there was a bug or memory that made ten have to break all their code into tiny chunks to work effectively. It's probably in the archives of rec.games.video.atari if you look hard enough.

 

I think John Carmack (Doom) wrote a bunch about the system's strengths and weaknesses, too.

 

Another thing I've read is that most Jaguar games are mostly just using the 68000, which is the same chip as the Genesis and Amiga machines. I don't think it's a coincidence that many of the games are the same, too.

 

To some extent, Sega Saturn had a similar issue, it was hard to get performance out of the many chips in that system. At the same time, Sony PlayStation had a lot of programming libraries to make development much easier (therefore faster, cheaper, more profitable).

 

Hard to program + slower than the competition + not many hardware units sold = failed platform. Maybe it could have done better in the absence of Sony and Sega.

  • Like 1
Link to comment
Share on other sites

Oh god please, not another of those.

 

It's been discussed to death dozens of time in the past (use the search function). And it always devolve into page after page of "I don't know anything about programming, marketing or economics, but I totally know why the Jaguar failed, and what Atari/the developers should have done, yadda yadda yadda". Even if you had a good point, it's highly unlikely not to have been brought up before.

Edited by Zerosquare
  • Like 19
Link to comment
Share on other sites

zerosquare, you do NOT have to participate. you chose too, you do not have to do so if you do not want. so respectfully, shut the fuck up

 

Well, that wasn't very respectful ;)

 

(You'll also notice his is the only post in this thread with any likes on it....) (so far, of course)

  • Like 10
Link to comment
Share on other sites

zerosquare, you do NOT have to participate. you chose too, you do not have to do so if you do not want. so respectfully, shut the fuck up

 

I'd advise you to treat other members with a bit more respect.

  • Like 8
Link to comment
Share on other sites

the system was touted as 64 bit but the games were on par with other consoles.

 

my theory: the two Processors on the system were only capable of limited math Processing. 2D games were easy. 3D games used more complex Formulas and thus required more processing power, thus the 3D capabilities were weaker. BattleMorph could've been better had it used fewer Details. it would've looked like shit but would've played better.

 

had Alien vs Predator been given a graphical update using the full power of both processors, it could've been less of a slow paced game and more of a fast paced shooter.

 

the problem lies with the processors, not just atari. too weak to be used efficiently and atari was too stupid to se the flaw.

 

thoughts?

jagdev.jpg

Link to comment
Share on other sites

Oh god please, not another of those.

 

It's been discussed to death dozens of time in the past (use the search function). And it always devolve into page after page of "I don't know anything about programming, marketing or economics, but I totally know why the Jaguar failed, and what Atari/the developers should have done, yadda yadda yadda". Even if you had a good point, it's highly unlikely not to have been brought up before.

By that standard, why discuss anything? It's all been discussed by someone else before.

  • Like 1
Link to comment
Share on other sites

By that standard, why discuss anything? It's all been discussed by someone else before.

 

You're right, there's nothing wrong with discussing topics that have been discussed before. However, Zerosquare also has a valid point. This is one of the topics that has been endlessly discussed in countless other threads. I'm thinking of stickying one of the countless other threads so we can keep discussion of this topic in one place.

  • Like 3
Link to comment
Share on other sites

The biggest problem with the Jaguar with 3D games is:

 

1- The blitter is too stupid, can't even draw a single flat shaded triangle (wasting cycles waiting for the blitter to finish or too many cycles wasted setting up the blitter for just a few pixels)

 

2- With textured polygons you'll have a lot page misses (you need a cache or write buffer for faster textures)

 

3- The blitter can't work in DMA mode (like OP), ideally you'll write a list of primitives to render (points, lines, flat triangles, textured triangles, etc) and tell the blitter to draw them, while it's busy rendering the list you can process the next frame. (real parallel processing)

  • Like 5
Link to comment
Share on other sites

I believe one of the most important things about a console is the controller design. I don't understand how Nintendo had 6 buttons with the SNES, and later Genesis comes out with 6 button controller to compete with that, and then the Jaguar when it comes out way after has a 3 button controller at launch(and no, the keypad buttons don't count). To me that was just plain stupid putting a system out to compete with those 2 systems and even next gen later but take a step back from them on controller design. As far as graphics, speed, etc. I have no clue because I never bought one to play due to the controller design. Bought a Genesis instead.

 

 

I know the Tramiels were all about making an extra buck... or the marketing of such. So I suspect they probably did that for the sole specific benefit of then offering the Pro Controller for everyone to then have to buy. If I had to completely make up something based on how I've read that guy typically operated... he probably assumed all games would take advantage of the Pro Controller, but that you could "get by" with the regular controller... so, he'd make double money cause everyone would buy the pro controller.

 

Like when a car company releases a hot new car... and then a year later offers it as a convertible so everyone then trades their old one in to get a new one.

 

 

 

 

zerosquare, you do NOT have to participate. you chose too, you do not have to do so if you do not want. so respectfully, shut the fuck up

 

 

Ouch...

Edited by 82-T/A
Link to comment
Share on other sites

How about we flip the question around?

 

What is it about the Jaguar that makes people wonder "what if it just didn't get a fair shake" and "why didn't it do better?"

 

Guesses:

Atari brand nostalgia

Made in America

Lots of Tramiel promises

Confusion between Atari Corp and Atari Games

64-bit, do the math

Link to comment
Share on other sites

The biggest problem with the Jaguar with 3D games is:

 

1- The blitter is too stupid, can't even draw a single flat shaded triangle (wasting cycles waiting for the blitter to finish or too many cycles wasted setting up the blitter for just a few pixels)

First of all, Blitter wasn't designed to do 3D rasterizing exclusively (that wasn't the original plan, as has been discussed to death, thousand times), rather assist in polygon rasterizing, and that's a job that Blitter does actually very well!

Keeping multiple codepaths for same visual feature [to extract the last bit of performance] is arguably part of the charm of coding for this machine :)

 

Also, if you think outside of the box, you can actually get Blitter to render 2 full textured triangles in a single call, instead of hundred calls that are needed for all,say for example, 50 scanlines. It won't be perspective-correct texturing, sure, but not all games need that. Besides, correct perspective results in too much of a pixelated mess, so a clean, nice textured wall, that does not shimmer when camera moves, is visually far superior to a pixelated mess of perspective-correct texturing in that low resolution, anyway.

 

Application ? Imagine something like Diablo3, where all wall vertices are properly calculated in 3D, so walls move correctly around the camera, with the only "drawback" being that the bottom vertices of the walls do not stretch into the far depths, so it looks partially like ISO-metric view, except you still get the full advantage of proper 3D occlusion (e.g distant walls moving slower than nearby walls), that's impossible to achieve in classic 2D ISO perspective.

However, you get 2 things : It's super fast (compared to scanline rendering) and it looks very clean !

 

For a while, I was actually rendering my perspective walls in H.E.R.O. using that trick - just a single call for full wall (2 triangles), but then I came to conclusion that it's a cheat, as there was no perspective, so I switched back to scanline approach (e.g. Blitter call per each scanline), where I can adjust the length of each scanline appropriately (although, arguably, for that particular game, the difference is just few pixels, so it's really only academic).

 

 

 

 

 

2- With textured polygons you'll have a lot page misses (you need a cache or write buffer for faster textures)

This keeps getting repeated over and over and over, and it's far from a realworld problem, actually.

Few weeks ago, I was doing a comparison/algorithm exercise, where I was rendering road purely via Blitter, using fractional scaling. Even with the texture being fully in cache, the single greatest performance loss comes from Blitter accessing every single texel in the source texture, regardless of how many texels are actually written to screen. You know - it's like when the road gets narrower into the distance. There's literally no performance difference between Blitter rendering double amount of texels, it's the source ones that matter, actually. It takes exact same amount of time for the bottom scanline (that is of full-screen width), as it takes for last scanline that is just 3 pixels wide.

We may argue, that it's a logical consequence of the way Blitter was designed, for this particular mode, but its realworld appication is very limited - most probably simple scaling of few sprites (e.g. roadside objects).

 

Having texture in cache helps performance, but not by much (the difference is way, way smaller, than if you are doing texturing on GPU and are texturing from RAM). You'd need to have multiple mipmaps (but you don't really have memory for that in 4 KB) to work around it, so in the end it's actually much faster just to let GPU texture it, and just use Blitter to merely transfer the texels (where you literally pay only for the amount of texels transferred).

 

I have the benchmark data written somewhere in code (don't remember it after few weeks), but the amount of texturing that Blitter can do via fractional scaling per frame was so ridiculously low, that I could not instantly come up with a type of game, where it could be useful as main texturing technique (perhaps only if you were using very low-res texture, at which point - why even bother with 3D ?).

I guess the only advantage here is that both GPU and DSP are basically free to do whatever they want, since Blitter is hogging the bus all the time, so they would be free to compute some nice real-time lighting, or some complex effect. I imagine 68k would actually have to be shut down as it would not get a chance to do much of anything.

 

 

 

3- The blitter can't work in DMA mode (like OP), ideally you'll write a list of primitives to render (points, lines, flat triangles, textured triangles, etc) and tell the blitter to draw them, while it's busy rendering the list you can process the next frame. (real parallel processing)

But, you're talking about a high-level API like DirectX or OpenGL on PC (and/or new consoles). That would actually be an extremely poor design choice, if Atari chose to do so (and thank god they did not). Imagine they would have to resort to the fractional Blitter scaling, for the texturing. It'd basically become unusable, as it'd be so slow, and you'd have no choice in the matter,as it'd be forced upon you.

 

This way, as you have to write it yourself, you actually have a choice - to design an engine/game around the capabilities of jag, around what it's really fast at.

 

Of course, it's much more research&engineering work this way, than just say, like in DirectX - call a function DrawIndexePrimitive (MyTriangleList).

But, nothing stops you, from rolling your own version of, DrawIndexePrimitive (), that is tailored to the performance characteristics and demands of the game you are writing.

 

E.g. With Great Power Comes Great Responsibility :)

 

 

I'm thinking of writing one long summary/article, with realworld benchmark numbers, what's jag fast at and what it isn't, but there's still so much more to discover...

  • Like 2
Link to comment
Share on other sites

I'm thinking of writing one long summary/article, with realworld benchmark numbers, what's jag fast at and what it isn't, but there's still so much more to discover...

 

Then get to it! *cracks the whip*

  • Like 1
Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...