Jump to content
IGNORED

Why are frame rates of Jaguar 3D games so low?


agradeneu

Recommended Posts

Reading five pages of anything will do that to you :P

I've always prefered large flat shaded polys as opposed to lousily textured shitty ones my self.

a few of the 3D games refined to take out the 68000 or at least make it run more efficiently. Or heck, a few new homebrews could use these techniques. I expect to be playing Halo on my Jaguar by the end of the year :P J/K

 

 

Actually the 68k is just a micro processor. It tells the video processor inside TOM

what colors to use but the video processor really generates all the colors. The 68k

just sends a value to a register inside that part of TOM, and the video portion of the

chip knows how to turn it into a colored pixel on your screen. Now keep in mind

that the video is built each frame by both the Object Processor Logic(OPL) and the

Blitter. You can however, write to the frame buffer directly with the GPU, DSP and

the 68k. There are also video line buffers you can mess with if you have a pair but

you are really treating the Jaguar like a very advanced 2600 at that point. I know of

a lad who has tried this and has had some interesting results.

 

Let the OPL deal with the frame buffers. The OPL uses an object list in memory.

That list represents a collection of windows much like sprites but very flexible

and very powerful. In fact any thing you ever see on a Jaguar screen is the

result of the OPL using this list to build windows onto your TV screen. These

objects in the list point to a place in memory where the image data is stored

and the OPL transfers to from the frame buffer to the line buffers which displays

on your TV. The Blitter is usually used also to write to the main window object

for polies and background effects like you see in T2k.

 

The best way to operate the jag is without the 68k at all..it is really not necessary. It only runs at half the speed and is only 1/4 the bus. It really holds up a 64 bit bus just

so it can move 16 bit data around. Even just it grabbing instructions is too much. The

GPU and DSP in proper harmony are well more efficient and they way the designers intended to run the system. So far all of our 3D games are using an engine that is soley GPU and no more 68k hoggin up the bus. The 68k boots the sytem and then goes to bed.

 

Hope that helps. :^)

Link to comment
Share on other sites

AWESOME! Someone is doing homebrew stuff without the 68k processor thingy. That's cool.

 

To bad they didn't just chop it out or something. But then, either the Jaguar would have really flown, due to being able to do much better than it can with it. Or it would have sucked much harder due to people not knowhing how to run the thing.

 

Are there any production games that cut out the 68k, and which ones are they?

Link to comment
Share on other sites

From what I understand you are going to see the best use of the Jaguar's special chip power in Battlesphere and Tempest 2K. I am also sure that John Carmack got the best he could get in the limited time he was developing for the Jaguar in Wolfenstein 3D. Battlemorph also rocked hard and I imagine that was because of the long time experience the Cybermorph guys spent in the Jaguar world.

 

AWESOME! Someone is doing homebrew stuff without the 68k processor thingy. That's cool.

 

To bad they didn't just chop it out or something. But then, either the Jaguar would have really flown, due to being able to do much better than it can with it. Or it would have sucked much harder due to people not knowhing how to run the thing.

 

Are there any production games that cut out the 68k, and which ones are they?

Edited by The Helper
Link to comment
Share on other sites

I am also sure that John Carmack got the best he could get in the limited time he was developing for the Jaguar in Wolfenstein 3D.
Hmm. I could swear I've read that it only took ID two weeks to get a port of Wolf 3D working on the Jaguar, and they were able to get the superior Jaguar version working as it is now relatively easily.
Link to comment
Share on other sites

AWESOME! Someone is doing homebrew stuff without the 68k processor thingy. That's cool.

 

To bad they didn't just chop it out or something. But then, either the Jaguar would have really flown, due to being able to do much better than it can with it. Or it would have sucked much harder due to people not knowhing how to run the thing.

 

Are there any production games that cut out the 68k, and which ones are they?

 

 

The real problem was the tools were just plain NOT ready for prime time.

Even with the 68k in there, if the tools were focused on the GPU/DSP, rather

than the 68k, that would have been fine. Remember, Atari did not believe that

the RISC's could run reliable out of main. They also thought it could not

sucessfully jump between main and local. they are very wrong on both accounts.

 

As far as the GPU being hard to code for....nonsense. I want you all to know,

qwith the new found ability to use main ram, I have five new Jag games working

and playable in less than 2 months. All in 3D and all at least 30-60 FPS and except

for the renderer, all main GPU code. the only thing the 68k does is the vblank. that too

will be moved to the GPU. We have not even come close to exhausting the Jag's power

yet either.

 

Ther renderer we are using is a souped up version of Atari's garbage.It is far from

efficient and we are still getting high frame rates. BattleSphere is probably the best

you will get flipping code in the local. That is roughly 20 000 cycles wasted every frame

for every 4k module fillped in...lots of waste...no longer necessary.

Link to comment
Share on other sites

From what I understand you are going to see the best use of the Jaguar's special chip power in Battlesphere and Tempest 2K.

 

 

No game I know of eliminates the 68k completely. Ours will be the first.

Battlesphere is the best you'll get doing things without main code.

That game would probabley be fully textured at the same FPS with

not having to flip the 5 4k modules every frame. That is over 3,000,000

cycles a second saved. That is a lot of polies or AI not there due to waste.

 

Carmack said that he could have done MUCH better on the Jag if he knew

some of the things he learned while making DOOM. Due to Atari breathing

down thier necks, that never happened. Carmack even considered the Jag

for the FIRST machine to get Quake. The Jaguar has hardly been exhausted.

We plan and intend to prove just that.

Link to comment
Share on other sites

Ours will be the first.

Can I ask if you are still planning to release some more Jaguar games? I was under the impression that you had moved on to other platforms....

 

That would be fantastic - those screenshots & videos of "GORF 3D" look sweet... :lust:

Link to comment
Share on other sites

Ours will be the first.

Can I ask if you are still planning to release some more Jaguar games? I was under the impression that you had moved on to other platforms....

 

That would be fantastic - those screenshots & videos of "GORF 3D" look sweet... :lust:

 

 

Jag releases are up in the air due to other projects. We certainly still put time and effort

in to them but not nearly as much. We also feel that even for the Jag fans, the current work

we do is something Im sure they and any true gamer would appreciate. No small dev outfit

like ourselves would pass up the opportunity. It is not like we can retire now...no,no,no,no,no!

We are loving the current work we aer doing and I am quite sure everyone else will. besides...

 

How can one retire his true love? It just wont let me! Belive me , I've tried! ;)

 

Oh...and Gorf 3D is no longer the name. Unless I ever hear back from Dave Nutting and Midway,

the original Gorf and 3DSSS are no longer and item. :(

Link to comment
Share on other sites

I am also sure that John Carmack got the best he could get in the limited time he was developing for the Jaguar in Wolfenstein 3D.
Hmm. I could swear I've read that it only took ID two weeks to get a port of Wolf 3D working on the Jaguar, and they were able to get the superior Jaguar version working as it is now relatively easily.

 

Yeah, but considering Wolf3D was done on old ass 286 (or earlier??) computers that altogether didn't have the processing power of the 68k, I imagine it was pretty easy over all to do.

 

 

From what I understand you are going to see the best use of the Jaguar's special chip power in Battlesphere and Tempest 2K.

 

 

No game I know of eliminates the 68k completely. Ours will be the first.

Battlesphere is the best you'll get doing things without main code.

That game would probabley be fully textured at the same FPS with

not having to flip the 5 4k modules every frame. That is over 3,000,000

cycles a second saved. That is a lot of polies or AI not there due to waste.

 

Carmack said that he could have done MUCH better on the Jag if he knew

some of the things he learned while making DOOM. Due to Atari breathing

down thier necks, that never happened. Carmack even considered the Jag

for the FIRST machine to get Quake. The Jaguar has hardly been exhausted.

We plan and intend to prove just that.

 

Cool, What games are you working on? Or do you gto a site I can go look at stuff at? That would be cool.

 

Maybe some day we'll get to see Quake or Tombraider on the Jag :D Doubt it, but an equivilant would be awesome.

Link to comment
Share on other sites

So, Gorf. will we able to see CD images (or even printed CDs) of your recent releases, or are they still intended for those with JUGS or BJL?

I, for one, have both, but I am too 'n lazy to connect cables and upload stuff ;-)

Yeah, last time I attempted to get my Jag BJL capable I killed it :sad: but I don't have a JAG CD yet so either way I'm in the dark :| Thus why I hope Jagware gets their JagCF out!

 

Too bad Gorf 2000 had the plug pulled on it, I was hoping for some more 2000 series games for my Jag ;) Still dissappointed I heard about Jag Gorf only after all production ceased.

Link to comment
Share on other sites

So, Gorf. will we able to see CD images (or even printed CDs) of your recent releases, or are they still intended for those with JUGS or BJL?

I, for one, have both, but I am too 'n lazy to connect cables and upload stuff ;-)

 

 

I assume you mean 'Surrounded!' demo available, if you simply

hook those cables up, you could be playing. ;) I understand that

getting those uploaders to work can be trying sometimes. It really

all depends on the OS you use. If you have an old '98 machine not

doing anything, that is youe best bet for simplicity and sucess with

BJL.

 

You dont even need to mod the Jaguar anymore. A simple BJL

CD verion burn and a cable and you're in! Again, as far as releases,

we are currently doing other most exciting work for someone else

at the moment and have no choice but to lower the jag stuff on the

priority list. We still work on those jag apps when we have a moment

or two, but we also are totally diggin the stuff we are doing now.

 

I love coding my Jag to much to ever have to completely give it up. :love:

Link to comment
Share on other sites

So, Gorf. will we able to see CD images (or even printed CDs) of your recent releases, or are they still intended for those with JUGS or BJL?

I, for one, have both, but I am too 'n lazy to connect cables and upload stuff ;-)

Yeah, last time I attempted to get my Jag BJL capable I killed it :sad: but I don't have a JAG CD yet so either way I'm in the dark :| Thus why I hope Jagware gets their JagCF out!

 

Too bad Gorf 2000 had the plug pulled on it, I was hoping for some more 2000 series games for my Jag ;) Still dissappointed I heard about Jag Gorf only after all production ceased.

 

 

Not nearly as disappointed as I. But, chin up! Better to do it properly and that is

not possible at this time.

 

Well, again, if some miracle happens and Midway and Nutting finally get back to me,

who the heck knows, but untill then, we'll have to come up with something else for a

name. The game however , whatever it is finally called, will DEFINITELY bring you

back to the days when you heard "My Gorfian Robots are unbeatable!"

:D

Link to comment
Share on other sites

No game I know of eliminates the 68k completely. Ours will be the first.

 

As far as i am aware this is absolutely true.

Even my project still uses the 68k for the vbl handler - though it does STOP in between vbls.

 

So does ours still....we do know it can be done though...its just a matter of getting to it.

Link to comment
Share on other sites

No game I know of eliminates the 68k completely. Ours will be the first.

 

As far as i am aware this is absolutely true.

Even my project still uses the 68k for the vbl handler - though it does STOP in between vbls.

 

So does ours still....we do know it can be done though...its just a matter of getting to it.

 

I know what you mean.

For me its a question of enough finding enough registers, i'll probably end up having to store registers or something.

 

I'm sure though its further in the future than yours :)

Link to comment
Share on other sites

No game I know of eliminates the 68k completely. Ours will be the first.

 

As far as i am aware this is absolutely true.

Even my project still uses the 68k for the vbl handler - though it does STOP in between vbls.

 

So does ours still....we do know it can be done though...its just a matter of getting to it.

 

I know what you mean.

For me its a question of enough finding enough registers, i'll probably end up having to store registers or something.

 

I'm sure though its further in the future than yours :)

 

 

Not with the current 'toys' where playing with....Too busy for that at the moment. ;)

 

Hey at least you had your eyes open when you where figuring out the trick for local

to main jumping...I still feel like a class 'A' putz for not seeing that one. ;)

Link to comment
Share on other sites

No game I know of eliminates the 68k completely. Ours will be the first.

 

As far as i am aware this is absolutely true.

Even my project still uses the 68k for the vbl handler - though it does STOP in between vbls.

 

So does ours still....we do know it can be done though...its just a matter of getting to it.

 

I know what you mean.

For me its a question of enough finding enough registers, i'll probably end up having to store registers or something.

 

I'm sure though its further in the future than yours :)

 

 

Not with the current 'toys' where playing with....Too busy for that at the moment. ;)

 

Hey at least you had your eyes open when you where figuring out the trick for local

to main jumping...I still feel like a class 'A' putz for not seeing that one. ;)

 

 

Don't. (I'm just glad i we finally talked about things.)

I used to believe that all Jag pages were the same size, feeling disappointed with myself for not looking further into that.

I LOST SOOOOOO much time on trial and error alignments because of that.

 

Its SO much easier now, thanks to you :)

Link to comment
Share on other sites

  • 16 years later...

I just had forgotten how low the frame rates were. I thought Atari would aim at Wings3d on SNES. Atari is so proud of their z-buffered Gouraud shader which saturate the memory bus. But for 10 fps, probably in cockpit view, and with 180px horizontal resolution (Doom) I still cannot completely grasp how the Jaguar could be so slow. On the other hand it appears over ambigious. So the z buffer is full blown. You can activate read and write individually. The buffer is interleaved with the frame buffer for fast page mode. Atari wanted a simple design and did not support transaparency in a register. For this there would need to be 4 bits which would go out as write-enable lines. So the blitter has always have to read the destination. Make it 8bits for 8bit framebuffer. Uh, would not work with 16 color mode. Hey Atari wake up. It is 1993 and 16 colors are so 1983 ( EGA graphics card ).

I am so sad that the z-buffer did not see a good use. I even propose to first read 4 texels regardless if the z-test fails. We save a bit difficult circuitry, but also eliminate any benefit of z-sort. A simple world with only two passes: Transform all vertices ( MatrixMult ), then draw all triangles ( which have 8bit indices onto the vertices ) . No translucency. No shadows.

Pixel mode is easy to set up in JRISC. Less code (very important with only 4 kB) and faster (JRISC is not very efficient per clock cycle). The blitter seems to have some register limit ( silicon real estate ). With smaller registers, everything is cheaper and there could be more registers and Gouraud and transparency could work in parallel. Adders would also be cheaper. Each register would have a carry flag in the middle, also it would be duplicated. Each pixel two registers at set onto the bus ( accumulator, delta ) and the sum is written into the accumulator duplicate. Next pixel sum goes back from dupe to first and the carry from the last pixel is taken in. So it is all very fast and each add costs only one cycle. For texels cache the last phrase address. That is 24 bit to store in a register .. not much. Looking at the big picture, the address generator has plenty of time to remove dupes. 4 cycles to get 4 carry flags of the texture cooardinates over the pixels in the phrase (store). Then read the 0..4 source phrases. Use the carries to condense the color values into the destination phrase. So 2 cycles/pixel minimum added, but maybe we keep the Tom design with separate address generator .. which again is just a big adder with carry flag, but for larger (address) values .. may be slow, may need more set-up time. But again look at the big picuture and think of the 10 fps -- a fixed round robin:

  1. write zPhrase
  2. write colorPhrase,
  3. read next zPhrase,
  4. read 0..4 texel phrases
  5. OP reads out 0 or 4 phrases ( display still runs at 60fps )
  6. Jerry streams two phrases from one voice of the orchestral sound track / 68k gets a blip
  7. DRAM refresh ( with the great pressure regulation as is ).

rinse repeat 

would have achieved 10 fps.

It seems to much more important to have the next register set ready for the next line. So there would be 2 duplicates per register. On the first pixel the other duplicate also reads the value from the bus so that the uniform values of the triangle only need to be set up in the first line. A write from JRISC would stall the blitter for a cycle. Or hey, invest in a single buffer like in the JRISC STORE instruction. I mean in the Tom as it is, the others get the bus while the blitter waits ( idles ) to be set up for the next line. With the interrupt method this takes 12 cycles. With JRISC idle loop still 4 cycles reaction time. Then you need to store like 4 values ( start, length, intensity, fractions of this, z .. ah). You know, the micracle wonder blitter just idles most of the time.

 

A bit more orchestration! Now I feel sad. Seems that only the the title screen animation can run at 60 fps or Tempest2000 because it does not even draw on the whole screen and then only flat and not z buffer.

Edited by ArneCRosenfeldt
  • Confused 4
Link to comment
Share on other sites

The Jaguar was a gaming console released in the mid-1990s, and its hardware specifications were not as advanced as those of modern consoles or gaming PCs. As a result, the Jaguar's 3D capabilities were limited, and it struggled to achieve high frame rates in 3D games.

The Jaguar's graphics hardware was based on custom chips designed by Atari, which were not as powerful as those found in competing consoles of the time, such as the Sony PlayStation or Sega Saturn. Additionally, the Jaguar's CPU was not optimized for 3D graphics rendering, which further contributed to its low frame rates.

Furthermore, game developers for the Jaguar had to work with limited resources, including memory and processing power, which made it difficult to create highly detailed 3D environments while maintaining acceptable frame rates. This was especially true for early Jaguar games, which were often rushed to market and lacked the optimization necessary to achieve smooth performance.

Overall, the low frame rates of Jaguar 3D games were largely a result of the console's hardware limitations and the challenges faced by game developers in working with those limitations.

 

Yeah, ChatGPT makes more sense.

 

  • Haha 6
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...