Hi people.
I’ve just started trying to get to know how to use sdl.
./configure make make install were flawless ( why by the way does it
require c++ compiler? I thought sdl was pure C)
Tests and founts proggie compiled ok. But then all of them
bail out with ‘couldn’t initialize SDL : no video devices available’ or
something like that. The only exception were some of the tests
(those that do not init video)
I’ve read all that there is on the website. I’ve read all the docs.
I’ve run it as root from xterm. I can’t understand.
What’s happening? Am i that dumb?
./lxnt
LxNT wrote:
Hi people.
[Problem about initializing SDL from programs deleted to conserve space]
After you did a ‘make install’, did you make sure that the library
directory
is in the file /etc/ld.so.conf (Usually /usr/local/lib), and did you run
ldconfig?
If not, on a linux machine you’ll have some troubles getting any library
to
be recognized.
Hope this helps!–
Craig Maloney (@Craig_Maloney) http://ic.net/~craig
Fortune for today: You are wise, witty, and wonderful, but you
spend too much time reading this sort of trash.
LxNT wrote:
Tests and founts proggie compiled ok. But then all of them
bail out with ‘couldn’t initialize SDL : no video devices available’ or
something like that. The only exception were some of the tests
(those that do not init video)
In addition to the /etc/ld.so.conf thing (often, /usr/local/lib isn’t in
there, and “configure” puts stuff there by default), you have to run
’ldconfig’ as root to update the shared library cache.–
Pierre Phaneuf
http://ludusdesign.com/
On Sun, 09 Jan 2000, LxNT wrote :
Tests and founts proggie compiled ok. But then all of them
bail out with ‘couldn’t initialize SDL : no video devices available’ or
something like that. The only exception were some of the tests
(those that do not init video)
Does this happen every time you try to execute it, or only after running it a
few times?
What’s happening? Am i that dumb?
No, have a similar problem with a game I’m developing right now. It works for
awhile, then suddenly no SDL linked program will work. They all bomb out with
the ‘couldn’t initialize SDL’ error message. Every single one of them (which
worked perfectly before). I attributed it to faulty clean up in my code, and
not with SDL. Has anyone else had that problem?
Doh. This is the new video driver detection code. If it can’t open the
X display, it doesn’t report that it’s a valid driver, and so SDL keeps
looking for usable drivers, and doesn’t find any. This is because it’s
possible that another driver (frame buffer console), may work. Previous
versions would report the X error “Can’t open DISPLAY”.
It needs to go into the FAQ.
Anyway, set your display environment variable appropriately (:0), and if
you still have problems, try xhost + localhost> -----Original Message-----
From: LxNT
To: sdl at lokigames.com
Date: Sunday, January 09, 2000 8:42 PM
Subject: [SDL] dumb question
Tests and founts proggie compiled ok. But then all of them
bail out with ‘couldn’t initialize SDL : no video devices available’ or
something like that. The only exception were some of the tests
(those that do not init video)
…
Damn, that’s wierd. Nobody that I’ve heard of has had a problem with it
quite like that. What the message means is that SDL is unable to find a
video device. When you boot up, it goes through all the video devices that
you compiled into it when you booted up, and checks 'em one by one to see if
they’re accessible. Make sure you have any video drivers compiled in (XLib
is included by default), and see if they work with any other major programs
of that nature (like Quake, for instance)
I am baffled.
What’s happening? Am i that dumb?
Nah, I doubt it’s you. See if either the last stable version or the newest
CVS version works (if you’re using the newest CVS, Sam (AFAIK) put some new
fullscreen code into there recently, that might be screwing you up)
./lxnt
Nicholas
-Sam Lantinga (slouken at devolution.com)
Lead Programmer, Loki Entertainment Software
“Any sufficiently advanced bug is indistinguishable from a feature”
– Rich Kulawiec
Hi.
As I initiall thought, problem was not in SDL, but - surprise,
surprise - 32mb pc66 dimm running at 100 mhz.
This caused, among other effects, egcs to coredump when compiling
(strangely gcc 2.7.2.3 coredumped several times less).
Today I’ve reset bus clk to 66 and everything rocked. Thanks a lot for
answers.
I must say that sdl documentation misses thorough INSTALL section.
the ld.so.conf issue definitely should be mentioned, (redhat 6.1 that
i have do not put /usr/local/lib into it)
Also it would be good to have a section on sdl internals overview -
how it initializes, works, how it selects which device to use, etc.
By the way, why do sdl require c++ compiler? I thought it’s pure C?
./lxnt
I must say that sdl documentation misses thorough INSTALL section.
the ld.so.conf issue definitely should be mentioned, (redhat 6.1 that
i have do not put /usr/local/lib into it)
If you want to write a good useable section for new users, I’ll be happy
to include it.
Also it would be good to have a section on sdl internals overview -
how it initializes, works, how it selects which device to use, etc.
A good idea.
By the way, why do sdl require c++ compiler? I thought it’s pure C?
The BeOS code uses C++.
See ya!
-Sam Lantinga (slouken at devolution.com)
Lead Programmer, Loki Entertainment Software–
“Any sufficiently advanced bug is indistinguishable from a feature”
– Rich Kulawiec
maybe I’m just dumb, but i cannot understand what the
SDL_UpdateRects(); function is for. The only example
code i can find using it has an SDL_UpdateRects()
occurring right after, and upon the same rect as a
blit. does the blit copy the image to framebuffer or
no? is the framebuffer different than the
corresponding physical video ram… what exactly is it
updating, to where and from where?
what else would i use this function for?__________________________________________________
Do you Yahoo!?
Yahoo! Web Hosting - establish your business online
http://webhosting.yahoo.com
UdateRects forces the display to be refreshed with the surface changes.
There is no point doing this automatically every time you make a surface
change as you may want to make hundreds of small changes to a surface
before refreshing the display screen.
I don’t think you need to call UpdateRects if you don’t want to refresh
the display.>maybe I’m just dumb, but i cannot understand what the
SDL_UpdateRects(); function is for. The only example
code i can find using it has an SDL_UpdateRects()
occurring right after, and upon the same rect as a
blit. does the blit copy the image to framebuffer or
no? is the framebuffer different than the
corresponding physical video ram… what exactly is it
updating, to where and from where?
what else would i use this function for?
Do you Yahoo!?
Yahoo! Web Hosting - establish your business online
http://webhosting.yahoo.com
SDL mailing list
SDL at libsdl.org
http://www.libsdl.org/mailman/listinfo/sdl
SDL_UpdateRects would be used if you had a whole bunch of screen rects you
want to update, like with isometric drawing. (starcraft, civ, baldur’s gate)
the framebuffer is, well just that, a section of memory that holds the next
frameOn Tuesday 11 March 2003 5:51 pm, Samuel J. Thurston, III wrote:
maybe I’m just dumb, but i cannot understand what the
SDL_UpdateRects(); function is for. The only example
code i can find using it has an SDL_UpdateRects()
occurring right after, and upon the same rect as a
blit. does the blit copy the image to framebuffer or
no? is the framebuffer different than the
corresponding physical video ram… what exactly is it
updating, to where and from where?
what else would i use this function for?
Do you Yahoo!?
Yahoo! Web Hosting - establish your business online
http://webhosting.yahoo.com
SDL mailing list
SDL at libsdl.org
http://www.libsdl.org/mailman/listinfo/sdl
–
"They that can give up essential liberty to obtain a little temporary safety
deserve neither liberty nor safety. "
–Benjamin Franklin
if i am understanding this (and the other relevant
post) correctly, it is like a “partial screen” version
of SDL_Flip(); is this right? wouldn’t this cause
visible ‘draw-in’ as if drawing single buffered?
sorry this is just one of those concepts i am having
trouble with.
— Robert Harrison wrote:> UdateRects forces the display to be refreshed with
the surface changes.
There is no point doing this automatically every
time you make a surface
change as you may want to make hundreds of small
changes to a surface
before refreshing the display screen.
I don’t think you need to call UpdateRects if you
don’t want to refresh
the display.
maybe I’m just dumb, but i cannot understand what
the
SDL_UpdateRects(); function is for. The only
example
code i can find using it has an SDL_UpdateRects()
occurring right after, and upon the same rect as a
blit. does the blit copy the image to framebuffer
or
no? is the framebuffer different than the
corresponding physical video ram… what exactly is
it
updating, to where and from where?
what else would i use this function for?
Do you Yahoo!?
Yahoo! Web Hosting - establish your business online
http://webhosting.yahoo.com
SDL mailing list
SDL at libsdl.org
http://www.libsdl.org/mailman/listinfo/sdl
SDL mailing list
SDL at libsdl.org
http://www.libsdl.org/mailman/listinfo/sdl
Do you Yahoo!?
Yahoo! Web Hosting - establish your business online
http://webhosting.yahoo.com
Samuel J. Thurston, III wrote:
if i am understanding this (and the other relevant
post) correctly, it is like a “partial screen” version
of SDL_Flip(); is this right? wouldn’t this cause
visible ‘draw-in’ as if drawing single buffered?
sorry this is just one of those concepts i am having
trouble with.
It ‘could’ call what you call ‘draw-in’ but, since you’re only updating
a subsection of the screen, it’s less likely to cause this effect than
if you tried to draw the entire screen instead (as you would do with
double-buffering when not supported by hardware).
Is the framebuffer different than the
corresponding physical video ram… what exactly is it
updating, to where and from where?
Sometimes the primary surface/front buffer is in video ram, sometimes it
is not. SDL has to provide a consistent interface for all these
possibilities, so you’re given a 2 part process: first update everything
on the ‘screen’ surface that SDL provides for you, then call SDL_Flip or
SDL_UpdateRects to move that ‘screen’ data to the physical video memory.
As such, you’d prefer the UpdateRects system on platforms where that
activity is a copying operation, to save time, whereas when working
entirely in video memory, this operation just involves switching a pair
of pointers and SDL_Flip is sufficient.–
Kylotan
http://pages.eidosnet.co.uk/kylotan