Turbo Engine 16 emulator by AamirM

mustangemu · Post by **mustangemu** » Sat Dec 20, 2008 2:56 pm

Hello AamirM,
Sorry i posted in the wrong forum. i am glad to learn you will be adding turbo buttons in the next release.

once again i love all your emulators. regen is totally awesome and turbo engine is coming along nicely. you sure do have lots of fun. you must be a super coder!

Neo Kaiser · Post by **Neo Kaiser** » Fri Jan 02, 2009 7:49 pm

I found the graphics of Soldier Blade to be screwed a little. Anyone have the same problem? also my emulator freezes if turned to full screen. Then again I'm using a old 800 MHz Pentium III Slot 1.

Dullaron · Post by **Dullaron** » Sat Jan 03, 2009 7:17 am

It crashes here when I tried to switch full screen back to window screen.

AamirM · Post by **AamirM** » Sat Jan 03, 2009 1:45 pm

Hi,

Fullscreen is buggy. I stated that in readme as well. Should be fixed next time.

@Neo Kaiser:
It works under 800Mhz??? Do you get 60 FPS comfortably?

stay safe,

AamirM

Neo Kaiser · Post by **Neo Kaiser** » Sat Jan 03, 2009 7:14 pm

AamirM wrote:Hi,

Fullscreen is buggy. I stated that in readme as well. Should be fixed next time.

@Neo Kaiser:
It works under 800Mhz??? Do you get 60 FPS comfortably?

stay safe,

AamirM

12-20 FPS on normal cards and 8-9 FPS on Super Graphs. I only tested Soldier Blade and 1945. Soldier Blade was still playable but not 1945. I know that it needs at least 1 GB to run but I wanted to test it on my slow machine anyway to see how slow it will run.

Dullaron · Post by **Dullaron** » Sat Jan 03, 2009 7:17 pm

Ok AamirM thanks for telling me. I will read the read me next time.

Neo Kaiser · Post by **Neo Kaiser** » Sat Jan 03, 2009 8:18 pm

I didn't found that on the readme... maybe I misread it...

Dullaron · Post by **Dullaron** » Mon Jan 05, 2009 8:16 pm

Wow I didn't see that ether. I guest he forgot to add that bug report in the read me. Unless I'm so blind.

AamirM · Post by **AamirM** » Sat Jan 31, 2009 9:03 am

Well, it took longer than I expected but work has been restarted on this again. I am in process of completely re-doing the frontend (GUI etc..). The reason behind it is that I re-used a lot of Regen's code in the frontend which was getting ugly (as Win32 already is), hard to maintain and understand. The fullscreen bug is a example of that. So that is why I am writing a new frontend/framework in C++/MFC. Once that is finished, I'll work on completing the CDROM support. I had already written some code to handle CDROM using ASPI and IOCTL so the bitchy part has been done

.

And if someone has any ideas/refinements for GUI layout etc.., please let me know. I mean, for example, I now have a slider in the bottom of the window for seeking to a previous position in the game since now TE has real time rewind feature.

Panzer88 · Post by **Panzer88** » Sat Jan 31, 2009 11:42 am

I noticed you linked Magic Engine on your homepage but not Ootake. Is there something wrong with Ootake that made you not link it like you did several other emulators like Magic Engine, Gens, etc.

h4tred · Post by **h4tred** » Sat Jan 31, 2009 11:47 am

So that is why I am writing a new frontend/framework in C++/MFC.

MFC? Why are ya going that far?

I kinda like Win32 to be honest. You could code your own wrapper to Win32, but seriously, MFC isnt that nice to play with.

AamirM · Post by **AamirM** » Sat Jan 31, 2009 11:59 am

h4tred wrote:
So that is why I am writing a new frontend/framework in C++/MFC.
MFC? Why are ya going that far?

I kinda like Win32 to be honest. You could code your own wrapper to Win32, but seriously, MFC isnt that nice to play with.

Whats the problem with MFC? I haven't encountered any problems yet with it. Once you understand how MFC works from the inside, I doubt there will be any problem.

I see that, VBA-M is done using MFC. So has it given you any headaches?

I also noticed its emulation loop is a bit weird (read: I don't understand it).

h4tred · Post by **h4tred** » Sat Jan 31, 2009 1:11 pm

I see that, VBA-M is done using MFC. So has it given you any headaches?

It has for me. Personally, I can't stand MFC's style, plus it feels so bloated to me. Hence the redoing to a decent GUI system like Qt (which is also cross platform).

I also noticed its emulation loop is a bit weird (read: I don't understand it).

Yeh, thats Forgotten's doing

.

Whats the problem with MFC? I haven't encountered any problems yet with it. Once you understand how MFC works from the inside, I doubt there will be any problem.

I just find it a mess personally, plus as told before, it seems bloated. Personally I'd prefer dealing directly with raw Win32 or a very simple wrapper around it, rather than dealing with MFC.

AamirM · Post by **AamirM** » Sat Jan 31, 2009 1:33 pm

It has for me. Personally, I can't stand MFC's style, plus it feels so bloated to me.

A little bloated maybe, but I haven't noticed any degradation in performance. I will accept that the size of the executable has sky rocketed (from 85KB to about 2.5 MB). But its not like that is a problem only with MFC. Qt libs are even larger (about 2x I think). Plus I think Qt is also slower than MFC (because it does more stuff).

EDIT:
I forgot to mention that some cool stuff is possible with MFC which would be a pain to do in plain Win32 (multilanguage support for example). You will see soon enough what I mean

.

byuu · Post by **byuu** » Sat Jan 31, 2009 6:09 pm

If you statically link with Qt (need to be LGPL yourself), it can be really small. Gambatte is 1.8MB. If you upx --ultra-brute the DLLs, Qt can be ~2.5mb as well.

I personally hate all the toolkits. GTK+ pretends to be C++, but loses type safety. Qt pretends to be Objective-C++, forcing a preprocessor. MFC and its clone, wxWidgets, have terrible eyesore macro systems. Qt's preprocessor is at least a non-issue if you understand GNU make well enough to fully automate it.

As for speed, Qt has problems starting up for the very first time after a reboot (~3sec lag), and painting a fullscreen, 1920x1200 conical gradient is pretty slow. I've not noticed problems anywhere else. Besides, the GUI is meaningless once the emu is running. I haven't lost a single FPS with it, and I gained a menubar that doesn't freeze the app when you enter it and auto-resizing windows.

Still, if you only plan to target Win32, plain win32 or MFC is best. Qt has a few tiny rendering issues where it doesn't quite match the native look and feel completely. It also looks as bad as Wine on GNOME.

kick · Post by **kick** » Sat Jan 31, 2009 8:11 pm

Panzer88 wrote:I noticed you linked Magic Engine on your homepage but not Ootake. Is there something wrong with Ootake that made you not link it like you did several other emulators like Magic Engine, Gens, etc.

Really,what's wrong with Ootake? I find it much better than Magic Engine.It's open source and has a focus on emulation accuracy.
Have you actually tried the latest version (2.01)? It's a massive improvement over the last 1.xx release.

AamirM · Post by **AamirM** » Sat Jan 31, 2009 9:40 pm

Really,what's wrong with Ootake? I find it much better than Magic Engine.It's open source and has a focus on emulation accuracy.
Have you actually tried the latest version (2.01)? It's a massive improvement over the last 1.xx release.

Sorry, I overlooked Panzer's post. I don't have any problems with Ootake. The reason its not linked from my paged is because I simply forgot

. I'll add a link to it soon (the web is in static HTML, so it will take time

). I also don't use it much either. That is because it contains many hacks. Also, it has a weird GUI ;P . For example, the 'S' key is mapped to save states. And upon reset, the 6-button controller gets selected automatically.

I haven't used the 2.01 release. I see it "was" released "tomorrow" (31 jan here still as I write this)

. Will try it right away.

If you statically link with Qt (need to be LGPL yourself), it can be really small. Gambatte is 1.8MB. If you upx --ultra-brute the DLLs, Qt can be ~2.5mb as well.

Well, first of all, the licensing issue sucks. Secondly, I haven't tried UPXing. I think it can make it < 1.5 MB. And did I mention that I was already linking everything statically

. If I use DLLs, the size will drop very much but then the loading will take time which I don't want. And if I am not wrong, MFC DLLs already come with Windows so I don't have to worry about distributing it as well.

And I've separated the frontend from the core emulation back end. Now, the backend is compiled as a separate library (into a DLL). Something similar to gambatte, which has libgambatte. So I am not counting the size of that. But its small anyway.

and I gained a menubar that doesn't freeze the app when you enter it and auto-resizing windows.

I think the same can be done in MFC as well (though it will require multi-threading I think).

Still, if you only plan to target Win32, plain win32 or MFC is best. Qt has a few tiny rendering issues where it doesn't quite match the native look and feel completely. It also looks as bad as Wine on GNOME.

I don't just want to target Win32. I also want to do OSX/Linux ports. But, just like Win32/MFC is best on Windows, Cocoa is best on OSX. So if there is going to be a OSX port (for sure) its going to be in native Objective-C/Cocoa. After all, it would be one more thing to add in the resume

.

The same goes for the Linux. If you ask DanceMasterGlenn, there is already a GTK+ port of Regen with four audio and video drivers each already. It got halted because there was some problem with SDL input which I wasn't able to figure out. But that will soon be restarted as well.

EDIT:
Just gave Ootake a try. There aren't any big changes regarding emulation accuracy. Its pretty much the same. If you notice, the only big thing added was Direct3D support. If you want my opinion, I think that Mednafen is the best PCE emulator right now.

Panzer88 · Post by **Panzer88** » Sat Jan 31, 2009 10:36 pm

AamirM wrote: upon reset, the 6-button controller gets selected automatically.

this can be avoided by configuring all your input controls the first time you boot it up, then it works fine, I haven't used mednafen really due to lack of a GUI, I'm sure you are right about hacks but Ootake has really good emulation of timing say over magic engine etc. He even writes about this on his site.

It's no big deal, just thought you should know

AamirM · Post by **AamirM** » Sun Feb 01, 2009 4:50 pm

Panzer88 wrote:this can be avoided by configuring all your input controls the first time you boot it up, then it works fine, I haven't used mednafen really due to lack of a GUI, I'm sure you are right about hacks but Ootake has really good emulation of timing say over magic engine etc. He even writes about this on his site.

It's no big deal, just thought you should know

Thanks, I didn't knew about the configuration thing. But I still can't use the 'S' key. Whenever I accidentally press it, it does a save state, which btw, are really huge. Also the fact that it shows an ugly screen at start up annoys me. But yeah, its not a big deal. But anyways, as I said I use Mednafen mostly. If something doesn't work, only then I try it on Ootake and Magic Engine.

Panzer88 · Post by **Panzer88** » Mon Feb 02, 2009 10:44 am

yeah I totally understand your reasoning and look forward to further development on your emu, that's really odd I have never had that problem with the s key and I use the s key in most my keyboard inputs.

Anyways, no big deal, just curious, and good luck on your work.

AamirM · Post by **AamirM** » Mon Feb 02, 2009 9:51 pm

yeah I totally understand your reasoning and look forward to further development on your emu

Added DirectDraw and Direct3D(for Vista/Win7) support today. And while I was at it, I tried something cool. Customizable menus (and toolbar(s))! You can delete/move/create/change shortcut/rename them anyway as you see fit (so we won't have GUI wars anymore

). Also ditching INIs in favour of XML for configuration and cheat files. So that will be next. Was going to take some screenshots but feeling too lazy right now.

funkyass · Post by **funkyass** » Mon Feb 02, 2009 9:59 pm

XML, really?

seems a bit heavy.

AamirM · Post by **AamirM** » Mon Feb 02, 2009 10:53 pm

funkyass wrote:XML, really?

seems a bit heavy.

Reasons to not use INI:

1) Some fields need custom parsing in INI. For example, key assignments in Regen's ini are stored like "Keys=1,2,3,4,5,6,7...".

2) I want configuration file to be cross platform (that is, usable by other ports as well) and good INI parsers aren't always available. And I am not going to spend time on writing some boring parser.

3) INIs almost fail for varying width fields like the cheat files. You again need custom parsing for that. IIRC, MAME has switched to XML for cheats, or at least they were trying to.

Reasons to use XML:

1) It solves the above problems.

2) Many XML parsers automatically have handlers for float/enums/structs/etc... instead of using strings.

3) UTF-8/Unicode support. This can be useful in cheat files.

4) You can probably use something like XSL and make it more human readable (if its not already) </shot in the dark, limited XSL knowledge>

FirebrandX · Post by **FirebrandX** » Mon Feb 02, 2009 11:40 pm

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.

byuu · Post by **byuu** » Tue Feb 03, 2009 12:11 am

I wouldn't use the literal INI format, but a similar variant.

1) Some fields need custom parsing in INI. For example, key assignments in Regen's ini are stored like "Keys=1,2,3,4,5,6,7...".

No problem for a custom parser to split on comma.

2) I want configuration file to be cross platform (that is, usable by other ports as well) and good INI parsers aren't always available. And I am not going to spend time on writing some boring parser.

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

2) Many XML parsers automatically have handlers for float/enums/structs/etc... instead of using strings.

Free struct support sounds interesting. Floats aren't very hard if you don't mind sscanf. Near impossible to avoid rounding errors if you try and do it manually.

3) UTF-8/Unicode support. This can be useful in cheat files.

No reason a config file can't use UTF-8.

4) You can probably use something like XSL and make it more human readable (if its not already) </shot in the dark, limited XSL knowledge>

Can't beat plain-text for readability :)

Code: Select all

cpu.speed = 24000000
video.driver = "Direct3D"
file.extensions = "*.pce,*.bin"
video.gamma = 2.2

Anyway, use what works best for you of course :)
Just pointing out my experiences.

Will have to go check out this toolbar ...