I am following the discussion about glSDL recently, and followed the links in David Olofson’s signature, who seems to have developed it, but I can
not find any specific information about it…
Could someone please explain what exactly the glSDL library will do when it’s finished, and where I can have a look at (partial) source code of it?
Thanks in advance, ofcourse 
I am following the discussion about glSDL recently, and followed the
links in David Olofson’s signature, who seems to have developed it, but
I can not find any specific information about it…
There isn’t any…!
My bad - I’m still letting a number of potentially useful libraries
evolve as a part of the Kobo Deluxe source tree, rather than breaking
them out.
Could someone please explain what exactly the glSDL library will do
when it’s finished,
It already does…
* ...convert surfaces into OpenGL textures transparently.
* ...tile surfaces to fit in the square power-of-two sized
textures.
* ...implement alpha blending using OpenGL blending.
* ...implement alpha channels and colorkeying using OpenGL
RGBA textures with blending.
It does not yet…
* ...tile large surfaces into multiple textures.
* ...keep track of unused areas inside textures, in
order to use them for other surfaces.
* ...support blitting from or whithin the screen
surface.
* ...support locking and "direct" access of the
screen surface.
* ...exist in an SDL backend version. The current
implementation is a source level wrapper, that
requires including glSDL.h instead of SDL.h and
recompiling.
and where I can have a look at (partial) source
code of it?
It’s in the two files glSDL.h and glSDL.c in the graphics directory of
Kobo Deluxe. You may want to get the latest snapshot from
http://olofson.net/download
to get the latest bug fix(es), but do note that that version will
probably not run on Win32 due to a problem with finding the audio data
files.
(If anyone could post an example of how to check if a directory exists
with a given path, I’d be grateful. stdio can’t do it reliably, and there
seem to be no POSIX compliant directory handling calls on Win32… heh
I’m going to make the EEL interpreter ask for files instead - but I’d
still like all filemapper_t methods to work properly on all platforms, of
course!)
//David Olofson — Programmer, Reologica Instruments AB
.- M A I A -------------------------------------------------.
| Multimedia Application Integration Architecture |
| A Free/Open Source Plugin API for Professional Multimedia |
----------------------------> http://www.linuxdj.com/maia -' .- David Olofson -------------------------------------------. | Audio Hacker - Open Source Advocate - Singer - Songwriter |-------------------------------------> http://olofson.net -'On Tuesday 05 March 2002 23:17, Martijn Melenhorst wrote:
[snipped]
Could someone please explain what exactly the glSDL library will do
when it’s finished,It already does…
…convert surfaces into OpenGL textures transparently.
…tile surfaces to fit in the square power-of-two sized
textures.…implement alpha blending using OpenGL blending.
…implement alpha channels and colorkeying using OpenGL
RGBA textures with blending.
What is the maximum size screen that can be converted to a texture? Have you
hard-coded it to some value or is it dependent on the OpenGL driver?
It does not yet…
- …tile large surfaces into multiple textures.
How large ??
…keep track of unused areas inside textures, in
order to use them for other surfaces.…support blitting from or whithin the screen
surface.
So SDL_BlitSurface() is not supported? How about SDL_FillRect() and later
SDL_UpdateRects()?
…support locking and “direct” access of the
screen surface.…exist in an SDL backend version. The current
implementation is a source level wrapper, that
requires including glSDL.h instead of SDL.h and
recompiling.and where I can have a look at (partial) source
code of it?It’s in the two files glSDL.h and glSDL.c in the graphics directory of
Kobo Deluxe. You may want to get the latest snapshot fromto get the latest bug fix(es), but do note that that version will
probably not run on Win32 due to a problem with finding the audio data
files.
I’d also like to add my opinion that this will be very useful if it ever
becomes a backend to SDL. I’m really running into limitations in X and SDL
when trying to do an efficient 2D accelerated game. Running at 800x600, the
framerate never goes higher than 80 fps on an Athon 1800+XP and GerForce 2MX
card.
Also, is it possible to have glSDL scale the screen by some size? For
example, right now, I have to manually resize the window, and scale all the
rectangles by some multiplier (both width and height). I heard that OpenGL
can take care of this scaling, and could do so very efficiently. If it could
do that, I could eliminate all scaling code, which would probably make the
emulator run even faster.
Anyway, thanks for the great work you’ve done so far.
SteveOn March 6, 2002 12:51 pm, you wrote:
At 13:48 06.03.2002 -03-30, you wrote:
Also, is it possible to have glSDL scale the screen by some size? For
example, right now, I have to manually resize the window, and scale all the
rectangles by some multiplier (both width and height). I heard that OpenGL
can take care of this scaling, and could do so very efficiently. If it could
do that, I could eliminate all scaling code, which would probably make the
emulator run even faster.
Hi!
Therefore you don’t even need glSDL, because OpenGL does it itself, with
one resize-function to be called right when you resize your viewport and
right after initializing the glContext. My resize-functions normally look
like this and perfectly do the job:
void resize(int width, int height) {
glViewport(0, 0, width, height);
glMatrixMode(GL_PROJECTION);
glLoadIdentity();
gluPerspective(90, 1, 0.1, 10000); // use what you need
glMatrixMode(GL_MODELVIEW);
glLoadIdentity();
gluLookAt( // also use what
you need …
0, 0, -20, // cameraposition
0, 0, 0, // point we LookAt
0, 1, 0 // Up-Vector
);
// do some glEnables() / glDisables() and whatever neccessary
}
Because of the gluLookAt, setting the camera at (0,0,-20) and the point we
look at at(0,0,0), my screen boundaries lie at upperLeft(20,20,0)
upperRight(-20,20,0) lowerLeft(20,-20,0) lowerRight(-20,-20,0).
Now, it doesn’t matter which values are used for width and height, you
always have these screen boundaries.
Hope that helped,
St0fF.
[snipped]
Could someone please explain what exactly the glSDL library will do
when it’s finished,It already does…
* ...convert surfaces into OpenGL textures transparently. * ...tile surfaces to fit in the square power-of-two sized textures. * ...implement alpha blending using OpenGL blending. * ...implement alpha channels and colorkeying using OpenGL RGBA textures with blending.What is the maximum size screen that can be converted to a texture?
Have you hard-coded it to some value or is it dependent on the OpenGL
driver?
It depends on the driver. Currently, glSDL doesn’t support tiling into
multiple textures, so provided you use a “normal” screen aspect ratio
(that is, not wider than twice the height…), the maximum width will be
the restriction, and on most current cards, that means you can’t go
beyond 1024 pixels.
This, however, is merely me being lazy - it’s not particularly hard to
eliminate this limitation entirely with a smarter tiling algorithm.
It does not yet…
* ...tile large surfaces into multiple textures.How large ??
Anything that can be “chopped up” into pieces that fit in the maximum
size OpenGL texture of your card. For example, Kobo Deluxe stores SFont
format font surfaces (very wide) as they are, and glSDL splits them up
automatically.
* ...keep track of unused areas inside textures, in order to use them for other surfaces. * ...support blitting from or whithin the screen surface.So SDL_BlitSurface() is not supported?
On the contrary, the whole point with glSDL is accelerating
SDL_BlitSurface()!
What I’m saying is just that with the current glSDL imprementation, you
can only blit to the screen, not from it, or whithin it. (It’s
generally a very, very bad idea doing so on most targets anyway, but it’s
useful for mouse cursors, screenshots and that kind of stuff.)
Blits between and whithin other surfaces than the screen surface are
covered by SDL’s software blitter. (“As usual”, for most targets.)
How about SDL_FillRect() and
Supported.
later SDL_UpdateRects()?
Not applicable, as glSDL normally acts as if the screen was a hardware
surface. This is not entirely true to the actual situation, but it’s the
best approximation, as SDL_BlitSurface() and SDL_FillRect() will render
directly into the frame buffer. (Or rather, have OpenGL do it.)
(Frankly, I can’t remember if I implemented the “software screen shadow
surface” mode - probably not, as it effectively eliminates all h/w
acceleration.)
* ...support locking and "direct" access of the screen surface. * ...exist in an SDL backend version. The current implementation is a source level wrapper, that requires including glSDL.h instead of SDL.h and recompiling.and where I can have a look at (partial) source
code of it?It’s in the two files glSDL.h and glSDL.c in the graphics directory
of Kobo Deluxe. You may want to get the latest snapshot fromhttp://olofson.net/downloadto get the latest bug fix(es), but do note that that version will
probably not run on Win32 due to a problem with finding the audio
data files.I’d also like to add my opinion that this will be very useful if it
ever becomes a backend to SDL. I’m really running into limitations in
X and SDL when trying to do an efficient 2D accelerated game. Running
at 800x600, the framerate never goes higher than 80 fps on an Athon
1800+XP and GerForce 2MX card.
Wow! 80 fps is actually pretty good… heh
Anyway, that’s why I started hacking glSDL - a generic, portable and easy
way of getting h/w acceleration without writing two versions of your
code. The potential ability to run SDL applications on top of glSDL
without them even knowing it exists will be a nice bonus, of course.
Also, is it possible to have glSDL scale the screen by some size? For
example, right now, I have to manually resize the window, and scale all
the rectangles by some multiplier (both width and height).
It’s probably broken right now, but there are internal scaling factors
and an API extension meant for this. Of course, this should be fixed and
connected to SDL_SetVideoMode(), so that unavailable resolutions can be
emulated without that horrible black border.
I heard
that OpenGL can take care of this scaling, and could do so very
efficiently. If it could do that, I could eliminate all scaling code,
which would probably make the emulator run even faster.
Yes, indeed. The only cost of scaling with OpenGL is the per-screen-pixel
rendering cost - which is relatively low. If the card has enough blitting
power for the actual screen resolution, you’re fine.
Anyway, thanks for the great work you’ve done so far.
Thanks! Always nice to know people are interested in your work.
//David Olofson — Programmer, Reologica Instruments AB
.- M A I A -------------------------------------------------.
| Multimedia Application Integration Architecture |
| A Free/Open Source Plugin API for Professional Multimedia |
----------------------------> http://www.linuxdj.com/maia -' .- David Olofson -------------------------------------------. | Audio Hacker - Open Source Advocate - Singer - Songwriter |-------------------------------------> http://olofson.net -'On Wednesday 06 March 2002 18:18, Stephen Anthony wrote:
On March 6, 2002 12:51 pm, you wrote:
Anything that can be “chopped up” into pieces that fit in the maximum
size OpenGL texture of your card. For example, Kobo Deluxe stores SFont
format font surfaces (very wide) as they are, and glSDL splits them up
automatically.
OK, that is the part that would probably cause problems for me, since I don’t
know what OpenGL cards the emulator would be used on. I think Voodoo had a
limitation of 256x256??
So SDL_BlitSurface() is not supported?
On the contrary, the whole point with glSDL is accelerating
SDL_BlitSurface()!
Yes, I thought it strange that SDL_BlitSurface() would not be supported
What I’m saying is just that with the current glSDL imprementation, you
can only blit to the screen, not from it, or whithin it. (It’s
generally a very, very bad idea doing so on most targets anyway, but it’s
useful for mouse cursors, screenshots and that kind of stuff.)
I happen to have code that does a screenshot from the current SDL_Surface,
but I’ve been having other problems with it anyway. I guess I could
eliminate that stage altogether and get the screenshot from the actual data
that the emulator core creates. Probably would be faster and more portable
that way too (same code could be used in SDL and X11 frontends).
I’d also like to add my opinion that this will be very useful if it
ever becomes a backend to SDL. I’m really running into limitations in
X and SDL when trying to do an efficient 2D accelerated game. Running
at 800x600, the framerate never goes higher than 80 fps on an Athon
1800+XP and GerForce 2MX card.Wow! 80 fps is actually pretty good… heh
Actually, using SDL_UpdateRect(surface, 0, 0, 0, 0) at the end of every
frame results in this framerate. When I move to using a dirty rectangle
update (using SDL_FillRect and later SDL_UpdateRects), the framerate jumps to
290 fps
Problem is that the actual emulator core is taking much less than 1% of
total CPU usage. Its the SDL rendering that is taking all the time, and that
is what I find unacceptable. Its not that I want to run the emulator at a
higher fps, just that I want to do a lower fps more efficiently.
But an OpenGL backend will definitely help me on my next project (working on
the FCEU NES emulator).
SteveOn March 7, 2002 10:34 am, you wrote:
Anything that can be “chopped up” into pieces that fit in the maximum
size OpenGL texture of your card. For example, Kobo Deluxe stores
SFont format font surfaces (very wide) as they are, and glSDL
splits them up automatically.OK, that is the part that would probably cause problems for me, since I
don’t know what OpenGL cards the emulator would be used on.
Well, consider it a bug that hasn’t been fixed yet. glSDL will tile
across multiple textures when needed - I just haven’t implemented that
yet.
I think Voodoo had a limitation of 256x256??
Yes, at least the old ones.
[…]
What I’m saying is just that with the current glSDL imprementation,
you can only blit to the screen, not from it, or whithin it. (It’s
generally a very, very bad idea doing so on most targets anyway, but
it’s useful for mouse cursors, screenshots and that kind of stuff.)I happen to have code that does a screenshot from the current
SDL_Surface, but I’ve been having other problems with it anyway. I
guess I could eliminate that stage altogether and get the screenshot
from the actual data that the emulator core creates.
That would at least guarantee that you get uncompromized image quality
(ie no dithered down to 16 or 8 bits, or whatever) - but then again, is
that really what you want, considering that the term is screenshot…?
Probably would be
faster and more portable that way too (same code could be used in SDL
and X11 frontends).
True, but “real” screenshots might be useful as a debugging aid,
perhaps…
I’d also like to add my opinion that this will be very useful if
it ever becomes a backend to SDL. I’m really running into
limitations in X and SDL when trying to do an efficient 2D
accelerated game. Running at 800x600, the framerate never goes
higher than 80 fps on an Athon 1800+XP and GerForce 2MX card.Wow! 80 fps is actually pretty good… heh
Actually, using SDL_UpdateRect(surface, 0, 0, 0, 0) at the end of
every frame results in this framerate. When I move to using a dirty
rectangle update (using SDL_FillRect and later SDL_UpdateRects), the
framerate jumps to 290 fps
That’s without full screen scrolling, I assume. (?) (Or at least, with
limited scroll position update rates.)
Problem is that the actual emulator core is taking much less than 1%
of total CPU usage. Its the SDL rendering that is taking all the time,
and that is what I find unacceptable.
What is your emulator core actually doing? That is, does it generate
complete, full screen frames, or does it just generate "control data"
that is then passed on to a hardware emulation layer that emulates h/w
scrolling, h/w sprites and the like?
I’m wondering because it makes a big difference WRT the usefullness of
glSDL for your application. You have to be aware that any software
generated data has to be sent to the video card for rendering - and
unfortunately, there are plenty of drivers on certain platforms (read:
most drivers on Linux) that can’t use busmaster DMA for that…
Then again, also note that good OpenGL drivers are virtually as fast at
downloading textures as SDL is at blitting them from system RAM to VRAM.
Thus, a 100% s/w rendering 320x240 game that’s rendered into an OpenGL
procedural texture will run almost as fast as in “SDL 2D mode” - and you
eliminate the need for an actual 320x240 video mode, as OpenGL can
stretch the image while blitting it.
Its not that I want to run the
emulator at a higher fps, just that I want to do a lower fps more
efficiently.
My primary worry is that of achieving an acceptable frame rate at all,
especially in new games (Read: “The Return of Project Spitfire” 
that
have a native resolution above 320x240.
(Note that Kobo Deluxe is a 320x240 game - it’s just the graphics engine
that happens to be capable of scaling all graphics with more or less
sophisticated filters, at load time. The game looks “ok” in 320x240 mode
only because all graphics was drawn in that resolution.)
But an OpenGL backend will definitely help me on my next project
(working on the FCEU NES emulator).
AFAIK, the NES (as most other 8 and 16 bit consoles, and most “home
computers”) has a very slow CPU, and relies entirely on h/w scrolling and
sprites. Besides, it doesn’t have any fancy blending effects (unlike the
SNES, which does scaling, rotation, blending and stuff).
Unless I’m misinformed about the above, you should definitely split the
actual rendering part out of the emulator, instead of implementing it as
s/w rendering inside the emulator. That’s the only way you can take full
advantage of glSDL - or any accelerated target, for that matter.
BTW, is there an SNES emulator that makes proper use of OpenGL to
implement the background transformation and blending effects? That would
be faster, and look better than the real thing!
//David Olofson — Programmer, Reologica Instruments AB
.- M A I A -------------------------------------------------.
| Multimedia Application Integration Architecture |
| A Free/Open Source Plugin API for Professional Multimedia |
----------------------------> http://www.linuxdj.com/maia -' .- David Olofson -------------------------------------------. | Audio Hacker - Open Source Advocate - Singer - Songwriter |-------------------------------------> http://olofson.net -'On Thursday 07 March 2002 16:40, Stephen Anthony wrote:
On March 7, 2002 10:34 am, you wrote:
BTW, is there an SNES emulator that makes proper use of OpenGL to
implement the background transformation and blending effects? That would
be faster, and look better than the real thing!
Snes9x does, and come with full source AFAIK. See http://www.snes9x.com.
(btw - sorry to have missed all the discussion about glSDL. I’m extremly
busy these days and unfortunately can’t help much, even though this is
something I really support. However, I’m still available if you want me
to help fixing the problems I had running Kobo on my machine. I’m
running XFree 4.1 with a Voodoo 3. Any other GL game just works
perfectly, but Kobo gives me this weird square thing in high
resolutions, while in 320x240 the menu and screen border aren’t
visible.)
See you,
Alex.–
http://www.gnurou.org
BTW, is there an SNES emulator that makes proper use of OpenGL to
implement the background transformation and blending effects? That
would be faster, and look better than the real thing!Snes9x does, and come with full source AFAIK. See
http://www.snes9x.com.
So that’s why it’s so damn fast… (I did try it on Win32, but at that
time, OpenGL wasn’t supported at all on Linux, IIRC.)
(btw - sorry to have missed all the discussion about glSDL. I’m
extremly busy these days and unfortunately can’t help much, even though
this is something I really support. However, I’m still available if you
want me to help fixing the problems I had running Kobo on my machine.
I’m running XFree 4.1 with a Voodoo 3. Any other GL game just works
perfectly, but Kobo gives me this weird square thing in high
resolutions, while in 320x240 the menu and screen border aren’t
visible.)
This sounds like you’re hitting the texture size limit. (The Voodoo 3 is
one of those with a 256x256 limit, right?) glSDL still lacks support for
tiling into multiple textures, so despite the tiling, you’re effectively
limited by the maximum area of a texture.
//David Olofson — Programmer, Reologica Instruments AB
.- M A I A -------------------------------------------------.
| Multimedia Application Integration Architecture |
| A Free/Open Source Plugin API for Professional Multimedia |
----------------------------> http://www.linuxdj.com/maia -' .- David Olofson -------------------------------------------. | Audio Hacker - Open Source Advocate - Singer - Songwriter |-------------------------------------> http://olofson.net -'On Thursday 07 March 2002 20:14, Alexandre Courbot wrote:
Snes9x does, and come with full source AFAIK. See
http://www.snes9x.com.So that’s why it’s so damn fast… (I did try it on Win32, but at that
time, OpenGL wasn’t supported at all on Linux, IIRC.)
In case you are using debian, there is a snes9x-opengl package, if you
want to quickly test it (not all binaries come with opengl support)
This sounds like you’re hitting the texture size limit. (The Voodoo 3 is
one of those with a 256x256 limit, right?) glSDL still lacks support for
tiling into multiple textures, so despite the tiling, you’re effectively
limited by the maximum area of a texture.
I don’t think the Voodoo 3 is limited by 256x256 textures. Voodoo 1 and
2 are, however. But this would make sense, though, as in 320x200 small
units are displayed correctly while bigger ones (border, title, …)
aren’t. Ah, will have to be patient, as I have neither the time nor the
OpenGL knowledge to fix this myself…
Alex.–
http://www.gnurou.org
[snipped]
I happen to have code that does a screenshot from the current
SDL_Surface, but I’ve been having other problems with it anyway. I
guess I could eliminate that stage altogether and get the screenshot
from the actual data that the emulator core creates.That would at least guarantee that you get uncompromized image quality
(ie no dithered down to 16 or 8 bits, or whatever) - but then again, is
that really what you want, considering that the term is screenshot…?
:Probably would be
faster and more portable that way too (same code could be used in SDL
and X11 frontends).
Yes, since the emulator is only creating a frame in 8-bit anyway, I won’t
lose any information by doing it that way. Right now, the surface is set to
the screen depth, and my snapshot code has to convert from that to an 8-bit
surface which is then saved. I should say that that is what I am trying to
do, but its causing some problems. Since the snapshot is in 8 bits anyway,
and since I have access to the palette and pixels from the emulation core, I
can bypass reading from the SDL surface altogether.
I should have realized that in the first place, but sometimes the solution
doesn’t present itself until you talk about it with someone else
Actually, using SDL_UpdateRect(surface, 0, 0, 0, 0) at the end of
every frame results in this framerate. When I move to using a dirty
rectangle update (using SDL_FillRect and later SDL_UpdateRects), the
framerate jumps to 290 fpsThat’s without full screen scrolling, I assume. (?) (Or at least, with
limited scroll position update rates.)Problem is that the actual emulator core is taking much less than 1%
of total CPU usage. Its the SDL rendering that is taking all the time,
and that is what I find unacceptable.What is your emulator core actually doing? That is, does it generate
complete, full screen frames, or does it just generate "control data"
that is then passed on to a hardware emulation layer that emulates h/w
scrolling, h/w sprites and the like?
The emulation core produces complete, full screen frames. If I try to copy
these frames to the surface, then (on a P3-667), the CPU goes to approx. 60%
usage, assuming I use SDL_UpdateRect(surface, 0, 0, 0, 0).
I have experimented a bit, and I know that the SDL_UpdatRect call is what is
causing the problem. I even wrote a small program that calls this function
60 times a second (for 60 fps) with no data being blitted and no frames
being generated, and it still took the same amount of time. To make a long
story short, the emulation core overhead is negligible.
I had to switch to looking at the differences between the current frame and
the previous frame, then calling SDL_UpdateRects() on those rectangles that
are different. I don’t understand why SDL_UpdateRect(surface, 0, 0, 0, 0)
would cause such a performance hit.
I’m wondering because it makes a big difference WRT the usefullness of
glSDL for your application. You have to be aware that any software
generated data has to be sent to the video card for rendering - and
unfortunately, there are plenty of drivers on certain platforms (read:
most drivers on Linux) that can’t use busmaster DMA for that…Then again, also note that good OpenGL drivers are virtually as fast at
downloading textures as SDL is at blitting them from system RAM to VRAM.
Thus, a 100% s/w rendering 320x240 game that’s rendered into an OpenGL
procedural texture will run almost as fast as in “SDL 2D mode” - and you
eliminate the need for an actual 320x240 video mode, as OpenGL can
stretch the image while blitting it.
Well, this is only an emulator for an Atari 2600, so as you can imagine, the
emulation code itself is very fast on modern computers. In fact, a 486 could
probably handle it.
My problem is that, for reasons that would take too long to explain now, I
want to update the screen every frame with a full frame, not with the
differences to the last frame. It will still look the same onscreen, but I
just have some other reasons for wanting to do it that way.
Basically, I want to treat the surface as a hardware buffer and push the full
frame to it on every frame update. Using the dirty rectangle method works
for speed, but complicates other things. Also, taking advantage of glSDL
would mean I could eliminate screen scaling code, since OpenGL should scale
it accordingly. I guess what I’m saying is that alot of the things I am
doing right now are already done in OpenGL. The big difference is that speed
would increase and code complexity would decrease.
SteveOn March 7, 2002 01:20 pm, you wrote:
Snes9x does, and come with full source AFAIK. See
http://www.snes9x.com.So that’s why it’s so damn fast… (I did try it on Win32, but at
that time, OpenGL wasn’t supported at all on Linux, IIRC.)In case you are using debian,
Not yet, but after some frustration with Red Hat, and major trouble with
Mandrake’s install/upgrade tool, I’ve decided to stay away from RPM based
distros in general, and Mandrake in particular. I did consider SuSE, but
it seems like everyone eventually ends up on Debian anyway, so I have the
latest official Debian release lying around on CDs… (Can’t install from
the 'net; modem at home, bandwidth restrictions at work.)
there is a snes9x-opengl package, if you
want to quickly test it (not all binaries come with opengl support)
Ok… I’ll probably build from source anyway, when I get around to try
it. Usually turns out to work best anyway.
This sounds like you’re hitting the texture size limit. (The Voodoo 3
is one of those with a 256x256 limit, right?) glSDL still lacks
support for tiling into multiple textures, so despite the tiling,
you’re effectively limited by the maximum area of a texture.I don’t think the Voodoo 3 is limited by 256x256 textures. Voodoo 1 and
2 are, however. But this would make sense, though, as in 320x200 small
units are displayed correctly while bigger ones (border, title, …)
aren’t.
Yeah… Fonts would have problems as well, because (despite what it may
look like), they are extremely wide surfaces, and the area required after
tiling quickly exceeds 256x256, at least for the two larger fonts.
Ah, will have to be patient, as I have neither the time nor the
OpenGL knowledge to fix this myself…
Well, if you had the time, you wouldn’t need to know much about OpenGL,
as this is strictly a limitation in my tiling code. It “simply” needs to
grab more textures when it runs out of space.
Anyway, I’ll get back to serious glSDL hacking pretty soon. I just want
to take Kobo Deluxe to a fairly stable and portable 0.4 release first.
Things are going well, but the audio engine contains a few thousand lines
of brand new code that has to be tested and verified WRT portability.
heh Sounds nice, though.
//David Olofson — Programmer, Reologica Instruments AB
.- M A I A -------------------------------------------------.
| Multimedia Application Integration Architecture |
| A Free/Open Source Plugin API for Professional Multimedia |
----------------------------> http://www.linuxdj.com/maia -' .- David Olofson -------------------------------------------. | Audio Hacker - Open Source Advocate - Singer - Songwriter |-------------------------------------> http://olofson.net -'On Thursday 07 March 2002 21:05, Alexandre Courbot wrote:
[…screenshot from engine…]
I should have realized that in the first place, but sometimes the
solution doesn’t present itself until you talk about it with someone
else
Indeed! Lots of “great ideas” and “obvious designs” actually turn out to
be quite stupid when you actually try to describe them. I’ve found that
documenting the API while writing it - and the code - can sometimes help
in that regard. If you try to describe how things interact, you’ll notice
when they, uh, actually don’t.
[…]
I had to switch to looking at the differences between the current frame
and the previous frame, then calling SDL_UpdateRects() on those
rectangles that are different. I don’t understand why
SDL_UpdateRect(surface, 0, 0, 0, 0) would cause such a performance hit.
CPU writes to VRAM. Video cards are designed for busmaster DMA…
I’m wondering because it makes a big difference WRT the usefullness
of glSDL for your application. You have to be aware that any software
generated data has to be sent to the video card for rendering - and
unfortunately, there are plenty of drivers on certain platforms
(read: most drivers on Linux) that can’t use busmaster DMA for
that…Then again, also note that good OpenGL drivers are virtually as fast
at downloading textures as SDL is at blitting them from system RAM to
VRAM. Thus, a 100% s/w rendering 320x240 game that’s rendered into an
OpenGL procedural texture will run almost as fast as in “SDL 2D mode”
- and you eliminate the need for an actual 320x240 video mode, as
OpenGL can stretch the image while blitting it.Well, this is only an emulator for an Atari 2600, so as you can
imagine, the emulation code itself is very fast on modern computers.
In fact, a 486 could probably handle it.
Yeah, that sort of stuff is usually a non-issue these days. The problem
nowadays is that some subsystems still maintain performance levels that
were state-of-the-art in the 386 era… We have to make sure we don’t use
those if we can avoid it, but rely on other subsystems instead - such as
OpenGL.
My problem is that, for reasons that would take too long to explain
now, I want to update the screen every frame with a full frame, not
with the differences to the last frame.
If nothing else, that will be required anyway, as soon as you emulate
some code that does h/w scrolling, changes screen colors or whatever…
[…]
Basically, I want to treat the surface as a hardware buffer and push
the full frame to it on every frame update. Using the dirty rectangle
method works for speed, but complicates other things. Also, taking
advantage of glSDL would mean I could eliminate screen scaling code,
since OpenGL should scale it accordingly.
Yes - but that’s the only benefit you could have from glSDL. In fact,
it’s probably better done in native OpenGL code, as a simple scaling of
an image (split into one or more textures) is pretty trivial, compared to
the generic splitting/merging that glSDL does.
[…]
//David Olofson — Programmer, Reologica Instruments AB
.- M A I A -------------------------------------------------.
| Multimedia Application Integration Architecture |
| A Free/Open Source Plugin API for Professional Multimedia |
----------------------------> http://www.linuxdj.com/maia -' .- David Olofson -------------------------------------------. | Audio Hacker - Open Source Advocate - Singer - Songwriter |-------------------------------------> http://olofson.net -'On Thursday 07 March 2002 21:17, Stephen Anthony wrote:
[snipped]
My problem is that, for reasons that would take too long to explain
now, I want to update the screen every frame with a full frame, not
with the differences to the last frame.If nothing else, that will be required anyway, as soon as you emulate
some code that does h/w scrolling, changes screen colors or whatever…
Yes, these are some of the problems I’m running into. Another one is when I
want to put some text onscreen that is not part of the game, but a message
from the emulator (like saying “snapshot saved” or “fps = …”).
Basically, I want to treat the surface as a hardware buffer and push
the full frame to it on every frame update. Using the dirty rectangle
method works for speed, but complicates other things. Also, taking
advantage of glSDL would mean I could eliminate screen scaling code,
since OpenGL should scale it accordingly.Yes - but that’s the only benefit you could have from glSDL. In fact,
it’s probably better done in native OpenGL code, as a simple scaling of
an image (split into one or more textures) is pretty trivial, compared to
the generic splitting/merging that glSDL does.
Yes, the two things I want are to push full frames on every frame update, and
scale the window. I will probably look into doing this in native OpenGL
(when I figure out how:) Can you recommend any books or online manuals that
describe something like this?
I just would have liked to keep the code exactly the same whether I used
software or hardware rendering. Basically, have the SW_SURFACE or HW_SURFACE
flag actually do what it states.
Anyway, thanks for all the help,
SteveOn March 7, 2002 05:16 pm, you wrote:
[…]
Basically, I want to treat the surface as a hardware buffer and
push the full frame to it on every frame update. Using the dirty
rectangle method works for speed, but complicates other things.
Also, taking advantage of glSDL would mean I could eliminate screen
scaling code, since OpenGL should scale it accordingly.Yes - but that’s the only benefit you could have from glSDL. In fact,
it’s probably better done in native OpenGL code, as a simple scaling
of an image (split into one or more textures) is pretty trivial,
compared to the generic splitting/merging that glSDL does.Yes, the two things I want are to push full frames on every frame
update, and scale the window. I will probably look into doing this in
native OpenGL (when I figure out how:) Can you recommend any books or
online manuals that describe something like this?
I have some incomplete OpenGL man files installed on my system, and some
(equally incomplete) documentation in HTML format… I would not
recommend any of those! heh
I think we should both simply go and get the OpenGL Red Book.
I just would have liked to keep the code exactly the same whether I
used software or hardware rendering. Basically, have the SW_SURFACE or
HW_SURFACE flag actually do what it states.
Yeah… But with glSDL as an integral part of SDL, you’d have a major
problem: The only time glSDL would have OpenGL do h/w stretching is
when emulating an unavailable video mode.
For example, if your system lacks the 320x240 mode you’re asking for,
glSDL would select the most suitable higher resolution (probably 640x480)
and set up OpenGL so that a 320x240 coordinate system maps to the full
screen area. You wouldn’t be able to explicitly tell (gl)SDL to actually
use a different physical resolution from that passed to
SDL_SetVideoMode().
OTOH, perhaps a guarantee that any mode you set will cover the full
screen area is all you need? In that case, glSDL would be sufficient, of
course - although I’d still recommend that you hack your own OpenGL
code, as glSDL never will do filtered stretching and the like. (It’s just
not compatible with the way SDL is normally used by 2D applications.)
Think of glSDL as:
1) A quick way of getting your 2D games to work with SDL
as well as OpenGL, without hacking OpenGL code.
2) An alternative target that will accelerate many
(most?) existing SDL games without even recompiling
them. (You will have to relink statically linked
binaries, of course.)
If you want access to OpenGL specific features, you’ll have to bypass
SDL, whether or not there is an OpenGL 2D target in it.
All that said, it might be uselful to add a flag ‘SDL_GLFILTER’ or
something, that
1) Makes SDL select a physical display mode twice the size
passed to SDL_SetVideoMode().
2) Sets up a software shadow surface for the screen.
3) Make SDL_FlipSurface() upload the software surface
to one or more textures, and then render them with
bilinear filtering enabled.
Now, that doesn’t really have much to do with what glSDL does, but it
would be relatively easy to add as a bonus feature for very low
resolution games and emulators, I think.
//David Olofson — Programmer, Reologica Instruments AB
.- M A I A -------------------------------------------------.
| Multimedia Application Integration Architecture |
| A Free/Open Source Plugin API for Professional Multimedia |
----------------------------> http://www.linuxdj.com/maia -' .- David Olofson -------------------------------------------. | Audio Hacker - Open Source Advocate - Singer - Songwriter |-------------------------------------> http://olofson.net -'On Thursday 07 March 2002 22:02, Stephen Anthony wrote:
In case you are using debian,
Not yet, but after some frustration with Red Hat, and major trouble with
Mandrake’s install/upgrade tool, I’ve decided to stay away from RPM based
distros in general, and Mandrake in particular. I did consider SuSE, but
it seems like everyone eventually ends up on Debian anyway, so I have the
latest official Debian release lying around on CDs… (Can’t install from
the 'net; modem at home, bandwidth restrictions at work.)
I wouldn’t bet too much on debian… Sure, it’s MUCH better than anything
RPM-based, but it’s far from perfect, no matter what those debian ppl say.
Try a source-based distro =)
PS. SDL! (topic saver)–
Trick
“There is no magic” - Nakor, magic user
Debian is far from perfect. Look at how long the SDL packages have been
in a broken state. There are some good maintainers and there are some bad
ones. As with anything technical, the best way to understand how Linux
dists really work is to build one.
I recommend Linux From Scratch. You’ll learn more from it. If you then
decide to go back to using canned or fresh penguin, you’ll have a much
better understanding of how it all works. Linux from Scratch is a little
light on details for a programmer though.
None of this has much to do with SDL except that it will make you more
conscious of how Linux does things. If you are similarly conscious of how
other platforms work, you’ll be a better programmer and your SDL stuff
will be naturally more portable. =)On Fri, Mar 08, 2002 at 08:08:17PM +0100, Trick wrote:
Not yet, but after some frustration with Red Hat, and major trouble with
Mandrake’s install/upgrade tool, I’ve decided to stay away from RPM based
distros in general, and Mandrake in particular. I did consider SuSE, but
it seems like everyone eventually ends up on Debian anyway, so I have the
latest official Debian release lying around on CDs… (Can’t install from
the 'net; modem at home, bandwidth restrictions at work.)I wouldn’t bet too much on debian… Sure, it’s MUCH better than anything
RPM-based, but it’s far from perfect, no matter what those debian ppl say.
Try a source-based distro =)
–
Joseph Carter Only l33t on Thursdays
I think irc isn’t going to work though—we’re running out of topic space!
– Joseph Carter
-------------- next part --------------
A non-text attachment was scrubbed…
Name: not available
Type: application/pgp-signature
Size: 273 bytes
Desc: not available
URL: http://lists.libsdl.org/pipermail/sdl-libsdl.org/attachments/20020308/9ba6d625/attachment.pgp
http://www.linuxfromscratch.org/
Sorry. Back to your regularly scheduled topical discussions. ;)On Fri, Mar 08, 2002 at 09:41:16PM -0800, Joseph Carter wrote:
I recommend Linux From Scratch. You’ll learn more from it. If you then
decide to go back to using canned or fresh penguin, you’ll have a much
better understanding of how it all works. Linux from Scratch is a little
light on details for a programmer though.
–
Joseph Carter Intelligent backside at large
“I am ecstatic that some moron re-invented a 1995 windows fuckup.”
– Alan Cox
-------------- next part --------------
A non-text attachment was scrubbed…
Name: not available
Type: application/pgp-signature
Size: 273 bytes
Desc: not available
URL: http://lists.libsdl.org/pipermail/sdl-libsdl.org/attachments/20020308/5abb765d/attachment.pgp
“David Olofson” <david.olofson at reologica.se> wrote in message
news:mailman.1015431725.4657.sdl at libsdl.org…
(If anyone could post an example of how to check if a directory exists
with a given path, I’d be grateful.
Heres a copy of OS.c/h which comes from SQLite which has just the function
call(int sqliteOsFileExists(const char *zFilename)). It also has my (beta)
mac support. It contains a whole stash load of file calls - most of which u
won’t be interested in - but i’ll include them so u get the jist of it.
riki
begin 666 os_files_utils.zip
M4$L#!!0@`(`&-\;2P;5'2?5!L#A@$````;W,N8^P\^W?:1M8_QW_% MQ#V;@H-M2-+L-JZS!]O888,A"T[=;+\>CD"#42PD50]3DOA_W_N8D49(8)P^ MTNWY>G9CF,>=>^_<]\RPO[.ULR.>U.L-,9!!+&<C&8K&<VC$]HNI%%823_U0 MV$XT=BUG%HFQ'RQ"YVH:B]@7\=2)1.0GX5A"ARWWA&A[(G M^.Y/$(8E7'EE MN<+S8V<L:V(J0RE at DB5&KHPBQ[MZH5:#_\ZMA5CXB;!]<>7[MK \&R<*>>.X M>TMC)@YT3OSPRKF1'D#"S]@11M*=T$S5*?P8%HV6YT=3"S"9A%*ZBYKPY U0 M'EO7@)"8^= 33RV/!B*,/<;QM_POY3$P8^*XR#\OMAPO(D;B\C'R*0KDV)DX M8^1V8(7 Q,2U0N$',K1B0!9A1(L(MBX"YN..!4D8^!'RG[>'@,-?!!#Z-PX` MMT3B.<">F;!&41Q:X]CQ/83D>V(^=<93F"E%**,8H0S^W7%BP _XP<LB._:W MOG*\L9L`M.WH9Q<&M+UX;[IM-/L1?H>&B6?+B>@-AF^[[1^VOA)9PV6["]^- MAO/F,39 BX 6QY-V!0<]?5(5GSZE3<66X?#XW1DT#X=+S>?M[MGETR>%]J-> MO]/LGAQ#!RTH5)_"2C0*K8B\J%.S="-9.JM>/HN!2<]V)O at IG5X&7(]2?]6? M9985EDW'F7Q6._$=['84VWO3EV;C9.S%[E(;2-)^%%OQ4G/LS"0UY59A3-)! M<\<;69$Y3 at _$3=W?^2HQQ0`$*!V60WN?U.*5,A,HA[83QBB9;WH#8))EWSB1 M'RZ$ZX^OHQ="-+N#MAA<G(A&O?YTKR$JC6^_?5XEO9 DV.+YWC=[3_:>"!=8 M%HEG_W@*8$,_N9J*9]_6E88M6./F4^F!>H"BC,&F,) X$F!:QJZT0K1;N&Z- M1RLMA"5\,!\AJ!8,\!8PW8$9A"#.1S"C!=$263.IH:.QC,'6P20R<K\$KC-V M8G<!H^#_?DV,DIAUV)E!GR1\V##$QHKI.F6+B 1M+* -G)X`4SW"AFP"S!V' M3A#[(6!R['L10 MYO1A5?PR[:1AGU$HO%A.[(0Z1<J^RO;>/@!K;-=$;]D\N M^Y]ZP^-^JWE1$_7GSYY5#Y9G/EF:^63=3)P\2 *R96HA,NMJJD#S'4K+!7Z- M9$8WD589R;&5@):135,.!PR^C3L9+68C'UB-\G#-7DPYB2I^]-#XD(?@G0.S M)W\!&8_0ER"O41:!"S4>'(,H`HPK8']AI#*I0'@-MVSNA]>TZ_ I<6U ",;! MMH.82ILID. %;%XE]FFG+,<5L(5C(A%(GEM BPN$VPLEC+@$3N9-322B`_B1 MPSL""4+ABGQ8=T!@1D"JDIDQ,2ST9P6Q(>*4#B%&F;3Q2F$4U\ M(_U3TB1H M7H at Y(@C8K).UB"0`Z#7'\2 /$(B4JP7,9S.)DMGFW;"B:S&3-:4/D1B%_K7T MH/_(LE$$]%=0J9FTO$Q7YN2ZD D@$,J(,/G IVCAC<$6>,X'Q3]K3%ICS7SV MK6-_%DATM&@S at .D1^]6")IMPYX[KTF9CD$)<7%I)+8(1BX;J>,!J</#@7354 M&;$%`-29&!XY=X %7A$''5#XO+0%%LYCJ8(1$&S-:MJ33RVB?69YUI4BFQ$' M+96AARJE)-=!VS='MEZ"K%.,9$&L-!>V%5MH[7$G>#]KR&B2:!0_AY<F"=(1 MC.-A8*/8EP)@?<4F[@> M at 0T9NBHE44C,/'0EC=D`> CC(69TC7V`]P6_!,F MXS@)5?PTP<9*%==PD;HJZ[,MQE,)>C-)C;16*/D+.$K<;%(I-+0>1[5(OAX; M$CYCF(%J"S!".0/]R'/ ]7W8`S#328@<3%D+@\<^VJ&))BR312G1]%@>V2*U MW[1900 at 1L)]$Z!K0SAAJCT2#%" @QM6(W7O1*3(W8PH2S(+JH,\!,-X5K/0^ MB<AX(8[X';<$8>0<1#OF27-8?HG-4Q_W@;=P%01B.SA6GQB!Y!; \."1S$ A MPS(6*3,'[(/(- "KA!NE-^A")Q9H[G$\=J8+(!#PU3RZ!M80&9UJ4"IXRC+% M<TI5R% N\Y#L"E&A/0>!**RH at O%"N[B6,H at X,PHE63_*G1(`6 &\0(3(?%PC MIRD:@65LZ8)*@#96%1NW(7;;9N,*.L#LBR4*>1*1TJ;B1I*":I"@E8)IAX=U M-I!:_G1^D'@X5MIZV&XC&\>#4!0+/H[<#$QX:8 %,M$[0RNG679^!Q&8EM,F MA$M6#.E+$+/:H&"'"AF at E!8F?\-*R^@HMK)=R'.<PEK0>4Z*P/0#,TDL0'D< M[P:\A,W*AGJ$`#++K85BF7FIE(9 GX/Q'K@?&<^E]%2*2XSCO?%21A+;.5=2 M46T3=0Q:O7%J!R>^Z_KSO(A$,KS!2))IO0;'"I[+5GX$8*./L,QL$-=K>Q/? M@$%IL1(%TA!$@[NYY36 _;B%.<C-$'7OY@#"M/T=<0*F!M#S$JH%P"0,WOPA MS5)#VJ0OV8C;@WL2B.&8RX10FBZD!3EG:K]$$R.>*U=K)F:>9%=GB1L[@2L+ M,06I- %A?<T)1I99Y^W/,JXH):/W$(S11N)W\H+<1&H+`%A3%6V*!?"-EXT8 M/D4+8&+B/8/IZ1XATY<W`O;X@%C+-L._3 at +:=\7^&%7I0.3^@\'U%Z;2[C9> MB'F(_IW44HC&WM[>"T%.A%M2:%Y?3 at Z6H7538A23HJS"D[(RW6V1%B_ *D#X M9T&$`1%%H.0M$A45HU"9`8"FM&:FM(K(^*E!52L6A3E2?(14:RQ>X7(XACX< MBH\8U;0O6L-7S<&KX5&[V^R_ at RS"_)_(!/2,U,):%J!:IE8ENI3W3FE at 69)$ M44R at 0B3*.R;P$:,S*UQ ?_=MIR-F6#RCE!#S%U@`70X,G)%*8+0"(7^.Y&4) MVL'PJJ.^53BUJGY4>QN.#U8(6-:L8B4K'B43HSE;(, _V!..@<4<1DT at P'FD M)E6QSYE4H/\A^).J(D34L7TF9V!=*X]@3>)_!"&O/ZG URK- at P][&,H=:A3V M.+;3?1C;Y?K0\D ?(04]E25T=ZI<@$*!. 7.5!YI\0"$"8EE#!!S at H;.D#A7 MQH.>:Q]0EUZ8ESGG?=) F5=54>6Q>= YOBA NR]1LP_UEJ2MJ)30W, at UH@L] M3*<#1BD:2%_;`U<1Y^C-ELB176. )I(`[&%&O@!W0\"HX_"0:5;CA5KS-)2R M8 at +*>*-0O(5_;[&^]7&9M,>/<03V*YXH&;O5JMF'( <3 at E(5-"+ at S'- <I#3 MA*JI-#>^8\-2!#,=42[HQ (#U=W=G)!PHRDJ]]R K GVH:Y85\K16V '5\70 M).^4E;PHN]M5V=U.%EM FHR9+J2K:)8P223SJXSC16MP`19F'%+DHTL7.?<\ M2BL6$RY!4QQ*%?2$(Q%KY #.5.Z('/#%;.ML!S+S]GY/R# D*WBA/"?&E)%R M\%A0XB1:TEC, at B";1)*NG+&J)T^P/F@@O(7VC/DT=/PAP1\&D at -_$KFO5!UT MH-!I]UHXJ-*L"O%_6TK25T&H\I"U at W9WQ2'H).P\>0 at 7!D!_I7J at I;AY`)MF MBEQN&/GZ-020X^US$8NS,'5XDD:H(W IUYQOH.\%Z:#B\4JZLZ(JB\4)IPX4 MK4"B8JO4;-_@;2_B016(DRC,AHARYP/&,S@#:##+LP)##L>[KF0##DKJPD(M MC(-6##4J_@].!X- @J,+#K8>#.+PR3??B$!/@J9C/U@<0SNP[<)_8T7 X0QH M+1L*\ '4N74M%< *1P!!-O91% @>%BC65* I0RPU3TH.>Z]S)HJZ+OIO6SI7 MR)C*Q0-VW"9S<>T6=6W(8(4`%XE,.NM5,$+EW'[5[)YT6F**1 at 2C(HY$\MRO MD;2?M;JM?OMXV&\U3[BESG\P..%/O3>M[K#U0WMPT>Z><=-IN],:-B\N^NVC MM\"5;J]_WNR(3]Q^VFF>#?N 0>]\V#P^;@T&&43XD+K<Z</#=O?[9J=],F1\ MA_ %6*G,ZK'K1V!5/1N0GBHKJ7C16/(=]4T$Z91,_,2!C[T!Z <:J#],OF M MV :0LC,9,R(H9] _<;!;T5'!8?^$"/6%:&0R>)MJ;S/+C+$VD>;#8%&I.H'! M/97WP1=@[ ^?N6**`:HN'V,Q%RPM`J"*24S3=C$CUH-U1I6=18"\UBC2Y?(V M5[LXI2',>IZ(DC&7BK&TCKNF"IJ2<=5U!<0KYCK&CF/K"MQ.`&;/YJR<#R^@ MOZZUBN9BI5M59"9494MI12"*7"P6-%9-,^FDVD#B\8D0LY^\5*KG!F7(-8 at Z M:@QT:9*><=SL7J"F$#D09MQP:H"$18D;Q<MD`AA at TQ7D:LL6H@?8XK!+S-XJ M(.6E=@)U2E6C@(\U%>YG"VP5#(EC[[Z<V/K,Q1#H%6<NK*4\Z[LTVED+I=?M MO#."RN6YR]94\^Q I-&B,'FDPE\C at LQUUK49T)QK8=9XGL3REPKC#^L'&.UA MUI)+D@@Q&J/G=G#+S+D*?YIO1'MC-$LF@&6BNKWSUKG&#,>I\H_"M^A/UAGP MM;8[9[S!^NJOEWT`K8:011Z\:O9;>I318@[,[#T;_&;GLOEN8$*YK[TO&OS# MM0;_#F++?%61P+3=H*>,HL^E*:5*F"G>'92ME/M?)_8H7,BTZ<&])<UTDG^@ M-T0DESTBFKN34_"'W%D3DZ@/MN^-#&=J1B at GW62&DT!%R$<>HOFY#!'O3Y^$ M:@E@!K14Q<>M!S02',C#U4L4%^"9#U;MU8,'MW17 at T<M\QN:EK>P``OW`*!L M:4":',"R7H*VJA]E:'\-<#I?9W^CV8#*V at .J.56K=Z&_$5_*6/^;<J:^EC-; MQ?F%V2LE>UVHA$6X-%S*#BW4X2N=+#J1>7S*,0*GSY#ZCJ09?JR)MRY\86'N MQX<!@0_13NQ8+IZ=)R$FS.D![!QC+(JPL(HQSX(6P!HKW%0+S4H=%(91<;>+ M=_#H=*@X<819N+[40,=ED)_I:*:-%ZG<4]>ZHNLT82)5\C\#O156&&)(, at .$ MJ?9J);$_PUR6,E(^=N)ZIV8,W8^@HT#RBW99/,A5:./8B()#K/5BY$+,6][0 MLN"K7/A*HZ>6WMWR%*MF!DX4-BF>%$,FL.TK$B]MVU=;]MOLGA9XE]->I].[ M-.YJI6W9?:V-8S3XV_KAN/,I`X)16[V^,FI;A^47CY]*2 at CW#JMP.2W9:J52 ML+?W#L$.5&B-PCL!\-&*Y=)^=&OYV.*B=?ZFUV_VWZT.+\26*/O/''_2ZK00 MW^[PN ,^>RE$*"Q?7$/3_^NCRGHQ:"2Y;.6#K!2GSPL(UPOMGR_ZT2'-_6.@ M^WKZSXR?Z")M!8EEA[[2GQONO.C-]_'@V?9?H +@[F(ELM2?WQIN>2.OG";H MRNC^.;P)!A\]0.IN9W*_E#M-EO_G#/:?(N%=;8I*"I9_3 ;[AQBL7V>DB!>; M6RBR%P_OFT)]GEW9R(*D9^IH2/S0"A?995&\-?GA*)E @(Q_Q R/4" <'CE7 M0GI\+Y7N%^ --;R-AZ>!<7;$=/ZFVSQO#0?M_[1(RZUQS"]%\C;A`E9&;G5A MR8JR!K!<0?G5,9!I-:P/)TX8_?@37E1@"=O>VU:RMKU_8X7[\2S(&I)HJ4%_ MN3TPX"/D#\?P+P&FH=O6: PR<S5UWE^[,\\/?@ZC.+F9_[+XL,T#FD?')ZW3 MLU?M?[WNG'=[;_[='UR\_?[RAW?_40/JC2=/GWWS_.__^'9;1T!.3;Q?OC:@ MK at SD3"/0" 0"9=@#=KWB'-8/A/.=.O]D)E3W<U]_K/]4A3&/'^LR(Q["X3T# MU>W\!(*&5PU$E2[P.%XBL_K+P\&P/3AI]ROJBL#,MV7Y2!7-&U#K?R^.5"2D MH[B5#M^T-MN^.OT-0.WB205%H":V_Q;MJQ.^[1J!43KWGNXPA"ZZ at 2-U8R+' MG,8W)OGJ8DYZO-\'O^;/CA:QK%3%WT1%\8ZWO;K;2 _@$?B/[Q\_1A%30N'] M9-:9>,!/:1UI/D5#FV8Y2(7*;\H-]1>3.EX1E>^-%4]_+--:(O1,QGI0I6S0 M[E,P=RF<JI;1 at X/J!AN:F_9;[VI^4S]W1Y5&E)PW$HH at ZX8<YW<8_8L0@[87 M-YX#%8EG?]\GNXZ#P;]HJR?8[WQ!8<!C-##B,B1T*M<]C^/C$R>ZKHGK"^T< M>-#%(D"_9E)4$ZE#W'CW#1?Z5]GXDK!#&,X60S]URKCL!:FOLB;V+<2-JX+6 MY5LY:1"Z-ES=+*PT#Y$I_MIHKCH[9O(K^1+TNMJCOA9 at V?2@@=_2J$-:RE L M])<3>L?27X)#=_U=EQ^'Q3+BUS-T75/E/I,$JW"8X*A)[5ZKW^<W`@M\!'(E MKGP^=9R'OG=5"%P0L8I9^J(;*CL!B3H.M&9Q,86!]BL_)@NP=+W$1(/X"N- M&!%GM>\05Q)P!*QC:!B$:8X:;(:^T')X"$/%/PVVO,A1N^)RR66O?[(QEJ0E MR M*,4 at J##S!3@`@+/+IJ-Y ]/97(4MBA8\LU+7A0UR/3DU(9 Q!`R1H".-E MB!VU;KQN*I)TE)R3299#+95T!;]$)OTT\::;8*&(_)EZ',?WN_AJF)\FU at 69 MXT-L4^@X5-Q4]$"28[G1MM)(X"D5"-;('XW[#CE873($IY#M;6Y:6. at VQX_$ MCMBQ2NX(%DG>IT]X83JN&KB699@:X=N-TT>!=<82&81&LQ"FBTLL-[^C8)[[ M-U*]+K?L?:[MZ$OYCK[@4A"J at 937E>4:OC^91+(H1)!OPF M#CRH)@:MUNOA MH'5Q#U<R@) #%GS#V.G]TP`AIJ12PE'KK-VM'MQG0W*<)S(A'("/IB,?0%/% MH2O7\$EGYKRX>$DSJI!"\[X!IJW>:6[7%'/2K45BWOB1X)*/'C6)3L$Z#&(K MC,TI=[L\K"> I0CI/(HUD ^0S&<I_*"2'F#,9G@)B%[>X'W1X at 8OO'$^MKA3 MP4HOS4WPF:6.03"IN:]G47!.W00OD[ORB,QFI&*)^]I^8-:#:1P'+_;W;7DC M77PPOF<%`8 at X\&1_;(4CW]N/G2 "+Q^'SO at ZVIO&,W?K@>U[7\?\>HEP^=[' M1TU\VK<=61.YO?6@'4>"+M%&KC_?$RY>HL)G?X.O(_'6<Z KLES!%(AC:SRE MTT=\$T3!P]8#K./>O=<78>+QXPC/N-G%+_CX;2>^=0*!+-1-U,2"YGH8"'_^ M'L<:KE9RAO<YVUVNXP2O3,51T3R[-\D,^L;A93:*E#5O8YF >QG2$_U(EA]% M)B&]H\9MP O<:0S*L679G52R,,L[LQ-@<TEEJU `VLC]\<L1O4U4SGFXZB15 MT<G.C?$`NZ7J.VPA-[;<=^&6 at C_C_5?6EC:_?H\MO7,A!>:L9,\KZ)1WJLSP M;.LYQG^Q]J[#,5TD3)\])^DCZ,+/`6P[]G9Z1P!=;OIDL[UT93)[.H8OF=7[ M`">"278REMFS2U9\!%4*)GUNEH=BC7].G! ?-=(!4/8H39W4K E$S03HZ.W@ MW;K@$\-J3"37I:G&(ZE5ARKFP0B]P7F9W8;$H,XH96?Y?FX"OW;1[6G9NV%F M\_2VRMAF=;J;+J]F06B8AUU\M#2AC<%_&#YQUAW&BP!E_'38/^D<O\YUX3V. M,7;JN"C7&V% `)WJJRNQD%'O9#4'?F2K]?H4`71>@X+CA&KN59%)).Z>8D!V MC%W&AR(_,]ZMYJ@!M&S5V[MK"R at 69?8D$YFEO:E^O',GD00S_N?3ET;]R3,S MY2SC09'.#2A<20D;K%]#2?WP\'00H,>D`T=],E3]_4FX+3%\QL-V;>#,I^F0 MJ>8>P[*!R5WXOL/&6.M3W-_#S*!F4R:XU-H0CQX9O(2&ZCTMP&7_+V !=O_? M!'QA$_#P2QN M_R[$&@`^!<.BH^P<P]:LM\?@> $`>#=2^.&94F\XR>QHW\R MRO-W_:"@_XS$9LI?B!=*(LO5)D*_R<VKPD,^K"L-5!KFLXVLG9^TKMS<>]F2 MM]V_@"TQWRNONR.SZM;&9G;BX?W4BP7K-S 5]=_#5#R\OZWH1U_05D#2!13@ M[T_P;_3Q3RSQ3V*%=!ZG?\#C2GKX0WY@/@H)!8T;P+3\Q8_T))0*D2S\C8,2 M*Q X]","^ N*E0K^.XQWJND)(O3"Q"L9PP<6N)F<C8-%Y1$=]:EC0I[VWU+. MK;=-& K S^NOH*I4A2Z]L#U,T9ZRB*E(21H%LFQ[08BAUBH0!D1-5>V_[UQL M8RY=U^TM./C8/O8QQ_;Q9V- 1($+=76M'":>9\[LH>E\/!I0N?.5_\T/W$7@ M+5Q5>!.!#'U%+5 3!S8?&LR=HNJ#*6.+#TEE^9ADJ]OLJ%!.X02IDZOG=ZMU M/_EIDA04#AA9H/6:PLQ;YQ-T^3S3Y!5HDU6E25'WMQ%1%!$QLJHS*9\82-'K MZ1<WW/ASUUW9Z%H9SWC!N2(I677F7%VU=@.RZJ.\@&U9_!*\]78RF=B7W5?Q M^:SW]TF7ZFGL6<A"^^7U[=*%+U^]9I 8Z(8>,=LFK\0M-'"+D-=,Q.4N$/'] M#!475N-N"FVH+#"-(7\56&DW$]5F&XEZF1QJ*L<:(0;ND7[#@%3%@_3JTODP MI@@Z^V7)B8Y.[?YQ<2?P<D^W)I!L-_=F\:RDUYZ+=&>=]S.F1 ^1W?:F42W> MO5<T00PO*TN!$)O[=(]K#"02]#:]L44,-2 JE]J!@^\?G9#!$$;_`OY#U* $ M]O'=4V/E@<,Q#*XQI-&73 :"WM'81)4\\*YY0PS$DUZP#Z)5[2IQT"Q 8]F" MD%LE=$@<@X)-B4P&W8K\_3M=5PEBT$A:, YE-%+X]+-+-M,\FA#8@@4Q/U9! M"@::[?1MX&_+:DLUF^WTC>7?A$+&OE U6TG60U0*9!Z9C L&]C5*CABKK)$D M%,^2DW<A\14MY(6IH.8#(S4:9I at MA(E-9E_QF^%B$[A?0V_I!=YT[GUWU]UC MI[ZB&N&S-62;3>?@<LT"[V9IQ<V,HW;_6Y"0(A*$B-)><E:D='T(Z[6/4K4" MQSTZ'K#$[#KG1H"B--L2S.*&`K\5ZTNJ3[+!'LC&4$!R2.(]GAVUN=C[DA H MC($Q_68R"M./4WN,DGX)_25Q<+IH>M&$"*(59_OXSHKQDE?,%$(JGVY^81WD MEZI6660U*^OG'N8>&;>!&!;0%+-5A(S0H)/P(8__Z<\#HCT2: ER2K_MUW0Y M#<+*RX7V at F5 X+%,U1L+]#J='*<<8&X$'7E8;7;6O#PN:0 at P!L?&[0KML*-$ M$:7@,,RD)GV&,H].XR;P2=?'&7#H^<.H`AZ5PTYZ&Y8YJ O#I(^PHU&3GY); MD2L9ULATBM3"ZUC9*W^NM/$ZZ+^T.M(<<4_FTFU8P$O6W^YLQKR]JKNI/O^I M(#?_,:2>7T>_`5!+`P04``(`" !C?&TLRMF#S<@#``#="0``!&]S+FBM
M5FUOXD80_LZO&!W2B7 ID%3)AU)50CF?@L1++B:]J%08H_QEF77]:Y)W*K
M_69LGP4&TM.IEJ+LSCSS^HS’]+NM;A>N!X,K#%QN%UA"E>W)&3Y(D80F8M-
M"J&T at 1)R:R$P29[=>S &7"QM&!-E at 9(BA![&,-B1)T-Q'[$*!P+11HXV2 MEQ!CBD!&E8K95Z_4L5C9ZIR"$W&80&UL:$('3(AH [J7H-3"1)&9ET+7>H
MR1.?69%:5%%A62G!. IJF_8V%I1)E"J_!(T[JAR)S:4$&P-:5PL= %D’[TR
MQ__SJ7M,S8A1A!0^D at JAX\P:.6-XD2[F5 at 5FFP@MC8:[JM<_<:+.+MX9VPO
M>’<!PA&!2<&+6%F7BH#.1&&FR;GN338"H<GVQN"4W^N%#’;ACJ?YY(AZ#D
MA5I3ADH!2\FW0%7U$?X6'NCY^+[KY0_\V+K1QQ>_NMMHPH5 at 1+\C->>,NY MO[Q?MMHDDAH;4 at 8S]LMX]O-UJPU0H4A+(KAB459X8]'3;/S<:J.R> AE>1-+ MY at 35H8SJ("2=CNY:[1+T#5/?*N^E2;_ at 903$?TA\\%C1)%#G=$D03[RC"0E! M:M;,[2<6F]6?&+AO;:B]K@\08Y#C&3$2 4O_PU)?RC_I\5#6LF4"39C’1GH
M)A,Z#@'Z76!!NB46B1.Q,ED)LTQ1\3IS<-!:; CJ1U$X1".GG[Y>A<5A6B#
M5"94U+X9>\6F9NE&34A*H-EE at 8U-BJTQ?RP3>GCWR&14O%4;[PI@^ST=1;
M^N,_/%XZA" _)2CLW(]^]Y9/_L3S’B[@_7O8N^]Q7OF:CF?+0K6<^@7_C=$X
M"1L4(4N:]P:DG@>IY51[WZM9KL7_W8H7 F++/PQ4N]'LX\3#^)AL\7?TZ[. M=/2\?!@M[C_<#"Z.L,UV'!97C'Y=QQW-KH_ICM:Q_;%B^L4BI2G</&(TR[94 MTO'<%'=_K-W5+:0%K!1]\OT$[#)]Y5]?7/S@?[^JV2BMG[J OG/.Q?BG;9
MW’Y$A0X[@='604!;OWLQ/ !P5=ZKM,Z^9K3^_](:_I+*@^=759]H0/A3YEY MK]1Y2U^1\V9G at LVURD\:-? +VOLLGXDM!3F1_9TR%CNGC3E0ITYF9V18Y at 1B MV\RK++[&EIF]:>$C;CK[E=+/@LCB$2S7P9GT:-WH0.R'+;3R;SQ!HT_B0V W M\8^A7#(OU#,ABS+?T#]I=5[Y2)\-LZ6ZPY-,^ HQZ;!D:TG%S:MUGG:83C.' MKQV6-]43%#L\4--33CSOY8//*R_AKU!+0(4!0``@(&-\;2P;5'2?5!L
M#A@```$``````````$( "V at 0!O<RYC4$L!`A0`% `"``@`8WQM+,K9 M@\W(`P``W0D```0``````````0`@`+:!=AL``&]S+FA02P4&``````(``@!D )8!`````
`
end
Thanks!
//David Olofson — Programmer, Reologica Instruments AB
.- M A I A -------------------------------------------------.
| Multimedia Application Integration Architecture |
| A Free/Open Source Plugin API for Professional Multimedia |
----------------------------> http://www.linuxdj.com/maia -' .- David Olofson -------------------------------------------. | Audio Hacker - Open Source Advocate - Singer - Songwriter |-------------------------------------> http://olofson.net -'On Wednesday 13 March 2002 03:37, riki wrote:
“David Olofson” <david.olofson at reologica.se> wrote in message
news:mailman.1015431725.4657.sdl at libsdl.org…(If anyone could post an example of how to check if a directory exists
with a given path, I’d be grateful.Heres a copy of OS.c/h which comes from SQLite which has just the
function call(int sqliteOsFileExists(const char *zFilename)). It also
has my (beta) mac support. It contains a whole stash load of file calls
- most of which u won’t be interested in - but i’ll include them so u
get the jist of it.