Jump to content
IGNORED

Super Burnout : Hidden Jaglink mode ?


Fredifredo

Recommended Posts

I removed my posts....now if Orion would do the same....Somehow I don't think Oliver cares either way.

He probably popped in seeing the interest in his game. I expect some of you think he might stick around.

I would not count to hard on it. Im sure he is a busy man coding for those other systems anyway.

Edited by Gorf
Link to comment
Share on other sites

BTW as that time I believe SBO had one of the best music player on Jaguar. We were able to play music 10 voices at 32 Khz with the best quality, no phasing, almost regardless of the number of sprites during the game with bikes, voices - ok, beside 2 players mode ;). Funny to see that at that time most of the games were struggling even to play 4 voices when there had an average number of sprites on the screen, doom was a perfect example of that.

In the main menu, because there was no bike to play and almost no GPU usage, we were able to play 16 voices at 50 KHz, the sound was really clear.

 

Anyway, I still do remember some of the technical details so if you have some questions don't hesitate, maybe my experience can help some new Jaguar developper ;)

 

Interesting. Thank you so much for these gems :)

 

This makes me think I have still some work to do on my mod player because I am far from such performance.

I am really impressed by 16 voices at 50 kHz! I would love to know the tricks you used ;)

Edited by SebRmv
Link to comment
Share on other sites

I don't know how often I'll be able to come back here, but hey let's continue to chat... ;)

 

>>1. Was there any build (albeit unstable) that included the buggy network feature that has somehow survived all these years?

 

Nope, I don't think so. I don't even have the sources anymore of SBO. Because this game has been released it may be possible to reverse engineer the code, the network code might just be simply deactivated, but I don't think it's worthwhile though.

 

>>2. What happened with Shen Technologies?

 

The company died in 1999, one year after I left.

 

>>3. The game you worked on after SBO, which you say was called "Nexus" sounds pretty cool. Is there anything you can tell us about it? I'm assuming it was to be for the Jaguar? How far along were you guys able to get on it before Atari said "bye bye?" Does Nexus exist today in the form of either early builds or ports to other platforms?

 

Same thing as SBO, I was not as careful on the archives at that time ;) Funny that I just saw some screenshots of SBO with "Stellar X" on it, and that was the first name of Nexus (I forgot that).

Kheang gave a great interview explaining a bunch of details (and I forgot a lot of them). But it's in French.

We had a big portion of the assets, a couple of levels done. In short, we were trying to reproduce Raiden with much more animation, details, several moving backgrounds with choreography, more agressive artistic design with prerendered raytraced objects displayed on 2D. I'm still proud of that code (maybe more than SBO actually, although there are a couple of good tricks in SBO as well ;).

 

IIRC, on the code side, everything was developped with the DSPs, nothing with the 68000, except just boot and VBL sync.

Because there was only 4 KB of memory on the GPU, I was hot-swapping portions of the assembly code, modules by modules, trying to reuse as much as possible the cached memory (something that is also done commonly on PS3 SPUs).

Everything worked well together and I'm pretty sure I still had CPU cycles left even with more than 1000 sprites on the screen.

By the way, I was displaying the 1000+ sprites on Jag with a trick on the display-list.

The Jag was a killer in 2D (ok, at that time ;), but the only downside was that if the display list contained too many sprites, it actually ate bandwidth on the sprites to display,

creating sometime this wobbling effect on some line (due to the fact the jag didn't have screen buffer but was diplaying everything on the fly, nice design to save expensive memory

but with some constraints ;)

So the way I resolved that was to actually use the branches of the display list, by having 3 levels of branches I was actually able to split the screen in 8 horizontal bands of 30 pixels or so.

Then I just had to fill each of the sub-display lists separatly, thus I just had 125+ sprites per display list, but 1000+ total displayed on the screen.

That way each horizontal line had almost full bandwidth to display the sprite.

The nightware was on the GPU side though, every single sprite had to be split in pieces to be placed on the proper horizontal band with the propoer offset initialized. Sometime sprites like bosses could be split over the whole 8 bands. Everything was displayed with that, even the multiple level of tiles for the background.

  • Like 2
Link to comment
Share on other sites

ol' Oliver is gone with the wind.

 

Why would you say that? lol *edit, nevermind, I see your next post. ;)*

 

Post removed by Gorf to avoid scaring Oliver away.

 

LOL. :D

 

C'mon, he doesn't seem like the type that scares easily. ;)

 

Olivier, it's so great you are taking the time to contribute to the Jag community. I know a lot of the hardcore Jag collectors live for this type of stuff. ;) Do you by chance have any sort of Jaguar collection? :P And did you know that people were developing homebrew games on the Jag after Atari died? :)

 

A LOT of people were wondering what Stellar X was and now we know. :) It's also very cool that you tried to get something out of the Jaguar, instead of how a lot of other companies just used the 68000 to port 16-bit games. ;)

 

Nexus sounded really cool. Great technical info too. Thanks. :)

Edited by kevincal
Link to comment
Share on other sites

>>I am really impressed by 16 voices at 50 kHz! I would love to know the tricks you used

By design, the sound DSP has the lowest priority to the bus access of the whole system (or something like that).

The reason is that the sprite engine could not wait at all as it was almost displaying the stuff in realtime to the TV, and Atari felt that the sound could wait a bit longer.

Although I think they were right that explained why for most Atari games the sound was dephasing when a lot of sprites were displayed

(could not read sound samples fast enough as the sprite engine was eating all the bandwidth).

 

About the trick:

First I assume that your code is optimized already (you should have around 5 to 10 asm instructions per sampling computed), otherwise optimize this first ;)

In order to reduce the dephasing with the sound the solution was to actually reduce the numbers of memory access by the DSP, thus there is less latency.

 

Instead of reading one sample at a time (just one byte), I actually read 32 bits at a time on a register. And for every sample read, I actually was taking the correct byte in the 32 bits register.

I was uploading the 4 next samples only as needed. By just doing this, I was able to roughly divide the number of memory accesses by the DSP by 4 and that's why we had more voices and quality than other Jag games. Also a nice side effect is that the number of samples read on the memory didn't change depending of the replay frequency (we would just read several times the same byte in the register). And that's why the 50 Khz was cheaper than the other method.

Obviously doing this trick with the register shifting made the code more complicated, so the asm code was slower but significantly reduced memory accesses which was the bottleneck.

 

Another idea that I don't remember if I implemented was that the DSP had to wait after the rendering, so the best was to read several samplings in a row. As for each sprite, when the rendering started it did not give up any bus cycle before the end. By reading several samples in a row (like 400 = 100 * 32 bits) and storing them on the cache we could read them later regardless of the bus state. And usually when the rendering released the bus, there was usually cycles free in a row as well. We don't want to waste that ;)

  • Like 2
Link to comment
Share on other sites

I don't know how often I'll be able to come back here, but hey let's continue to chat... ;)

Ah, but we DO appreciate you taking the time you already have :) How long you're able to do it is up to you, but I just want to let you know in the strongest terms possible, that we appreciate your presence and the willingness you've had to put up with us :D

>>1. Was there any build (albeit unstable) that included the buggy network feature that has somehow survived all these years?

 

Nope, I don't think so. I don't even have the sources anymore of SBO. Because this game has been released it may be possible to reverse engineer the code, the network code might just be simply deactivated, but I don't think it's worthwhile though.

That would be interesting. However, we are a group that will respect the work you did and not mess with forces we shouldn't :) I'm not sure about the legality of reverse engineering games, but if someone had the skill (and it was legal) it would definitely be cool to be able to look into it and see if that net code is still there -- just deactivated.

>>2. What happened with Shen Technologies?

 

The company died in 1999, one year after I left.

You must have been the corner stone, then ;) I'm sure it's interesting to look back to those days and see where you are now... with EA, I believe others here have said. That's quite the job and it shows that you're indeed a talented fellow.

>>3. The game you worked on after SBO, which you say was called "Nexus" sounds pretty cool. Is there anything you can tell us about it? I'm assuming it was to be for the Jaguar? How far along were you guys able to get on it before Atari said "bye bye?" Does Nexus exist today in the form of either early builds or ports to other platforms?

 

Same thing as SBO, I was not as careful on the archives at that time ;) Funny that I just saw some screenshots of SBO with "Stellar X" on it, and that was the first name of Nexus (I forgot that).

Kheang gave a great interview explaining a bunch of details (and I forgot a lot of them). But it's in French.

We had a big portion of the assets, a couple of levels done. In short, we were trying to reproduce Raiden with much more animation, details, several moving backgrounds with choreography, more agressive artistic design with prerendered raytraced objects displayed on 2D. I'm still proud of that code (maybe more than SBO actually, although there are a couple of good tricks in SBO as well ;).

Too bad about the archives hehe. Hindsight is always 20/20, though ;) Even though you may not think some of this is interesting, we definitely do :D Many of us are so incredibly eager to know about existing jaguar games as well as ones that never made it out. We sure are an odd bunch :)

IIRC, on the code side, everything was developped with the DSPs, nothing with the 68000, except just boot and VBL sync.

That is something very significant. It's great to see that at least one person, who was an original dev on the Atari Jaguar, had an idea how to get more bang out of our black kitty! Gorf tells us all the time that new devs need to lay off the 68k (and rightfully so!) It's unfortunate that very few developers of yesteryear did not try a little harder -- or more appropriately, that Atari did not give them the tools necessary to keep the coding bopping along at a steady pace :|

Because there was only 4 KB of memory on the GPU, I was hot-swapping portions of the assembly code, modules by modules, trying to reuse as much as possible the cached memory (something that is also done commonly on PS3 SPUs).

Everything worked well together and I'm pretty sure I still had CPU cycles left even with more than 1000 sprites on the screen.

By the way, I was displaying the 1000+ sprites on Jag with a trick on the display-list.

The Jag was a killer in 2D (ok, at that time ;), but the only downside was that if the display list contained too many sprites, it actually ate bandwidth on the sprites to display,

creating sometime this wobbling effect on some line (due to the fact the jag didn't have screen buffer but was diplaying everything on the fly, nice design to save expensive memory

but with some constraints ;)

So the way I resolved that was to actually use the branches of the display list, by having 3 levels of branches I was actually able to split the screen in 8 horizontal bands of 30 pixels or so.

Then I just had to fill each of the sub-display lists separatly, thus I just had 125+ sprites per display list, but 1000+ total displayed on the screen.

That way each horizontal line had almost full bandwidth to display the sprite.

The nightware was on the GPU side though, every single sprite had to be split in pieces to be placed on the proper horizontal band with the propoer offset initialized. Sometime sprites like bosses could be split over the whole 8 bands. Everything was displayed with that, even the multiple level of tiles for the background.

... I don't understand much of that, but there are still devs here today who can benefit from the information you give. Thank you so much again!

 

I believe it was mentioned a couple of times already, but can you tell us a little more about the games you've developed (and that were released) since you stopped coding for the Jaguar? It would be interesting to know what game development teams you've been a part of over the years :)

Link to comment
Share on other sites

I don't know how often I'll be able to come back here, but hey let's continue to chat... ;)

OlivierNallet - thank you so much for posting and sharing your thoughts and experiences on Super Burnout and the Jag! For those of us who still care, it's an extremely interesting and useful perspective on the system. :D

 

If you decide to stick around and read deeper into the various site forum (here and otherwise) history of the Jag, I would caution you to please try to pay little attention to the crazed egomaniacal, self serving, reality dismissing, counter productive bullsh*t that has plagued the poor system (and is still unfortunately going on) for so many years. There is unfortunately entirely too much of it, but know there are still rational fans who enjoy the system - we're not all nuts. ;)

 

Thanks for visiting, and hope to hear more! :)

  • Like 1
Link to comment
Share on other sites

I just found out about this thread right now, read thru the whole thing and I just gotta

say, its really neat having someone whomade a jaggy game just drop by outta

the blue.

 

Good thread, I hope you stick around for a little while.

 

Thanks for a great game.

Link to comment
Share on other sites

So the way I resolved that was to actually use the branches of the display list, by having 3 levels of branches I was actually able to split the screen in 8 horizontal bands of 30 pixels or so.

Then I just had to fill each of the sub-display lists separatly, thus I just had 125+ sprites per display list, but 1000+ total displayed on the screen.

That way each horizontal line had almost full bandwidth to display the sprite.

The nightware was on the GPU side though, every single sprite had to be split in pieces to be placed on the proper horizontal band with the propoer offset initialized. Sometime sprites like bosses could be split over the whole 8 bands. Everything was displayed with that, even the multiple level of tiles for the background.

 

Impressive again :)

I imagine the nightmare it can be to handle this correctly.

I imagine it was transparent at usage, isn't it?

DId you split also scaled sprites (the word "nightmare" should be a bit weak then :D)?

Edited by SebRmv
Link to comment
Share on other sites

About the trick:

First I assume that your code is optimized already (you should have around 5 to 10 asm instructions per sampling computed), otherwise optimize this first ;)

In order to reduce the dephasing with the sound the solution was to actually reduce the numbers of memory access by the DSP, thus there is less latency.

 

Instead of reading one sample at a time (just one byte), I actually read 32 bits at a time on a register. And for every sample read, I actually was taking the correct byte in the 32 bits register.

I was uploading the 4 next samples only as needed. By just doing this, I was able to roughly divide the number of memory accesses by the DSP by 4 and that's why we had more voices and quality than other Jag games. Also a nice side effect is that the number of samples read on the memory didn't change depending of the replay frequency (we would just read several times the same byte in the register). And that's why the 50 Khz was cheaper than the other method.

Obviously doing this trick with the register shifting made the code more complicated, so the asm code was slower but significantly reduced memory accesses which was the bottleneck.

 

Hey! I thought exactly at this kind of optimisation during the night ! :)

 

Concerning my MOD player, I adopted a lazy approach: I have just coded a Paula emulator

and then adapted an Amiga routine.So this is the interrupt routine that makes all the resampling also.

(10 instructions is thus very short for doing this :-o)

 

Was it the case for your routine or did you do resampling by blocks (a bit like on STF thus)?

 

Anyway, I'll try this LOAD vs LOADB trick then.

Edited by SebRmv
Link to comment
Share on other sites

IIRC, on the code side, everything was developped with the DSPs, nothing with the 68000,

except just boot and VBL sync.

 

I think Oliver just made the point for me that the 68k should not be running

if you want real performance from the Jaguar. :D

Edited by Gorf
Link to comment
Share on other sites

IIRC, on the code side, everything was developped with the DSPs, nothing with the 68000,

except just boot and VBL sync.

 

I think Oliver just made the point for me that the 68k should not be running

if you want real performance from the Jaguar. :D

 

I think ultimately everybody agrees on that subject, no?

Link to comment
Share on other sites

Hi Olivier,

I don't know how often I'll be able to come back here, but hey let's continue to chat... ;)

Great to have a former developer generously giving useful insights to everybody, openly.

I read the Atari suggestion for splitting the display list, but reading your comments in this

thread about it and the complexities which result is far more interesting than a dry old doc!

Really appreciated, and I have to add SBO is one of my FAVOURITE Jaguar games anyway.

Cheers,

Richard / JustClaws.

Link to comment
Share on other sites

It is very cool that you found this thread and I loved Super Burnout. I hope you get that site translated to English someday. I saw that site a long time ago but lost the link.

 

Loved Super Burnout. My friend got a mailer from Atari and had it on pre-order when it first came out. It is very interesting hearing the stories of your experiences with coding the Jaguar. Looking forward to reading more of your posts.

Link to comment
Share on other sites

I don't know how often I'll be able to come back here, but hey let's continue to chat... ;)

OlivierNallet - thank you so much for posting and sharing your thoughts and experiences on Super Burnout and the Jag! For those of us who still care, it's an extremely interesting and useful perspective on the system. :D

 

If you decide to stick around and read deeper into the various site forum (here and otherwise) history of the Jag, I would caution you to please try to pay little attention to the crazed egomaniacal, self serving, reality dismissing, counter productive bullsh*t that has plagued the poor system (and is still unfortunately going on) for so many years.

 

 

 

Yeah but through it all we still accept you anyways Remo. ;)

Link to comment
Share on other sites

For me SB is the fourth best game of the Jaguar :)

 

What are your first 3? :)

 

Have you played any of the post Atari released games (World Tour Racing, Iron Soldier 3, Battlesphere)? Sorry to ask you so many questions but do you still have a Jaguar? If I released a game I would keep like 10 copies and a number of backup systems available at all times :)

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