OlivierNallet

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

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.

Oh yeah and I forgot, the original name was "Burnout", Atari's marketing decided that adding "Super" would incrase the number of sales. BTW nice website Fredifredo, that brings a lot of memories

Trying to keep up with the questions. A little history (just to show how different things were back then . When we started SBO we didn't have a contract with Atari. Elysee (project leader) had some contact with a company named Virtual eXperience that was developping on Jaguar. They agreed to lend us their dev kit every week-end (so they could still develop their game during the week). So every friday night we grabbed the dev kit in their office, I worked crazy hours during the whole week-end, then monday morning we gave them the kit back. The artist Kheang Tan was able to work during the week on Amiga, but for me as programmer, I needed the console to develop the game and put graphs / sounds / data together. Needless to say that was tough. Especially that our "main office" was Elysee's bedroom During the week I was going to the university to study my BSc. Within 6 months our week-end project was further along than VX project that started before ours, so VX decided that it would be their best interest that we had one of their devkit full time. It coincided with the end of my university cycle, so then I continued full time on SBO and had to stop university. I believe that Atari saw the demo and was very iterested, Jack Trammiel came to see us, and we started the contract with Atari at around that time. They gave us 3-4 months to polish the game and we finally shipped. IIRC it took 12 to 14 months total between having the kit the first time in hand and shipped the product. The first 6 months were not as productive as the middle obviously, there is so much you can do during the week-end without sleep The last 4 months were not very productive as well, we were trying to convince Atari that "No, we cannot have leaves falling from the trees with the wind, etc.." plus some tests like the jaglink, a couple of cheats, more bikes, etc... At the end we were not doing much, waiting for Atari to approve the final build. With the money that we got, we created the company Shen Technologies, and unfortunately had no other deal with Atari anymore (they loved us though as we had specs for the jaguar 2 and this kind of stuff), but they died while we were developping our next game Nexus, so we had to switch to another platform. About the 2 players mode, I actually don't remember the details but if I can guess (or maybe imaginating the past), we had to play 2 set of bikes for the two players and it may not have been enough CPU cycle to play these plus the music. Also note that the DSP had lower priority on the bus than the GPU. In 2 player mode we actually display more sprites, although I may have split the display list, the costly zone was around the horizon line as that's where we had most sprites in a single line. Thus having 2 players reduced the quality of the sound. We didn't have the time to change the music to reduce the number of voices to fit, so we prefered to cut the music instead of having the same phasing effects than other Jaguar games. (Also 16 bikes at the same time + music was particularly noisy and saturated). 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

Thanks guys! Let's say that I'm quite busy with X360 and PS3 these days I'm sure you appreciate the similarity between the Jaguar and the PS3 Cell, they are not that very different in the way they are designed (not talking vector unit of course). The Jaguar DSps had the advantage to be able to access the whole memory so it was easier to use them.

Hey guys, I discovered this forum while browsing the web! Funny that people are still talking about a game I wrote more than 13 years ago So actually the JagLink version was only one vs. one, somebody on the publishing side may have dreamed the 8 players version (possibly because that's what Atari was advertising). We did not ship with it as the version was too unstable. IIRC The game was randomly crashing. That was my first game, at that time I did not know how to write more stable network connection to recover from bad hardware. Also IIRC, I just had few weeks to implement it before we shipped, it was just a nice to have features, so we could not afford to post-pone the ship date. Oh well, old memories