See http://all-things-andy-gavin.com/video-games/making-crash/ for more making-of details.
EDIT: And they were running 200Mhz MIPS CPUs - blazing fast!
Otherwise, go for the lower level part: mednafen.
Love reading gems like this!
can't find the bit about the opengl tho
The code was C and lisp so it didn't really require any effort to port other than replacing the rendering pipeline. And we used the SGIs to pre-render every frame anyway, to precompute the polygon sort order. (The PS1 had no Z-buffer, so you were stuck sorting polygons at run-time if you didn't do something clever.)
So we already had the rendering pipeline ported. Obviously you couldn't save your game to the memory card, etc. -- some stuff didn't work. But the game was playable (albeit very frustrating with keyboard controls).
The camera in Crash was on a rail. It could rotate left, right, up, and down (in Crash 2 and beyond, at least), but could not translate except by moving forward/backward on the rail. This motivates a key insight: if you're only rotating the camera, the sort order of the polygons in the scene cannot change.
This allowed us to sample points on the rail and render the frame at each sample point ahead of time, as a batch job, on the SGI using a Z-buffer. (We may have done the Z-buffer with software; I don't remember.) Then we could recover the polygon order of each frame by looking at the Z-buffer. And, even better, at run-time we could simply not render at all those polygons that weren't ultimately visible in the pre-rendered scene. This solved both the sorting and clipping problem nicely, and made the look of the game closer to 3K polygons/frame vs. the 1K polygons we were actually rendering in real time. (Many polygons were occluded by other polygons.)
The trick, though, was what exactly to do with this sort/occlusion information. In a nutshell, what I did was write a custom delta-compression algorithm tailored to the purpose of maintaining the sorted polygon list from frame to frame, in R3000 assembly language. Miraculously, this ended up being quite feasible because the delta between frames was in practice very small -- a hundred bytes or so was typical. And if a transition was too heavyweight (i.e., the delta was too big) we'd either sample more finely in that area or tell the artists to take stuff out. :)
One thing nobody talks about but which is obvious in retrospect is that without a Z-buffer you're pretty screwed: sorting polygons is not O(N lg N) -- it's O(N^2). This is because polygons don't obey the transitivity property, because you can have cyclic overlap. (I.e., A > B and B > C does not imply A > C). This is why virtually every game from that era has flickery polygons -- they were using bucket sorting, which has the advantage of being linear time complexity, but the disadvantage of being wrong, and producing this flickery effect as polygons jump from bucket to bucket between frames.
I'll leave the matter of weaving the foreground characters -- Crash himself and the other creatures -- into the pre-sorted background for another day.
Hearing how you managed to squeeze all this stuff out of what sounds like it was an experimental platform for 3D is just amazing.
>>I'll leave the matter of weaving the foreground characters -- Crash himself and the other creatures -- into the pre-sorted background for another day.
Please do \drool
And you can actually see a difference between Crash 1 and Crash 2+ if you pay close enough attention. For Crash 2, Stephen White cloned the PS1's renderer in software for the SGI so that it was pixel-for-pixel accurate. He did this in like two days, thereby earning himself a place in my top-5-programmers-I've-ever-worked-with list.
If you look closely during Crash 1 while you're moving Crash, you can see sometimes see what Andy not-so-affectionately called "crispies". These are pixel-size flickery bits caused by the subtle difference between the SGI's renderer and the PS1's hardware renderer. Just the difference in the way the two implementations rounded fractional coordinates showed up in the game.
I must say going with very minimal texture on Crash is intriguing. FF7 also uses very little I believe during combat, they all look like color shaded mesh but it clearly looks good on Crash.
All these development stories from 90s is fascinating, especially because there's a fond childhood attachment to the PSX.
On one of the Playstation Underground Magazine discs there are entire series on the development on Crash Bandicoot. These are truly a gem. Myself having watched the entire series.
Crash also benefited from the (at the time) novel rendering model that Andy, Mark (Cerny) and Jason developed. This basically allowed any vertex of crash to move anywhere in the animation sequences -- which was huge, because it allowed Jason to approximate traditional squash-and-stretch even on that limited hardware.
Though since this was written in Unity, it would be pretty easy to detect if it were using any of the networking libraries.
 - http://hatintime.com/
And maybe changed the pitch.
It seems to be a 1:1 copy of Mario 64/Galaxy mechanics but without any of the aesthetic charm. Inspiration's good and all, but straight up copying isn't. That's just insanely off-putting to me.
the classic game "Descent" was written by Parallax and published by Interplay. The split-up remnant of Parallax owns all of the assets -- the ship name and artwork, the name of the evil corporation, the music, the robot artwork. Interplay owns the name Descent. Anybody can make a game that flies like Descent (Sol Contingency and Geocore are both trying to), but only an Interplay-licensed company can call their game "Descent", and only a Parallax-licensed company can put in the "Pyro-GX" and the "PTMC". And there seems to be some distrust between the two companies.
This has led to a fair bit of complication for the Interplay-licensed Descent:Underground game (currently on kickstarter -- https://www.kickstarter.com/projects/descendentstudios/desce... ). A lot of fans are asking "where's the pyro?" Well, they can't have the pyro, because they don't have a license for that part of the game. They can make a ship that looks fairly similar and flies identically, but it has to be identifiably visually different and have a different name.
"The first approach is from the 2nd circuit "The Subtractive Approach" (Altai, Nichols) and the other approach is "The Concept and Feel Approach" (Ruth Greeting Cards, Krofft)"
I am curious to know what would happen if someone decided to clone the exact level design of a game but changed all the audio/visual assets.
This actually happened quite often in early generations of computer games and consoles. Super Mario Bros had quite a few clones where all that changed were the visual assets.
More recently, there are many examples of this happening on the iOS App Store and other venues with a low barrier to entry.
Pure speculation: It's possible Super Mario Sunshine(2002), Super Mario Galaxy(2007) and other Mario-like 3D could have "refreshed" any patents from Super Mario 64.
That is, if any patents from Mario 64 exist.
The patent in question, http://www.google.co.uk/patents/US6410835. Espacenet has it too of course, http://worldwide.espacenet.com/publicationDetails/claims?CC=..., but Google is better is it gives the B2 published form of the claims as opposed to the A1 first submitted form. Major fail there for the EPO's ESPACENET in my opinion.
Claims 1, priority date is 24 July 1998:
>"1. A dance game apparatus comprising: music output means for outputting one piece of music from at least one stored piece of music; a floor panel having a step-on base section; said step-on base section comprising a top panel and a support member which supports the panel; detection means for detecting a stepping operation on said step-on base section; said detection means comprising stepping sensors interposed between said panel and said support member at mutually opposing positions of said panel; said stepping sensors comprising longitudinally extending conductive sections having a longitudinal length, one of said conductive sections being moveable laterally relative to another of said conductive sections at any one of a plurality of positions along the longitudinal length of said one conductive section to effect contact with said other conductive sections at any one of a plurality of corresponding contact positions such that said stepping sensors detect stepping on said step-on base sections at plural locations corresponding to said plurality of corresponding contact positions, guidance means for performing a stepping operation instruction to said step-on base section in time with said music; measurement means for measuring a time deviation between the timing of a stepping operation instruction and the time at which the fact that said step-on base section is stepped on is detected by said detection means; and evaluation means for providing a higher score the smaller the measurement result." //
FWIW the Mario Kart patent you cite refers to methods of controlling NPC in order to provide strong rivals, avoid bunching of NPC in racing games and provide variation in race orders despite relatively fixed characteristics (acceleration and top-speed). None of that prevents you having cars with the same styles, having the same tracks, having the same end goals, having the same range of pickups and such - it only relates to specific algorithms for providing competing computer controlled cars/NPC.
Now though, I can't see this as being acceptable for Nintendo.
This is clearly a rabbit hole of exceptions and ifs, but this somehow doesn't apply to music as well, based on the recent judgement over Blurred Lines (the song).
However, on the primary copyright issue of the APIs, the court ruled that "So long as the specific code used to implement a method is different, anyone is free under the Copyright Act to write his or her own code to carry out exactly the same function or specification of any methods used in the Java API. It does not matter that the declaration or method header lines are identical." The ruling found that the structure Oracle was claiming was not copyrightable under section 102(b) of the Copyright Act because it was a "system or method of operation."
_The appeals court reversed the district court on the central issue, holding that the "structure, sequence and organization" of an API was copyrightable._
I have no idea why you think this.
This is long settled in US law. Things like art and text are copyrightable. The game itself is not.
What is a game if not an expression of an idea? I would not call the idea for a game a game. I would call the expression of an idea a game. Therefore I would consider games protected by copyright. At least in casual conversation. When speaking in legal terms there is a lot more nuance.
On one hand you can say that games are not protected. Tetris however is. And has successfully been defended us such in court. http://arstechnica.com/gaming/2012/06/defining-tetris-how-co...
If you re-created Mario 64 from scratch but art swapped every asset with something original you would get bitchslapped in court. Hard. The layout and configuration of levels is not an idea. It's an expression of an idea. If you want to make a different level using different assets but using the same mechanics of Mario 64 then that is probably acceptable. You're making your own expression.
It does get a little tricky if you start copying the physics of Mario 64 precisely. There are lots of platformers. Why copy the exactly moveset from Mario 64? Why meticulously reverse engineer the physics of jumping from Mario 64? Copy too much and you run risk of losing a copyright suit as demonstrated by Tetris.
A set of rules. Such rules are potentially eligible for patent protection. They are not eligible for copyright protection.
> On one hand you can say that games are not protected. Tetris however is. And has successfully been defended us such in court.
I suggest you read the actual text of the Mino decision, which rests heavily on visual elements, not gameplay. I also suggest you not put too much stock in the decision of a single district court judge. District court decisions are not binding precedent. Especially ones obviously written by a judge who either doesn't understand what the functional elements of a game are, or was looking for an excuse to find for Tetris.
> The layout and configuration of levels is not an idea.
Those would be assets.
At least you agree with me that layout and configuration of levels is protected by copyright. At least I assume you believe that assets are protected. You don't specify.
All of these waters are largely untested. It doesn't take much discussion to hit them. Good luck.
Edit: and :)
Trademarks seem a much higher legal barrier for example.
EDIT: This is obviously not true for some X where X is a base case of a popular game genre (e.g. Portal, Donkey Kong, Wolfenstein 3d), but it's generally true. Mario 64 is just a 3d platformer at some level, which is why it's so easy to clone.
Wolfenstein 3d: Catacomb 3d
Note- I'm not certain that the games on the right are the originators of the genre of games on the left, but they certainly came prior.
"Most closed source things will likely be useless in 5-10 years unless constantly updated, and even though not likely. Once opensourced, however, it can endure. You get tired of it, feel it is done, or just need to move on, someone can always come in and make sure it works on new systems. "
When that happens, I suggest he call it Dangerous Dave Controller.
"Everything is just as you remember, except some really minor stuff that nobody cared about like red coins or the Wing Cap or the Big Bob-omb."
Chain Chomp is missing and lots of people cared about him, and there is a TON of environmental detail missing too, causing the level to look very empty.
"Haha I was mostly kidding about the Wing Cap. It’s actually one of my favourite parts of the game! But the time it would take to do the code and animations would just have been too much extra. Same goes for the other moves, since it took awhile to do each animation. I tried to make sure all the essentials were in first and foremost. Glad you liked it!"
Wahhhhhhhhh!(?). You needed the red coins to get the star! Who DIDN'T care about the red coins?! I'm not a completionist, but getting the red coins in Mario64 was actually a fun challenge and not some tedious badge task.
"Cool Game I Made Using Unity" gets, well, not that much.
I hear the guitar riff in the left audio channel, but I don’t notice it ever clashing with the main melody. It plays varied chords most of the time. When it is monotonous from 0:39 to 0:55, the note it repeats is always a note in the underlying chord, so I still don’t perceive it as clashing.
Really? Lame one? Devoted cult?
Edit: still a fine joke, but not funny for the ambiguity.
It brings back lots of memories...games were so good back then!