(good) MSX-emulator for mobile phones?

Página 4/4
1 | 2 | 3 |

Por Haze

Expert (117)

imagem de Haze

04-07-2003, 11:49

Time for a reply from a MSX and GP32 user... me! Tongue

Yes, the CPU speed is set by the software and the previously mentioned speeds are correct. Though nowadays running at the max 133MHz isn't used that much as it proves to be a bit unstable for various consoles and it isn't necessary anymore, with all the optimized code. Smile

The fMSX emulator is running quite fine. MSX1 is up to full speed, MSX2(+) varies at about 80%-90%. PSG sound nice, FM Pac is okay, SCC is... well... oi!
And best of yet: wireless multiplayer between consoles! ^-^

But enough with the commercial-rant... back to the topic!


Champion (293)

imagem de MOA

04-07-2003, 14:15

Anyway, off-topic but talking about tiles and speed; the PowerVR (Kyro) 3D chips used tilebased rendering too Smile I wonder if that's still possible with things like pixel and vertex shader programs nowadays... And the quick Z-buffer clear techniques used by ATI and nVidia are also tilebased.

Tiles rock!

Yeah the Dreamcast uses that (tilebased) PowerVR chip and its texture capabilities are simply awesome.

A tilebased approach is often used by hard- or software when there's some kind of cache available (1 tile will for instance perfectly fit in one data-cache line ~ or fill up the complete cache for that matter). Some more info on this topic can be found here

Por mth

Champion (503)

imagem de mth

04-07-2003, 21:56

openMSX has two renderers: SDL and OpenGL. The SDL renderer is a simple framebuffer renderer, the GL renderer is more interesting however. Textures are used to store converted MSX graphics. For bitmap modes, every line is a texture. For character modes, every character is a texture. The same texture can be used to blit the line/character many times. For every VRAM write, a check is made whether any textures should be marked dirty.

Because the AGP bus is the main bottleneck when doing emulation on PC, caching using textures helps a lot. Especially MSX1 games have almost 100% cache hits, because they usually upload all their characters at the start of a stage and then continue to use that same set for the entire stage.

I haven't found an efficient way to put sprites into textures though. Especially the V9938 feature of OR-ing sprites makes it difficult. I will continue trying, maybe after refactoring the sprite code a solution becomes easier.

So openMSX does optimize by using tiles, but those tiles are blitted to a frame buffer by OpenGL. Therefore we have no problem with bitmap/character splits like Space Manbow and Psycho World. It would be very hard to make a perfect MSX emulator with V9938/58 using an embedded device with a slow CPU and a character based video mode. However, I think it is possible to make something good enough for playing many games.

In openMSX you can select screen, line or pixel accuracy. Line accuracy is what most other emulators have. I was surprised that games run fairly well on screen accuracy. For example Aleste has a screen split between the score bar and the playing field. If I run it on screen accuracy, the score bar disappears, but the game remains playable. Even Space Manbow would be possible if you can detect the sprite split and map the second sprite table to a different set of sprites on your host platform. The bitmap part can be emulated in tiles, it doesn't change often so when using dirty checking it shouldn't claim much CPU/bus time.


Champion (293)

imagem de MOA

05-07-2003, 01:31

Now that's what I call interesting info! Smile

Thx dude!

Página 4/4
1 | 2 | 3 |