Quote:

- It would be awesome to be able to change settings in Catapult without having to have a running openMSX process... - The SDLGL-PP renderer is the only one for which the 4x scaler works, so it's the obvious choice. But does it have to be that blurry? Try running the first phase of Aleste and you'll see what I mean. Obviously, for games like BPS Tetris it's quite fine...

This will hopefully be the last release with the wx based Catapult. It will be completely rewritten for next releases (but we would really appreciate some help here). We'll make sure to address the settings issue you mentioned.

The problem with the SDLGL2 was not a known issue, so please report all issues you see. The SDLGL2 renderer should have been disabled in this beta (it will be in the release). It's an (abandoned) experiment we did during development. Instead use SDLGL-PP.

The SDLGL-PP renderer with scale_algorithm=simple will either be very blurry or not blurry at all, depending on the blur setting. It could also be that the shader files are missing, in that case it will always be blurry. Can you verify whether you have the files simple.frag and simple.vert in your openMSX/share/shaders/ directory?

Thanks for reporting these issues.

Yes, both files are present:

06/29/2006 19:51 653 simple.frag
06/29/2006 19:51 360 simple.vert

Playing with the console... Blur was set to 50. I tried setting it between 0 and 100; reducing it reduced the anti-aliasing of individual pixels, but didn't help with the general motion blur, which is greatly improved using the SDLGL-FB32 renderer.

Let me share some images, reduced in size to 640x480:

This is with the SDLGL-PP renderer, blur=0:



This is with the SDLGL-FB32 renderer, blur=15:



As an aside, I also saw some openMSX crashes when switching between rendering modes. This is the most recent one I saw:

(c00.9b8): Stack overflow - code c00000fd (!!! second chance !!!)

almonaster.sourceforge.net/mfeingol/msx/openmsx-crash.dmp

As another aside, it would be great to have the openMSX window remember where it was located the last time it was moved. That way the 4x scaled window (which fills the entire screen at 1280x1024) wouldn't need to be moved every time the emulated MSX is restarted.

Ah, motion blur. That's controlled via the glow setting. Try 'set glow 0' (the default value) in the openMSX console or in catapult.

About that openmsx-crash.dmp file. What kind of file is this? Some windows variant of a coredump? Any way I can get some useful info out of it on my Linux box?

set glow fixes the problem, thanks.

I don't think you can use the dmp file in Linux without doing something like running the Windows debuggers under Wine:

www.microsoft.com/whdc/devtools/debugging/installx86.mspx

On Windows, install that package and run cdb -z <file>. You'll need an openmsx.pdb file to make any progress, of course.

Quote:

Vampier, don't get upset. I think that Manuel only mentioned Bifi because you once stated that you were going to take it more slowly as far as your MSX activities were concerned. Something about Real Life(tm) taking up too much of your time iirc.

Yes, this is indeed exactly the case. I was talking about the current situation in which BiFi seems to be our main Windows tester. But the occasional testing you do is of course much appreciated. Any testing anyone can do is useful! But these days, more Windows testers are really needed.

A new beta is available:

www.treewalker.org/temp/openmsx-0.6.1-beta-win32-bin.exe (installer)
www.treewalker.org/temp/openmsx-0.6.1-beta-win32-bin.zip (ZIP)

And for the do-it-yourself types and non-Windows users:

www.treewalker.org/temp/openmsx-0.6.0-1.2141.tar.gz (source)

The problem with the configuration scan sometimes hanging should be solved now. Please test and report any problems here or via the regular channels (IRC, openmsx.org forum, SourceForge).

About renderers: SDL and SDLGL should still be working as they always did. SDLGL-PP is new and contains pixel shader effects, please test this. SDLGL2 and SDLGL-FB16/32 are experimental renderers which will not be included in the release.

For the "arcade feeling", try this:

• set renderer SDLGL-PP
  
• set scale_factor 4
  
• set scale_algorithm TV
  
• set display_deform 3d

There was a header file missing from the source archive. Here is a more recent version with all files in it:
www.treewalker.org/temp/openmsx-0.6.0-1.2143.tar.gz (source)

Now, a question from the curious: what happened to 1.2142?

The simple answer: it resides in CVS Like all other versions.

I've replaced the beta from the initial post of this thread with the final (I hope) beta for this release. Please test and report here! We really need you people

I played around with the new beta and saw the openMSX process hang twice.

The second time, I attached a debugger and captured this dump:

http://almonaster.sourceforge.net/mfeingol/downloads/openmsx-hang.dmp

Now you tell us!

Anyway, we still have the problem that we can't do a thing with such a dump file if we don't have the proper tools... (which we don't).

Share your symbols (.pdb files) and I'll give you stack traces.

But seriously, if you want any better feedback than "it hung playing Daiva V", you'll need to learn to consume those dumps.

http://www.microsoft.com/whdc/devtools/debugging/installx86.mspx has all you need (except the Windows installation, that is).

Sorry, but the developers (that actually write C++ code) don't run Windows (hence the request for a Windows developer) and we don't have pdb files either, because we build with MinGW for Windows.
We can build a version with debug-symbols in it and you could run it with gdb (yes, there's a Windows version) and make a stack trace then. Would you please consider doing that? Please contact us on IRC or so to make this easy.

I'm not sure how easy it will be to repro the hang, but if you provide me with an debug openMSX binary I will try to do what you ask.

Judging from google, BTW, there's no way to get mingw to output .pdb files. Has anyone on your team considered porting openMSX to build with Microsoft's compilers? That might be a way to get more Windows people involved in the project, and there are free beer versions now. I would love to help you with this, but I just don't have the time to take on new projects. I am a professional developer, but I know next to nothing about developing emulators in general, so I wouldn't be much help anyway.