I wish source code for more old games was available. For a long time I was trying to trace the source of Dark Sun: Shattered Lands and Dark Sun: Wake of the Ravager, as I'd love to port them to run in modern systems (without emulators, and with the idea to fix bugs and/or improve the art - making a "remastered edition", if you will). Same for other games I loved back in the day - the Twinsen series, Twilight:2000, and a few others.
There's the hybrid emulation approach (http://gabrielgambetta.com/remakes.html - disclaimer, I wrote that) but I haven't gotten around to doing it for these games.
This hybrid approach was used for a series of arcade games on XArcade for the Xbox 360. Frogger, Gauntlet, Joust, Gyruss and a bunch of others. I think we referred to it as "reskinning".
Mostly it was applying higher-resolution tiles and sprites but some had particle effects added. For instance, some exhaust smoke on the cars in Frogger.
My favorite was Gyruss which is somewhat like Space Invaders of Galaxian but with a 3rd person view from behind the player's ship so you see enemies come toward you in pseudo-3D. We found that the game internally used polar coordinates and had a fair bit of code that converted those 2D and chose the right sized sprites. Replaced all that with 3D models rendered at the same spot in space.
I view these techniques along a continuum where you're essentially changing the porting layer. An emulation puts that layer at the hardware. A hybrid approach pushes it some ways into the game. A source code port is above the binary but some ways into the code. A remake is at the "game design" level.
Since Data East's fall, tracking the source down seems hard, especially as many game companies of that era failed to preserve the source for many of their games.
Might be interesting to see how GOG got their Dark Sun bundle [0] running. It's backed by DOSBox, but the midi driver seems different, and some of Ravager's frequent bugs have disappeared.
Maybe a partial remake like you suggest in your article?
Theoretically they could be binary patching. By using a disassembler and a debugger to understand what's going on, in many cases bugs might be fixable inline, or by replacing old functions with a redirect to where it's been redefined (if there wasn't sufficient space to fix inline).
In the 90s a lot of companies (including big ones like Square Enix) simply deleted the source code once the game launched. They truly thought they had no need for it any more.
While I support YAGNI, I only support it when there is a copy somewhere in the source control history. I don't understand why they would permanently delete it even if they weren't planning on ever using it again? Was space that limited? Or was this a middle management kind of thing?
To be honest this is pretty normal for any modern medium. There's a period where nobody bothers to do any kind of archiving.
TV shows didn't get routinely archived until quite some time after things like "video tape" existed. Now and then early episodes of something important being discovered is news.
Most of the early history of comic strips and comic books has been lost. Original art was thrown away; modern restorers have gone through some heroic efforts to piece together archives from whatever copies of the stuff they can find.
Games? Hell, there's a not-insignificant chance nobody was even using source control until the time when video game budgets started to match feature film budgets. Companies die, and if you're lucky then someone takes home source archives. before all the drives are wiped.
If the game is part of a series or potential series, they would not delete them. If it's a one off, they definitely deleted a lot of assets. A lot of backgrounds, models, and assets from PSOne Final Fantasy games do not exist anymore, for example. This is why a lot of companies that remaster games for HD actually "reverse engineer" the game disc.
A good example is the Steam release of Final Fantasy VII - it actually ships the original binaries from the 90's PC version mostly intact. Code for things like the Direct3D 6 and software renderers, and MIDI sound is still there in the binary, just unused. All the new features like cloud saves, achievements, and original music are implemented using a separate DLL that hooks a lot of stuff in the game, like the graphics and audio subsystems. It's a pretty fascinating thing to reverse engineer.
Back in the day, I remember using Glide wrappers to run the UltraHLE emulator on non-3DFX hardware. Now, a lot of older games need a DirectX shim to fix various issues (palette and some kinds of slowdowns, especially).
You might want to look into N64 emulators like Project64. They do something similar, though closer to emulation than remake. They allow you to render the 3D objects at a higher resolution and replace the textures with arbitrary bitmap images.
Yep, very similar idea! Key difference is that DOS games didn't use a standard 3D API so you can't just intercept that and replace higher quality textures - you'd have to intercept and rewrite the renderer itself.
Definitely. My favorite game as a kid was Civil War Generals 2, by Impressions Games/Sierra, and I've been hoping that it would turn up on GOG for years now, like some of their other titles do, but it really does not like to run on modern versions of Windows. I've been keeping a Windows 98 VM around just to scratch that itch from time to time.
Old Games say they have a version that'll run on Windows 10 [0], but I've got no idea how legal that is, what with copyright age, and companies disappearing.
Oh, wow, another fan of that! Great, great game. Huge improvement over the first one, in every way. Still haven't seen anything quite like it. Closest I've played in feel (if not interface or actual play) is Ultimate General: Gettysburg. There's an Ultimate General: Civil War out now that I haven't tried yet but assume includes a ton more content. Not as stat-crunchy and no equipment purchasing though, at least not in Gettysburg. :-(
It's a pity. If you were a Nintendo fan back in the day (because if you were a gamer in the 16-bit days and did not have high discretionary income, you likely only had a SNES or a Genesis, not both), you played an interesting, albeit completely different Aladdin game, made by Capcom instead:
Interesting in its own regard for being one of the early projects of Shinji Mikami, the Capcom designer who masterminded Resident Evil, Devil May Cry, and others.
It was one of the rare games where the Genesis version bested the SNES one. I had a genesis and always felt the sting of having the lesser-than version of everything and could only jealously read about the better SNES versions in gaming magazines.
I played the hell out of my genesis Aladdin cartridge though. Fantastic gameplay.
You remember how long it took you to play through a game 23 years ago???
I wish I had a memory that sharp. When I look at these retro games, I'll sometimes recognize the box art and remember having a fondness for the game, but that's it.
Personally, I don't remember all of those experiences, but Aladdin was one that stood out. Mostly because of the crushing disappointment of playing the Genesis version at a friend's house then begging to get the SNES version ... which I'd assumed would be the same.
Well I didn't do it without losing a life! It was a little more luck than judgement though. I beat him on my last life (and I had quite a few at that point).
I still remember the music from that scene having this awfully jarring "DURRR-DUNNN" tone siren in it that was rather disturbing. Not... Sonic drowning music disturbing, but close
35 yo here. yeah I was quite disappointed by the fact I'd finish it so quickly.
And yeah I have a strange memory, I tend to remember few stuff but very detailed
Also 34, and wouldn't even be able to tell you what games I finished back then, let alone the time it took. Except for Link to the Past... I remember being quite happy beating that.
This is my favorite game of all time. What an amazing breakdown of its contents! Still inspiring in 2017. I'm glad to see other finely animated side scrollers like Cuphead are being made.
The PC shareware version of this game was the very first thing I ever downloaded from the internet back in 1995. I never got the audio to work. With my Sound Blaster 16 card it would always produce the "data noise" that you would hear if you were to play back a data track in a CD player.
This is one of those unanswered questions in my computing career. Did anyone else play the PC version and if so, did you also have problems getting the sound to work in the shareware demo? Does anyone have any ideas as to what could have caused this problem? Was it just not tested?
If I never do get an answer, one day when I have time, I hope to set up a test environment, find that old shareware demo and try to reverse that part of the code to see what it is doing.
It's available on archive.org. It (the music) works in DosBox using Sound Blaster 16 emulation, and providing the value for DosBox's "hdma" setting, rather than the standard "dma" setting. Giving it the value for "dma" just resulted in silence, but maybe could've screeched in your ear on the actual hardware.
I've got a machine with an SB16 at home, and you've made me curious to try it. My kid'll be happy to see a new game running on it :-)
Looked at it. I've got 192MB in that machine, and apparently there's a bug in the game that causes it to react badly to over 32MB of RAM, with an error like "Error allocating XMS".
I can have Windows 98 expose less memory to the process, and the game launches, but no OPL3 audio then. Apparently there are some XMS-eater programs that would consume all the spare memory, but I haven't experimented with those yet.
That's the easy solution, but I'm tempted to find the error in the code and patch the binary.
Thanks for looking into it. Hmm, I recall that I was running the game on a Windows 95 (ver a or b most likely not OSR2) box with maybe 32MB of ram? Possibly 16MB
So on your machine, what sound card do you have installed? Are you able to select sound blaster 16 in the configuration?
Also, as a side note, I finally got to hear what it is supposed to sound like on archive.org :)
I've got a Creative Labs Sound Blaster 16 card. It's a version with ISA and PnP (no jumpers), but I don't remember the exact model number offhand.
I selected SB16 in the configuration without trouble.
I also did some extra credit work: I diagnosed and fixed the memory error that I described, to get it running on my machine. There's a place in the code where it gets the number of kilobytes of free RAM. It compares it to the required memory, then uses a "jg" (signed comparison, jump if greater) to jump. I changed that instruction to "ja" (unsigned comparison, jump if above), and the game boots correctly now.
Of course, the easier answer was always "download the demo from archive.org and run it in Dosbox", but then you're missing out on part of the fun ;-)
Thank you for the follow up. I have an old Pentium 3 laptop lying around that I have been meaning to try to use to simulate the audio issue. I am not convinced that giving the value of "dma" is what caused the audio glitch.
I wanted to record a video showing the issue so maybe we can try to trace what was causing the audio problem. It could have been maybe an old version of the shareware demo with the bug? Maybe there was something specifically wrong with my machine back in 1995? I do recall that I did have an ISA Sound Blaster 16 card. I am not entirely sure but I may have re-tested the game (and still had the problem) in 1998 when I got a better computer, this time with an AWE64 Value ISA card.
I have to embarrassingly admit that despite me studying CS, I would not know how to trace the game like you did to discover the cause of the memory problem. One day I hope to get to your level of expertise.
I have not been able to set aside some time to see if the audio glitch is reproduced on that Pentium 3 laptop. I am not even sure what kind of sound card is in there but it is the oldest hardware that I have so it will be worth a shot.
The (S)NES classic editions have demonstrated the clear appeal of these older platforms.
I think Nintendo/Sega/etc could rake in a lot of cash if they designed new games for these old systems. I would love to see a new Super Mario World-esque game that operated within the confines of the classic SNES.
I'm not sure what would be earned for developing such a game verses developing one on a modern system that looks like it could have been from that era. It would likely cost less to develop and would be easier for the average consumer to use. I've played a number of 16-bit games since that time, and some manage to pull of a similar feeling.
That's true, although I guess there is some sort of value for people using "authentic" stuff instead of emulators, etc (even though the SNES classic likely runs on an emulator, it still feels more like the old device).
Primarily, I am interested in seeing another effective 2D Mario with the same charm and style as the SNES games - I do not care so much if it is running on a modern system. :)
> (even though the SNES classic likely runs on an emulator, it still feels more like the old device).
Yep, the NES and SNES classic things run an emulator on a little ARM computer. It's possible to replace the games with other games, or to copy the emulator off and get it working on something like a Raspberry Pi.
Have you ever tried out a "rom hack"? People often alter ROMs code to make entirely new worlds/levels. Pair them with something like an ever drive and you get to play them on the real hardware.
Just a word of caution for anyone looking to buy rom hack cartridges, many rom hacks were never intended to be put on cartridges and the original rom hack developers do not support nor benefit from doing so. It's also possible the rom hack on the cartridge isn't the final version.
I am not sure I understand, so I will defer to you.
My understanding was that independent game authors were writing games and making cartridges for these games which they then sold.
If I am understanding you correctly, somewhere in this chain is copyright infringement? Are people buying a cartridge, extracting the content, and loading it into new cartridges?
Is the market large enough to support that much effort and expense?
Or are people finding roms, perhaps intended for use with emulators, and loading those onto physical cartridges and selling them without renumeration or permission?
If so, is the market large enough for that to go unnoticed? My understanding was a successful new game might sell a few thousand cartridges and great success was in the 10,000 units sold area.
Being so small a market, and requiring the investment to even make the cartridges, it'd seem easier to spot this (from the IP owner's perspective) and seek preventative legal responses.
Sort of related: I know this requires some specialized equipment to make new cartridges, but do you know if they sell blank cartridges that can just be loaded with games? I am aware that some cartridges had custom chips on them and didn't confirm to any standard, like Zelda cartridges that contained memory and a chip for saving game states.
I am guessing, hopefully, that you know more about this stuff than I do.
> Or are people finding roms, perhaps intended for use with emulators, and loading those onto physical cartridges and selling them without renumeration or permission?
I think they're talking about this case (based on the wording "rom hack cartridges"). Someone takes an original game ROM and modifies it in some way (translation, level mods, whatever). Someone else takes the modified code, burns it onto actual hardware, and sells the result.
> Sort of related: I know this requires some specialized equipment to make new cartridges, but do you know if they sell blank cartridges that can just be loaded with games?
The usual method that I know is to remove the ROM chips from a donor cartridge (a working game), and replace them with chips flashed with customized data. The donor cart would need to provide the same custom chips/memory mappers/whatever that the game code expects to be present.
Ah! That explains the method, at least. I'm a bit surprised that the market is large enough to support the effort and expense. My limited exposure suggests that it isn't a very large market and I'd been led to believe that it wasn't very profitable.
Though, I suppose it becomes more profitable if you're not paying to develop the game or for the rights to distribute the game.
I wonder if there's technically a possibility for, and a market large enough, for generic cartridges - perhaps several kinds that had different standardized hardware in them.
I don't know much about market size, but I know that some developers are working on physical releases of new games for old consoles. Written from scratch, with new IP.
It says that the NES game Star Versus has sold about 300 copies since its release (in 2014, I think). So, there's an idea of the market, I suppose. I haven't found much in the way of information about its development, so far. There was a forum post that mentioned that it seems to use a new, undocumented memory mapper chip, which implies that the developer produced their own, rather than use the "donor" method that I suggested earlier.
>My understanding was that independent game authors were writing games and making cartridges for these games which they then sold.
In most the cases I'm familiar with, the official release is only a patch file. You have to patch the original game with the patch file yourself. Often a third party will patch the file and host it themselves, making only add revenue. In some cases, a fourth party will take the patched file (either creating their own or taking one from the third party), and put it in a cartridge which they then sell of a significant sum of money (compared to the third party who is only getting the add revenue from you using their site).
In general, the people actually making the patch aren't making any money off it because of the increased risk of being shut down by whomever holds the original IP.
>Is the market large enough to support that much effort and expense?
I think the market for custom cartridges is mostly driven by people who buy cartridges and load their own roms onto it for their own use. Only a few do the extra work of trying to load roms and sale them.
Then again, certain games can go for $50 or more on ebay for a used cartridge. If you can fake the cartridge good enough, you might be able to make decent money selling these.
>it'd seem easier to spot this (from the IP owner's perspective) and seek preventative legal responses.
It's probably hard to track down because of the independent nature of those doing it. It's like the $50-$100 dollar craigslist ads for people offering to mod your SNES classic and add a bunch of roms to it (once you have everything set up, it is less than 15 minutes, and $50 tax free dollars is pretty good income for them amount of time).
>but do you know if they sell blank cartridges that can just be loaded with games?
That's my understanding of how most of this works, but that may be wrong. I personally don't do cartridges since my old systems are more finicky than using an emulator.
>I am guessing, hopefully, that you know more about this stuff than I do.
I only deal in the software side and don't do anything to make money. I'll help friends set up emulators on their PC, or help them with a retro-pi/SNES classic mods, but always for free. The extent of my knowledge of the hardware cartridges is based on posts by the rom hack creators disavowing any relationship with the hard copies. Though as another poster pointed out, I have seen a few people attempting to release hardware copies of new games. Mostly I just deal with unofficial English translations of JRPGs.
I once tried to create a legitimate ROM for the Gameboy Advance but it was obviously pretty involved. For those interested, plenty of resources such as: http://www.loirak.com/gameboy/gbatutor.php
Yeah - GBA homebrew is hard. Mostly because it's a modern processor (it's an ARM7TDMI) with some really nutty RAM and graphical limitations. But any 8-bit or most 16-bit systems (except the Genesis, which is something of a kludge) are pretty straightforward.
I do streaming charity events on occasion and an idea I've had is collaboratively writing an NES game over the course of a weekend, on-camera.
What? GBA is clearly easier than NES. Just set up a single tile layer in mode 0, and you got what's practically a NES with more colors, sprites and a much more powerful CPU that you can program in C++ if you like.
Sure, if you sit in mode 0 it's pretty simple. But if you're writing code for the GBA, you're probably gonna want to do stuff with the GBA's feature set, yeah? The bitmap modes, affine sprites and layers, sound, etc. get a little bit complicated. It's all stuff you can learn, don't get me wrong, and it's not like it's not so weird that knowledge you'd acquire from using other systems isn't applicable--but I find that there's a lot more that I had to have in my head when playing around with it than the NES (or systems I lean towards more, like the C64). It's a great platform to mess around with, but it is more complex. But if you're not going to use that complexity, for homebrew--I dunno, I'd just go grab a NES emulator.
GNU C++ had gremlins for the GBA last time I was writing homebrew for it, so I can't speak to that. I kinda enjoy writing assembly when messing around with this stuff, though, so, eh. For anything else, I love me some (Modern!) C++, but it kind of feels like I should be writing assembly for that stuff, it's more fun to me.
Do me a favor and chew on something for a sec, though: what does your "What?" do except add a hostile and combative edge to the conversation? Maybe don't do that. Thanks.
The NES is a much simpler system. Granted, it's a simpler system that you're programming in a less-convenient language, but I think that which one is "easier" depends on what you're used to.
Most 8-bit systems perform poorly with C compilers so you are looking at writing in ASM. Additionally, there are all kinds of messy things like "mappers" on NES and GB to handle bank switching of the severely limited address space.
GBA lets you use C without bank switching. I'd say it is far easier than the older generations.
If you want to write C, that's an absolutely fair cop. I would much rather write assembly for this stuff--as I mentioned in a sibling, it sorta feels right?--so that wasn't something I was thinking about. Rather, the profusion of features that are kinda tricky (mentioned in that sibling) along with the ARM/Thumb mess.
I recently found a channel on YouTube ran by an old Telltale Games developer talking about some of his development tricks, mostly for SEGA Genesis games. Really well done.
I searched the website and didn't find anything. Is it really an archive if it is private? Sure, museums and stuff have a lot more in archive than is what is on display, but at least some of it on display.
There's the hybrid emulation approach (http://gabrielgambetta.com/remakes.html - disclaimer, I wrote that) but I haven't gotten around to doing it for these games.