[Aranym-user] [UTD] MacAranym -- ATARI / OSX
mandin.patrice at wanadoo.fr
Thu Dec 14 19:21:12 CET 2006
Le Thu, 14 Dec 2006 09:41:06 -0500
"Standa Opichal" <opichals at seznam.cz> a écrit:
> > sequence is missing the
> > hostscreen.renderBegin();
> > ...
> > hostscreen.renderEnd();
> > part in the line drawing code. That is actually a bug, so the line
> > drawing is supposed to be a _lot_ slower than it is (given the way
> > MacOSX SDL apparently works). ;-)
> I think at least XWin (in Linux) did not need the
> SDL_Lock/UnlockSurface() calls at all. Whereas Framebuffer didn't need
> the SDL_UpdateRect() I think.
That's what the purpose of SDL_MUSTLOCK() macro is, checking if surface
needs to be locked or not. And it happens mostly in the case of a
SDL_HWSURFACE (i.e. when it is in video ram, or need extra steps to get
access to the data).
You should remember we changed some weeks/months ago the mainSurface
from SDL_HWSURFACE to a SDL_SWSURFACE, so now calling the lock/unlock
functions is totally useless, as the SDL_SWSURFACE is always in system
RAM (and SDL_MUSTLOCK() should return 0 now).
As said in the link posted by Johan, "the weakest link" is
SDL_UpdateRect(). Drawing to a surface using SDL_UpdateRect() never
requires locking. Locking is required only if you want to mess with the
The problem with nfvdi is that it touches separately single pixels on
the main surface, so requires heavy operations each time to update the
screen surface, whereas videl fb is completely blitted in a single
SDL_UpdateRect(), thus fast.
That's why I started the 'host-video' branch, so that each subsystem
draw in its own surface, before the result being blitted once to the
Currently http://bugzilla.libsdl.org/ is not available, so I can not
have a look if the "problem" is listed or not.
> PS: This is rather a topic to be discussed in the developers' list I
> would say.
Programmeur Linux, Atari
Spécialité: Développement, jeux
More information about the cz-bobek-lists-aranym-user