philipj
-
Posts
979 -
Joined
-
Last visited
Content Type
Profiles
Forums
Blogs
Gallery
Events
Store
Posts posted by philipj
-
-
No worries, anything posted "there" is regarded as nonsense by any sane human anyway - I mean, just look at the admin and moderators, LOL
All good.
Hold up now... First off I respect the mods over there and what they've brought to the table on Facebook. I don't know about anyone else, but they've been nothing but kind and inviting to me over there otherwise I wouldn't have vented there; I regard them as great people a particular moderator as good friend he's a straight up fellow if you ask me. Please dude... Don't insult my friends.
-
So you deffo wouldn't run off and cry elsewhere and try and cause problems when corrected by facts... that is.... good to know.....
Hey man, I apologize for that; I didn't realize the gravity of what I did until after the comments. Besides my frustration was elsewhere beyond the forum and I just vented needlessly. I certainly don't want to cause the stir that I did, but it happened and I kind of wish it didn't after the fact. I don't want to make anymore problems for anyone here and I usually don't and haven't in times past. Now I've had people come me and start trouble with me here in the past and I simply never fed into that sort of thing thus was one of the reasons I left the scene for a minute, but I'm not here for that today. I took something the wrong way not really knowing if any of that old stuff from the JS2 days really died down since I've left the scene; it's hard to read attitudes behind sarcastic one liners. I'm sorry it came up, but I'm glad it came up to clear the air "I sincerely apologize for whatever trouble that post has caused". You don't know how far reaching your actions at a social media or forum are until after the fact. I want to be a contributing factor here and see more innovative stuff on the Jag personally, but I like original new releases in 2D and what-have-you even emulation. I like to see Neo Geo games work on the Jag to be honest, not to be sold, but just a great little project to work on.
-
Doesn't that depend on which group you are in?
Only if you make it a group thing... I usually don't get in to politics in a game forum like that.
-
But is 18 years of disappointment worth more or less than $800?
Well that's quite a legacy; that nearly beats out some Neo Geo carts... It pulls off quite a few feats on the Jag for its time and the programmer is quite knowledgeable with the Jag; they cracked the cartridge encryption using a custom key before the official one went public in case people forgotten. I hardly call that a disappointment, but everyone is entitled to their opinion.
#LegacyMatters
-
For that matter is that why the Jag CD units sell for so much... BTW I wish I'd gottten that game when Scatalogic first published it.
-
Hopefully no contraband will be found in these systems... lol This video below had me in tears when I first saw.
-
1
-
-
Dude that's awesome work... The graphics looks a little modular like it's following a path of some sorts rather than a modeled 3D environment... Kind of reminds me of "Checkered Flag"; despite the choppy frame rate, that game is probably one of the most open world 3D games to have a set of reusable 3D objects in a game. It seems like if the game wasn't in a loop with the race tracks, it could go on forever. You really got something on your hands there buddy; I really hope this engine comes out really solid for some really meaningful 3D gaming, which is a little lax these days as far as home-brewing. Great stuff man.
Out of curiosity I'd find a use for it... I'll take it.
-
1
-
-
Ok... Here's another little nugget that can serve as a great example for using the Object Processor... If my memory serves me well, the "Wolfenstien" demo for the Atari 8bit wasn't a raycasting program, but was a scan-line based program that used "interrupts" to pull of the pseudo 3D effects. Someone can correct me if I'm wrong with the info or give a link to the topic that covers this project as I would like to know more about it. I guess Doom for the Jag kind of demonstrates very efficient scan-line based rendering in real-time. I'd like to see more creative stuff in this regard.
-
I'm pretty sure the programmers of Super Burnout took a good crack at tapping that untapped whatev ...
Well that goes without saying obviously; its ability to scale pixels really fast... My thing real-time manipulation of the OP list via the RISC before it actually reaches the OP, but that's for another day. Here's an insert from the Jaguar Manual...
Object Processor
The Object Processor is responsible for generating the display. For each display line it processes a set
of commands - the object list - and generates the display for that line in an internal line buffer.
Objects may be bit maps in a range of display resolutions, they may be scaled, conditional actions may
be performed within the object list, and interrupts to the Graphics Processor may be generated.
I want to exploit the living day-lights out of those "Conditional Actions" on a whole-other level if possible... At least that's my intentions.
That is a bit of a stretch....
Well... I know it can't be programmed like the RISC or the 68000 can, but you can certainly do more stuff in comparison to the 7800 graphics chip that's totally dependent on 6502 that slows the system down by default... That's the point I was conveying.
-
Remember that the object processor runs on every video line. Adding an extra half-phrase per object would have a significant impact on the bandwidth usage, not to mention alignment problems.
The object list building code, on the other hand, only runs once per frame at most (and only for moving objects if you're a bit clever).
Maybe they Jaguar designers had more common sense that you think
Sort of reminds me of the Atari 7800 graphics chip that uses a display list where the graphics isn't pixel based per-say, but based on list being sent to the graphics chip only in the case of the Jaguar, the OP is programmable... Very fast graphics and untapped potential never fully taken advantage of.
-
Cartridge pins probably just need a thorough cleaning... Get some rubbing alcohol (99% Proof) and some Q-tips to clean the cartridges out. That worked for me in the past and if the screen is still showing red, then you'll know if the system's a lemon or not.
-
Ok... Here's another impressive game call "Racin' Force" that uses voxels as well as the 68000 processor; I see the arcade board uses a series of graphic chips, but I don't see if they were math chips... Whatever the case, this looks feasible to do on the Jaguar hardware considering it's ability to do voxel really well. Any kind of fast pseudo 3D for the Jag will probably be volumetric in nature in order to get those blazing fast non polygonal pseudo 3D graphics. Voxels doesn't look very good unless it's in high resolution, but it's possible to cheat jagged edges from voxels by clipping the edges at it's drawing points via the object processor. Just some tid-bit thought on some ideas; sometimes I look at 3D stuff and my brianstorming goes into overdrive.
http://www.system16.com/hardware.php?id=574&gid=854#854
-
I was never an Atari ST owner, just a 2600 buff in the 80s, I wish I had an ST back in the day though. Recently I ran into a book at www.archive.org when looking for some Motorola 68000 assembly programming books. The book is called "Real-Time 3D Graphics for The Atari ST" and one other 3D graphic book for the ST that's sparked my interest a little more toward the 68K so I'm certainly looking at some possibilities with the CPU... I'll leave a couple of pdf files.
https://archive.org/details/Real-Time_3D_Graphics_for_the_Atari_ST_1991
Real-Time_3D_Graphics_for_the_Atari_ST_1991.pdf
Atari_ST_3D_Graphics_Programming_Concepts_And_TechniquesuBee.pdf
-
Don't forget mine... Here's my confirmation Number: 2010257Date Ordered: Friday 25 February, 2011Detailed Invoice:Products------------------------------------------------------1 x 7800 Expansion Module (7800XM1) = $99.99------------------------------------------------------Sub-Total: $99.99United States Postal Service (1 x 3.50lbs) (Priority Mail (2 - 3 days)):$13.20Total: $113.19Delivery Address------------------------------------------------------Billing Address------------------------------------------------------Payment Method------------------------------------------------------Credit Cards - Visa/Mastercard/AMEX/Discover
Visa XXXXXXXXXXXX7112
-
There's a hard limit how many times you can spin Blitter up at 60 fps. Even if the lines are 1 px short, that limit is there. So, much much sooner than you think, you'll hit a concrete stone block, and no amount of splitting the work among 68000 and DSP will help you.
You could, of course, do SW rasterizing in parallel on both DSP and 68000. The DSP's 16-bit bus won't matter, as you draw lines byte by byte, so it's going to 8-bit access anyway.
The problem is, however, that you'll be hitting and locking the bus from 3 places : Blitter, DSP, 68000 and while the grand total number of lines drawn will be higher (than it would be from just GPU), when using all 3, just don't expect a dramatic increase in number of lines at 60 fps.
@VladVR
I remember some years back I had a discussion about the Jaguar's ability to do "Parallel Processing" and from that discussion it became very clear that the Jag bus bottleneck issue will probably require a less parallel technique to getting over the bottleneck issues... Not that it isn't possible, just a bit of a nuisance and potentially problematic towards progression so I've always bear that in mind; I think that whole discussion started from my curiosity of why "Checkered Flag" ran so sluggish on the Jaguar. It was assumed back then that the M68K was hitting the bus too hard doing a lot of game logic and AI functions thus is why I was a bit hard on keeping the 68K off back in the day. A less or non parallel way of processing would probably mean a less or non traditional method of real-time graphic display in a meaningful way. That's where my head is for Jag development.
Granted, it was 3am here, and I was sleepy&grumpy, but he mentioned 2.5D, like, 2-3 times.
2.5D is largely accepted as isometric engine - e.g. Diablo. Whereas in that x68000 game, it's a wireframe of a proper 3D world...
It was my understanding that the phrase "2.5D" mean "Pseudo 3D" like raycasiting, Doom style rendering which is different then ray-casting, 3D voxels using 2D sliced images to make up a 3D object or 3D box values in 2D space, 2D metaballs or even 3D metaballs that use simple shapes to produce countless polys on the fly and so-on... My hope is to one day find a way beyond the traditional confines of a large 3D data set and take away the restrictions of polygon counts. Inspired by the old VistaPro program, the file sizes prior to being rendered are a fraction of what the program actually produces on account that the program has to calculate all of the 3D math to produce it. Well the Jaguar's strength is in the 2.5D/Pseudo 3D stuff so a hybrid of both 2.5D (third mention) and real 3D seems to be the thing to pursue with the Motorola and/or DSP doing some real 3D work while the GPU with OP and BP rendering something in Pseudo 3D or fake 3D based on a real 3D framework and maybe some other pre-rendered or pre-calculated stuff to fake a high polygon object that may have been modeled in Blender or Zbrush without it being a large data set.
https://en.wikipedia.org/wiki/2.5D
I did some similar-looking experiments. This particular one is not using Blitter for lines - just drawing them pixel-by-pixel from GPU:
So, you can expect a similar output from DSP (again, from GPU, I was doing 8-bit access, so the DSP's 16-bit is more than adequate). Of course, minus the bus lock, as when the GPU is accessing framebuffer, the DSP has to wait, and vice versa.
Using GPU to draw lines pixel-by-pixel gives you a tremendous advantage in the visuals, as Blitter cannot do the shading at 256 color mode.
But, on GPU, you can do it very easy (note the colorful lines):
Man I got to commend you on the 3D work you managed to get out of the Jaguar so far... Keep up the good work.
Honestly, the best bet would be to use the GPU to do it's job as intended, performing the vector maths calcs and feeding work to the blitter. Use the blitter to build the output in a frame buffer, and then once drawn, point the OP at it. You don't have any risks of a single scan line being too complex and taking too long messing the whole thing up that way, you only show a frame when it's ready, and you get no tearing when there is movement.
Us the OP and blitter as they were intended too, the system will work with you then, not against you. Use the 68K sparingly if you don't have the bus time, or as a manager for your game, leave the DSP for all the other bits and bobs, or even use it as the main system loop and bin off the 68K.
But don't try rendering your 3D scene into the scan-line buffer 2600 style with the GPU, there be dragons, headaches, and an ultimately sub par result. The jag can do 3D, same as significantly less powerful systems could do in the late 80's.. Jag can do it better I am sure and faster, until you start trying to treat it like a modern system (which don't forget is 20+ years it's junior, and computer tech increases in performance exponentially).
Duly noted buddy... I was looking at the old "Chase The Beam" theory for the Jag... It's more like "Chase The Line" in the Jaguar case. Even by 1995, just a couple of years after the Jaguar release, the average PC that did 3D graphics ran at 60 or more megahertz, which wasn't available to the masses in 93 and 94 unless one owned a graphics workstation like the SGI stuff. Even the 3DO arms chip was proven in the Acorn PCs to do decent 3D stuff. Don't mean to give a history in that sort of thing and throw the topic off, but the best you had with 3D past 60fps was Doom, Super Burnout, Val d'Isere Skiiing, and Atari Karts showing some promise and let's not forget the voxel stuff. I want to get the GPU to produce better 3D graphics in the same kind of way it was able to produce those fast frame rates in these 2.5D games only smarter.
-
OK... Here's a good example of a low poly engine running an X68000 computer... It's very fast with no surfaces, just straight wire-frames running decently fast on a 68k processor. For the Jag, I would use low poly using the DSP, or the M68k, or both for speed and let the GPU render a high-poly version to screen using a type of scan-line render-er using the OP. Or if I could just fake the living daylights out of 3D using 2.5D methods at the GPU level based on the real low-poly 3D stuff, I'd settle for that; the Jaguar's strength is in it's 2.5D rendering. I've always been a firm believer in that fact. That's my vision a 3D engine for the Jaguar in a nutshell.
-
1
-
-
Ok here's an example of a low level view of Vistapro animation sequence before it's rendered on an Amiaga... It runs much faster on an IBM machine. Just an illustration to bat in a point.
-
1
-
-
Of course, with only 3 different types of such scaled bitmaps on each track, you could -alternatively- just precompute all the mipmaps and pre-scale them at load-time (we have 2 MBs, after all), at which point there's zero performance overhead of scaling at run-time. OP, then, could just copy/paste them all over the screen (via separate objects, all pointing to same image data), if you want - e.g. something like AfterBurner (where each scaled bitmap is reused dozen times).
I would personally choose the flexibility of Blitter, but I can see that a lazy coder could just create a composite of the bitmaps and let system eat all the bandwidth it has
@VladR
I wouldn't have consider composition stuff to be that of a lazy coder... I think my point is being missed a little here when I mention the word composition. First off let me make an important note here my philosophy for Jag development is to "Think really Big, but Start Small." That's really the driving force behind a lot of my ideas; I got the phrase from a solar power company and become somewhat of an epiphany that stuck with me for years. When I mention the word composite, I'm thinking in terms of the Jag doing composition on a very small scale in a way that's feasible. You probably can't do shaders in the sense that a modern PC or game console can do, however, you might can trick some of the more simpler Jag mechanics to do some similar using low depth color, low poly objects or just simple bounding boxes in main for the DSP or M68K to manage until an actually reaches the GPU for fast rendering. Large data sets doesn't have to occupy physical memory, but rather a representation of such data can be present in the machine before an actual rendering takes place. We can't make the Jag get on the PS4 level-it just not built that way, but we can get on the Jaguars level where data and throughput can be very small and quickly manageable for real-time purposes. It all sounds good to me, but I know the reality of Jags complexity so I try and keep and open mind these days.That's also why I say in other topics that there need to be a radical re-thinking of how to program the Jaguar because system is what it is and any other 3D pipeline that came after it wasn't designed to be put on the Jag due better system architectures.
It takes twice as much bus to get stuff in and out of the DSP, this does matter. Yes it can do more in it's cache (which also has to hold your code remember, so you are already eating into your 4096 (roughly) instructions worth of RAM. You need to be able to hold all the data you need for your calculations in there and the output (several pixels worth) to mitigate the 16bit bus limit. You also lose your matrix transformation optimisations. Not saying you cannot use the DSP to assist with 3D, hell you can use 68K if you want to do all your 3D, I am mearly disputing the 16bit bus width not being an issue.
@ LinkoVitch
The same answer I gave VladR can also somewhat apply and I hope it give better understanding to a lot of my comments.
There's a couple of old 3D programs that I use to work in in the late 90s called "Impulse Imagine 3D, which was in direct competition with the original "3D Studio" ; the other program is called "Vistapro" which was a landscape program that seems to use fractals to render landscape, which I'm going to post a couple of stuff I did in Vistapro (and showboat a little
). Both of these programs were out during the Jags hay day and were both consider ray-tracer based programs on the Amiga, but my versions was on IBM pc. These programs would start out as low poly bounding boxes or in Vistapro's case as low level fractals before anything was every rendered. If you think about the game Doom, it started as a low key binary tree set that resided in ram and didn't actually get rendered until the GPU actually picked it up via one of the Jag processors right? Well the same principal can apply for a real-time 3D render-er; the key would be the consolidation of the 3D sets for fast low bit depth recovery at the right time.Now the videos I made back in 2006, actually for a grade in a couple of college classes I was doing at the time, started out as low fractal height maps that looks very similar to "Rescue on Fractalus" for the Atari 8bit systems. Not to through this off topic, but to get a point across, Before I rendered the actual video you see, I would preview it in a height map fractal view designed for real-time viewing on an IBM 386 or higher. Not that I saying we should use fractals exclusively, what I'm saying is that the same principal low level fast small data set can be handled by the other processors on the Jaguar, before it actually reaches the GPU, Blitter, and OP for real-time polygon rendering or some other fast rendering scheme... Something like THAT should be the design philosophy behind the technicalities.
Native Land Treasure: I rendered this in "VistaPro" for Windows, compose the
music using "Acid" beat loops and edited everything in Adobe Premier back in
2005 or 06.
A high res "VistaPro" rendering I also did in 2006.
Sigh. Great memories...
-
Not familiar with NeoGeo's specs, so can't comment on that one. I wouldn't say Atari Karts is a good example of jag's strengths - its framerate looks slightly better than Supercross, but is far from something I would voluntarily endure for more than 10 minutes.
Then again, if the said person perceived jag's wolf as 60-fps-no-framedrop-kind-of game, then I guess Atari Karts could work for them
Ok... Here's a post of two racing games; one is "Riding Hero" for the Neo Geo and the other is "Super Burnout" for the Atari Jaguar. Both are doing similar style graphics of zooming sprites using both system sprite zooming features. For the Atari Jag it would be the "Object Processor" doing all of the work and for the SNK, although the system has less ram than the Jag, the Neo Geo pulls off some pretty good stuff on its own merit.
Riding Hero for the Neo Geo
Super Burnout for the Atari Jaguar
-
2
-
-
Jag can clearly do super high resolutions and flatshading, at 30-60 fps. Unfortunately, that's not where the market went, so this era was completely bypassed. If you look at many Sega 32x games, they could have been phenomenal on jag, in high res.
Recently I was watching some vids on one Japanese arcade (name escapes me at the moment, but it had like 4 RISC chips and 3-4 additional other processors) that was using laserdisc and all games were flatshaded. They look absolutely stunning in high res. Even by today's standards - because there's no pixelated grainy textures, everything is nice, sharp and clean. Honestly, I wouldn't even go for Gourard (though, that's more passable as simple texturing) - but that's personal preference....
That reminds me of the old "Namco System 21" arcades... Not to throw this topic off of the subject, but I looked at so many hardware's in comparison to the Jaguar hardware including the old graphic workstations in the 80s. Archive.org has some stuff there concerning old workstations and some 3D arcade hardware if you're lucky. If Gourard shading can be pulled off pass 30fps I'll take it; I have no problems with shading except for the slowdowns. As for the grainy texture, I'm wondering if the OP can blur out the graininess using anti-aliasing...? The OP can do effects like fog and other effects that involve scan-line based effects. The N64 blurred textures by default, which was one of the highlights of that system, but I think the Jags GPU is capable of doing similar but very differently due to there being no video ram; some things would have to be worked out with the other processors especially the DSP having the highest priority and access to main ram at full speed.
I don't know what happened to Saturn, and while I haven't seen PS1's SDK, I find it more sad (than, say, jag) that Saturn didn't stand a chance against PS1...
You can thank the Silicon Graphics technology used in the PS1 and N64 for that... Sega learned from that experience when they released "Scud Racer" in the arcades around 96 using the "Lockheed Martin Real3D/PRO-1000" technology. Those kind of hardware's were used in the auto industry, graphic workstations and military application before it made its way into the gaming world so the shading techniques were tried and true versus the Jaguar hardware that was an in house Atari exclusive hardware in the making; not to take away from the Jags ability, I think all of those tricks the other hardware do can be done on the Jag also.
Object processor is a cunning way to not need to keep updating a frame buffer to display graphics on the screen. You cannot display anything on a jag (beyond changing the screen colour) without using the Object processor.@LinkoVitch
Right... The OP feeds lines into the video chip to be displayed while preparing another line for the video chip display to screen. I'm hoping to one day capitalize on it's ability to change screen color to pull off some other effects in 3D beyond gouraud shading, which I know that's what the blitter is responsible for... I would like to see the OP ability to change screen colors on the fly more cleverly used to pull off effects like smoke and fog as well as some other stuff to make 3D objects look better.
What do you mean "keep refreshing the phrase" ? that makes no sense at all??The simplest way to keep displaying the same object list each frame is to generate it once and then just copy it back over the list after the OP has processed it. A simple blitter copy will do it lightning fast, but you can even do it using the 68K depending on the size of the list.
Agreed... That was my first thought when I read that... The Blitter is one big copy machine that can be used for more than just graphics; I would like to use the Blitter to do math for graphical purposes if possible.
-
1
-
-
I find that Blitter is extremely overrated in terms of its performance. When I did some benchmarks for bitmaps scaling through Blitter (both when bitmap was in the tiny cache, and in main RAM), the pixel throughput was truly laughable. Even using the fast cache and tiny little bitmaps didn't help much (33%, if I recall correctly, compared to main RAM). And that was just 8-bit bitmaps, forget the 16-bit ones...
You may have to use very low color depth of 4bits or even 3bits just to get any significant speeds especially if you talking about a 3D texture mapping situation... I think the PS1 used 4bits dithered images using its hardware to pull off considerable speeds. The Jag seems to linger between being a really fast sprite machine more than the 3D power house it should've been so that's something to consider also. I think it was the Tempest 2000 that gave the Blitter its mythical status thanks to Jeff Minter.
Considering how Doom works, the GPU seems to be treated like a VGA card rather then a 3D chip, where the main processor does all of the real work and the VGA displays pixel very quickly using tricks like mode-x and what-have-you. The only difference is with the Jaguar, the display-er is smarter thanks to Jag-RISC with a Blitter to do better than what a VGA mode-X could do the blitter being programmable and all. If you think in those terms, I think a proof of concept outside of the Jaguar would be a more hopeful approach just as Doom was originally a PC game ported to the Jag that was proven to work on old 386 machine.
That's true only for 2D games, which didn't really matter to Atari much at the time of the jag's short commercial lifespan.
For 3D, the OP is actually worse than the old simple Antic in Atari 800, as you have to keep refreshing the phrase of the framebuffer's OP data (which the OP shamelessly destroys each frame), regardless of the actual framerate, so it eats cycles during vblank.
Certainly the Jag can do better than a Neo Geo or even a Sega CD hardware that can do zooming, scaling, and rotating... I think games like "Super-cross and Atari Karts" is phenomenal on the Jag with their pesudo 3D effects. That's where the Jag strength is that I hope to one day take advantage of in making a 3D engine.
If you, as a coder, are willing to complicate the engine design, you can keep GPU processing other stages of the pipeline, while Blitter - nicely in parallel - shades the current scanline. I have a compile-time flag that enables/disables waiting for Blitter and the performance differences are quite staggering.
Then again, to be fair, so are the debugging/testing/development complications
No surprise there... The Jag needs a better SDK. During the last shelf life on the Sega Saturn, Sega released a better SDK for the Saturn for one last coup-de-grace. Keep fighting the good fight. lol
-
1
-
-
For kicks I googled the word "Object Processor" and this old topic popped up in the search engine... A great throw-back topic; very simple, but very direct to the point. I think any real gains to be made in making really fast, high frame rate stuff on the Jag will come from making good use of the "Object Processor." The Blitter is phenomenal in and of itself, but it doesn't seem to have the kind of speeds you could get from the Object Processor less you use the blitter minimally for shading or other task like good old T2K.
Very nostalgic.
-
Well for me I was just curious about the AMY chip and decided to do some quick research on it, found a bunch of stuff about it and found it suitable to post in this topic. Just putting the found information out for others to see. Being a music composer myself, I found it interesting that "Bell Labs" was at the origin of this AMY chip concept, it would've blown the sid chip off of the map in comparison. I like music and I remembered running into the website was posted by Curt Vendel posted some years back was just curious about the chip.
-
1
-
-
Just revisiting this old topic... Here's an article about the "Synergy Keyboard" I just googled and thought suitable for this topic. This keyboard is probably the closes you'll get to what the Amy chip might actually sound like minus a few bells and whistles.
-
1
-
Like us on Facebook
Follow us on Twitter
AtariAge on Instagram
Watch us on YouTube
Chat on Discord
How was the object processor used?
in Atari Jaguar
Posted
And to think I had a 1200XL and sold it... What was I thinking. It was the "Mr Wizard" Atari system of all systems. lol Well the info I got from the "M Project" came straight from the horses mouth/the guy who posted the YouTube in a comment some years back when he first posted it. At first I thought he was using some raycasting on the Atari 8 computer, which was done once before, but not quite the way this guy seemed to have pulled it off at that kind of resolution. I can't seem to find the actual quote, but no ray casting was used, it was full on scan-lines using interrupts to do all of the pseudo 3D effects; that much I do remember considering at that time I was looking at the Atari 7800 graphic chip able to use display-list, which is very different then the 130xl graphic chip, yet share some common ground with the Jaguar's OP able to display almost in similar manner. It seem like whatever the Jaguar OP lacks in comparison to the Atari 8s graphic ability, could be made up in speed, but then again, even the Atari 8bit computer had a little more ram to do more graphical things then the Jags GPU with only 4KB of internal.
My thing is this, the GPU is a 2D monster very capable of doing 2D display and manipulation in real-time without breaking a sweat, which I've always credited as the Jaguar's strength... If 3D can be done using the DSP or the M68K or both very minimally using low poly based 3D models, and I mean low poly to the bone for the sake of speed and broad view distance, the GPU can interpret 3D data and render fairly accurate pseudo 3D/2.5D based of real 3D math as a way to fake high polygon objects in a similar fashion a voxel height-map is used or 2D meta-balls are used to render high detailed 3D images to screen only in this case, pseudo 3D is faked to look like real 3D high poly objects when in reality no real polygon is used, it just looks that way. It doesn't have to be voxel or metaballs per-say; just a smarter way to convey high detailed 3D in a way that takes the polygon count out of the equation or "Limitless 3D" as I use to say back in the old JS2 days; only its a new day today, I have a better understanding on things today then I did back in the day. That's what I mean by faking the living daylights out of 3D if that make any since to anyone.