My view on double buffering:
it is nice but not everyone does have enough memory for a given
video mode. Page flipping is ‘time cheap’, but if you just replace
it with copying a system memory to the video memory, it’ll slow down
a lot. Add ‘dirty rectangle’ buffering (only modified parts of the
backbuffer get updated on the screen…)–
------------------------ Tomas Andrle ~ Virsoft — @Tomas_Andrle -------------
My view on double buffering:
it is nice but not everyone does have enough memory for a given
video mode. Page flipping is ‘time cheap’, but if you just replace
it with copying a system memory to the video memory, it’ll slow down
a lot. Add ‘dirty rectangle’ buffering (only modified parts of the
backbuffer get updated on the screen…)
Not always, copying from system memory is now generally much faster than
writting directly to the screen, so the best strategy is to double buffer
by copying the data from a single offscreen memory location on to
alternating screen bufs. then toggling. This avoids tear.
njhOn Mon, 24 Aug 1998, Tomas Andrle wrote:
Will
SDL_LockSurface()
work on all platforms? The one problem I had with GGI is that I couldn’t
directly access the memory to the surfaces on all the targets. So I had to
avoid that in order to make my program portable which involved using PutPixel
routines for everything.
Yup, you can draw directly to the surface memory on all platforms. 
-Sam Lantinga (slouken at devolution.com)
Lead Programmer, Loki Entertainment Software–
“Any sufficiently advanced bug is indistinguishable from a feature”
– Rich Kulawiec
hi`
does SDL allow changing display targets at ‘run time’? That might be a
nice feature.
so mixer, the ttflib support, image loading support (ImageMagick is very
nice for loading almost any gfx format (e.g. postscript ;-))) and
whatever could be loaded at run time on demand.
btw, the new fullscreen code looks clean - I guess I’ll borrow some code
in the future :-)–
Daniel Vogel
666 @ http://grafzahl.de
hi`
does SDL allow changing display targets at ‘run time’? That might be a
nice feature.
Display targets are built into SDL. This avoids distribution complexity,
and has very little penalty on modern demand-paged operating systems like
Linux.
so mixer, the ttflib support, image loading support (ImageMagick is very
nice for loading almost any gfx format (e.g. postscript ;-))) and
whatever could be loaded at run time on demand.
These are separate shared libraries that the app links with dynamically.
btw, the new fullscreen code looks clean - I guess I’ll borrow some code
in the future
Heheh. It’s actually really complex to get all the window manager
interactions right.
Have fun!
-Sam Lantinga (slouken at devolution.com)
Lead Programmer, Loki Entertainment Software–
“Any sufficiently advanced bug is indistinguishable from a feature”
– Rich Kulawiec
hi`
Sam Lantinga wrote:
Display targets are built into SDL. This avoids distribution complexity,
and has very little penalty on modern demand-paged operating systems like
Linux.
but it provides flexibility - which I agree is not really needed. I
haven’t followed the SDL development closesly, but I remember a point in
time where you had to recompile SDL to use the fbdev target instead of
the X11 one. With the right design one could add display targets
afterwards (like plugins) - okay, way too much overkill for SDL 
These are separate shared libraries that the app links with dynamically.
yes, but I really love the ‘plugin’ concept
btw, the new fullscreen code looks clean - I guess I’ll borrow some code
in the futureHeheh. It’s actually really complex to get all the window manager
interactions right.
I noticed it when I added support for the VidMode extension to Unreal
Tournament… I guess I will have a closer look how you did it and then
grab some source :-)–
Daniel Vogel
666 @ http://grafzahl.de
but it provides flexibility - which I agree is not really needed. I
haven’t followed the SDL development closesly, but I remember a point in
time where you had to recompile SDL to use the fbdev target instead of
the X11 one. With the right design one could add display targets
afterwards (like plugins) - okay, way too much overkill for SDL
There’s actually another reason not to use dynamically loadable drivers.
If you statically link your application with SDL (under a separate license
available soon), and dynamically load an object, your code is suddenly
dependent on the version of libc the object was compiled against.
These are separate shared libraries that the app links with dynamically.
yes, but I really love the ‘plugin’ concept
I know. grin
I noticed it when I added support for the VidMode extension to Unreal
Tournament… I guess I will have a closer look how you did it and then
grab some source
-Sam Lantinga (slouken at devolution.com)
Lead Programmer, Loki Entertainment Software–
“Any sufficiently advanced bug is indistinguishable from a feature”
– Rich Kulawiec
hi`
Sam Lantinga wrote:
There’s actually another reason not to use dynamically loadable drivers.
If you statically link your application with SDL (under a separate license
available soon), and dynamically load an object, your code is suddenly
dependent on the version of libc the object was compiled against.
Yes, but if you all compile on one machine… Okay, you are right, the
way SDL is used it might be the best to have a monolithic lib :-)–
Daniel Vogel
666 @ http://grafzahl.de
Sam Lantinga wrote:
There’s actually another reason not to use dynamically loadable drivers.
If you statically link your application with SDL (under a separate license
available soon), and dynamically load an object, your code is suddenly
dependent on the version of libc the object was compiled against.
I think I tried statically linking the shared library object, but if I
remember correctly, mixing static libc code didn’t work out very nicely
in the end…–
Pierre Phaneuf
http://ludusdesign.com/
SDL looks very powerful and I’ve seen some excellent examples of it being
used - but picture trying to write an Adventure game, similar to King’s
Quest or the Monkey Island games, where the characters need to scale larger
and smaller as the move around on the screen. SDL doesn’t support sprite
scaling - which is a big let down. I could likely write my own scaling
routine, but doubtless my code would be slow.
Perhaps you could think of adding surface scaling?
example:
extern int SDL_BlitSurface(SDL_Surface *src, SDL_Rect *srcRect, SDL_Surface
*dst, SDL_Rect *dstRect)
Where the dstRect does not need to be the same size as the source rect and
the source image is scaled larger or smaller to fit the dstRect.
Thanks
Clay Larabie
Lead Developer of Tacendia Online
Yep, it’s on the wishlist, just not implemented. The difficulty is
the large number of combinations of conversion/colorkey/alpha blits
that all need to be written for scaling.
Although, perhaps just a scaling copy blit would be a nice addition.
See ya!
-Sam Lantinga, Lead Programmer, Loki Entertainment Software
Dear SDL
Luckily I came across SDL. I think it’s class having a graphics library
which is multiplatformable. I’ve developed games before but in old time DOS
and then DirectX.
Am wanting to go back into games programming and want to use OpenGL. I also
want to program to take into account of video settings so you have the
option of switching to software rendering without opengl drivers. What
factors/things do I need to know to program my games with opengl/no-opengl
modes?
Also, I want to program a multiplayer server/client game that’s easily
multiplatformable between linux/MAC/windows. Do you know any networking
libraries, etc? or any vital information on the net, or any best books you
recommand for this sort of thing?
Many thanks
Kevin
Student
http://www.libsdl.org/intro/usingvideo.html
http://sdldoc.csn.ul.ie/video.php
For information regarding video setup, including loading opengl libraries
etc…
http://www.libsdl.org/libraries.php
For information on SDL type libraries, including SDL_net - a cross platform
network library.
http://www.google.com/
For information regarding general network issues (search for beej’s network
guide).
http://www.libsdl.org/tutorials.php
http://www.libsdl.org/articles.php
http://www.libsdl.org/faq.php
There is enough information there to fill several large bags of holding.
Have fun,
Owen Butler> -----Original Message-----
From: sdl-admin at libsdl.org [mailto:sdl-admin at libsdl.org]On Behalf Of
Kevin
Sent: Tuesday, 17 December 2002 8:11 AM
To: sdl at libsdl.org
Subject: [SDL] SDLDear SDL
Luckily I came across SDL. I think it’s class having a graphics library
which is multiplatformable. I’ve developed games before but in
old time DOS
and then DirectX.Am wanting to go back into games programming and want to use
OpenGL. I also
want to program to take into account of video settings so you have the
option of switching to software rendering without opengl drivers. What
factors/things do I need to know to program my games with opengl/no-opengl
modes?Also, I want to program a multiplayer server/client game that’s easily
multiplatformable between linux/MAC/windows. Do you know any networking
libraries, etc? or any vital information on the net, or any best books you
recommand for this sort of thing?Many thanks
Kevin
Student
SDL mailing list
SDL at libsdl.org
http://www.libsdl.org/mailman/listinfo/sdl
Hy! Im a total newbie an I’ve got a question. How can I run
SDL apps as a normal user? Is suid the only way?
I use SDL 1.2.8 and Linux 2.4.
with friendly greetings–
+++ GMX - die erste Adresse f?r Mail, Message, More +++
1 GB Mailbox bereits in GMX FreeMail http://www.gmx.net/de/go/mail
You should be able to run them normally as any user, just make sure in
your .bash_profile for your /home directory that the path to SDL libs is
included. They are ussually in /usr/lib or /usr/local/lib.On Thu, 2005-01-06 at 16:22 +0100, Michael Anonym wrote:
Hy! Im a total newbie an I’ve got a question. How can I run
SDL apps as a normal user? Is suid the only way?
I use SDL 1.2.8 and Linux 2.4.
with friendly greetings
–
John Josef
Wyled
Crazed Monkeys Inc www.crazedmonkeys.com