Quick reaction:
- keyboard response: weird, first time I hear complaints about it... needs investigation
- graphics: openMSX doesn't have an option to sync to the host monitor, so you can get tearing, unfortunately. blueMSX has this done better (due to low level Windows stuff, I think); this doesn't work with the SDL library we use, for some reason.
- scanlines: you can tune them and even completely disable them, shouldn't be a problem.
- sound: not much we can do about this, I think?
- debugging: you can download the openMSX debugger from our website (see the download box). It's not finished, but it's already quite useful and FRS seems to be quite happy with it already Try it out! If you need help, we're glad to assist
Thanks for the feedback!
manuel> That's a load of something starting with a b. I complained plenty about the keyboard lag (even with the delay set to zero). Just didn't do so recently. But the effect is obvious. Spent some time playing a timing critical game on openmsx. Then switch to the real thing and watch yourself fail.
Sync is a real problem these days. Just before the TFT era, monitors would do 100 Hz refresh easy. So syncing was simple and very welcome. Now my TFT runs at 60 Hz. So syncing 50 Hz to that will probably be a mess as well. Apart from changing screenmodes there's probably no good way to deal with this. Maybe high refresh rates will come back soon.
Sound may be just a bit too harsh. Probably the analogue circuits in the old hardware provide some mild filtering to soften the square waves a bit.
Edwin: hmm, well, sorry, I forgot about it... I suppose you were the first then, but in any case, we didn't get a bug report in the tracker for it or other reminders or from other people the same input.
But it's weird then, the lag is apparently not for everyone (me or Vampier have no problems... but maybe we don't use the real machine enough? (Makes me wonder how a lag can make a game easier?))
After the last discussion about it (sometime while I coding MJTT where the effect is obvious), responses didn't make me want to waste my time to fill in the bug tracker.
It's not about making it easier. You just automatically compensate for it. When you are completely trained on that timing and switch to the real thing where it's gone, you find that you keep dropping off the platforms because you're reacting too late.
If you have some good ideas on how to tackle this, please speak up... I'll talk with Wouter and ask him if he also has ideas how we can get this more concrete and debug it. Putting it in the tracker is always useful, because then we certainly won't forget about it (as what I did now).
If you compensate for lag, and then play on the real hardware without lag, wouldn't that make you react faster instead of slower? (Because the real system reacts quicker on your input.)
I don't know the exact wording anymore, but the gist of it was that it probably has some something to do with sdl, so it couldn't be helped. I can take a hint.
You're right, I was jumping just short of the target. The other one was when switching back to openmsx. My current project feels noticeably different as well. So I suspect you should feel the difference with any 60 Hz game engine.
btw, did you guys try with openMSX 0.8.0? We fixed something to the input event latency... Knowing if it's better/worse/equal would be useful.
Quick re-reaction
Quick reaction:
- keyboard response: weird, first time I hear complaints about it... needs investigation
Try to ask hard-gamers...
- scanlines: you can tune them and even completely disable them, shouldn't be a problem.
I'm sure you're right. Anyway I'd like spend my time playing games instead tunning and tweaking the emulator. I love when things work the way they are supposed to. :-)
- sound: not much we can do about this, I think?
VST support!!!
- debugging: you can download the openMSX debugger from our website (see the download box). It's not finished, but it's already quite useful and FRS seems to be quite happy with it already Try it out! If you need help, we're glad to assist
Ok, I'll try it.
thank you!
warau: scanlines are enabled by default, because an MSX monitor is typically a CRT which has scanlines... So, it is 'as it is supposed to be'
No those scanlines.... In my opinion, the default OpenMSX scanlines are unrealistic.
And what about the VST support? It would be nice and a lot of new features could be implemented after that.
For instance, I could apply a sound-warming effect (to simulate the sound coming out of the real thing), any type of reverb, chorus, spatializer...
We could even make a real DAW multitrack recording of each MSX individual channel, or even better, it would be possible to create true 5.1 surround mixings of MSX songs by using standard music production tools.
It should also allow to use the internal OpenMSX FM/SCC/PSG engines as a VST instrument and to mix/combine/process them which a lot of new filters, synths and effects.
There are a lot of SID-based VST instruments out there. Why not to do the same with the OPLL and SCC+ ?