This is not just about Bubsy 3D

This started with just a quick analysis of Bubsy 3D, but that bobcat hole just kept going!
Instead, turning into why Bubsy 3D and most early Playstation games look the way they do.

First, A bit about Bubsy 3D

Bubsy 3D comes up as one of the worst games in the Playstation’s library.
In it’s defense, it was among the first ‘open world’ 3D platform games created.
Sure tank controls (Up/Down: moving & Left/Right: rotating) are horrible now, but it was common in early 3D games.
And the fixed camera was also very common, the L2 button controls the camera, this was a time before dual analog sticks.

The design of the game is pretty limited, Bubsy can jump, shoot, run (or swim in water levels), climb and glide.
The level features are interesting but stark, moving platforms, helicopter switches and a rail system.
For it’s lack of design and features, it does have a lot of gameplay with 18 levels (some large), 4 bosses and repeatability in that collecting all the pieces of the rocket gives you the “good ending”.

However, it’s always criticized for it’s (lack of) visuals and often compared to Crash Bandicoot and Super Mario 64.
The only thing they have in common is that they came out weeks apart from each other.

Why was Bubsy 3D mostly flat shaded?

A few reasons, the game runs at the PlayStation’s highest resolution, which is in interlace mode.
This resolution on the Playstation was mostly for low CPU GPU tasks like rendering static images (ie intro & menu screens) or videos (MPEG).
Very few games run at this high resolution in game and in 3D.
It forced the fastest display refreshing the TV & Playstation can perform, (PAL:60 NTSC:50 frames per second).
And well, flat coloured polygons is what the hardware can render the fastest! (NB: lines aren’t polygons).

Bubsy 3D PS1 VRAM
[The VRAM is hardly used with empty spaces and duplication, see above (notice there’s no double buffering)]

Perhaps the original concept was to make Bubsy 3D similar in style to what 3D games were already out in 1994.
Like Sega’s early 3D “Virtua” games which are mostly flat shaded, but unfortunately very dated for the end of 1996.
I personally like the style, it’s reminiscent of the late 80’s and early 90’s 3D.
So with very little textures, I guess it made sense to use the largest amount of VRAM for resolution.

The early Playstation developers didn’t have access to hardware!

This is an interesting story, and one which isn’t very well known.
It’s a hint to what it would have been like to work with the early Playstation technology and what would become the Net Yaroze a few years later!

Bill Guschwan was part of the Sony US Playstation developer support team, previously working at 3DO in a similar role.
He had access to in-depth hardware knowledge and he helped developers get straight to the hardware when Sony itself prohibited it!
Obviously Ken Kutaragi wasn’t happy with this!
Listen from 8 minutes:

[I recommend watching it all, it’s about the advancement of console hardware and goals]

Originally, Ken Kutaragi wanted a software interface (a 2D, 3D, audio, video and peripheral library for C programmers) to access hardware features, obfuscating the hardware from their developers, called the OS (Operating System).
His thinking was so they could provide backwards support on PS2.
Programming at the hardware level is very complicated and time consuming compared to using their ‘OS’ C library.
If it was similar to the Net Yaroze, then I wouldn’t be surprised if Sony used this C library to lure game developers promising 3D education and a rapid development environment, just like the Net Yaroze was marketed, and remember most console development up to the mid 90’s was in assembly!

Continuing with Bill’s presentation, Sony learnt from the 3DO’s failures, citing the limited hardware and the lack of launch games.
Ken wanted to show off more ports and new games before the US Playstation launch at the 1995 E3 show (mentioned at 12 minutes).
Ken knew that programming at the hardware level would slow down the US launch titles.

But Bill Guschwan argued that accessing hardware directly yields better performance and a better ‘experience and value’ to the customers, and obviously by pushing the graphical limits of the hardware, Ken could deliver the ‘wow’ factor.
Ken agreed and made Bill a graphics engineer, working “in Playstation headquarters in Japan under Ken Kutaragi“.
Bill knew the Crash Bandicoot developers (naughty dog) from their 3DO game “Way of the Warrior” and as per his tweet:
“I convinced kutaragi-San to give hardware diagrams and source code of ps1 to naughty dog”

I convinced kutaragi-San to give hardware diagrams and source code of ps1 to naughty dog, Bill Guschwan

I would suspect some of the early Japanese developers already had access to hardware information or had time and approval to reverse engineer it like Battle Arena toshinden.
Bill sheds some insight into an interesting period in time for sure, and well, the rest is history!

So how bad was the early playstation library like?

I wouldn’t say bad, the library would have been quick to pick up and make a game, very similar to what Unity3D is today, abstracting the hardware details away.
Also, most developers would have struggled with the 3D programming and the 3D asset pipeline, this library & tools would have been a life saver!
But, the downside to building a game on top of this generic library is that it’s not optimized and was slow, at least for 3D graphics.
If we look at Crash Bandicoot, Bubsy 3D and Resident Evil, which would have been developed from 1994 through to their release in 1996,
we can see which used Sony’s early 3D library (last two) and which didn’t (crash Bandicoot).

What’s the connection to Net Yaroze?

As an original member of the Net Yaroze, I read the UK & AUST OPSM articles and played the games on the demo discs, before purchasing it in early 1999.
The games on average didn’t look like much and were very simple, but they were made by truly independent people, normal programming people like me! :D

When Sony people talked to the press about the Net Yaroze, they sometimes mentioned how the games completely fit in RAM (ie it doesn’t use the CD-ROM to stream data).
As an example the official Net Yaroze FAQ and gaming magazines, Ridge Racer is specifically mentioned.

Well, in the exclusive Net Yaroze member’s newsgroups, someone asked if Ridge Racer was created with a library similar to the Net Yaroze library.

Colin Hughes provided SCEE Net Yaroze support and explains the very early Playstation library in a post.


When the Playstation was first released to developers the first version of LibGS ( which wasn’t even as good as the Yaroze LibPS ) was pretty much all there was for quick 3D ( Ridge Racer was produced in a very short time, and the developers didn’t have any CD access at all on their prototypes )


I think a lot of input came from Namco and was used to improve the 3D capabilities of LibGS


So in my opinion you could quite easily produce a Ridge Racer clone using the Yaroze libs.
Stuart played around with a very simple car game model that runs at 60fps with two cars racing ( split screen ) that is available on the web site.
You could easily take some of the ideas that he uses and add more graphical polish.


The secret to producing a good racing game is to forget about the track as being in a 3D world and split it up into sections that you race ( like Scaletrix or model railway track ).


You can then generate a screen by drawing background/track pieces from the position of the car up to a clipping point ahead on the track. ( I know that this doesn’t work very well for crossing tracks but there are none of those on the original ridge racer )
If these pieces ( straight / left turn by lighthouse / underbridge ) are separate TMD’s then this becomes quite simple with the Yaroze libs.


Colin Hughes explains the original playstation library
[Click image to read the original post]

Colin mentions a 3D format called TMD, which was the only way to send 3D data to the GPU on the Net Yaroze.
It wasn’t like early OpenGL, with glBegin and glEnd statements, where the programmers can custom build their draw calls, but instead it was way, way more high level!

Basically, on a PC you would process a 3D object (OBJ format) through a converter to get a TMD and then to render it on the PS1, you’d load it into RAM and pass its address to a draw call, and it would appear on the screen.
Sony even had a TMD animation format (TOD) and plugins for 3D Studio (for DOS), which made it very easy to use!

But, If you were clever and wanted to optimize performance, you figured out how to dynamically create these TMD files in the Playstation’s RAM and animate it programmatically by changing the vertices, colour’s or UV’s.

The TMD format supported all combinations of the 3D geometry that the hardware supported (except for double sided polygons and lines in the Net Yaroze library).
This made it a huge memory waster as you would have large headers for each object mostly empty and processing each object’s draw call was slow, very slow! I know all this from experience!

[Rendering individual textured TMD’s, notice the poor draw distance and the low number of quads drawn!]

[Rendering a lot of textured quads from a single TMD and one draw call, many, many times faster]

[In my PS1 game, the level is a single, dynamically created TMD and rendered with a single draw call for each player’s screen]

The TMD draw calls would have been either CPU bound, trying to order and reorder the GPU packets (low level instructions) or GPU bound with unoptimized GPU packets, ie texture cache misses, my guess would be the former, CPU bound.

The Bubsy 3D developers used the technique Colin mentions, building a world out of “Scaletrix or model railway track”, you can see them popping in and out in the distance.

The “Scaletrix” way of building a scene in 3D is very simple, but very slow when the hardware has no Z buffering, specifically Z culling, which means the GPU waste time draws hidden objects!
Bill, mentions that he saw Andy Gavin “counting polygons”.
I would assume for the purpose of reducing the overlap of polygons, Andy mentions some details here:


At Naughty Dog, we combined my ridiculously ambitious octree approach — essentially, dividing the entire world up into variable-sized cubes — with Mark’s godlike assembly coding to produce something *barely* fast enough to work — and it took 9 months.


This was the one the one area on Crash when I thought we might actually just fail — and without Mark and I turning it into a back-and-forth coding throw-down, we probably would have.


This problem wasn’t new, but it would have been a mute exercise to do a BSP of polygons on top of the TMD and LibGS!

Re-reading the Net Yaroze User Guide, Chapter 2 ‘The PlayStation Development Environment’, there’s hints of it’s professional legacy, mentioning both the professional and Net Yaroze development systems.
To me this reads like Sony’s intention was to maintain both the ‘OS’ (high-level) 3D library and the newer low level (hardware) access, concurrently.
And maybe from feed back, a more optimized version of the TMD format was eventually created, I don’t know.
But here are a few paragraphs:


This OS was developed specifically for the PlayStation’s R3000 CPU and incorporates extremely novel concepts used by both the Professional Development System and Net Yaroze.



If the CPU and peripheral devices operate at sufficient speed, the programmer can rely on the services provided by the operating system to control the hardware.
Application development can proceed smoothly and rapidly as there is no need to spend time pushing hardware performance to its limit.
Thus, the programmer is free to concentrate on application development.



Access to these services is provided via a set of library functions written in the C programming language.
Using C means that the source code can be more readily understood and maintained.
Furthermore, the structured nature of the language and the ease with which functions can be called allows program development to proceed easily.



It is composed of a small-scale OS kernel that provides efficient interrupt processing and multitasking support, and a hardware management library and middleware for high-level services such as a MIDI driver and 3D graphics system.



SCE’s R&D teams continue to expand the professional PlayStation library and middleware based on requests from professional application developers.


But did Bubsy 3D use this libGS library and it’s TMD format?

It’s safe to assume, the Net Yaroze members didn’t receive all of Sony Playstation proprietary format.
But yes, a quick web search of ‘Bubsy 3D TMD format’ reveals a TMD ripper, mentioning Bubsy 3D TMD assets and a forum post on how to rip Bubsy 3D TMD objects.

With hindsight, Michael Berlyn the creator and designer of Bubsy (he worked on the 1st and Bubsy 3D) revealed that Sony only wanted to support one ‘furry animal product’:

“We learned a lot about 3D design and coding and the environment and what could and what couldn’t be done,” he said,
“and we went to Sony to pitch them on doing a product.


We brought a prototype for Bubsy 4, which was really just nothing other than a calling card.
And they could see where we had taken it, and said, ‘Oh yeah, we’d be interested in doing a product with you.
Absolutely not a furry animal product, though, we already have one of those.”


At this time, the Sony marketing machine was busy placing their new mascot, Crash Bandicoot, into pizza commercials.
“So we said okay, pick a product any product, and by mutual consent, we agreed to do Syphon Filter.”


I would guess, with better technical understanding of the hardware, the game could have been a fully textured world and maybe a draw distance twice as far!
And I’d like to think everything is fare in life, and if the programmers of Bubsy 3D wanted low level, hardware information to improve their graphics, that Sony or Bill would have obliged them.
But I believe that the most likely reason for them not going down the hardware path would have been their project time and cost, and the very new challenge of developing interactive 3D software.

Most console development kits are never open to the public, not even decades later!
However the Net Yaroze was available in Japan in 1996, only 2 years after launch.

I would imagine the success of Crash Bandicoot and the other titles, which by passed Sony’s 3D C library, would have proven that better ‘experiences and products’ wasn’t possible with their 3D C library and using it would have been counter productive.

So Sony (Ken) must of been really convinced that the original library was so redundant that having it in the public wasn’t a threat to their business nor to their professional developers, who paid $20,000 USD plus, compared to the Net Yaroze’s price tag of only $750 USD (which is only 3%).

I believe that if the developers didn’t push the hardware to the limits, the Net Yaroze experiment wouldn’t have existed at all.
And with the context of above, Bubsy 3D, Ridge Racer, Resident evil, Time Commando, etc could better be considered as ‘commercial’ or ‘Professional’ Net Yaroze games, and well that is impressive!

Interview with Michael Berlyn:

Why bring up Bubsy 3D?

Coming up for an idea for a game is hard, and more so for a specific platform, the original 3DS, see why!
Firstly, the original 3DS has a pretty weak GPU, think an overclocked Nintendo 64 but with modern, built in effects, ie cell, phong shading, stereoscopic 3D etc.
If you look at the 3DS’s library of 3D games, the large majority look like mobile phone games.
The reason being 3D objects cached in VRAM with a small scenes (drawing distance) is more optimized for the hardware.
Dynamically generating each frame and sending raw vertex data to the GPU is a lot slower (and old fashioned) but has some benefits (Vertex animation in code is portable).

I was thinking about a ‘Bubsy 3D’ type of game because, the 3DS has only one analog stick and a limited CPU & GPU!