Jump to content
IGNORED

Atari Jaguar vs 3do


JazGaming

Recommended Posts

yes.. sadly its mystlike.. and sadly its not fun to play cause of this :_(

 

but if it would had x3 the fps (and im sure there was much optimizing possible) it would be some of the best if not the best motocrossgame of its time

There is tons of room for optimization in that engine, end even without further optimizing, if they had used a 2D backdrop for the stadium and gotten rid of that ridiculous "big screen" in the stands that just shows exactly what you see on the main screen, that would have probably tripled the frame-rate. Even as it is, I do enjoy playing it once in a while, one track at a time, but it would have been outstanding if it had 3x the frame-rate. a few sprites of tires or hay bales along the track were needed to so it doesn't look like you are crashing into an invisible wall (which you are). It's definitely another example of a game Atari rushed to market in time for the holidays when it needed another 6 months to be truly finished...another beta release.

Link to comment
Share on other sites

Ummm... Well my dad gave me an A1200 when I was 8... Played Sensi to death, of course, as well as Alien Breed and Civilisation... And I got given a PS1 when I was 11, but that's about it... Everything else is just stuff I've had an interesting in getting and decided to buy and try it out... So now I have 13 consoles and plans to get more...

 

Respect.

 

I'm going to raise my daughter and son with an appreciation for the classics while acknowledging modern gaming. My daughter is 4 1/2 and she has been playing games since 2. While she primarily plays games on her iPad, when she asks to play "video games" with me, she's referring to the games on the Atari Flashback 2. She's pretty good with Warlords which, of course, is one of my all-time favorites.

 

When she gets older, I may let her play with my 5200 but that hardware's expensive, working controllers and all! :) But in the meantime, we'll be deciding between Lego Dimensions and the Disney Infinities shortly for them, and for which console.

Link to comment
Share on other sites

There is tons of room for optimization in that engine, end even without further optimizing, if they had used a 2D backdrop for the stadium and gotten rid of that ridiculous "big screen" in the stands that just shows exactly what you see on the main screen, that would have probably tripled the frame-rate. Even as it is, I do enjoy playing it once in a while, one track at a time, but it would have been outstanding if it had 3x the frame-rate. a few sprites of tires or hay bales along the track were needed to so it doesn't look like you are crashing into an invisible wall (which you are). It's definitely another example of a game Atari rushed to market in time for the holidays when it needed another 6 months to be truly finished...another beta release.

Actually, there's no way that the "big screen" has that kind of a performance impact. It's a very simple downsample of a current framebufferer (e.g. a simple nested loop that skips every 4th (or 8th or x-th) texel. Even a simple brute-force code on 68k at the given framerate (e.g. ~8 fps) would not result in significant / measurable performance drop.

 

I've done that on 68k on jag plenty times, so I am pretty sure that generating lowres texture out of the framebuffer is not going to have a big impact on framerate. Half of one vblank is most you can expect. Plus, with Blitter, you could bring that cost even further down.

 

Sure, the actual texturing of the wall slows system down a bit, but I really doubt that texturing that wall costs more than 2 vblanks (and even that is too much, considering the amount of screen space it takes up).

 

Since at framerate of 8 fps, each rendered frame takes 60/8 =7.5 vblanks, even if we gained 2 vblanks by turning big wall off, we'd be at 5.5 vblanks -> 11 fps. And that's a very generous scenario.

The numbers of course are approximate and presume there is no vsync in the game (not sure, have not played it).

 

Is there even a noticeable slowdown when the big wall comes up ?

Link to comment
Share on other sites

Is there even a noticeable slowdown when the big wall comes up ?

There isn't. I would imagine the code is as you described. I would find it hard to believe the developers could've eliminated that jumbotron screen and gotten even 1.5x the frame rate but decided that screen was more important.

Link to comment
Share on other sites

Actually, there's no way that the "big screen" has that kind of a performance impact. It's a very simple downsample of a current framebufferer (e.g. a simple nested loop that skips every 4th (or 8th or x-th) texel. Even a simple brute-force code on 68k at the given framerate (e.g. ~8 fps) would not result in significant / measurable performance drop.

 

I've done that on 68k on jag plenty times, so I am pretty sure that generating lowres texture out of the framebuffer is not going to have a big impact on framerate. Half of one vblank is most you can expect. Plus, with Blitter, you could bring that cost even further down.

 

Sure, the actual texturing of the wall slows system down a bit, but I really doubt that texturing that wall costs more than 2 vblanks (and even that is too much, considering the amount of screen space it takes up).

 

Since at framerate of 8 fps, each rendered frame takes 60/8 =7.5 vblanks, even if we gained 2 vblanks by turning big wall off, we'd be at 5.5 vblanks -> 11 fps. And that's a very generous scenario.

The numbers of course are approximate and presume there is no vsync in the game (not sure, have not played it).

 

Is there even a noticeable slowdown when the big wall comes up ?

I may not have been clear enough, maybe the extra screen wouldn't have much effect, but I meant with the combination of getting rid of the ENTIRE polygon stadium and replacing it with a 2D scrolling background, which at the same time would be removing the "big screen" window in the polygon stadium stands, would probably triple the frame-rate without further optimization. Not just getting rid of the textures on the stadium, but the entire stadium in favor of a 2D horizontally scrolling backdrop for the stadium.

 

The whole polygon stadium, textured or not, looks like shit anyway and probably slows down the frame-rate drastically where a 2D scrolling 16 or 24-bit color background would have been much nicer looking and taken a lot of burden off of the 3D engine increasing the frame-rate without even optimizing the 3D engine further, then if you did optimize it further, we could probably have had a 30fps game.

Edited by Gunstar
Link to comment
Share on other sites

Hack it to take it out. Then you'll know. Even if you have to learn assembly to do it you'll still have an answer quicker than waiting for vladr.

These thoughts, questions, about it are merely academic. I'm not really interested in seeing it done, it's just curiosity if these steps alone could make it better. If and when I do decide to delve into Jag programming and learning assembly I'd put my time to better games to hack and original home brews. Besides, wouldn't require the source code? There seems to be only a handful of Jag games that the source has been made available for, and I don't recall SC3D being one or them.

 

If I where to get into Jag programming, my first full-scale project would be an original racing game, probably polygon and probably garaud shaded for a better look than something like Checkered Flag, but still capable of a good frame rate. Or mostly 2D like Super Burnout but with garaud shaded polygon cars.

 

VladR just seems to be the one of the few people interested in discussing this stuff if even purely on an academic level. I just have fun speculating about this stuff. Sorry if it annoys you.

 

Honestly, I prefer spending my free time playing games and talking and speculating about software and hardware, and occasionally hacking hardware and repairs and refurbishments. You apparently would rather do home brews and ports in your free time. Everyone has their own interests and hobbies to spend their free time, to each their own I say.

Edited by Gunstar
Link to comment
Share on other sites

...also from years of SW development unless the code is obviously so bad that it is the culprit one way or another I personally stopped speculating on what causes perf impacts and what doesn't until I run some sort of a profiler run or perf counting (latency, call counts, cache misses etc..).

Many times I speculated/guessed wrong because the code I thought was responsible, although it could have been optimized, was not the one being executed the most hence not in the critical path after all.

 

I am not saying that your guess about removing the 3D stadium and replace it with a "static" backdrop a la VF for Saturn would not improve the frame-rate, I just wouldn't be so sure that it would buy a 3x fps increase .... again your guess may be correct in the end but I wouldn't be surprised if the impact is not that marked either.

 

EDIT: also garaud = Gouraud, named after Henri Gouraud

Edited by phoenixdownita
Link to comment
Share on other sites

There's no source for any of the ports I've made and i didn't use the source for the cf patch.

 

It is absolutely not require

 

...also from years of SW development unless the code is obviously so bad that it is the culprit one way or another I personally stopped speculating on what causes perf impacts and what doesn't until I run some sort of a profiler run or perf counting (latency, call counts, cache misses etc..).

Many times I speculated/guessed wrong because the code I thought was responsible, although it could have been optimized, was not the one being executed the most hence not in the critical path after all.

 

I am not saying that your guess about removing the 3D stadium and replace it with a "static" backdrop a la VF for Saturn would not improve the frame-rate, I just wouldn't be so sure that it would buy a 3x fps increase .... again your guess may be correct in the end but I wouldn't be surprised if the impact is not that marked either.

 

EDIT: also garaud = Gouraud, named after Henri Gouraud

 

Thanks for the Gouraud correction, I have always had trouble remembering how to spell that correctly, and it is quite often misspelled by others, who I would copy. Spell checker seemed to be no help, but I was unaware of whether it was a proper name or invented word in the age of computers (or exactly why it was selected if so, like some sort of acronym or something). Even now it shows as a misspelled word in this forum text editor where we have used it. I will right it down for the future.

 

As to your other comments above, I appreciate the insight, but I am a hardware guy, not software, and my speculation is purely for academic enjoyment, I doubt I will ever have the time or inclination to learn any programming and attempt to put it to use in any practical speculative hacking or otherwise. Just like academic philosophy, which is rarely made practical. My use of these forums is purely for entertainment and social interaction with other fans of the system(s). It does not mean that I don't have good ideas or concepts about games, and one never knows where an idea might come from and provide a spark of creativity to those who do program. Laymen often see thing from a perspective different from the experts or see something simple and basic that becomes overlooked by experts in their high-thinking. I remember a true story I heard long ago, about a semi-truck that had gotten wedged into an underpass and all the police, firemen and other "experts" on the scene worked for many hours trying to solve the problem of removing the semi from the overpass, when a young girl in a passing car suggested to a police officer, when the vehicle was held up, to simply remove the air from the tires, which the astonished police officer then proceeded to tell the other "experts" and the semi was easily removed.

Edited by Gunstar
Link to comment
Share on other sites

I may not have been clear enough, maybe the extra screen wouldn't have much effect, but I meant with the combination of getting rid of the ENTIRE polygon stadium and replacing it with a 2D scrolling background, which at the same time would be removing the "big screen" window in the polygon stadium stands, would probably triple the frame-rate without further optimization. Not just getting rid of the textures on the stadium, but the entire stadium in favor of a 2D horizontally scrolling backdrop for the stadium.

 

The whole polygon stadium, textured or not, looks like shit anyway and probably slows down the frame-rate drastically where a 2D scrolling 16 or 24-bit color background would have been much nicer looking and taken a lot of burden off of the 3D engine increasing the frame-rate without even optimizing the 3D engine further, then if you did optimize it further, we could probably have had a 30fps game.

Oh, the whole stadium - that's a different thing. Sorry, if I misread that earlier.

 

The entire stadium often covers substantial part of the screen, so its performance impact is definitely very big.

 

You could definitely replace it with a 2D scrolling bitmap that jag's ObjectProcessor would scale (based on your distance) for roughly ~free - this way you would get the zooming in/out currently handled by 3D engine. Plus, the hand-drawn 2D bitmap would be easily nicer than the lowres texture there is right now.

The bitmap would have to be 16-bit, as with 24-bit regime you allegedly can't mix 16bpp and 24bp bitmaps (though I would speculate that a GPU interrupt object should be able to accomplish this). This bitmap could be animated (e.g. people cheering) - 4-6 frames should be enough - the cost of switching the frames is virtually zero (change one pointer in OP list and have a separate autoincremented counter with one condition).

 

As for the performance impact, even at ~8 fps, we probably would still not double it to 16 - but we should come close to this - I reckon 12-14 fps would be realistic, given how much the 3D engine would be offloaded (less polygons to transform&clip - though that is a negligible task compared to texturing).

 

To get to 30 fps, though, on Jag, you'd have to downscale the res to 175x240 (e.g. as in Doom) and completely refactor the 3D engine to run within GPU. And switch to 8-bit, but considering the terrain textures are really only tinted greyscale, that would be enough, as other opponents can be 16bpp bitmaps.

Link to comment
Share on other sites

 

As for the performance impact, even at ~8 fps, we probably would still not double it to 16 - but we should come close to this - I reckon 12-14 fps would be realistic, given how much the 3D engine would be offloaded (less polygons to transform&clip - though that is a negligible task compared to texturing).

 

To get to 30 fps, though, on Jag, you'd have to downscale the res to 175x240 (e.g. as in Doom) and completely refactor the 3D engine to run within GPU. And switch to 8-bit, but considering the terrain textures are really only tinted greyscale, that would be enough, as other opponents can be 16bpp bitmaps.

Hmm...I figured, since the engine was so pitifully slow, even compared to other 3D Jag games, and the fact that there really isn't much to it, it's a small area, not a whole world like the morph games or Hoverstrike, Iron Soldier, etc., that there would be a ton of optimization possible keeping it at the current resolution(though I realize that those worlds aren't completely rendered at once, and there is a draw distance, but I think the area SC3D covers might still be less). Or, if it was just moved to the GPU as you suggest. But obviously you know more about it than I, who only derives ideas from what I have seen done in other games, and not a wit of programming knowledge. Maybe just switching to 8-bit and keeping the current resolution? But even at 14-16fps it would make a world of difference in it's playability.

Edited by Gunstar
Link to comment
Share on other sites

These thoughts, questions, about it are merely academic. I'm not really interested in seeing it done, it's just curiosity if these steps alone could make it better. If and when I do decide to delve into Jag programming and learning assembly I'd put my time to better games to hack and original home brews. Besides, wouldn't require the source code? There seems to be only a handful of Jag games that the source has been made available for, and I don't recall SC3D being one or them.

 

If I where to get into Jag programming, my first full-scale project would be an original racing game, probably polygon and probably garaud shaded for a better look than something like Checkered Flag, but still capable of a good frame rate. Or mostly 2D like Super Burnout but with garaud shaded polygon cars.

Merely academic = talking utter nonsense with nothing to back it up. As CJ pointed out, source code isn't necessary to hack code. How do you think people crack retail software? They ask the author for the source code and just remove the license check routine and recompile the code?

 

I look forward to your first ever project in assembly on a console being a game that looks better than Checkered Flag. Should be pretty easy to do for a first-time coder.

Link to comment
Share on other sites

Merely academic = talking utter nonsense with nothing to back it up. As CJ pointed out, source code isn't necessary to hack code. How do you think people crack retail software? They ask the author for the source code and just remove the license check routine and recompile the code?

 

I look forward to your first ever project in assembly on a console being a game that looks better than Checkered Flag. Should be pretty easy to do for a first-time coder.

post-40055-0-59810700-1447259659_thumb.jpg

Don't hold back, tell us how you really feel.

Link to comment
Share on other sites

attachicon.gifbeating_a_dead_horse_by_pjperez.jpg

Don't hold back, tell us how you really feel.

Spewing utter nonsense accusing others of spewing utter nonsense. It's too bad people have to keep quoting the jerk so I see his crap even when I have him on ignore.

Link to comment
Share on other sites

Hmm...I figured, since the engine was so pitifully slow, even compared to other 3D Jag games, and the fact that there really isn't much to it, it's a small area, not a whole world like the morph games or Hoverstrike, Iron Soldier, etc., that there would be a ton of optimization possible keeping it at the current resolution(though I realize that those worlds aren't completely rendered at once, and there is a draw distance, but I think the area SC3D covers might still be less). Or, if it was just moved to the GPU as you suggest. But obviously you know more about it than I, who only derives ideas from what I have seen done in other games, and not a wit of programming knowledge. Maybe just switching to 8-bit and keeping the current resolution? But even at 14-16fps it would make a world of difference in it's playability.

- area: no, you are completely correct. Reducing the whole world down to a renderable area may be quite a CPU-intensive task. It's a problem that has way too many approaches and algorithms. In short, it's far from free. Super cross does not have to handle this at all.

 

- 14-16 Fps: Sure, it would be much comfortable to steer the bike at double frame rate. However, I'm sure you noticed that lots of people would bitch about the game anyway. There can always be found some obscure nonsense. Plus, it doesn't help that the game in itself is a niche. Out of 10 people you can easily find 4-5 who enjoy car racing games. But bikes? On a circuit? Maybe 1-2 in 10?

Link to comment
Share on other sites

Just for fun.

 

I am aware that Doom for 3DO is not good but a little known detail, if you run it with the rendering windows at its smallest which I believe at that point is smaller than 1/2 screen but bigger than 1/3 of the screen [so maybe native 200 out of 320?], the framerate gets much smoother. In the same full res stuttering areas you can see gains of almost 70% (yep anecdotally almost twice as fast).

 

My experiment was in the first enclosed area of level 1 after the first door you have to open. I was playing at super-easy, killed the lonely marine there.

At that point staring at the "marine alcove" [for lack of better words] I simply rotated around and roughly timed how long it took to get back looking at the same spot. On an NTSC 3DO max size sceen it took about 5secs on min size screen around 3secs, and it seems it is all gained by the engine not stuttering so much [so maybe the slowdowns are due to the engine not dropping frames and yet taking longer to render, not that is generates that many frames to begin with but ...].

 

By looking at the textures between the various resolutions it seems like as the screen size increases the textures details increase as well [not linearly but somewhat you can tell there's finer details rather than a wholesale scaling].

 

My hypothesis is that rather than having the game play at a fixed resolution and simply scaling the results (2x or 3x however it may be) it actually increases the resolution rendered as it increases the screen size and also it uses more detailed textures.

 

The Jag version does not have re-sizable area if memory serves so I am not sure at what resolution it runs.

 

I prefer the Jag version (lack of sound notwithstanding), just unsure why on the 3DO they didn't settle for a fixed resolution (or maybe 2) and "magnification" rather than a choppy mess at the higher sizes.

Not even sure even at the smallest size it still fares any good wrt to the Jag version.

 

Just wanted to point out this experiment, not saying anything against the Jag or for the 3DO.

If you have it just try it for yourself and see what I mean, yes it feels like playing on a post-stamp but at that point the slowdowns are barely noticeable at least in the first 2 rooms of level 1, at max screen size it's already slowdown hell. I didn't experiment any further, there are better ways to enjoy Doom anyway.

Edited by phoenixdownita
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...