Could Bubsy 3D on Sony Playstation been a better looking game?

5 Jun 2018 In: GameDev, NetYaroze

– IN DRAFT –

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.

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

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

[Bubsy 3D | Playstation | Playthrough]

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!

In the mid 1980’s, An electronic engineer at Sony’s R&D, Ken Kutaragi watched his child playing Nintendo Entertainment System (NES) which made him interested in video games, around the same time he also saw the System G (System Gazo) a real-time 3-D texture mapping render.

System G was a geometric engine for 3-D processing, developed for broadcasting networks.
An example of a current application is its use by Nippon Television Network Co. to change the size of computer-generated faces in the popular TV program Denpa Shonen.

In the early 90’s PC game’s were mostly programmed in C with some assembly parts for performance, console games were mostly still programmed in assembly.
But assembly was still possible by small team developers because the chips were common and relatively simple, and 2D programming (and the 2D art pipeline) were well documented.
The Playstation’s hardware on the other hand, used more complicated and proprietary chips which made programming in assembly a non trivial task.
Adding to this, 3D was still new in video games and the learning curve of 3D programming (and the 3D art pipeline) would have made development on Playstation an impossible and drawn out feat for most small teams.

I assume Ken Kutaragi architectured the PlayStation based off System G and/or Sony’s NEWS 32bit RISC CPU workstations, the playstation did have many UNIX workstation standards, ie filesystem, Input/output,etc which would suggest that it could be operated and programmed just like a computer.
Although, computer video games of the late 80’s and early 90’s did use the hardware directly, largely thanks to PC hardware standards, other standards were beginning to emerge, like operating system related standards, including graphics.
Using these principles of (software) standards, Ken created a simplified, software interface (a 2D, 3D, audio, video and peripheral library for C programmers) to access all hardware features, obfuscating the hardware from their developers, he called the library: PS-X OS (as in Operating System).
His thinking was so they could easily make hardware changes and provide PS1 support on later console generations, just by maintaining the PS-X OS library.
As you would expect from a computer, but also making it very quick and easy for developers!

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

[Bill Guschwan: A History of Video Game Development @ Google Tech Talks May 14, 2008]

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

If the PS-X OS library was similar to the Net Yaroze, then I wouldn’t be surprised if Sony used this PS-X OS library to lure game developers promising an easy 3D transition and a rapid development environment, just like the Net Yaroze was marketed.

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

Continuing with Bill’s presentation, In 1993 Sony learnt from the 3DO’s failures, citing the limited hardware and the lack of launch games.
I would guess this is the reason why Ken created SCEI, SCEA and SCEE, to have a world wide sales and distribution channel, but he also setup internal development teams and also courted 3rd party developers, he wanted to show off more ports and new games before the US Playstation launch at the 1995 E3 show (mentioned at 12 minutes).

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 that ‘wow’ factor he wanted to achieve.
I imagine Ken would have thought about the quality of the Japanese 3D launch games being developed by early 3rd parties and agreed, making Bill a graphics engineer, working “in Playstation headquarters in Japan under Ken Kutaragi, Jan 1994 – Nov 1994 “.

Or was Ken angered by him telling 3rd party developers how to access the hardware and was it a non PlayStation role?
Because "C++ graphics code for procedural texture maps" doesn't sound like it?

C++ Graphics Software Engineer

Company Name Sony
Dates Employed Jan 1994 – Nov 1994
Employment Duration 11 mos
Worked in Playstation headquarters in Japan under Ken Kutaragi.
Wrote C++ graphics code for procedural texture maps.

Bill sheds some insight into an interesting period in time for sure!

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

If you’re still not convinced, have a look at the 3D (polygonal based) Japanese launch games (Dec. 1994):

[The PS1’s Japanese Launch Lineup - PlayStation Year Zero by Retro Pals]

[00:00 Ridge Racer, 14:00 TAMA, 19:45 A-Train, 38:36 Mahjon Goku Tenjiku, 43:18 Crime Crackers]

And a year later, launching in the US and PAL regions in Sept. 1995, arguably they only had three ‘killer apps’, Battle Arena toshinden, Ridge Racer, by Namco which is no coincident and wipeout which was made by Psygnosis, who Sony purchased in 1993 and also published the newer and better Psy-Q development kits.

The PlayStation Year One: The US Launch Lineup by Retro Pals

[00:00 Battle Arena Toshinden, 17:05 Total eclipse, 20:00 Ridge Racer, 24:00 ESPN Extreme Games, 35:35 Power Serve 3D Tennis, 51:22 Kileak]

It’s not that the developers of launch games didn’t have high expectation, I’m sure the developers made the best they could with what they had at the time.

Given the competition of existing 3D games on the 16bit consoles, Sega’s 32x, phillip’s CDI, EA’s 3DO and Atari’s Jaguar, these early Playstation games were somewhat an improvement.
But the Sega Saturn launched earlier then the PlayStation in all regions and with way better 3D (polygonal based) quality games!

From Winning the Game: The Intertwined Histories of PlayStation and Final Fantasy VII

Upon Saturn’s release, Sony engineers disassembled the Saturn and were stunned by the internal complexity, all PlayStation components elegantly fit on a single circuit board, while Saturn contained a web of cables and even required a separate daughterboard for the CD-ROM controller.
Realizing that volume production would hurt Sega due to the more difficult manufacturing process, Sony engaged Sega in a price war
and both companies reduced their prices by $100.

…

By the end of 1995, Sega (Saturn) ruled Japan, and Sony had to regroup to fight for the survival of PlayStation.

The price drop didn’t help with the lack of quality of the early 3D playstation games!

[Cosmic Race - PlayStation Year One #011]

[Power Serve 3D Tennis - PlayStation Year One #008 by Retro Pals]
[Was Bubsy 3D this bad? Cosmic Race or Power Serve 3D Tennis bad?]

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

For me, the beginning of the Net Yaroze and PSX-OS connection, goes back to 1993!

Sony and Psygnosis put on the first developer’s conference for the PSX late in 1993.

SCEE had recently moved from Golden Square to Great Marlborough Street, so recently in fact the tiles floor had to be laid quickly the day of the conference.
Phil Harrison, David Worrall, John White, and Dominic Mallinson presented the machine to an audience sat in quiet awe.
There had been some leaked shots of the infamous dinosaur head, but the conference was the first time the full dinosaur was shown, fully animated, textured, and lit.
The crowd was astounded, and this wasn’t an easy crowd to impress – it truly was the who’s who of European development at the time.

[T-Rex PlayStation 1 Tech Demo by LittleBigPlanet Show]

[Very impressive for 1993!]

Well, the dino demo was also apart of the Net Yaroze!
It was a great reference for skinned mesh animation, but animation Mime/Vertex Differential File (dino.vdf) format wasn’t very well documented.

The next connections comes when the 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 F.A.Q. 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 (wearing the PlayStation shirt) 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]

To be clear, the LibGS was the pro developer graphics library and the LibPS was the ‘all in one’, Net Yaroze library which also referenced the “GS” API (Application Programming Interface) but had lines and double sided polygons features removed.

Colin mentions Namco “Ridge Racer was produced in a very short time, and the developers didn’t have any CD access at all on their prototypes”
This makes sense as Namco developed the System 11 arcade board which was mostly based on PlayStation’s prototype hardware specification.

He also says “I think a lot of input came from Namco and was used to improve the 3D capabilities of LibGS”.
-TODO-

Lastly, he mentions a 3D format called TMD, which was the only way to send 3D data to the GPU on the Net Yaroze, I would assume the libGS had more formats.
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!

WIP PS1 Net Yaroze FPS - added walls

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

PS1 Net Yaroze FPS - Prototyping dynamic level added textures
[Rendering a lot of textured quads from a single TMD and one draw call, many, many times faster]

PS1 Net Yaroze FPS - some gameplay with different coloured enemies
[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!
Jason also mentions:

Andy and Dave broke a lot of rules. First and foremost, they didn’t follow PlayStation’s library restrictions.
Other developers often complained that Crash was using some sort of secret Sony library.
That is the exact opposite of the truth.
The truth is that Crash used as little as it could of Sony’s library and the programmers basically hacked everything right to the hardware.

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.

What is PS-X OS?

I raised this question in the assemblergames forum, and read the earliest available document (V1.1, Sept 1995, Published August 1994), here are a few high lights:

…

If it has a fast enough CPU and peripheral devices, there is no need to take time to figure out a method of
maximizing the capabilities of the hardware and one may concentrate on programming by skillfully using the services provided by the OS.

…

In addition each service is provided as a C language function. By using C, not only may we aim for
better source code readability and maintainability, it also makes block structure description and
function calls easier and makes it possible to program with greater ease.

…

In this way, operating system chip capabilities are maximized and a higher level of tuning may be achieved.
Of course because everything can be done in C, there is no need to learn the intricacies of R3000 assembler.

…

Until now in hardware control of consoles, one had to analyze hardware driver code and painstakingly
work through everything with an assembler. In order to lighten this burden all hardware features are
provided as C language functions by the . The overhead of each function is kept to a
minimum.

…

Debug monitor
The command interpreter which takes an external RS-232C channel as a standard input/output device and starts.
Debugging is possible, using printf( ), whose output is piped through the RS-232C link.

Note the Debug monitor part, I’m not sure if the early dev kits used a serial interface to an external playstation prototype box, but this is exactly how Net Yaroze development worked via the DTL-3050 serial cable.

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

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

[Crash Bandicoot “Pizza Hut” (Playstation 1) - Retro Video Game Commercial by VideoGameAds]

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:

[Interview with Michael Berlyn the creator of Bubsy Bobcat by doctorclu Published on May 24, 2016]

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