[hatari-devel] Suggestion about small additions for v1.4

Eero Tamminen eerot at users.berlios.de
Wed May 12 23:14:50 CEST 2010


Hi,

On Wednesday 12 May 2010, Anders Eriksson wrote:
> Oh no don't try this on me :)  I've reported many times that in OS X
> window mode, Hatari is slow as snails, while in fullscreen it works fast.

I assumed it was slower than you would like it to be, not slower than it
should be (as it works fine for me).  If you expect to be understood, you
need to quantify your issues properly / be exact (give FPS numbers etc).


> > Does the slowness you're reporting happen only when overlay LED is
> > enabled (not necessary visible) and statusbar is disabled?
> > Or does it happen also if statusbar is enabled or both statusbar & led
> > are disabled?
>
> The general slowness is whatever of statusbar/HUD status. It's something
> to do with updating the actual window.

Just to verify, even when running hatari with both "--statusbar off" 
and "--drive-led off" options, it's slow in windowed mode?


> > To me it seems 1/2 (or maybe 1/3) of normal speed.  I think easy way to
> > check how much the slowdown is would be to try frameskip values of 1 or
> > 2. Btw. If OSX SDL is doing VSync() on windowed mode and you have an
> > LCD monitor, you probably should be running Hatari with frameskip
> > anyway. Otherwise OSX/SDL is forcing e.g. monochrome mode (71Hz
> > updates...) to be running too slowly as LCD refresh is usually
> > something like 60Hz. (My CRT refresh is 85Hz so I cannot see issues
> > like this.)
>
> Come on, so the solution to a small little green box slowing down Hatari
> to a crawl is to frameskip it,

I mean, needing that even after you disable the --drive-led.

If your OS / SDL is limiting (Vsync()ing) window updates to your (LCD)
monitor updates (60Hz?) and you ask the emulation to run at higher screen
update frequency, things will *obviously* be slower than they should.

In other words, if your monitor doesn't offer high enough frequency to show
all the emulated Atari frames, there are only two possibilities:
- skip frames from the Atari emulation
- things running at slower speed than on Atari

However, this *should* be an issue only for 71Hz emulation, but as there
have been some issue (mentioned in Hatari code) in getting accurate timing
information on OSX, I guess it might be an issue also when the emulation
runs at 60Hz.

Do things work better if you run in Hatari something using 50Hz mode?
(*after* disabling both statusbar & drive-led)?

If they do, one possibility would be to skip wait on the Hatari side on OSX
and assume on OSX SDL or OS will be doing it with Vsync(). That would be
quite fragile though as Hatari has no API to query whether OS or SDL
actually uses or provides VSync() and whether that matches the frequncy at
which the emulated program is running.


> not to fix the thing that slows it down?

To get OSX SDL to be fixed, you need to complain to SDL OSX maintainer.
We don't maintain it.


>> Well, yours seems to have problems getting the updates to screen
>> frequently enough.  ;-))
>
> Funny, now you remember that I've reported performance issues before..

To be exact, I was referring to this mail discussion we're having here. :-)


> > Is it implemented on top of SDL?
>
> I have no idea, but the implementation is great.

On Linux Vice seems to be using X window system directly, so I guess on OSX
it uses OSX facilities directly.  I.e. it's not using a portable library
like SDL for that.

(If we wouldn't be using SDL, then somebody using OSX would need to code
that support to Hatari and maintain it. And same thing for every other
platform where somebody would like to run Hatari.)


> >> This wouldn't even let me go to fullscreen at all.
> >
> > It works fine on Linux SDL.  Please file a bug against OSX SDL,
> > HWSURFACE is an optional thing according to SDL documenation.
> > See the documentation on it to see why I asked to test removing it:
> > 	http://www.libsdl.org/cgi/docwiki.cgi/SDL_SetVideoMode
>
> Wonderful, I knew this was coming, Hatari is fault free and the problem
> lies elsewhere, even though Hatari includes the "elsewhere" code.

Jerome reported that it's not a problem for him.  Do you have different
SDL or OSX version than him?


	- Eero



More information about the hatari-devel mailing list