It's here, MSX.emu for the iPhone!! Based on BlueMSX!!

Page 5/10
1 | 2 | 3 | 4 | | 6 | 7 | 8 | 9 | 10

By wouter_

Champion (456)

wouter_'s picture

27-05-2011, 14:38

Hi all,

As one of the main openMSX developers, I just had to react to this topic ;-)

First of all, (certainly from the developers position) the 'competition between openMSX and blueMSX is very friendly. We even notify each other when features are added or important bug fixes are made that may also be useful for the other emulator. Possibly because of this the feature-set and the accuracy of both emulators is very similar. This is certainly the case for the subset of features that are relevant for gamers (for use on handheld devices).

It is true that blueMSX has an easier to use GUI. But in this context that is irrelevant because, if I understand correctly, the whole UI will be replaced with some other on-screen UI. The fact that openMSX already has some form of on-screen UI is also irrelevant.

openMSX is already ported to a few handheld devices. Based on these ports the code was already optimized quite a bit (in our experience the performance bottleneck on those systems is not always the same as the bottleneck on desktop systems):

  • GP2X (main CPU ARM920@200MHz). MSX1 and many MSX2 games run real-time. Games that use sound extensions like SCC or MSX-MUSIC run often too slow.
  • Dingoo (main CPU MIPS@336MHz). Most games run fine. When sound extensions are used extensively the framerate drops occasionally below real-time, but generally games remain playable.

Most current devices are more powerful than these two examples, so openMSX (and probably also blueMSX) should run without any problems. But even on those newer devices, to safe battery power, it's still important to have the best possible performance.

Now about the speed measurements Rakashazi took. I don't want to question his numbers, but I do want to add some extra info:

As Rakashazi already noted, the SDL library (the cross-platform library used by openMSX to display the graphics) has considerable overhead. At least on some platforms. This can easily be seen when you switch to the openGL based video renderer in openMSX: the CPU usage can easily be cut in half by this switch. This overhead is mostly caused by copies between system and video ram. These copies often disappear (or are hardware accelerated) when using a different graphics API like openGL (openMSX) or DirectX (blueMSX). On embedded devices you typically have direct access to the video ram. So there, even when using plain SDL, this overhead disappears completely.

Other reasons for the measured speed difference could be the (default) configuration of both emulators:

  • By default openMSX has blur and scanlines enabled for video rendering. I don't know what the blueMSX defaults are. (These effects are generally not used on embedded devices).
  • By default openMSX emulates sound devices at their native frequency and does band-limited resampling to the host device sound frequency. BlueMSX emulates sound devices directly at the output frequency, possibly with oversampling and interpolation (I don't know what the default setting is). The first approach is more CPU intensive but has better audio quality. For embedded devices with small speakers the difference in audio quality is not that important and you can activate the cheaper resampling algorithm in openMSX.
  • As Vampier already said earlier in this thread: openMSX has by default the 'reverse' feature enabled. This also has (a little) overhead. Actually 'reverse' may be one of the few features that are relevant for gamers that openMSX has and blueMSX has not (or not yet, I believe dvik was working on it last year).

Another very important point I want to make is about the possible license exceptions for blueMSX. I don't believe dvik alone is able to make this decision. While dvik is (by far) the largest contributor to blueMSX he's certainly not the only one (I counted commits from 11 different authors). I guess most of those authors won't have a problem with re-licencing their contribution (I certainly don't have a problem for the (few) commits I made). But in some cases tracking all authors for some piece of code is very hard. For example the MSX-AUDIO, MSX-MUSIC and MoonSound implementation in blueMSX are all copied from (an old version of) openMSX. That code in openMSX is in turn based on MAME. Finding all those contributors will be very hard. And there only has to be one who doesn't like the more restrictive licence.

Wouter

By muffie

Paladin (933)

muffie's picture

27-05-2011, 17:02

Now the next thing comes to mind. If Rakashazi would offer the games for $0,99 in the App store. What will gamedevelopers say if they see their Metal Gear 2 Solid Snake or Auf Wedersehen Monty in the App store? How abandoneware are these games? Does anyone know?

He'll be sued pretty quick if he includes Metal Gear or any other Konami game.
Each game would need to be negotiated individually and I can bet that Konami would never allow that... Unfortunately.

By dvik

Prophet (2200)

dvik's picture

27-05-2011, 18:04

I think the optimizations you did for low end devices probably makes it less cpu intensive. I should say though that blueMSX has been ported to low end devices as well. I have a version running on a 200MHz PXA270 based industrial device running an RTOS with the motor control etc on the device is running on a higher priority Smile I only tried 'simpler' games like Space Manbow, so no heavy Moonsound or MSX Audio. I'm sure the emulation would lag with those sound chips.

A few notes about the difference, they emus are probably more similar than that:

blueMSX enables blur as well as default but its all done in the UI part, so the emu core renders to an internal frame buffer. There are a couple of choices of abstraction depending on where to plug in the UI. In my PXA port I plugged in the frame buffer based display right at the VDP renderer. I believe the Wii port plugs in at a more abstract level that also supports blending of frames, video input although they use the most efficient version.

blueMSX sound devices runs either at native frequency (e.g. MSX Audio, moonsound) or oversampling (PSG is 16x oversampled). Not fully sure what the SCC and PCM does.

blueMSX has the reverse feature disabled by default and its explicitly enabled by the UI (The windows port enables it if the CPU is fast enough, but it can be changed by the user)

Also notable that when it comes to common features used by 90% of users (game players) I think they ara >95% feature equivalent both on both emulated hardware, and UI (although look and feel is quite different). There are some unique features on each emu, e.g. GFX9000 on openMSX, Obsonet on blueMSX but these features are only used by a handful of people.

Also if you want a slick MSX1 emu, I would consider Meisei. It has by far the best reverse play feature which could be cool for gamers.

When it comes to the license exception perhaps you want to disable some parts. Most of blueMSX is GPL, but some is using less strict licenses, such as ZLIB. As wouter pointed out, MSX Music, MSX Audio and Moonsound forked from openMSX 5 years or so ago. The SFG-05 emulation is I believe directly ported from Mame. SCSI support has (to me) unknown origin and was given to me as a patch and there are other components that have external origin. The 80 or so percent of the emu that is developed by the blueMSX team is all under GPL and I doubt that any of the authors would have an issue with restictive licensing.

By muffie

Paladin (933)

muffie's picture

27-05-2011, 19:15

as far as usability, learning curve and distribution options... We might have a clear winner.
One looks like a finished product. The other one like an academic exercise with several different pieces and restrictions.

By Manuel

Ascended (17937)

Manuel's picture

27-05-2011, 19:53

Restrictions? (I shouldn't feed the trolls though...) Anyway, all those things you mentioned are not relevant for an iPhone/Android port, muffie...

By Rakashazi

Rookie (18)

Rakashazi's picture

27-05-2011, 21:22

I turned off scaling in OpenMSX and the CPU usage dropped to 7% which makes more sense so both emus are definitely usable on mobile devices. However, for the App Store at least, I'd need to go with whichever is easiest to get a GPL exemption for.

As for how distribution will work, for unrestricted platforms (jailbreak iOS, Android, WebOS) I plan to release the app as GPL from between $10-20 and it should be just as functional as the PC versions once all features all implemented, plus you get access to the source code.

For the App Store, it'd be a stripped down version supporting only ROMs and locked into a directory of pre-bundled games for around $5 depending on what the games are. These would all need to be licensed of course so I'm thinking I could work out some revenue sharing with the MSXdev authors and the original emulator authors. Getting commercial games from companies like Konami on there would take considerably more effort and they probably want to see a finished product first. Also, I checked the C64 emu and it does include BASIC so apparently that's no longer a problem.

Now, as you know the emu is currently in an incomplete state (no disk loading/swapping support, no on-screen keyboard, etc.) and any donations are appreciated (link is on my site). I'll also give out the preview version shown on youtube to anymore who donates $20 or more, and also give you a coupon code for the platform of your choice (except Android which doesn't support them) for use when it goes on sale :)

By hap

Paragon (2036)

hap's picture

27-05-2011, 22:29

In this exclusive case, I'm ok with putting my blueMSX code contributions under any license exception that dvik decides for.

Selling code from MAME is generally a nono, please remove MoonSound functionality in your port. This counts for Jarek's YM2413 emulation from MAME too, there are other implementations of it around though (like Okazaki).
http://mamedev.org/legal.html

By dvik

Prophet (2200)

dvik's picture

27-05-2011, 23:16

Yes, the mame derived code may be an issue, but its easy to disable, both in openMSX and blueMSX since both have a nice modular design (in blueMSX, remove the instantiation of the objects). blueMSX may have the Okazaki version buildable too, but I need to check, same goes for openMSX I believe. What you really need is MSX Music support . MSX Audio and Moonsound aren't used as much and often the games have MSX Music support as a backup. What's important from a licensing pow is what license the code was under at the time when openMSX forked the MAME version (blueMSX forked openMSX a short while later). Perhaps wouter_ knows.

By muffie

Paladin (933)

muffie's picture

28-05-2011, 00:40

Restrictions? (I shouldn't feed the trolls though...) Anyway, all those things you mentioned are not relevant for an iPhone/Android port, muffie...

I'm pretty sure everyone here just LOVE C-BIOS! Smile

By muffie

Paladin (933)

muffie's picture

28-05-2011, 00:45

I turned off scaling in OpenMSX and the CPU usage dropped to 7% which makes more sense so both emus are definitely usable on mobile devices. However, for the App Store at least, I'd need to go with whichever is easiest to get a GPL exemption for.

As for how distribution will work, for unrestricted platforms (jailbreak iOS, Android, WebOS) I plan to release the app as GPL from between $10-20 and it should be just as functional as the PC versions once all features all implemented, plus you get access to the source code.

For the App Store, it'd be a stripped down version supporting only ROMs and locked into a directory of pre-bundled games for around $5 depending on what the games are. These would all need to be licensed of course so I'm thinking I could work out some revenue sharing with the MSXdev authors and the original emulator authors. Getting commercial games from companies like Konami on there would take considerably more effort and they probably want to see a finished product first. Also, I checked the C64 emu and it does include BASIC so apparently that's no longer a problem.

Now, as you know the emu is currently in an incomplete state (no disk loading/swapping support, no on-screen keyboard, etc.) and any donations are appreciated (link is on my site). I'll also give out the preview version shown on youtube to anymore who donates $20 or more, and also give you a coupon code for the platform of your choice (except Android which doesn't support them) for use when it goes on sale :)

$5?
Charge $0.99 for the emulator with some freeware games bundled + a key game that will receive $0.20 per copy. That would grant you $0.50 per each copy ($0.20 goes to apple)
Each "in-app" 3 game bundle would cost additional $0.99. $0.20 for the good game and $0.10 for each of the other 2 games. More $0.30 per additional bundle for you.

With $5 bucks, in my humble opinion, you'll get just a few sales.

Page 5/10
1 | 2 | 3 | 4 | | 6 | 7 | 8 | 9 | 10