Discussion:
question from a (semi-)beginner
(too old to reply)
jeroen clarysse
2007-10-26 14:46:01 UTC
Permalink
Hi all,

i'm a programmer for the Psychology-dept of the KULeuven university,
and i have been working on stimulus-presentation software for quite
some time now. The package relies on DirectX for fast blitting of
visual stimuli and graph-plotting of measured input. Recently, I have
been getting requests to port the package to MacOS X, which is
feasible fairly easily except for the DirectX part. So here are my
questions :

1) how difficult is it to use SDL to replace DirectX as a high-speed
blitter ? This basically boils down to 3 essential calls :
DX_display * init_direct_draw(monitor_GUID)
DX_surface * load_bitmap_into_surface(filename, surfacepointer)
void blit_surface_to_surface(DX_surface * , DX_surface *)
void blit_surface_to_display(DX_display * , DX_surface *)

2) is it hard to implement these DX_sound calls ?
DX_Sound * load_sound(filename)
play_sound (DX_sound * )
mute_sound(DX_sound *)

3) can I use SDL to fast-grab keyboard & mouse input ? I know that
keyboards are inherently inaccurate, but within these limitations, i
need to fetch keypresses as fast as possible.

4) can I use multiple monitors using SDL ? This part is probably the
hardest, as I haven't found docs on dual-monitor OpenGL


many many many thanks !

Jeroen
Gabriele Greco
2007-10-26 16:26:31 UTC
Permalink
Post by jeroen clarysse
DX_display * init_direct_draw(monitor_GUID)
SDL_SetVideoMode
Post by jeroen clarysse
DX_surface * load_bitmap_into_surface(filename, surfacepointer)
SDL_Surface * SDL_LoadBMP (use SDL_Image if your bitmaps are in other
formats)
Post by jeroen clarysse
void blit_surface_to_surface(DX_surface * , DX_surface *)
SDL_BlitSurface()
Post by jeroen clarysse
void blit_surface_to_display(DX_display * , DX_surface *)
SDL_BlitSurface() (the display is another surface)

Look at the wiki at libsdl.org for better description of the various calls.
Post by jeroen clarysse
2) is it hard to implement these DX_sound calls ?
DX_Sound * load_sound(filename)
play_sound (DX_sound * )
mute_sound(DX_sound *)
If you use SDL_mixer as helper library is REALLY simple, if you use the
"bare" SDL to do the audio is something more complex since you have to
define an audio callback yourself where to mix your samples.
Post by jeroen clarysse
3) can I use SDL to fast-grab keyboard & mouse input ? I know that
keyboards are inherently inaccurate, but within these limitations, i
need to fetch keypresses as fast as possible.
SDL_GetKeyState()
Post by jeroen clarysse
4) can I use multiple monitors using SDL ? This part is probably the
hardest, as I haven't found docs on dual-monitor OpenGL
AFAIK at the moment no. Probabily you'll be able to do it in 1.3
experimental tree.

---
Bye,
Gabry
jeroen clarysse
2007-11-09 22:35:36 UTC
Permalink
(well, actually from a Visual C 6 user who is trying to appreciate the
Mac world :-)

I' delighted to say that I got the SDL samples compiled under XCode3
(leopard). Apparently, dropping the given FrameWorks for SDL projects
into /Library/Application Support/.Apple/Developer Tools/Project
Templates/Application/ doesnt work under leopard : after quitting &
restarting XCode, these new types do not show up in the wizard of "new
project".

fortunately, one can simply these frameworks as a whole, fiddle around
a bit to replace the template strings, and get things compiled !

What worries me though is the gdb console output that I see when I run
the application :

2007-11-09 23:33:19.573 «PROJECTNAME»[2332:813] Warning once: This
application, or a library it uses, is using NSQuickDrawView, which has
been deprecated. Apps should cease use of QuickDraw and move to Quartz.

What does this imply ? Will this have a performance hit on blitting 2D
sprites ? My application is very very simple (just some 2D surface
blitting) but really really really needs all the speed it can get,
since it will be used for psychology priming experiments on 200Hz
monitors, so I really have to be sure that I can blit a few sprites in
less than 1millisecond.

is there any way to reassure myself that blitting is hardware-
optimized within VRAM ?

many thanks !
matt hull
2007-11-10 04:53:10 UTC
Permalink
i dont think SDL 1.2 uses hardware vram for windowed apps, only full
screen.... not sure though.

i think there was some talk about improvements with version 1.3; as
that would use opengl textures.

matt
Post by jeroen clarysse
(well, actually from a Visual C 6 user who is trying to appreciate
the Mac world :-)
I' delighted to say that I got the SDL samples compiled under
XCode3 (leopard). Apparently, dropping the given FrameWorks for SDL
projects into /Library/Application Support/.Apple/Developer Tools/
Project Templates/Application/ doesnt work under leopard : after
quitting & restarting XCode, these new types do not show up in the
wizard of "new project".
fortunately, one can simply these frameworks as a whole, fiddle
around a bit to replace the template strings, and get things
compiled !
What worries me though is the gdb console output that I see when I
2007-11-09 23:33:19.573 «PROJECTNAME»[2332:813] Warning once: This
application, or a library it uses, is using NSQuickDrawView, which
has been deprecated. Apps should cease use of QuickDraw and move to
Quartz.
What does this imply ? Will this have a performance hit on blitting
2D sprites ? My application is very very simple (just some 2D
surface blitting) but really really really needs all the speed it
can get, since it will be used for psychology priming experiments
on 200Hz monitors, so I really have to be sure that I can blit a
few sprites in less than 1millisecond.
is there any way to reassure myself that blitting is hardware-
optimized within VRAM ?
many thanks !
_______________________________________________
SDL mailing list
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
jeroen clarysse
2007-11-10 08:07:08 UTC
Permalink
Post by matt hull
i dont think SDL 1.2 uses hardware vram for windowed apps, only full
screen.... not sure though.
i think there was some talk about improvements with version 1.3; as
that would use opengl textures.
and how about the windows version with directX ? Does that library
store its stuff in VRam ? I know that, using plain DirectX , its
fairly easy to allocate a surface in hardware...

does someone have knowledge of how the blitting can be done in
hardware is the images are not in vram ?
E. Wing
2007-11-10 11:16:01 UTC
Permalink
Post by jeroen clarysse
(well, actually from a Visual C 6 user who is trying to appreciate the
Mac world :-)
I' delighted to say that I got the SDL samples compiled under XCode3
(leopard). Apparently, dropping the given FrameWorks for SDL projects
into /Library/Application Support/.Apple/Developer Tools/Project
Templates/Application/ doesnt work under leopard : after quitting &
restarting XCode, these new types do not show up in the wizard of "new
project".
fortunately, one can simply these frameworks as a whole, fiddle around
a bit to replace the template strings, and get things compiled !
To be clear, a "Framework" is the dynamic library + headers +
resources all in one package.
Frameworks go in /Library/Frameworks.

You seem to be referring to an Xcode project template. That is just an
Xcode project pre-setup to build certain things in certain ways. Our
templates are optional and provided as merely a convenience.

Xcode 3 changes the location of where templates are installed:

(From Xcode release notes)
Templates

The location for Xcode templates, scripts, and other support files has
changed. These files were previously located in /Library/Application
Support/Apple/Developer Tools/ and/Library/Application Support/Xcode/.
They are now located in the developer directory's Library/Xcode/
folder. Additionally, your own custom support files should now be
placed in a folder of the appropriate name (e.g. "Project Templates")
in any of the following locations:

/Library/Application Support/Developer/3.0/Xcode/
/Library/Application Support/Developer/Shared/Xcode/
~/Library/Application Support/Developer/3.0/Xcode/
~/Library/Application Support/Developer/Shared/Xcode/


-Eric
jeroen clarysse
2007-11-10 11:37:11 UTC
Permalink
Post by E. Wing
To be clear, a "Framework" is the dynamic library + headers +
resources all in one package.
Frameworks go in /Library/Frameworks.
ah ! This is quite a revelation... does such a "framework" get linked
statically ? If i distribute my program as a simple one-file-
appliction, will it find these frameworks ? Or are they like DLLs and
do they have to be distributed alongside the app ? (newbie to mac
here... really sorry if i ask stupid questions)
Post by E. Wing
You seem to be referring to an Xcode project template. That is just an
Xcode project pre-setup to build certain things in certain ways. Our
templates are optional and provided as merely a convenience.
thanks !
too bad the FAQ & docs still point to the old locations... who manages
these files ? Maybe I could help him out by mailing him the new
locations...

anyway : this mailinglist is very helpfull ! Thanks to all, and i hope
i'll be able to provide some help too, one day...

PS to eric : you seem to be quite an authority here... can you shed
some light on the gdb console message I was talking about :

2007-11-09 23:33:19.573 «PROJECTNAME»[2332:813] Warning once: This
application, or a library it uses, is using NSQuickDrawView, which has
been deprecated. Apps should cease use of QuickDraw and move to Quartz.

will this have a performance hit ?
E. Wing
2007-11-10 12:59:37 UTC
Permalink
This post might be inappropriate. Click to display it.
jeroen clarysse
2007-11-11 10:07:41 UTC
Permalink
Post by E. Wing
No, this is a good question. Frameworks are like a DLL. They are
dynamically linked in. This is actually nice when dealing with
licenses like the LGPL.
allllllright... see clearly now (the rain is gone :-)
Post by E. Wing
Post by jeroen clarysse
will this have a performance hit ?
Yes, no, maybe, it depends. So first, SDL is supposed to shelter you
from a lot of the details. For just getting started, I wouldn't worry
myself about these things. However, if you need serious hardware
performance and more low level control, then you might consider OpenGL
instead.
ok, i'll continue developing with SDL, and profile my app later when
we get to a stage of runnable code

many thanks already !
David Olofson
2007-11-11 15:13:55 UTC
Permalink
On Sunday 11 November 2007, jeroen clarysse wrote:
[...]
Post by jeroen clarysse
ok, i'll continue developing with SDL, and profile my app later when
we get to a stage of runnable code
An easy way to add optional OpenGL rendering is to use the glSDL
wrapper. You basically include glSDL.h instead of SDL.h and
recompile, and you're done; now you select OpenGL or standard SDL 2D
using an extra flag to SDL_SetVideoMode().

As of glSDL 0.8, there's color and alpha modulation, scaling and
rotation when using OpenGL. (Not likely to be implemented over the 2D
backends, as glSDL is really only meant for fast rendering to the
display surface. These extensions are for optional effects.)

Another solution might be to move to SDL 1.3/2.0, which has fully
accelerated OpenGL and Direct3D backends. AFAIK (haven't tried it in
a while), it also has scaling and extended blending that works on all
backends.


//David Olofson - Programmer, Composer, Open Source Advocate

.------- http://olofson.net - Games, SDL examples -------.
| http://zeespace.net - 2.5D rendering engine |
| http://audiality.org - Music/audio engine |
| http://eel.olofson.net - Real time scripting |
'-- http://www.reologica.se - Rheology instrumentation --'
jeroen clarysse
2007-11-11 15:17:22 UTC
Permalink
wow !

glSDL seems like a VERY valuable source !!!!!!!

i had never heard of it !

many thanks !
Post by David Olofson
[...]
Post by jeroen clarysse
ok, i'll continue developing with SDL, and profile my app later when
we get to a stage of runnable code
An easy way to add optional OpenGL rendering is to use the glSDL
wrapper. You basically include glSDL.h instead of SDL.h and
recompile, and you're done; now you select OpenGL or standard SDL 2D
using an extra flag to SDL_SetVideoMode().
As of glSDL 0.8, there's color and alpha modulation, scaling and
rotation when using OpenGL. (Not likely to be implemented over the 2D
backends, as glSDL is really only meant for fast rendering to the
display surface. These extensions are for optional effects.)
Another solution might be to move to SDL 1.3/2.0, which has fully
accelerated OpenGL and Direct3D backends. AFAIK (haven't tried it in
a while), it also has scaling and extended blending that works on all
backends.
//David Olofson - Programmer, Composer, Open Source Advocate
.------- http://olofson.net - Games, SDL examples -------.
| http://zeespace.net - 2.5D rendering engine |
| http://audiality.org - Music/audio engine |
| http://eel.olofson.net - Real time scripting |
'-- http://www.reologica.se - Rheology instrumentation --'
_______________________________________________
SDL mailing list
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
Continue reading on narkive:
Loading...