- News for September 12, '98 -





Neil Bradley Talks Retrocade! - September 12, '98 by JoseQ
In a few days, Retrocade will be released to the public. This has been one of the most awaited emulators for a long long time. There are many reasons for this. Among them the fact that many great favorites are in it, some new previously unemulated games, faster speeds and a killer GUI make up this great Emulator. Hype has been built up over months, and it will be time to live up to expectations for Retrocade. With a huge beta testing team doing Quality testing as you read this, Retrocade should prove to be one of the best emulators in existence. Read on as we talk to Neil Bradley, one of the main heads behind Retrocade, as he expresses his feelings about some controversies regarding this emulator as well as what you can expect to get this Monday. NOTE: This InterView was done about two weeks ago, so time related answers are outdated.

1. How in your personal opinion is Retrocade turning out to be? Everything you expected?

In most regards more than, in some regards less than. If I had known that Retrocade, in its current form, would take me over a year to complete (with help from others of course), then I probably wouldn't have done it. I expected to go beta in November of last year. What I envisioned Retrocade becoming and what it is now is almost totally different. It saddens me that it has taken so long to get to where it is today, and that it isn't released yet, but at the same time I'm proud of what it is. When people start out with projects this large, the focus, featureset, and operability shift over time. On several occasions, I had considered just dropping it altogether, but I'm glad I stuck with it. We have rewritten sections of the code sometimes 2-3 times.
Performance-wise, it's a better performer than I thought it could ever be. I really do like the feature set and ease of adding platform extensions into the core. I think the architecture is 95% of what it should be.

2. Do you think you can run out of ideas to add to Retrocade? How much (percentage wise) of Retrocade is done compared to everything you want to put into it?

There are far too many ideas floating around for us to run out of things to add to Retrocade. ;-) One large regret I have is that I haven't had time to do any theory testing, such as dynamic translation, or other minor emulation-asseted programming efforts. I'd love to create a library of ASM graphics drawing routines - specifically targeted at emulation - for all to use. I'd also like to create a 68K EMU in ASM, freeware, just like my other ones. They'll eventually get done. It's just a matter of when. Retrocade is eating up all my time.
Percentage-wise of what I expected Retrocade to be and what it is? 140%. There are several features in it, like the tweaked VGA modes and state save, which I didn't envision would be there at all. Same with translucent vectors, antialiased lines, and backdrops. That wasn't originally on my radarscope at all.

3. Are you satisfied with the speed achievements made in MAME? Do you still see room for speed improvements?

I think the speed improvements are a good start. Satisfied? Nope. But then again, I'm very hard to please when it comes to speed. I've been known to spend hours getting an extra 5fps out of a game, trying theories, etc.. I still think that games like Marble Madness should be playable, full speed, with sound, on a Pentium 133 (and I mean 44.1khz sound). In my opinion, it isn't optimized until the machine is just flatly out of power. But that's Retrocade's goal, not MAME's. I actually get aggrivated when I pour a bunch of work into Retrocade and get little to no payoff in performance. There are a few games I'm holding back because they aren't fast enough, and I haven't had a chance to get to yet.
There's no question that MAME can be improved further. However, from what I've been told by a handful of MAME developers, the graphics engine is the bottleneck, not the CPU cores. A rewrite of the CPU cores in assembly would help MAME, but not to the degree that everyone thinks it would.

4. Were all those speed improvements achieved via honest optimizations or is there some tweaking, tricking and assuming involved in there?
I think there are only 3 cheats:

  • One, the sound engine in Spy Hunter is not a 68K emulation - it's a translation of what the board would do. This is the only way we could get speed out of it. The output of everything is still identical, and it still pulls data from the ROMs.
  • Two, the drums in Gyruss are not 8039 based - they are samples. We didn't like the way the 8039 sounded, so we created samples in the spirit of the originals. I don't think that the original authors would've used an 8039 to generate crappy drum sounds if they had other options.
  • Three, in Burgertime, we don't do runtime decryption of the ROM images - we decrypt them after loadtime.
The list above might look like "not true emulation", but the end result winds up being the same, and they certainly make things much faster, which is Retrocade's primary purpose. Keep performance up!
But everything else is 100% emulation - no cheats or funky tricks.

5. There are rumors surrounding Retrocade about a "borrowing" or even "stealing" code or design from other emulators, for example MAME?

No. Not true at all. Mike Cuddy & I had freeware emluators before MAME existed, and our architectures were pretty much hammered out before MAME came along. It's also all our code. The architectures of the two emulators aren't compatible with eachother. I learned that lesson when I gave Aaron Giles my Blasteroids PE to work on. But looking at MAME's source, we've solved some of the same problems in different ways.

6. How bout the rumor that Retrocade is an end-user product, simply cause in the end, if possible, it might be for sale?

Retrocade is an end user product. That's what it's designed to be. As far as the "We're actively seeking to sell Retrocade", it's a load of crap. I don't know how the rumor got started. Retrocade is not currently for sale. I'd rather not ever have to negotiate a contract with these game companies (already did it several times unsuccessfully).
However, I have said before that I'm keeping my options open to go commercial, which is part of the reason I am not releasing source code in its entirety. This means that if a game company sees Retrocade, likes it, and wants to pay us lots of $$$$ to develop or license it, I am *NOT* going to say no, and I am doing things like writing my own code for various operations (sprite code, CPU emulators, I/O handling, sound engine, etc...) to minimize contract hassle in the off chance that Retrocade might be approached.
That being said, it doesn't mean that I *WANT* Retrocade to go commercial. Honestly, I hope it doesn't. Negotiating with big game companies is really frustrating, because they have a tendency to not tell you everything and also promise the world but deliver nothing. The negotiation process is tiring and aggrivating. That ruins the fun of it all. Regardless of the money, if the fun isn't there, it's not worth doing.
But if a game company wants to offer me (or us) a job in the gaming industry in exchange for Retrocade's rights, I'm all theirs. The only hidden agenda I have is that it adds a great line in my resume, maybe gets me some contract work or a job at a game company, and makes people happy. I already have a job that earns me a decent living, so it certainly isn't money I'm after. I didn't start doing emulation because I thought it would earn me money. I started emulation because I thought it was fun to relive the games I grew up with. I strongly identify at least 6-8 years of my childhood with video games, and as an adult, I get to be a kid again - both from the aspect of playing the games and learning just how ingenous the old arcade game authors are, and making a few other people happy in the process.
I've always been up front with this information, and there's nothing more aggrivating than lamers on the message boards posting false information that you know are blatant lies. I don't have a hidden agenda, and never did. And after releasing a freeware emulator and many freeware processor emulators that are used in a couple of dozen emulators, to be accused of trying to "cash in" is about the biggest insult an emulator author can get.

7. Is there any secret behing Retrocade that helped you achieve this great quality product, with incredible efficiency?

Oh please. ;-) Praise on an emulator that hasn't been released yet. ;-)
There is no secret. All of the techniques I've used to increase speed are as old as the games we're playing. But one thing that I did the entire time was rewrite, rewrite, rewrite, optimize, and rewrite. This is, of course, the main reason it has taken so long to write.
Most coders fall into the trap of thinking that there's never time enough to rewrite it, or "I don't want to rewrite it". The fact of the matter is, a rewrite, in a lot of cases, is what's in order. I've seen projects profesionally that could have used a rewrite, and would have taken much less time to develop and would've been a much better piece of code to base their work on. Always throw your first piece of code away when you prove a theory.
The other famous pitfall is "I'll optimize it later". The problem is that the best optimization tricks are algorithmic changes, which are tough to alter in big ways after they're created. What you wind up with are small optimizations that help performance a bit, but you never get the big wins that an algorithmic or architectural change will yield. Ask yourself this: If you are going to build a 1 ton pickup truck, would you mould and shape a VW bug's frame until it became a truck?
And the final famous pitfall: "I'm going do to an emulator and I'm going to write it in C++". That's exactly like saying, "I'm going to dig a hole, and I'm going to use a spoon to do it!". One should never fall in love with a language, construct, or operational theory about anything, and should *ALWAYS* evaluate the tool for the application, rather than shaping the application to fit the tool.

8. What items are on the to-do list that have kept Retrocade from falling out of the Beta status?

Mostly buttoning up "required" features and ensuring that they work properly. Adding things in to make transitions between games smoother. Going back and fixing "little" bugs, and maybe a feature or two here and there (like save state). Oh yeah - and documentation. Getting the web site fixed up. And most importantly, making sure that I haven't induced more bugs. ;-|

9. After the first release? What's next?

Bug fixes! ;-) Seriously. I'm going to be tracking what people whine about most and fix most of that stuff first before going on. People will be happy to know, though, that when new versions come out, emulation overall will never get slower. If anything, it'll get faster. The main CPU execution core loop hasn't changed in about 2 months.
After that, I really want the Atari system 1 games in there. That'll be my main focus after release, along with getting the Windows and Macintosh versions whipped into shape.

10. Will you be shooting at newer, more advanced technology, more colorful kind of games, or is classic status the key to the games that will be eventually added to Retrocade?

We want the "cool" games. And the "cool" games, by definition, are a combination of the games that we like the best and the games that end users like the best.

11. Finally, when is the world turning Green, Retrocade green? (Can you put a rock hard release date?)

I can't. Best estimates at this point are 2-3 weeks. But don't hold me to that. Surprisingly, we have personal lives, too, which tend to get in the way sometimes of more important matters. ;-) I also don't want to release too soon with irritating bugs and risk the wrath of angry users. If I release too late, it's vaporware. I can't win, man! ;-)

One Article Up: The Dead of Slapstic
One Article Down: PSEmu Pro's Tratax InterViewed!

Post Some NEW Comments on this topic...

2001 EmuViews