What could have saved the Jag?

[+Stephen]

I would think that not having standard PC as a dev kit was another hindrance.  Making devs use a Falcon / TT couldn't have helped anything. 

[laymanpigeon]

Falcon is anemic compared to TT, I would pity those that got latter as dev kit.

 

Largest hurdles for compillers on Jaguar were of course hardware bugs.

Another if those solved then 4KB SRAM on Tom could cache textures.

Like 8 bit uncompressed textures be it one 64x64 or four 32x32.

[+CyranoJ]

15 minutes ago, laymanpigeon said:

Another if those solved then 4KB SRAM on Tom could cache textures.

Like 8 bit uncompressed textures be it one 64x64 or four 32x32.

 

Where do people get this stuff? LOL

[Matt_B]

14 hours ago, agradeneu said:

NES, SNES and Game Boy games were programmed mostly in assembly too. Otherwise the performance would have been crippled.

Those consoles all had slightly modernized versions of CPUs designed in the 1970s though. It's rather difficult to get efficient compiler output when there's such a high degree of asymmetry with addressing modes and most of the registers have a single function.

For an early 90s RISC processor, you definitely wanted a compiler though. They're a lot harder to do hand-coding with but their instruction sets tend to give compilers a bit of a leg up.

 

Even a lot of the 68K and x86 machines were seeing a lot of the development done in high level languages, but with hand optimization for the code that generated the graphics and other timing critical parts. Developers moving from machines like the PC and Amiga to the Jaguar would not be impressed by having to write everything in assembler for a processor the likes of which they'd never seen.

[JagChris]

56 minutes ago, laymanpigeon said:

Largest hurdles for compillers on Jaguar were of course hardware bugs.

There was one bug Atari couldn't figure out or didn't even try to.

 

High Voltage Software came up with their own fix for it It seems to have been trivial for them because they can't even remember what their solution was. They combined it with an LRU caching system and a DSP engine 30X more efficient than anything Atari had allowing the DSP to help the GPU. Using C on the GPU became what they referred to as easy and efficient for them. They tried several times to let Atari know what they accomplished and got ignored.

 

Though some think the significance of a gpu compiler is overplayed I think it did have some significance since most the games used the 68k and ran like crap.

 

And the other systems had compilers. 3do, Saturn and PSX. Saturn may have had asm libraries but it still had a compiler for the average programmer to use. And the 3do came out before the Jag and still had a compiler setup.

 

And even if they didn't they had off the shelf well known chips with full support of the manufacturer. The Jag had brand new buggy custom chips completely alien to the computing world with the full backing of... Atari.

 

The fact that most developers favored the 68k on the Jag speaks volumes I think about the need for a GPU compiler even back then.

Edited August 27, 2022 by JagChris

[JagChris]

30 minutes ago, Matt_B said:

 by having to write everything in assembler for a processor the likes of which they'd never seen.

😅

I think guys like @Seedy1812are probably still traumatized by this.

Edited August 27, 2022 by JagChris

[+CyranoJ]

3 hours ago, Matt_B said:

Developers moving from machines like the PC and Amiga to the Jaguar would not be impressed by having to write everything in assembler for a processor the likes of which they'd never seen.

 

The jRISC instruction set is, for the most part, a subset of the 68000 instructions, and the chips function is much the same way - so that statement is completely wrong for any competent assembly coder.

[Matt_B]

39 minutes ago, CyranoJ said:

The jRISC instruction set is, for the most part, a subset of the 68000 instructions, and the chips function is much the same way - so that statement is completely wrong for any competent assembly coder.

Sure, at least to the extent that we're talking about competent assembly coders.

 

However, I was thinking more of those who'd already got used to developing in HLLs. You don't necessarily need to know much about the 68K instruction set to write a game in C, or even Blitz BASIC.

 

 

 

[agradeneu]

4 hours ago, Matt_B said:

Sure, at least to the extent that we're talking about competent assembly coders.

 

However, I was thinking more of those who'd already got used to developing in HLLs. You don't necessarily need to know much about the 68K instruction set to write a game in C, or even Blitz BASIC.

 

 

 

Home computer or console development community, e.g. Atari ST was very proficient with Assembly.  I think any proficient game/demo development was common with 68K. It was nothing exotic. 

 

[agradeneu]

9 hours ago, JagChris said:

There was one bug Atari couldn't figure out or didn't even try to.

 

High Voltage Software came up with their own fix for it It seems to have been trivial for them because they can't even remember what their solution was. They combined it with an LRU caching system and a DSP engine 30X more efficient than anything Atari had allowing the DSP to help the GPU. Using C on the GPU became what they referred to as easy and efficient for them. They tried several times to let Atari know what they accomplished and got ignored.

 

Though some think the significance of a gpu compiler is overplayed I think it did have some significance since most the games used the 68k and ran like crap.

 

And the other systems had compilers. 3do, Saturn and PSX. Saturn may have had asm libraries but it still had a compiler for the average programmer to use. And the 3do came out before the Jag and still had a compiler setup.

 

And even if they didn't they had off the shelf well known chips with full support of the manufacturer. The Jag had brand new buggy custom chips completely alien to the computing world with the full backing of... Atari.

 

The fact that most developers favored the 68k on the Jag speaks volumes I think about the need for a GPU compiler even back then.

The only game that allegedly used that HVS compiler you are talking about was Ruiner Pinball. Well, it has slowdowns and it does nothing really groundbreaking in any category. It is not even 3D. 

Can we conclude that there is little evidence for any of your assumptions?  

 

 However, there is a lot of evicence that quality of games like Rayman, AvP or Iron Soldier have no context with some sort of compiler doing magic. Carmack wrote his own custom compiler for the DOOM port.

 

 

 

 

Edited August 27, 2022 by agradeneu

[+CyranoJ]

6 hours ago, Matt_B said:

Sure, at least to the extent that we're talking about competent assembly coders.

 

However, I was thinking more of those who'd already got used to developing in HLLs. You don't necessarily need to know much about the 68K instruction set to write a game in C, or even Blitz BASIC.

 

Hardly any commercial games on any platform at the time the Jaguar was released were written in high level languages.  The next generation (Saturn, PSX) brought that in. So, yes, what you said is meaningless in context of the timeframe.

[JagChris]

5 hours ago, agradeneu said:

The only game that allegedly used that HVS compiler you are talking about was Ruiner Pinball. Well, it has slowdowns and it does nothing really groundbreaking in any category. It is not even 3D. 

Can we conclude that there is little evidence for any of your assumptions?  

Don't remember any slowdown in Ruiner. And it wasn't necessarily about groundbreaking it was about ease of development for the company. And Vid Grid also used it and TRF.

 

You can conclude whatever you want. This was related by the developers. But yeah I'm sure Scott Corley, Adisak Pochanayon and Brian McGroarty were all just making this story up.

[agradeneu]

20 minutes ago, JagChris said:

Don't remember any slowdown in Ruiner. And it wasn't necessarily about groundbreaking it was about ease of development for the company. And Vid Grid also used it and TRF.

 

You can conclude whatever you want. This was related by the developers. But yeah I'm sure Scott Corley, Adisak Pochanayon and Brian McGroarty were all just making this story up.

Well, there is slowdown in Ruiner. Maybe just play it? It is not regarded as a glowing example of a Jaguar game anyway. 

 

I even won't discuss their other games, WMCJ anyone?

 

 

So, if you are focusing on quantity rather than quality of games, you might be right about the potential impact of that compiler.

 

However, despite the nice port of NBA JAm, HVS was a mediocre developer on the Jaguar at best. So what is your evidence of any groundbreaking results of their development efforts? There is none, simple as that. 

 

The problem of Jaguar was always quality, not quantity. And  I see no evidence there was a "one trick pony" to fix that. You are way overstating the impact of such tool probably because your approach to development is purely theoretical, not practical. All redundant talk, no proof whatsoever.

 

 

 

 

Edited August 27, 2022 by agradeneu

[JagChris]

58 minutes ago, agradeneu said:

Well, there is slowdown in Ruiner. Maybe just play it?

I've played the hell out of Ruiner and have never seen slowdown, even in multi-ball. I've looked. When you find a video that shows or can record this slowdown you let me know and I'll stand corrected.

 

Their setup was groundbreaking in that they didn't have to use assembly from the ground up on the GPU. Or worry about overlays. And this set up only became mature with Ruiiner so Ruiner and everything after was what used it according to the developers.

 

And opinions on the quality of their games is a different matter. And just an opinion. For instance it seems to be trendy to bash white men can't jump. And a lot of people like living in memes and trends.

Edited August 27, 2022 by JagChris

[agradeneu]

4 minutes ago, JagChris said:

I've played the hell out of Ruiner and have never seen slowdown, even in multi-ball. I've looked. When you find a video that shows or can record this slowdown you let me know and I'll stand corrected.

 

Their setup was groundbreaking in that they didn't have to use assembly from the ground up on the GPU. Or worry about overlays. And this set up only became mature with Ruiiner so Ruiner and everything after was what used it according to the developers.

 

And opinions on the quality of their games is a different matter. And just an opinion. For instance I think it's trendy to bash white men can't jump. And a lot of people like living in memes and trends.

Lol, whatever.

 

[Austin]

Ruiner has a ton of frameskipping, not slowdown. It basically can’t keep a stable framerate which can make it jarring to play. That said, I am pretty sure it’s the only game on the system that is constantly scaling a 2D playfield and its objects the way it does. Especially on the Ruiner table itself, there’s a lot going on which I am doubting was an easy task to pull off. It’s not a shining example of a pinball game because of performance issues, but it’s still cool to see nonetheless.

[agradeneu]

19 minutes ago, Austin said:

Ruiner has a ton of frameskipping, not slowdown. It basically can’t keep a stable framerate which can make it jarring to play. That said, I am pretty sure it’s the only game on the system that is constantly scaling a 2D playfield and its objects the way it does. Especially on the Ruiner table itself, there’s a lot going on which I am doubting was an easy task to pull off. It’s not a shining example of a pinball game because of performance issues, but it’s still cool to see nonetheless.

I disagree, the Ruiner table slows down when player activates the parachutes and scaling planes at the top of the left table. 

I dont think it is even running 60FPS, but rather 30?

Overall, there are some cool effects yes, but the artwork is very inconsistent, just like the performance and table designs. Flipper physics are somewhat off. 

I like it and it is quite enjoyable. But I see nothing too special about it, except the scaling and rotation effects. (However the gfx get very pixelated when zoomed out, and there is slowdown)

 

EDIT: Music and sound FX are very soso. Mediocre, just like most aspects of the game. 

 

The performancce might have been improved by incremental and custom optimizations of the engine. The artwork could have been improved and polished as the designs of the tables.

There is a lot of practical evidence that optimizations in Assembly is the way the improve performance and detailed customizations of the engine to make it just do the things the game needs.  

 

 

 

Edited August 27, 2022 by agradeneu

[Chilly Willy]

7 hours ago, agradeneu said:

Home computer or console development community, e.g. Atari ST was very proficient with Assembly.  I think any proficient game/demo development was common with 68K. It was nothing exotic. 

 

 

I was working on the Amiga at the time, and I agree. Everything but my last project on the Amiga was 100% assembly. The last Amiga product I worked on was done mostly with SAS/C. Between the ST, the Amiga, and the Mac, there were a LOT of people used to programming the 680x0 in assembly. When the PPC accelerators started becoming more dominant, I did a few things on it with StormC.

[42bs]

1 hour ago, JagChris said:

Their setup was groundbreaking in that they didn't have to use assembly from the ground up on the GPU. Or worry about overlays. And this set up only became mature with Ruiiner so Ruiner and everything after was what used it according to the developers.

Any reference for this statement?

[JagChris]

8 minutes ago, 42bs said:

Any reference for this statement?

Yes.

 

http://www.3do.cdinteractive.co.uk/viewtopic.php?f=35&t=3356#p37117

 

Then follow the HVS gpu manager story link at the bottom if you want the in depth part.

Edited August 27, 2022 by JagChris

[42bs]

9 minutes ago, JagChris said:

Yes.

 

http://www.3do.cdinteractive.co.uk/viewtopic.php?f=35&t=3356#p37117

 

Then follow the HVS gpu manager story link at the bottom if you want the in depth part.

I need to check if they did copy the overlay code from JagTris 🙂 for their GPUMGR 

[agradeneu]

11 minutes ago, JagChris said:

Yes.

 

http://www.3do.cdinteractive.co.uk/viewtopic.php?f=35&t=3356#p37117

 

Then follow the HVS gpu manager story link at the bottom.

A31chris is Jagchris just for your info. 

 

 

Edited August 27, 2022 by agradeneu

[JagChris]

5 minutes ago, 42bs said:

I need to check if they did copy the overlay code from JagTris 🙂 for their GPUMGR 

You made your own overlay manager? Holy moly.

 

Didn't you also solve the problem of using the 68k for vertical blank as well some 20+ years ago?

 

It's possible they were skulking around the underground. I think Adisak use to frequent Jaguar Interactive way back when.

[42bs]

2 minutes ago, JagChris said:

You made your own overlay manager? Holy moly.

 

Didn't you also solve the problem of using the 68k for vertical blank as well some 20+ years ago?

 

It's possible they were skulking around the underground. I think Adisak use to frequent Jaguar Interactive way back when.

Well, not that sophisticated as HVS claims, their manager is.

But stopping the 68k saves a lot of cycles. In JagTris it runs only for the MOD player. With LSP instead of tIn's player the 68k would be shut of completely.

 

[JagChris]

22 minutes ago, agradeneu said:

A31chris is Jagchris just for your info. 

 

 

Yes. 

 

When I joined AA in 2003 I quickly decided on a name. When I was browsing the forum there was jagwarlord, Jaggod, Jag this, jag that. This name was a lazy follow suite and quickly slap a jag prefix onto the front. If I think about it I've never really liked the name I hastily gave myself but some mistakes are built to last.

Edited August 27, 2022 by JagChris