Jump to content
IGNORED

Open Lara engine on the ATARI Jaguar


Gunther

Recommended Posts

1 hour ago, phoboz said:

This is what PhOBoZ & Krauser has been up to lately (e.g. designing some 3D models for an upcoming Jaguar 3D game that hopefully will run in double digit framerate)

 

The first ship is the vessel of Bounty Hunter N17, featured in the action adventure game Asteroite.

 

The last ship in the demo is the player's ship in the game Wormhome 2000.

 

The idea is that the game will be an arcade like dogfight game, with different missions for BH - N17 to hunt down cosmic villains.

That looks really sharp. What's the range of performance you're getting with that renderer?

Link to comment
Share on other sites

15 minutes ago, alucardX said:

That looks really sharp. What's the range of performance you're getting with that renderer?

You can see the FPS at the top left of the screen (you probably have to maximize the video window, unless you have very sharp eyes). I have a PAL system, so it alternates between 50, and 25 FPS. On an NTSC system that will probably be between 60, and 30 FPS.

Removing the debug text actually makes it better, but there will be other calculations done in the final game as well. It seems like a feasable target to set, that we should reach double digit framerate in the end.

 

It's not the number of polygons that matters the most for performance, but rather it's the size of the polygons. So it's probably the BLiTTeR that is the bottleneck (e.g. due to texturemapping)

Edited by phoboz
Link to comment
Share on other sites

3 minutes ago, phoboz said:

You can see the FPS at the top left of the screen (you probably have to maximize the video window, unless you have very sharp eyes). I have a PAL system, so it alternates between 50, and 25 FPS. On an NTSC system that will probably be between 60, and 30 FPS.

Removing the debug text actually makes it better, but there will be other calculations done in the final game as well. It seems like a feasable target to set, that we should reach double digit framerate in the end.

I'm sorry I wasn't very clear with my question, though you've offered a lot of helpful information anyway. What I meant to ask was how many polygons are you able to push before the framerate drops too much? It looks like you're texturing most of these polygons too, so I am interested to know how hard you've pushed the renderer.

Link to comment
Share on other sites

13 minutes ago, alucardX said:

I'm sorry I wasn't very clear with my question, though you've offered a lot of helpful information anyway. What I meant to ask was how many polygons are you able to push before the framerate drops too much? It looks like you're texturing most of these polygons too, so I am interested to know how hard you've pushed the renderer.

I haven't really tried to push more than ~200 polygons, but it stays at 25 FPS in that case. Turning off texturemapping (using gouraud shaded polys only), makes it stay at 50 FPS.

 

We haven't considered using more detailed models than this. As this will be a one-on-one dogfight game, we focus on making the ship models look nice with textures and so on.

 

Note that I belive a game engine is best evolving in a sharp projects. So if the need arise to optimize further, add new features etc. that will happen over time. I think that Jeff Minter said that a "game is a living thing".

Edited by phoboz
  • Like 3
Link to comment
Share on other sites

1 minute ago, phoboz said:

I haven't really tried to push more than ~200 polygons, but it stays at 25 FPS in that case. Turning off texturemapping (using gouraud shaded polys only), makes it stay at 50 FPS.

 

We haven't considered using more detailed models than that. As this will be a one-on-one dogfight game, we focus on making the ship models look nice with textures and so on.

That answers my question. Will adding a background cause problems for the framerate, or is that handled well enough in hardware that it doesn't interfere with anything? I'm thinking that a scrolling shooter with sprites and polygons would be an interesting game to pursue on the Jaguar. I know the Saturn and PlayStation had some of those.

  • Like 1
Link to comment
Share on other sites

2 hours ago, zzip said:

I remember 3D hardware was one of the selling points of the Jag.     It was one of the first consoles to do so, so of course it's going to be weak compared to consoles that came a few years later like PSX, and may seem "barely 3D" in retrospect.

For sure.  So let's look a bit at the history here.  The Atari Jaguar's development really was started in what, '90-'91?  It launched late '93.  3Dfx wasn't even founded until a year later.  Saturn and PSX were right after that.  The definition of '3D hardware' was barely even a thing.  Sure there had previously been games for the ST / Amiga and even earlier that used flat polygons.  Jaguar was released on the very early days of '3D is the future'.  If it had no 3D hardware, how did they ever expect the JagVR setup to work?  (Hint, they did manage to get a working version, it's just the framerate, as we've found out much later, makes people ill if it's not 80 fps or faster...)  Hell, the VR arcade systems would use the Amiga 3000...

 

I love that people are whining about the lack of 3D, and along comes phoboz showing that it can do it just fine :)

  • Like 2
Link to comment
Share on other sites

7 hours ago, phoboz said:

This is what PhOBoZ & Krauser has been up to lately (e.g. designing some 3D models for an upcoming Jaguar 3D game that hopefully will run in double digit framerate)

 

The first ship is the vessel of Bounty Hunter N17, featured in the action adventure game Asteroite.

 

The last ship in the demo is the player's ship in the game Wormhome 2000.

 

The idea is that the game will be an arcade like dogfight game, with different missions for BH - N17 to hunt down cosmic villains.

Oh, something like BattleSphere and SpaceWar 2000? Awesome! However, that last line makes me think this is going to be more in line with Namco's Star Luster on Famicom.

  • Like 1
Link to comment
Share on other sites

14 hours ago, leech said:

Heh, sorry my brain and fingers left out a word or two... I meant 'at least' some minimal hardware.  That's what I don't get, it definitely does have 3D hardware in it.  I remember back in the day there were arguments made that it indeed had some more 3D hardware in it that made it a tad better than the PSX, one of which was the Z-buffer.

I can remember at least one Jaguar coder saying this about the Jaguar Z-buffer :

 

 

"Z-buffers are expensive and consume bandwidth during rendering. The Atari jaguar
is the only platform I know of with true hardware support for Z-buffering. Even
so, not too many people use it because of the increased rendering time"

 

John Carmack didn't seem a fan of it:

 

"The jag has some stupid hardware for z buffering and gouraud shading,
but I can just ignore it and tell the two 27mhz risc chips to do EXACTLY
what I want. A 64 bit bus with multiple independant processors may
not be the easiest thing to optimize for, but there is a LOT of
potential."

 

 

And Andrew Howe of ATD saying:

 

"Cybermorph uses hardware z-buffering and Gouraud shading. The Jaguar is
pretty damn fast at this, as it writes 64 bits (4 pixels) at a time.
Z-buffering is great for lots of small polygons (i.e. several bio-blobs
intersecting with the TGriffon) but not so efficient for large ones (like the
sides of buildings). Using the z-buffer simplifies things a lot, and most
of the polygons in Cybermorph are quite small"

 

Edited by Lostdragon
  • Like 5
Link to comment
Share on other sites

20 hours ago, phoboz said:

This is what PhOBoZ & Krauser has been up to lately (e.g. designing some 3D models for an upcoming Jaguar 3D game that hopefully will run in double digit framerate)

 

The first ship is the vessel of Bounty Hunter N17, featured in the action adventure game Asteroite.

 

The last ship in the demo is the player's ship in the game Wormhome 2000.

 

The idea is that the game will be an arcade like dogfight game, with different missions for BH - N17 to hunt down cosmic villains.

Some really good looking models and it runs pretty fast! Did you do some optimizationes to the renderer?

 

One can dream of a rail shooter ala REZ, mix of wireframe, shading and textures would run reasonable.

  • Like 3
Link to comment
Share on other sites

36 minutes ago, agradeneu said:

Some really good looking models and it runs pretty fast! Did you do some optimizationes to the renderer?

I have not attacked the renderer so much yet, rather I am in the process of understanding it, and how to use it in the most efficient way. There are room for optimizations depending of what type of game to make.

 

This code is quite different from using the Removers' library, which is really optimized for 2D. Now I have to learn some things from scratch again (e.g. really learning about some of the low level aspects of the Jaguar, which was hidden by the abstraction layer that the Removers' library provided)

 

I think that this is the long path that a Jaguar developer has to take in order to not have a game requiring 2 seconds to render a frame (using the 68k to draw pixels into framebuffer)

Edited by phoboz
  • Like 4
Link to comment
Share on other sites

22 hours ago, phoboz said:

This is what PhOBoZ & Krauser has been up to lately (e.g. designing some 3D models for an upcoming Jaguar 3D game that hopefully will run in double digit framerate)

 

The first ship is the vessel of Bounty Hunter N17, featured in the action adventure game Asteroite.

 

The last ship in the demo is the player's ship in the game Wormhome 2000.

 

The idea is that the game will be an arcade like dogfight game, with different missions for BH - N17 to hunt down cosmic villains.

This looks awesome. Very excited for this. It might be too early in the process, but any thought to multiplayer? Split screen two player?

Link to comment
Share on other sites

9 hours ago, Lostdragon said:

can remember at least one Jaguar coder saying this about the Jaguar Z-buffer :

 

 

"Z-buffers are expensive and consume bandwidth during rendering. The Atari jaguar
is the only platform I know of with true hardware support for Z-buffering. Even
so, not too many people use it because of the increased rendering time"

 

John Carmack didn't seem a fan of it:

 

"The jag has some stupid hardware for z buffering and gouraud shading,
but I can just ignore it and tell the two 27mhz risc chips to do EXACTLY
what I want. A 64 bit bus with multiple independant processors may
not be the easiest thing to optimize for, but there is a LOT of
potential."

 

 

And Andrew Howe of ATD saying:

 

"Cybermorph uses hardware z-buffering and Gouraud shading. The Jaguar is
pretty damn fast at this, as it writes 64 bits (4 pixels) at a time.
Z-buffering is great for lots of small polygons (i.e. several bio-blobs
intersecting with the TGriffon) but not so efficient for large ones (like the
sides of buildings). Using the z-buffer simplifies things a lot, and most
of the polygons in Cybermorph are quite small"

 

All of these are simultaneously correct, except the HW support isn't "stupid" as Carmack claimed (I'm sure he was just being flippant), it's just not what he needed for Doom/Wolf3D/etc. Gouraud shading is one of various shortcuts you can take to get reasonable looking lighting with relatively fast computations, but it doesn't get you the style of rendering used in Carmack's engines. In general, it works relatively well for high-polygon-count models, but kinda falls apart for low-polygon stuff. As for z-buffering, Wolfenstein, Doom, and the Quake software rasterizer* all had very precise and highly optimized occlusion culling mechanisms built in that would have performed better than z-buffering on the memory-bandwidth-constrained Jaguar. Again, not that the z-buffer mechanism on the Jaguar was "stupid" so much as those engines being very clever and being designed from the ground up to avoid the need to throw bandwidth at z-buffering to accomplish depth sorting. While porting Quake the game to run on the Jaguar isn't terribly interesting (The game data would likely never run well within the Jag's limits), porting Quake the engine to the Jaguar to see how its rasterizer, minimally optimized for Tom & Jerry as the Doom one was, performed Vs. say, the Hoverstrike one would be a fun experiment. In theory, it would be a good pairing. Still, it is interesting that Carmack praised the memory bandwidth and dismissed the z-buffering support in the same sentence. I assume if he had paused to reflect, he would have seen the irony there, but again, the spirit of the statement as a whole totally holds up when you understand how his engines of the time worked. It would have been pointless to try to make them use this fixed-function hardware.

 

Saturn didn't have z-buffer support in its HW, but they had an entire processor more or less dedicated to depth-sorting quads instead. Still, sorting  at the polygon level is hard (Google "painter's algorithm"), and likely why so many games there have a ton of shimmering when polygons overlap & animate relative to each other. The original Virtua Fighter port is famously bad at this. Zero 5 apparently does things this way though, and does fantastic job of it. I don't know what PS1 has/does in this regard.

 

The advantage of z-buffering is that it's a very simple algorithm that handles almost all cases well (Notably, it doesn't handle translucency well), but it is indeed very bandwidth intensive. I think it carried the day on modern GPUs simply because of its simplicity/generality and the fact that one thing GPUs excel at is having (or making it seem like they have) ~infinite memory bandwidth. As with many things, if the Jaguar had enough fast local RAM tied to Tom for a framebuffer or well-designed blitter cache, the zbuffering support would have been a killer feature. As-is, it's a powerful tool but you pay for it in terms of the bandwidth it chews up.

 

* I think Quake does use a z-buffer for non-map "entities", e.g., enemies and things you can blow up. It's been a long time since I looked through that stuff. Again, it would be very interesting to see how hybrid depth sorting techniques like this performed on the Jaguar if someone curious and knowledgeable had infinite time.

  • Like 2
Link to comment
Share on other sites

Doom is not a polygon 3d engine, so no wonder Carmack thought it was stupid.

But most 3d games before Jaguar, but on PC were flatshaded and the first fully gouraud shaded game, TIE Fighter, came after Cybermorph.

Even Mechwarrior 2  renders a non textured, flat/gouraud shaded 3D world.

 

  • Like 1
Link to comment
Share on other sites

There's nothing wrong at all with flat shading when done properly.  Sorry to use the PSX in the example, but comparing the fully texture mapped Tekken to the flat shaded Tobal #1, Tobal looked way better.  It ran at 640*480 at 60fps.  Give me sharp edges and fast framerate over crappy textures any day.

  • Like 3
Link to comment
Share on other sites

2 hours ago, phoboz said:

I have not attacked the renderer so much yet, rather I am in the process of understanding it, and how to use it in the most efficient way. There are room for optimizations depending of what type of game to make.

 

This code is quite different from using the Removers' library, which is really optimized for 2D. Now I have to learn some things from scratch again (e.g. really learning about some of the low level aspects of the Jaguar, which was hidden by the abstraction layer that the Removers' library provided)

 

I think that this is the long path that a Jaguar developer has to take in order to not have a game requiring 2 seconds to render a frame (using the 68k to draw pixels into framebuffer)

Just asking because it runs faster than the 3D demo I watched on yt. 

The old demo runs 15-20 FPS and around 6000 polys/sec, while your demo runs 12000 polys/sec and 25-50 FPS.

Link to comment
Share on other sites

25 minutes ago, agradeneu said:

Just asking because it runs faster than the 3D demo I watched on yt. 

The old demo runs 15-20 FPS and around 6000 polys/sec, while your demo runs 12000 polys/sec and 25-50 FPS.

The 3D models were optimized, and the size of the rendering area was reduced from 320x200, to 320x160. It was done because the cockpit will cover 40 pixels at the bottom of the screen, and there is no point in rendering stuff there that won't be seen.

  • Like 2
Link to comment
Share on other sites

22 hours ago, phoboz said:

The 3D models were optimized, and the size of the rendering area was reduced from 320x200, to 320x160. It was done because the cockpit will cover 40 pixels at the bottom of the screen, and there is no point in rendering stuff there that won't be seen.

what 3D model optimizig you are doing?
what specs on the models are beneficial for this 3d engine?

  • Like 1
Link to comment
Share on other sites

22 hours ago, phoboz said:

The 3D models were optimized, and the size of the rendering area was reduced from 320x200, to 320x160. It was done because the cockpit will cover 40 pixels at the bottom of the screen, and there is no point in rendering stuff there that won't be seen.

Hm, so this alone doubles performance? 

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...