openMSX post-0.7.0 build available for beta testing

Expert (87)

16-02-2009, 20:07

I would like to invite you to do some beta testing (really alpha testing) of the following openMSX builds:

http://openmsx.sourceforge.net/temp/openmsx-0.7.0-dev8625-win32-bin-vc-x86.zip
http://openmsx.sourceforge.net/temp/openmsx-0.7.0-dev8625-win32-bin-vc-x64.zip

The goal here is to get your feedback on the reliability, stability and performance of these builds, while providing you with an advance look at a binary drop of the post-0.7.0 openMSX sources. If you run into any bugs, please let us know either on this thread or through the SourceForge bug tracker: https://sourceforge.net/tracker2/?group_id=38274&atid=421861.

I should note that these builds were created from the sources in the current SVN repository, so they represent a WIP release of openMSX with some largely untested changes since the 0.7.0 release. Consequently, this is a buyer-beware release that may not behave quite as you expected.

On the bright side, you get some neat new stuff in these builds that isn't in the 0.7.0 release:

1) openMSX was built with Visual C++ 2008. This resulted in a smaller and apparently somewhat faster binary than the 0.7.0 release. It also means that if openMSX crashes, you can send us a .dmp file and there's a reasonable chance that we'll be able to debug it without asking you for repro steps, etc.

2) There's now a native 64-bit binary for x64 CPUs, for those of you running 64-bit XP or Vista. I find it to be about 10% faster than the 32-bit binary on my Vista x64 system.

3) Unicode is now supported throughout the system, including the Catapult launcher. You may need to install your favorite font to see the right characters in the openMSX console, but aside from that this build should 'just work' with non-Latin character sets. As a downside to this, only Windows 2000 and above are supported. So if you were running on Win9x or NT4, please continue to use previous versions of openMSX.

4) A few bugs have been addressed, and no doubt a few have been added.

As usual, you can find more developer-oriented details inside the official project changelog: http://openmsx.svn.sourceforge.net/viewvc/openmsx/openmsx/trunk/ChangeLog?view=markup

By cesco

Champion (391)

16-02-2009, 23:24

is it ok if I give you my impression about the Mac OS X version ?

I have tested the game "La Corona Encantada" with both the official release 0.7.0 and the latest SVN snapshot using these settings:

Set Renderer sdlgl-pp
Set Scale_algorithm simple
Set Scale_factor 4
Set throttle off
toggle_fps

With OpenMSX-0.7.0 - Average FPS: 426-429fps
With OpenMSX-0.7.0-dev8626 - Average FPS: 336-352fps

I know that I can't compare the result of a build made by a professional compiler versus GCC4, but I have noticed that there should be something new introduced in this last version that is slowing down a lot the emulation (I have compiled and build both the official release and the SVN snapshot on my machine using the makefile and GCC 4.0.1)

EDIT: Discard this message. I don't know why, but the first three times I tried the game with the SVN snapshot I got worse and worser result. The fourth time I have tried it I got more or less the same results as the official 0.7.0.

By Manuel

Enlighted (5672)

17-02-2009, 23:02

instead of frames per second, you can also measure performance by checking how long openMSX takes to run e.g. Space Manbow on a certain machine using this script (benchmark.tcl):

set save_settings_on_exit false
#set renderer sdl # select the renderer you want to benchmark with
set renderer sdlgl-pp
set throttle off
set scale_algorithm simple
set scale_factor 2
set scanline 20
set blur 50
set noise 0
set glow 0
set display_deform normal
set minframeskip 0
set maxframeskip 0
set accuracy pixel

#set sound_driver null # uncomment this if you do not want to benchmark sound emulation
set frequency 44100
set sound_driver sdl
set resampler blip
#set mute on
set master_volume 1 # otherwise it's a bit annoying :P
soundlog start test.wav # make sure no sound is skipped

after time 230 quit

like this:

$ time openmsx -machine Philips_NMS_8250 -carta spmanbow.rom -script benchmark.tcl

(if you're not on a UNIX like environment (i.e. Windows), you'll have to leave out the time command and find another way to measure automatically.)

Of course you can also base it on other programs (e.g. running zexall to benchmark the Z80 emulation, you could turn off sound (set sound_driver null) and rendering (set renderer none) to get a more specialized benchmark), other machines and other times.

Anyway, this request was for Windows users specifically! Who tried it? How did it run?

By cesco

Champion (391)

19-02-2009, 09:57

These are the results on my Mac (iMac Intel Core2Duo 2.33 with 3Gb of RAM and NVIDIA GeForce 7600 GT graphic card) :

(0.7.0-dev8626)

real 0m17.363s
user 0m14.561s
sys 0m2.218s
(Official 0.7.0)

real 0m19.342s
user 0m15.992s
sys 0m2.262s
(0.6.3-dev7420)

real 0m21.295s
user 0m16.392s
sys 0m2.998s

So, according to these data I guess that the latest SVN snapshot is even faster than the official 0.7.0
BTW if you want I can try the latest Windows binaries on a virtual machine

By FiXato

Scribe (657)

20-02-2009, 01:14

the x64 build seems to work nicely under Win XP Pro 64 bit

Thanks for the build!

By Manuel

Enlighted (5672)

20-02-2009, 12:21

Ah cool, the even more optimized Z80 emulation (using computed gotos) seems to pay off

By the way, the 'real' time also depends on other tasks in the background, so make sure nothing else is running if you want to use them as an indication for performance. Also, measure several times and only if the results are very similar, you can trust them.

The 'user' time does confirm your statements, so, that's OK

Fixato: thanks for testing! Anyone else, please??

By Manuel

Enlighted (5672)

20-02-2009, 18:56

By the way, if you used openMSX 0.7.0, but you have problems with it due to unicode (so, you have a localized "Documents and Settings" or "Desktop" folder name, e.g. ... we've heard about Russian and Greek cases), you should definately try this stuff out, because it should work fine out of the box with this binary!

By Philip

Rookie (30)

20-02-2009, 22:25

This build seems to work very well on my vista 64 bits.
I couldn't find any problems with it.

For some reason (I guess crappy opengl support om my geforce8500) the sdlgl-pp renderer is very slow here, it runs about realtime with set throttle off
So I did some tests with the sdl renderer:

0.7.0:
real 0m22.926s
user 0m0.000s
sys 0m0.000s

dev8625:
openMSX ran for 17.81 seconds
real 0m17.930s
user 0m0.000s
sys 0m0.000s

I don't know why user and sys are 0, I used cygwin to get the time command.
Anyway, the new one is quite a bit faster !

By mfeingol

Expert (87)

20-02-2009, 23:38

Philip:

Thanks for the reply. To address your OpenGL performance issues, try disabling the advanced "multicore performance" option in the nVidia control panel. I had the same issue, and turning that option off worked for me (it's on by default in recent drivers).

We should really add this to the FAQ.

By Philip

Rookie (30)

21-02-2009, 13:15

I couldn't find that option in the nvidia control panel.
However, if I disable vertical sync it runs a lot faster.
0.7.0:
real 0m23.186s
user 0m0.000s
sys 0m0.015s

dev8625
real 0m22.481s
user 0m0.000s
sys 0m0.015s

Still not as fast as the sdl renderer though.
Ofcourse the 8500 isn't a fast card, I bought it because it has no fan and I don't need fast 3D.

By mfeingol

Expert (87)

21-02-2009, 18:50

Philip: okay, I have an nVidia-based PC in front of me now. :-)

Try nVidia Control Panel / 3D Settings / Manage 3D Settings / Global Settings / Threaded Optimization: Off.

Don't you have an account yet? Become an MSX-friend and register an account!