Question from a (semi-)beginner

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

jeroen clarysse wrote:

DX_display * init_direct_draw(monitor_GUID)

SDL_SetVideoMode

DX_surface * load_bitmap_into_surface(filename, surfacepointer)

SDL_Surface * SDL_LoadBMP (use SDL_Image if your bitmaps are in other
formats)

void blit_surface_to_surface(DX_surface * , DX_surface *)

SDL_BlitSurface()

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.

  1. 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.

  1. 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()

  1. 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

(well, actually from a Visual C 6 user who is trying to appreciate the
Mac world :slight_smile:

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 !

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.

mattOn Nov 9, 2007, at 4:35 PM, jeroen clarysse wrote:

(well, actually from a Visual C 6 user who is trying to appreciate
the Mac world :slight_smile:

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 !


SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

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 ?

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/

-EricOn 11/9/07, jeroen clarysse <jeroen.clarysse at telenet.be> wrote:

(well, actually from a Visual C 6 user who is trying to appreciate the
Mac world :slight_smile:

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.

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)

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 ?

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)

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.

But to avoid having a mess of files installed all over the system and
avoid possible conflicts (a.k.a dll-hell), Mac has a ‘bundling’
convention where all necessary components can go inside to constitute
a single package. For applications, this is often referred to as an
’.app bundle’ or application bundle. If you dissect a good (Cocoa
based) application, you will see it just looks like a single file in
Finder. But if you go to the Unix command line, you will see it is
actually a directory structure containing a bunch of things including
the underlying executable and resources (icons, images, sounds,
localizations, etc). It may also contain dynamically linked libraries
inside which could be SDL. So to the end-user, it the application
looks like a single file which can be drag-and-dropped anywhere. But
to the developer, this is where you put all your stuff.

(Frameworks themselves are actually a bundle because they are just a
directory structure organized in a special way that contains the
underlying dynamic libraries, the header files, and any resources if
applicable.)

So when you deploy your app, you should bundle it with SDL. This way
the user doesn’t need to worry about installing additional
dependencies. This is similar to statically linking except that you
get the benefits of dynamic linking, such as potentially less pain
when dealing with the LGPL.

This thread which also asked the same thing and it just had a follow
up today. You might want to look at it.
http://lists.libsdl.org/pipermail/sdl-libsdl.org/2007-October/063084.html

Also, I recommended watching the screencast tutorials I made for
OpenSceneGraph which go into detail about how to get started with
Frameworks, Xcode, and bundling.

http://www.openscenegraph.org/projects/osg/wiki/Support/Tutorials/MacOSXTips

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…

The documentation that comes in the official packages was provided by
me. I know this is an issue, but the last SDL release predates Leopard
so we couldn’t talk about it. I sent some different changes to Sam
some weeks ago but still haven’t heard back. I’m waiting on this
before I submit any more changes.

PS to eric : you seem to be quite an authority here…

Kind of, sort of, not really.

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 ?

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.

Performance is hard to characterize at this high level. Also note that
hardware is not always faster than software. I think there is an SDL
FAQ item on hardware surfaces vs software surfaces and for the common
case, software usually wins I think. There are a bunch of reasons for
this I don’t want to get into here. Search the archives.

Performance may also depend on which version of OS X you are running
on. First, OS X uses a fully compositing graphics system, meaning
applications don’t get direct access to the framebuffer and everything
must go through a single service (Quartz Compositor) whose job is to
combine all the backing stores into a final image. A lot of different
things can happen here, shadows, alpha blending, anti-aliasing, etc.
But the point is that you don’t have direct access to the hardware and
you should consider everything virtualized.

QuickDraw is Mac classic technology (predating Quartz/OS X) and used
the draw to hardware idea. This obviously doesn’t mesh well with
Quartz and my guess is that Apple had to do some nasty things to get
the two to play together.

Speedy was not something used to describe Quartz in early versions of
OS X. On of the problems was that Quartz anti-aliases everything to
look nice while QuickDraw bypassed all that on the system. So early
on, people who needed speed still coded in QuickDraw against Apple’s
warnings.

But then Apple started optimizing Quartz and pushing more of the
responsibilities onto OpenGL to get hardware acceleration. Since then
Quartz’s performance caught up to QuickDraw and in most cases exceeded
QuickDraw by far.

And Apple is trying to do a lot of different things with the graphics
system like Resolution Independent UI. These things don’t gel well
with QuickDraw. But since OS X, it’s been well known QuickDraw was a
goner. So here we are 7 years later.

As for what SDL is doing with QuickDraw, I’m actually not sure. But
your performance might vary depending on which version of OS X you run
and what kind of drawing you do and how much.

I’m expecting that SDL 1.3 will remove/rewrite deprecated code if it
hasn’t already been done.

But again, I would say, don’t worry too much about it getting started.
SDL performance is generally good. If not, profile and find out where
the real problems exist. I’m actually expecting that things like
Resolution Independent UI (if it ever ships) will not work correctly
if we are using QuickDraw, but I’m not familiar enough with the code
to say. It could be that the QuickDraw code is rarely used. And
ultimately you might also be able to move to SDL 1.3 when it becomes
ready and you have problems.

Ars Technica article on Quartz in Tiger:

-EricOn 11/10/07, jeroen clarysse <jeroen.clarysse at telenet.be> wrote:

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 :slight_smile:

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 !

[…]

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 --'On Sunday 11 November 2007, jeroen clarysse wrote:

wow !

glSDL seems like a VERY valuable source !!!

i had never heard of it !

many thanks !On 11-nov-07, at 16:13, David Olofson wrote:

On Sunday 11 November 2007, jeroen clarysse wrote:
[…]

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
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org