I am new in SDL and trying to follow Marius Andra’s SDL tutorials and I
found a strange thing: pixels member of SDL_Surface become null when I
try to initialize it with
and naturally, when I later try to draw a pixel, ? find myself on a
parachute. However, without SDL_FULLSCREEN flag everything seems to work
just fine (in window mode).
The interesting thing is that the second tutorial where only
SDL_BlitSurface function is used, not the direct access to the video
memory, works fine for me in both full-screen and window modes (although
pixels member is still NULL in full-screen mode – I checked), so I
beleive there may be a bug somewhere in SDL. I have some DirectX 9
installed but I am not sure how pre-built Windows library works, and so
I do not know whether it uses DirectX or plain GDI.
Here is my environment:
Mingw+MSys
Win 2K SP2
ATI Technologies Rage 128 VR AGP, 32 Mb of memory.
The pre-built SDL 1.2.4.
Any ideas?
Thank you,
Pavel
PS. I would build the newest version from CVS to check if the problem is
still there, but there is no autoconf/automake toolkit in MSYS. If
anyone throw a configure file for MinGW/MSYS at me or point out to The
Right Way to build from CVS in my environment, I will appreciate.
Regards,
JakobAm Samstag, 28. Juni 2003 22:29 schrieb ptolov:
Hello,
I am new in SDL and trying to follow Marius Andra’s SDL tutorials and I
found a strange thing: pixels member of SDL_Surface become null when I
try to initialize it with
and naturally, when I later try to draw a pixel, ? find myself on a
parachute. However, without SDL_FULLSCREEN flag everything seems to work
just fine (in window mode).
Hardware surfaces must be locked before accessing ->pixels.
//David Olofson - Programmer, Composer, Open Source Advocate
.- The Return of Audiality! --------------------------------.
| Free/Open Source Audio Engine for use in Games or Studio. |
| RT and off-line synth. Scripting. Sample accurate timing. |
`-----------------------------------> http://audiality.org -’
— http://olofson.net — http://www.reologica.se —On Saturday 28 June 2003 22.29, ptolov wrote:
I do lock and unlock the surface, but apparently I have not completely
understood the meaning of this.
I tried to cache the addresses of scanlines for the screen to speed up
the pixel drawing comparing with the Marius’s sample DrawPixel()
function and I even succeeded with it (in windows mode – for up to 30%,
depending on the color size). However, I grabbed the “pixels” pointer before I locked and so (I guess) locking can (for the full-screen
mode) actually set this pointer. Please correct me if my guess is
incorrect. I do not de-reference the pointer or its derivatives
(scanline pointers) before locking, but apparently all of them are
computed wrong by the time I draw and that’s where I am getting the
parachute:
Now I have another question about this (yes, it is easy to start asking,
but difficult to stop):
If I lock a surface, take the pixels pointer, unlock the surface and
then lock it again – this time for drawing – does SDL guarantee that
the “pixels” value will be the same as the one I grabbed first time? If
not, I will have to use another indirection for each pixel I draw,
therefore reducing my performance gain to something possibly negligible
:-(. I know, I know, early optimization is a devil, but this one looked
sooo attractive…
If I lock a surface, take the pixels pointer, unlock the surface and
then lock it again – this time for drawing – does SDL guarantee that
the “pixels” value will be the same as the one I grabbed first time? If
not, I will have to use another indirection for each pixel I draw,
therefore reducing my performance gain to something possibly negligible
Assume that the pixels value will change between separate calls to
SDL_LockSurface().
After all, that’s the whole point of SDL_LockSurface - it brings the video
memory into a memory region that is accessible to the CPU, and depending on
what you did between calls to the function, the memory layout changes.
:-(. I know, I know, early optimization is a devil, but this one looked
sooo attractive…
Why is that a problem anyway? Simply reduce the number of calls to
SDL_LockSurface. I.e. if you need to draw 100 pixels, just lock the surface
once, draw all pixels, then unlock.
cu,
Nicolai
Thank you again,
Pavel
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.2 (GNU/Linux)
The problem is that I cannot have the addresses of scanlines
pre-computed, so I will have to use one more redirection per every pixel
access. It is not related with SDL_LockSurface() overhead per se.
Have a nice day,
Pavel>Assume that the pixels value will change between separate calls to
SDL_LockSurface().
After all, that’s the whole point of SDL_LockSurface - it brings the video
memory into a memory region that is accessible to the CPU, and depending on
what you did between calls to the function, the memory layout changes.
…
Why is that a problem anyway? Simply reduce the number of calls to
SDL_LockSurface. I.e. if you need to draw 100 pixels, just lock the surface
once, draw all pixels, then unlock.