A Couple PS1/N64-gen questions

Did you work on the handling engine at all for WDC, ERP? I've been wondering whether the inability to steer while braking (or is it brake while steering?) without sliding out was a bug or a feature.
 
Try driving really fast in a straight line hitting your brakes really hard and turning, I wouldn't recomend it on public roads. depending on what order you do the latter in you'll find that you'll either keep going in a straight line (severe understeer) or spin around in circles (severe oversteer) or in some cars one and then the other. tires have a certain amount of grip, if you use it up trying to stop, you don't turn much and if you hit your brakes hard in a turn you transfer all you weight forwards and loose traction in the rear. WDC does actually have driver aids, very basic traction control and abs but the faster cars ar really on the border line of the what physics integration will cope with stably.

To be honest from a game play standpoint I was never really masively happy with the handling or game balance in World driver, the game was rushed out to meet a publishers fiscal quarter, in retrospect the first half of the game should have been shorter and the second part longer. On the physics side it's a pretty complete, suspension motion is approximated to be vertical, but outside of that it has a very complete tire and suspension model.

The way the joystick input affects the steering input has as much of an affect in the handling as anything in the physics. Gran Tourismo has a lot of things going on in this area, if your ever really bored, take out GT and look at how wheel angle changes with input, course position, facing and velocity. WDC is much simpler in this area, it usea a basic 3D mapping taking into acount only Joystick position and velocity as inputs.

On the technical side there are a couple of things in WDC that do affect the handling detrimentally, there is an abnormally large latency between changes to the input and seeing the result on screen (worst case 7/60th's versus 5/60's which would be more normal for a 30fps game), this is a direct result of the graphics archetecture. There is also an issue in banked corners which is a result of approximating curves with triangles, you can observe the same issue in Gran Tourismo, but some of the camera shake they do tends to hide it.

Also if I remember correctly car to car collision has a major math error in it, which I fixed for Stunt Racer 64, but I doubt most people would notice, since it requires backing one car diagonally into another to observe.
 
I took this interview from the number 3 of EDGE compilation of old issues named FILE

Silicon Graphics designed and engineered the internals of the Ultra64. The programme inaugurated in August 1993 and code named "Project Reality", is the first time that the Californian Company has ever had to produce a machine for home use. To succesfully develop graphics workstations costing hundreds of thousands of dollars is quite and achievemente, but to develop the innards of a box that Nintendo swears will sell for "less than $250" is a completaly different task. How has the dream of bringing Jurassic Park special effects to the home been sacrificed long que way?
Edge met with the general manager of SGI´s consumer electronic marketing during the Shoshinkai show.

EDGE So was it SGI´s idea to present this technology to a videogame company, or was SGI approached from the outside?
GZ Jim Clark - Who was the chairman of Silicon Graphics back then- took this technology and really pursued the idea of working with the leading game manufacturers

EDGE What did SGI and Nintendo agree should be the technology´s major features?
GZ We wanted to get the Reality Engine look and the feel, in terms of the quality of the polygons and the pixels, within an high performance machine. There´s a lot of things that happer when people start engineering. It´s easy to end up with a machine that can either do the graphics features or the performance, but the real challenge is to create a machine that does them both well. This way you don´t suffer certain optimizations - where your features might work but all of sudden you get this crummy performance, or you have good performance and low quality textures.

EDGE So what else did you offer Nintendo in terms of SGI expertise in graphics?
GZ As well as designing the hardware, we supplied the software emulation system. Basically we had Ultra 64 microcode running on an Onyx Reality Engine back in July 1994. so someone could sit down and start building the game. And that´s what Mr Miyamoto did with Super Mario 64. He started building the game on the Onyx Reality Engine with Nintendo Ultra 64 software emulation system over a year ago.

EDGE So how does the Ultra64 compare, in terms of power, to the original SGI Reality Engine from which it was derived.
GZ From a consumer perspective. I don´t thinks that the gamers will be able to tell the difference. If you ask someone in the Reality Engine team wheters it´s the same thing, they´ll say, "Of couse not! The Reality Engine does blah blah blah".
But since and NTSC TV secreen has only a quarter of the pixels compared to an high end monitor, Ultra 64 has an equivalent amount of performance. So although in actual fact Ultra 64 has probably one quarter of Reality Engine performance (we haven´t done direct competitive tests), we only have a quarter of the screen to fill. So, in terms of polygon count and pixel count, Ultra 64 has the same performance as Reality Engine. Ten years ago the rendering performance of the Ultra 64 would have been onbly possible on a $14 milion flight simulator.

EDGE What level of secrecy did you have to implement internally within SGI?
GZ There was an unbelievable amount of secrecy. It was challenging because at SGI our culture is a really open one and engineering groups from all over talk to the other groups to see what everyone is doing. Because we are working with Nintendo in this area and because there is such potential for competition, like, see what was going on, we had to deliberality to cut down the level of communication internally. No-one knew where the lab was internally -we had a whole lab full of Ultra 64 stuff and 70 people working on the CPU alone - there was a big Donkey Kong Country poster on the window so no-one could see in.

(From now I will only post the parts of the interview that are interesting for the subject of the thread)

EDGE Nintendo claims CD-ROMs are unsuitable for games. But data loaded from a CD behaves just like cartridge ROM
GZ I agree. The problem is, homever, that you have to have enough RAM...

EDGE Which is expansive
GZ I think that´s the problem. If you don´t have enough RAM, the issue you start getting into a very complex virtual paging of the CD-ROM into memory. When you have a small amount of memory, the low level OS you need to do virtual paging can get kind of complex

EDGE And Nintendo does´t feel it can afford to include enough RAM in Ultra 64 to avoid these problems?
GZ That´s correct. Interestingly, the cost of the curve RAM is pretty flat for the next three of four years. Demand is going to meet supply and -from what I heard - the cost of the RAM is actually going up. In the future I think there are going to be three staple requeriments bread, water and RAM (smiles)

EDGE It did loook great (they talk about Mario64 demo) , but it wasn´t utilizing all the graphics features we talked about. Why was that?
GZ The texture were bilineary interpolated , they weren´t trilinealy interpolated - because mip mapping wasn´t turned on in that demo. And antialiasing wasn´t turned on. I don´t know why. I think that they just wanted a stable demo to show people. But these features definitely work, because we have demos here with that stuff running fine. I think people completed the non-antialiasing. non-mipmapping versions first, and so they choose to show these. which they knew would run okay. Also, the problem with the mip-mapping is that you have to generate multiple levels of texture maps. There´s a little bit extra work to make sure you can generate the correct levels. You can always make those extra levels look better if you spend more time on theh -and presumably the developers of the games on show didn´t have that time.

________

Sorry for the long post.
 
ERP, nevermind, that was faulty memory. I just tried the game again...apparently I was trying to turn at 90mph without realizing it.

Why do reviewers always complain about rock tracks? It's like rock is the forbidden genre of game music. I personally like 80's-style guitars, but whenever you hear them in games, the reviewers always say, "Crappy generic rock! No stars!"
 
Well I turn off the WDC soundtrack rather rapidly. :???: Not a fan of Zack Ohren's game music efforts. Especially in mono MP3 format, heh. Top Gear Rally's electronic soundtrack is better IMO and the tracker format certainly sounded better (IMO) due to the machine's storage limitations.

ERP, I don't think you've ever told the epic tale of Top Gear Rally. ;) I remember seeing the pre-rendered, pre-release demo video of the game. I bought WDC because of experiences with TGR. TGR was my first console game that attempted to really simulate vehicle physics and it certainly looked pretty amazing at the time too. (Prior to TGR, the most "realistic" racer I had on console was Stunt Race FX lol) Cars with suspension! I was almost saddened when I discovered that the "ride the rails" trick had been fixed in WDC. Oh and there were a few times when I saw a competitor literally go vertical into the sky after hitting a guard rail's edge head on. :p
 
Last edited by a moderator:
Well I turn off the WDC soundtrack rather rapidly. :???: Not a fan of Zack Ohren's game music efforts. Especially in mono MP3 format, heh. Top Gear Rally's electronic soundtrack is better IMO and the tracker format certainly sounded better (IMO) due to the machine's storage limitations.

ERP, I don't think you've ever told the epic tale of Top Gear Rally. ;) I remember seeing the pre-rendered, pre-release demo video of the game. I bought WDC because of experiences with TGR. TGR was my first console game that attempted to really simulate vehicle physics and it certainly looked pretty amazing at the time too. (Prior to TGR, the most "realistic" racer I had on console was Stunt Race FX lol) Cars with suspension! I was almost saddened when I discovered that the "ride the rails" trick had been fixed in WDC. Oh and there were a few times when I saw a competitor literally go vertical into the sky after hitting a guard rail's edge head on. :p

Regarding the audio there not in mono and they're not MP3's.
It's actually an Amiga style tracker, channels are left or right, I can't remember how many channels we supported off the top of my head. N64 really didn't have good audio.

TGR happened because we were located just up the road from Kemco's US office. They were looking for a dev to do a Top Gear racing game on Nintendos upcoming platform, and several of us wanted to do a racing title.

The prerendered sequence we did back then was largely to convince Nintendo to get devkits, it wasn't a common sales tactic in those day, but since it's become common practice.

The physics engine went in very late in TGR, There were actually two developed and the first prooved to be unusable. I wrote the second one to dig us out of a dev hole. In terms of what's modelled it's similar in principle to the WDC one, the tire model is simpler and it has some bonus bugs in it. The WDC one is also about 10x faster (which gives you how an idea of how much implementation can change performance) mostly due to improvements in the collsion representation.

The Snow tracks came about because an artist volunteered to do it in a meeting with Kemco. Everyone loves the Jungle in the Snow...

The paintshop was an idea that had been thrown around internally, and I always fought against (I lost) because it hurt the graphics quality of the cars significantly.

Audio like our later titles was a tracker, because that's what our sound guy (Barry Leech at the time) wanted given the very significant constraints. At the time the Nintendo libraries used the RSP for the mixing, but we measured a significant performance penalty for this, so I wrote a mixer on the main CPU, which balanced load a bit better. For WDC we moved the mixing back to the RSP because we had access to the uCode and it wasn't really the bottleneck.

TGR was notable because it was the first game where we used a single package for all of our art assets, everything came out of Alias, and for the most part if you put something in thye model it would turn up in the game.
 
Any idea why Nintendo withheld the microcode for so long? It seems weird that they would want to deliberately hold back development on their system. Also, could someone explain what the benefit of Z-buffering is over the tables the PS1 used? Does it allow you to do different effects or something?
 
Last edited by a moderator:
I know that WDC has a note in the credits (or boot up) about using the Fraunhofer MP3 codec..... I'm actually stunned to learn it wasn't MP3-encoded music!

I really wonder how many people actually messed with that TGR paint shop in the end. I never really messed with it at all. It was a fascinating feature though; I'm sure the reviewers touted it. And yeah, the "winter" Jungle w/ snow was fun stuff. The weather effects really added a ton to the game's very limited number of tracks. Each of the tracks was so different and large, too, and had those nifty shortcuts.

Thanks for the insight into TGR. I and a friend played it a ton for a year or so and it was definitely one of the highlights of my N64 experience. :cool:
 
I know that WDC has a note in the credits (or boot up) about using the Fraunhofer MP3 codec..... I'm actually stunned to learn it wasn't MP3-encoded music!

I really wonder how many people actually messed with that TGR paint shop in the end. I never really messed with it at all. It was a fascinating feature though; I'm sure the reviewers touted it. And yeah, the "winter" Jungle w/ snow was fun stuff. The weather effects really added a ton to the game's very limited number of tracks. Each of the tracks was so different and large, too, and had those nifty shortcuts.

Thanks for the insight into TGR. I and a friend played it a ton for a year or so and it was definitely one of the highlights of my N64 experience. :cool:

I'm pretty sure WDC has no mention of fraunhoffer in the credits.
Top Gear Overdrive which was written by Snowblind does, it's the only N64 game I can think of off the top of my head that used MP3 audio.
 
Any idea why Nintendo withheld the microcode for so long? It seems weird that they would want to deliberately hold back development on their system. Also, could someone explain what the benefit of Z-buffering is over the tables the PS1 used? Does it allow you to do different effects or something?

They probably presumed uCode would have been a support nightmare and I know that SGI had just had a problem when they released one of there systems uCode to a secific developer.
N64 uCode was not paricularly easy to develop, the tools were bad, the documentation minimal and you had to do everything including triangle setup. And there is nothing like trying to debug random hangs with no way to debug the case.

Zbuffer basically determines depth on a per pixel basis, without it, your stuck sorting on a per triangle basis or more often per group of triangles.
 
I'm pretty sure WDC has no mention of fraunhoffer in the credits.
Top Gear Overdrive which was written by Snowblind does, it's the only N64 game I can think of off the top of my head that used MP3 audio.

You are right. I loaded up WDC to check it out. I don't know why I was thinking so certainly that it was MP3. I haven't played TGO more than a rent once, so I doubt it was that game where I saw it. Perhaps some Factor 5 game.
 
Thanks ERP for sharing those interesting facts :)

While the mayority of N64 games didnt match so well against PS1 stuff. The top tier games on N64 were almost a generation ahead of the PS1 ones.
 
16 bit Z Buffers suck BTW.
Fixed-point ones, certainly, but a floating point one would be OK.

For example, IIRC, 3Dfx had this. Of course, you have to set near=1 and far = 0.
 
it's the only N64 game I can think of off the top of my head that used MP3 audio.
What about Shadow Man?
I'm sure it used somr form of compressed audipo. It sounds quite tinny compared to a game with realtime generated audio..
Peace.
 
Fixed-point ones, certainly, but a floating point one would be OK.

For example, IIRC, 3Dfx had this. Of course, you have to set near=1 and far = 0.


If only it were floating point...
Even fixed point W wouldn't have been bad in retrospect.
 
The worst Z fighting I can recall in gaming has been in Unreal and UT, on maps with large open areas, and space games (again large open areas). With UT, I could get around the issues mostly, by forcing a "32-bit" Z-buffer. If I recall correctly, in UT, 3dfx cards running Glide didn't have these issues on the same level (if at all).

I can also remember a few probs in N64 games. Goldeneye frequently had issues with flashing decals.
 
I could be wrong but I'm pretty sure Perfect Dark mentions MP3 somewhere in its startup screen with all the copyright stuff.
 
The worst Z fighting I can recall in gaming has been in Unreal and UT, on maps with large open areas, and space games (again large open areas). With UT, I could get around the issues mostly, by forcing a "32-bit" Z-buffer. If I recall correctly, in UT, 3dfx cards running Glide didn't have these issues on the same level (if at all).

I can also remember a few probs in N64 games. Goldeneye frequently had issues with flashing decals.

The original Unreal has some weird issues with the models. Fog draws behind models, for example. Also, Doom 64 occasionally displays sprites in front of walls. Either they had a bad node builder, or it's the 16-bit Z-buffer.
 
Mmm, Doom64.

I don't recall that game having too many graphical issues, but that could be rose-tinted glasses at work.
 
Back
Top