Turbo Engine 16 emulator by AamirM

[AamirM]

Out of curiousity, what advantages does this emulator have over Magic Engine? I paid for my copy of Magic Engine some years back and have been thrilled with its overall accuracy and features ever since. Is this new emulator going to be more accurate? Again just curious.

Well, the most obvious advantage is that this emu is free . Secondly, it doesn't use any hacks whereas Magic Engine seems to be. Thirdly, and this may not count as advantage for some, everything is cycle based except the renderer which is line based. Simply put, it is like bsnes but it doesn't run things in parallel (thats on my todo list ). My current build can run all the Hucard games, except one, quite perfectly. I can fix this one game using a hack but I am not going to. This emu also has perfect SuperGrafx emulation whereas the SuperGrafx emulation in ME is more or less completely broken. Thats all I can think of . And I almost forgot, it has a cooler name than Magic Engine.

But this emu has some disadvantages as well. Most obvious of them is that there is no CDROM emulation yet. Magic Engine can run that one game this emu can't. It does not supports 6-button/multitap controllers. ME has more features (for now ). This emulator is the slowest emu out there and requires a very powerful system to run full speed. This issue will be addressed in future. For now, the code is being kept simple.

And yeah, I am NOT trying to compete with Magic Engine or any other emu for that matter. I completely respect their work and I've heard the David Michel is a nice guy who shares his findings. So the above comparison is invalid .

My parser's only ~80 lines and some type traits.

Nice! . Your variant to INI sounds interesting. I haven't seen such small implementation. But the problem of varying field width is still there. For example, Cheat0=address:data,address:data......There can be one pair or as many as you like. This is hard to handle.

[h4tred]

Well, the most obvious advantage is that this emu is free

Easily solved by opening the emulator up in a debugger.

[AamirM]

Easily solved by opening the emulator up in a debugger.

Something not everyone (I think >95% of users) can do .

[byuu]

For example, Cheat0=address:data,address:data......There can be one pair or as many as you like. This is hard to handle.

Not with a decent string library :D

Code: Select all

stringlist item;
item.split(",", Cheat0);
for(unsigned i = 0; i < item.size(); i++) {
  stringlist part;
  part.split(":", item[i]);
  unsigned addr = part[0].fromHex();
  unsigned data = part[1].fromHex();
  cheatcodes.add(addr, data);
}

Easily solved by opening the emulator up in a debugger.

We'll call it ... Magic Engine Cloud ;)

[FirebrandX]

This emu also has perfect SuperGrafx emulation whereas the SuperGrafx emulation in ME is more or less completely broken.

I'm not sure that's correct. I believe Daimakaimura is a SuperGrafx game and it plays perfectly in Magic Engine. I've also used Magic Engine to run Rondo of Blood, which seems to run great (though I'm sure its not technically a supergrafx game).

[AamirM]

I'm not sure that's correct. I believe Daimakaimura is a SuperGrafx game and it plays perfectly in Magic Engine. I've also used Magic Engine to run Rondo of Blood, which seems to run great (though I'm sure its not technically a supergrafx game).

Hmm...I'll have to recheck it again then. I am sure the last time I tried SGX games on ME, they weren't displaying correctly (some layers wouldn't appear right).

EDIT:
Here is what I am talking about:





Many leftmost columns are missing in Daimakaimura.

Not with a decent string library

Writing custom parsers is one of the thing that XML is trying to avoid. And did I mention that the read/write methods of some parsers are template-ized(templated?)? so you can use it for just about any thing .

And, why are you re-implementing something that standard library provides? *looks at nall*

[h4tred]

We'll call it ... Magic Engine Cloud

Well yeah, but thats plain lame

Still, I am amazed the latest version is not up on the rls channels.....its shareware, after all.

[byuu]

Writing custom parsers is one of the thing that XML is trying to avoid.

Yeah, it's nice having stuff done for you in libraries.

And, why are you re-implementing something that standard library provides? *looks at nall*

The standard library does not provide the utilities of nall.

std::string stores memory differently (like a C-string, done for compatibility), doesn't work like stringstream on its own, lacks split and replace functions, let alone q-variants (ignore data inside quotes, very useful for language parsers), and the cast to const char* is painful rather than implicit. I can also easily wrap it around other types, like QString. std::vector<std::string> is just horrible to use compared to stringlist.

std::vector is designed to handle objects without simple constructors, meaning you can't index out of bounds without the program crashing / throwing an exception. I require a default constructor, but in return you don't have to call push_back for each element. It's far more convenient:

Code: Select all

nall::vector<foo> f; f[7].x = 3; //no crash

Not saying my versions are better than C++'s, but the syntax is much nicer for me.

nall::array is a POD-container, it can probably be replaced with C++0x's array.

Type traits, nall::function and nall::any are only in boost, but C++0x may help to eliminate some of them.

The rest are things you won't get elsewhere. Priority queue, modulo array, variable-bitlength integers that work 100% transparently as regular integers (int_t<24> n), stdint-wrapper for compilers without it, etc.

[AamirM]

*Sorry for the double post. See below*

[AamirM]

Yeah, it's nice having stuff done for you in libraries.

Yep, sure is. But the good stuff is almost always OS/platform specific.

...lacks split and replace functions...

*AamirM remembers his RetardedString class*

The rest are things you won't get elsewhere. Priority queue, modulo array, variable-bitlength integers that work 100% transparently as regular integers (int_t<24> n), stdint-wrapper for compilers without it, etc.

Really nice. I didn't noticed those things.

[FirebrandX]

I'm not sure that's correct. I believe Daimakaimura is a SuperGrafx game and it plays perfectly in Magic Engine. I've also used Magic Engine to run Rondo of Blood, which seems to run great (though I'm sure its not technically a supergrafx game).

Hmm...I'll have to recheck it again then. I am sure the last time I tried SGX games on ME, they weren't displaying correctly (some layers wouldn't appear right).

EDIT:
Here is what I am talking about:





Many leftmost columns are missing in Daimakaimura.

There must be something wrong with your version because mine never shows these errors. Here are the same two games from my copy of Magic Engine:





At NO POINT in either game do graphics or columns of graphics disappear from my end.

[Dullaron]

Working fine here as well. Using MagicEngine v1.1.3. http://www.magicengine.com/

I found this on his website.

"2009-01-21

The new version may be a bit late.
At the moment I'm running a lot of tests on a true PC-Engine to tune the new emulation core but it's taking me more time than I had planned so the release will probably be late of one or two weeks, this should push it to early february. ^^;"

So there another version coming soon.

Btw: You can get another key for newer version. If your key doesn't work on the newer version. Send your info to dmichel in pm at that forum.

[FirebrandX]

Like Dullaron, I am using 1.1.3 registered to my name of course. I know this should be taken with a grain of salt, but here's the claims from the programmers concerning 1.1.3:

MagicEngine emulates the PC-Engine almost perfectly. The emulator has:


full HuCard emulation!
full SuperGrafx emulation!
full CD-ROM and Super CD-ROM emulation!
(with a custom System Card - no BIOS ROM needed)
full Arcade Card emulation!
very accurate and fast emulation!
game save/load feature!
nice and easy to use graphical user interface!
five players mode - fully configurable!

[Panzer88]

the author of Ootake claims Magic Engine has some sort of desync or delay for really fast fighters, scrolling shooters etc. but that doesn't really mean anything either. just sayin.

[FirebrandX]

I read that article he wrote, and its referring to an overall emulator approach to polling the controller for input. He's not claiming that just Magic Engine has this problem, but rather HIS emulator is the only one that doesn't. Nevertheless, I've downloaded the latest ootake to test his claims myself. I hope the emulator actually works this time, as the last time I tried ootake, it would crash on startup.

Edit: Got ootake working, and while there are some excellent options and features, I simply could not get it to load a supergrafx game. I'm guessing it either doesn't support them, or it doesn't accept the .sgx extension versions of the roms.

Edit: It turns out to be the format extension. I couldn't find ANY documentation anywhere using google on this issue, so I just had to take a guess as to this being the problem. I found a .pce extension version and that plays fine.

Anyway, now I can get on with my tests.

[FirebrandX]

Ok finished my tests and found a couple interesting point/counterpoints. First, I was able to confirm the input responce time is a fraction of a second faster in ootake. Its almost not noticeable unless you're specifically testing for it or are relying on intense reflex gaming skill (such as in fighting games or shooters). The time difference was approximately one tenth of a second compared to Magic Engine.

After getting the unzip dll and correcting the issue of the sgx extension ootake refused to recognize, I was just about to rule in ootake's favor as being all around better than Magic Engine when I noticed something horribly wrong. Ootake's palette is WAY off, making many parts of games appear washed out. I made sure to use default gamma settings just to be sure, but the problem was definitely with the palette coded in to ootake. Compare pics below to see what I mean:

First Magic Engine:


Now look at the Ootake version:



The midtones are too close together, looking much as if graphic detail is lost. Additionally the title screen to Daimakaimura shows a disturbance in the blue glow around the text, where during the fade out a purple tone shows up when run by Ootake. The Magic Engine palette shows a much smoother fade out.


So my own personal conclusions are this:

Ootake is more responsive and more accurate in execution, while Magic Engine is more accurate in display and has a more user-friendly UI. I will end up keeping both programs on hand, though I will hope the Japanese fella reconsiders his palette choice. Perhaps even allow for custom palettes since the system only has 512 colors.

[AamirM]

At NO POINT in either game do graphics or columns of graphics disappear from my end.

Strange indeed. I will try re-downloading/installing and see if that works. I don't really care much anyway. I am using 1.1.3 demo version.

The new version may be a bit late.
At the moment I'm running a lot of tests on a true PC-Engine to tune the new emulation core but it's taking me more time than I had planned so the release will probably be late of one or two weeks, this should push it to early february. ^^;"

It will be interesting to see that.

Btw: You can get another key for newer version. If your key doesn't work on the newer version. Send your info to dmichel in pm at that forum.

I don't have a key for ME. I've never had the money to buy it. And I am not a supporter of selling emulators as well. And 5 minute limit more than enough for me. But I am one of those guys who wouldn't say anything instead of saying something bad/harmful so....I did the next best thing and made my own emu </joke> (HTML is OFF, BBCode is ON)

Ootake's palette is WAY off

Yep I noticed that as well. But it wasn't such a big deal for me. Maybe he has the palette right? Do you have a PC-Engine?

EDIT:
Missed this one.

nice and easy to use graphical user interface!

[h4tred]

Btw: You can get another key for newer version. If your key doesn't work on the newer version. Send your info to dmichel in pm at that forum.

No, I cracked mine. There's zero point paying for emulators....not even Nintendo's VC shit.

[Panzer88]

So my own personal conclusions are this:

Ootake is more responsive and more accurate in execution, while Magic Engine is more accurate in display and has a more user-friendly UI. I will end up keeping both programs on hand, though I will hope the Japanese fella reconsiders his palette choice. Perhaps even allow for custom palettes since the system only has 512 colors.

excellent tests, it'd be great if we could get the best of both worlds

I wonder if any other emus use his method for more immediate input reaction.

It's one of the only reasons to use Ootake, and it'd be cool to see other emulators with this feature.

[powerspike]

FirebrandX: Try setting the gamma to 1.14 in Ootake. It should look similar to the other shot.

Edit: I turned off scanlines too. Something seems funky with the way Ootake handles them. One thing I'd like to point out though is the colors on my PC Engine / TG16 console looked completely different when it was hooked up to a CRT TV(Neither one looks like it). Really I can't say I'd pay for deeper colors or a nice GUI.

[Panzer88]

we should throw mednafen and turbo engine up there just for the comparison.

[AamirM]

we should throw mednafen and turbo engine up there just for the comparison.

TE will look like ME with brighten enabled.

[Mednafen]

Perhaps even allow for custom palettes since the system only has 512 colors.

For more flexibility/correctness, a custom colormap/palette should have 1024 entries(512 normal, followed by 512 for no-colorburst mode). Maybe I should add such a feature to Mednafen...I already did for GBA, but I don't know if anyone actually uses it.

[AamirM]

For more flexibility/correctness, a custom colormap/palette should have 1024 entries(512 normal, followed by 512 for no-colorburst mode). Maybe I should add such a feature to Mednafen...I already did for GBA, but I don't know if anyone actually uses it.

I'll use it. I am sure there will be many others.

[FirebrandX]

FirebrandX: Try setting the gamma to 1.14 in Ootake. It should look similar to the other shot.

Edit: I turned off scanlines too. Something seems funky with the way Ootake handles them. One thing I'd like to point out though is the colors on my PC Engine / TG16 console looked completely different when it was hooked up to a CRT TV(Neither one looks like it). Really I can't say I'd pay for deeper colors or a nice GUI.

Already tried every gamma and brightness setting with ootake, which is how I know its the palette to blame.

Also the point about not paying for ME, with competing emulators like ootake and others, I can see the reason for not paying for it. The only reason I did some years back is because ME was about the only emulator worth a damn at the time. I had the spare $10 bucks or whatever it was back then, so it didn't really bother me. I wouldn't do it now though for the reasons we've been listing in these comparisons.

Still like has been said, the best of both worlds would be ootake's code with ME's palette and possibly the GUI too.

Edit: Just to be completely fair on the palette, I turned the scanline feature off both emulators and set their brightness and gammas to default. Here are the results:

Magic Engine 2xscale point filtered, no stretch:



Ootake 2xscale point filtered, no stretch:



Considerably better, though ME still has the nod on vividness and contrast. I tried lowering Ootake's gamma and brightness to minimum settings, but this did not make up for the vibrancy ME's palette has. Still, the palette is much more acceptable now in ootake, so it would seem the scanline effect is mostly to blame.