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.
|Neil Bradley Talks Retrocade! - September 12, '98 by JoseQ
1. How in your personal opinion is Retrocade turning out to be? Everything
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:
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.
- 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.
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
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
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
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
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!