Hello,
I have just installed the free version of BeOS 5 yesterday. I am having
a bit of a problem using SDL apps. It doesn’t find the SDL library. I
know the webpage says that the gnu directory that it is put under isn’t
default for be and I understand that, but I have SDL in the same
directory as everything else. (/boot/develop/lib/x86) all of the other
libraries seem to work. Will I really have to create a /home/lib
directory for just that one file or am I doing something wrong?
Put the SDL lib on /home/config/lib/
Eugenia.----
BeNews editor
John Garrison wrote in message
news:38E3E83D.CF014013 at visi.net…
Hello,
I have just installed the free version of BeOS 5 yesterday. I am having
a bit of a problem using SDL apps. It doesn’t find the SDL library. I
know the webpage says that the gnu directory that it is put under isn’t
default for be and I understand that, but I have SDL in the same
directory as everything else. (/boot/develop/lib/x86) all of the other
libraries seem to work. Will I really have to create a /home/lib
directory for just that one file or am I doing something wrong?
Hiya
A couple of things:
Although the drivers are still in closed beta, Be’s resident OpenGL/assembler
wiz R. Jason Sams has publically stated that the new API is based around
BDirectGLWindow, which is derived from BDirectWindow. Since the current
Be SDL library uses BDW exclusively, adding support for it should be relatively
easy.
The current implementation uses BDirectWindow/DrawBitmap for both windowed
and fullscreen display [1]. While this is an elegent solution, I can’t help
thinking
that you could get better performance by making more use of the GameKit, eg.
using BWindowScreen for the fullscreen mode, and using custom blitting code
(rather than DrawBitmap) where possible.
The solution we used in BeMAME was to create an abstract base called
’Display’, then derive windowed/fullscreen classes from that - all you have to
do is instantiate the correct class and leave the rest to the wonders of
polymorphism ;^)
I can’t see any major problems with this method apart from minor things
like switching between full-screen and windowed (instantiate a new display
from the old one, then delete the original), and the issue of increased code
complexity.
Does this sound reasonable? Are there any BeOS programmers here who
would be able to help with the work?
[1] What are people’s opinions on current BeOS SDL performance? I’ve heard
that the windowed mode is fast, but fullscreen is slow.–
C-YA
Jon
Quoting Eugenia Loli :
Come on people!
Reply please! I know that they are linux devs here who develop SDL
apps for
BeOS as well. Let’s make the BeOS a better (SDL) place!Eugenia.
Hi, I am the Arianne Developer.
My experience with Arianne & BeOS is that the window mode runs
as fast as Windows, that is 21 fps on a k6-2 300.
In Linux it is a little slower
Miguel
SDL for Be is slow as snot (1.1.3, compared to the windows
implementation); which is a shame, because I do 99% of my development
under Be. As for full screen being SLOWER than windowed, I don’t think
that’s the case. I think they are equally slow, but in full screen you
are more likely to notice things like tearing (I just did some tests
with the screen res set to 640x480, and windowed vs full screen seemed
about the same; I would do time tests, but I’m lazy).
The BeBook, BDirectWIndow page:
“The key to the BDirectWindow class is the DirectConnected()
function…”
So why doesn’t the Be implementation implement this function???
Implementing BDirectWindow::DirectConnected will give an appreciable
speed increase for windowed mode, but hardware acceleration for full
screen is a necessity. For 2D, we absolutely need to start using
BWindowScreen for a slew of reasons. Or two. 1) BWS gives access to
"hooks" which allow for hardware blitters, solving the “Be’s SDL is
slow” problem. 2) BWS doesn’t move other windows to fit the new
resolution like BDW does (Workspaces is in the lower right hand corner
of your screen right now, waiting to get moved by evil SDL).
First you said that the new OGL implementation is based around
BDirectWindow (which is good), then you suggest that we move SDL AWAY
from using BDW (which is bad)… Big problem. Should we just create a
second video device? One that uses the polymorphized BDW/BWS hybrid,
intended for 2D use, then a BDirectGLWindow using device? The 3D device
obviously wouldn’t suffer from slow blits, but it would be a shame to
see full screen 3D apps move around windows like it’s Christmas. That’s
my two cents.
James Marr
Interius Software
@James_Marr
www.interius.com
Come on people! 
Reply please! I know that they are linux devs here who develop SDL apps for
BeOS as well. Let’s make the BeOS a better (SDL) place!
Eugenia.
“Jonathan Belson” wrote in message
news:00036db5c8d7df42_mailit at dougal…
Hiya
A couple of things:
- Support for the new OpenGL API.
Although the drivers are still in closed beta, Be’s resident
OpenGL/assembler
wiz R. Jason Sams has publically stated that the new API is based around
BDirectGLWindow, which is derived from BDirectWindow. Since the current
Be SDL library uses BDW exclusively, adding support for it should be
relatively
easy.
- Improved performance.
The current implementation uses BDirectWindow/DrawBitmap for both windowed
and fullscreen display [1]. While this is an elegent solution, I can’t
help
thinking
that you could get better performance by making more use of the GameKit,
eg.
using BWindowScreen for the fullscreen mode, and using custom blitting
code
(rather than DrawBitmap) where possible.The solution we used in BeMAME was to create an abstract base called
’Display’, then derive windowed/fullscreen classes from that - all you
have to
do is instantiate the correct class and leave the rest to the wonders of
polymorphism ;^)I can’t see any major problems with this method apart from minor things
like switching between full-screen and windowed (instantiate a new display
from the old one, then delete the original), and the issue of increased
code
complexity.Does this sound reasonable? Are there any BeOS programmers here who
would be able to help with the work?[1] What are people’s opinions on current BeOS SDL performance? I’ve
heard> that the windowed mode is fast, but fullscreen is slow.–
C-YA
Jon
Well, I’m using SDL, and I will work on it but not until some time.
I’ll use SDL for some commercial games, so I’ll really need to tune it if
required, however, I’ve no time now, but I hope someone could check what
the problem is.
Ingenu.
James Marr a ?crit :> SDL for Be is slow as snot (1.1.3, compared to the windows
implementation); which is a shame, because I do 99% of my development
under Be. As for full screen being SLOWER than windowed, I don’t think
that’s the case. I think they are equally slow, but in full screen you
are more likely to notice things like tearing (I just did some tests
with the screen res set to 640x480, and windowed vs full screen seemed
about the same; I would do time tests, but I’m lazy).The BeBook, BDirectWIndow page:
“The key to the BDirectWindow class is the DirectConnected()
function…”So why doesn’t the Be implementation implement this function???
Implementing BDirectWindow::DirectConnected will give an appreciable
speed increase for windowed mode, but hardware acceleration for full
screen is a necessity. For 2D, we absolutely need to start using
BWindowScreen for a slew of reasons. Or two. 1) BWS gives access to
"hooks" which allow for hardware blitters, solving the “Be’s SDL is
slow” problem. 2) BWS doesn’t move other windows to fit the new
resolution like BDW does (Workspaces is in the lower right hand corner
of your screen right now, waiting to get moved by evil SDL).First you said that the new OGL implementation is based around
BDirectWindow (which is good), then you suggest that we move SDL AWAY
from using BDW (which is bad)… Big problem. Should we just create a
second video device? One that uses the polymorphized BDW/BWS hybrid,
intended for 2D use, then a BDirectGLWindow using device? The 3D device
obviously wouldn’t suffer from slow blits, but it would be a shame to
see full screen 3D apps move around windows like it’s Christmas. That’s
my two cents.James Marr
Interius Software
james at interius.com
www.interius.com
SDL for Be is slow as snot (1.1.3, compared to the windows
implementation); which is a shame, because I do 99% of my development
under Be. As for full screen being SLOWER than windowed, I don’t think
that’s the case. I think they are equally slow, but in full screen you
are more likely to notice things like tearing (I just did some tests
This is due to the use of DrawBitmapButTakeYourTime() routine for
screen updates.
The BeBook, BDirectWIndow page:
“The key to the BDirectWindow class is the DirectConnected()
function…”So why doesn’t the Be implementation implement this function???
I’m not sure - I was wondering the same thing when I first started
rummaging through the code. I suspect this is why there are crashes
when eg. switching between windowed and fullscreen.
Implementing BDirectWindow::DirectConnected will give an appreciable
speed increase for windowed mode, but hardware acceleration for full
Why would it be faster? DirectConnected() is a means to allow syncronisation
between the screen and the drawing thread, ie. you can draw, you can’t
draw, the screen has just changed etc.
screen is a necessity. For 2D, we absolutely need to start using
BWindowScreen for a slew of reasons. Or two. 1) BWS gives access to
"hooks" which allow for hardware blitters, solving the "Be’s SDL is
Yup (although I don’t think all drivers support this).
slow" problem. 2) BWS doesn’t move other windows to fit the new
resolution like BDW does (Workspaces is in the lower right hand corner
of your screen right now, waiting to get moved by evil SDL).
Yeah, that’s annoying.
First you said that the new OGL implementation is based around
BDirectWindow (which is good), then you suggest that we move SDL AWAY
Yup.
from using BDW (which is bad)… Big problem. Should we just create a
No, I suggested using driver code that best suits the type of screen being
used. If you want full screen use BWindowScreen, if you want fullscreen
with OpenGL use a fullscreen BDirectGLWindow (in theory, if you want
OpenGL you won’t be quite so bothered about 2d speed).
second video device? One that uses the polymorphized BDW/BWS hybrid,
intended for 2D use, then a BDirectGLWindow using device? The 3D device
My idea was to decide the best display method for according to the user’s
wishes:
If the user wants windowed display but no OpenGL, use a BDirectWindow.
If the user wants windowed display but OpenGL, use a BDirectGLWIndow.
If the user wants full-screen but no OpenGL, use a BWindowScreen.
If the user wants full-screen with OpenGL, use a full-screen BDirectGLWindow.
This way we can have optimal screen updates for each type of display.
The difficulty will come when the user wants to switch between windowed
and full-screen, since the current display object will need to be deleted then
the appropriate new one created.–
C-YA
Jon
Well, I’m using SDL, and I will work on it but not until some time.
I’ll use SDL for some commercial games, so I’ll really need to tune it if
required, however, I’ve no time now, but I hope someone could check what
the problem is.
I am in the same situation. When we have something closer to commercial
shipping, we can look at
fine tuning in more detail.
Bernard Giltrap
http://www.ideas2reality.co.uk>----- Original Message -----
From: Rod?ric VICAIRE
Implementing BDirectWindow::DirectConnected will give an appreciable
speed increase for windowed mode, but hardware acceleration for fullWhy would it be faster? DirectConnected() is a means to allow
syncronisation
between the screen and the drawing thread, ie. you can draw, you can’t
draw, the screen has just changed etc.
…and since you can draw, here is a pointer to the frame buffer 
I’m
not that sure about how fast DrawBitmap() is, but I would guess that an
asm blit directly to the screen would be quite a bit faster.
DrawBitmap() takes into account junk things, like window overlap, but
if the window is the font window, no need for that trash. The
DrawBitmap() method for drawing should stay in there for compatibility
reasons (not all video cards support direct access to frame buffer),
but if DirectConnected() gets called, and gives a valid pointer to the
frame buffer, why the hell not use an asm blit for screen updates?
screen is a necessity. For 2D, we absolutely need to start using
BWindowScreen for a slew of reasons. Or two. 1) BWS gives access to
"hooks" which allow for hardware blitters, solving the "Be’s SDL isYup (although I don’t think all drivers support this).
Right, but at least for some users we will have hardware acceleration,
which is better than what we currently have; nothing.
second video device? One that uses the polymorphized BDW/BWS hybrid,
intended for 2D use, then a BDirectGLWindow using device? The 3D
deviceMy idea was to decide the best display method for according to the
user’s
wishes:If the user wants windowed display but no OpenGL, use a BDirectWindow.
If the user wants windowed display but OpenGL, use a BDirectGLWIndow.
If the user wants full-screen but no OpenGL, use a BWindowScreen.
If the user wants full-screen with OpenGL, use a full-screen
BDirectGLWindow.
Oh, I think I understand. Are you suggesting that we continue to have
only one BeOS video device, but have that one device create a
BDirectGLWindow if the gl flag is passed, a BWindowScreen if the
fullscreen but not the gl flag is passed, and a BDirectWindow if
neither the fullscreen or the gl flag is passed? My only question, how
fast is inheritance compared to a switch? Would it really be faster
(execution speed) to derive separate classes for each window type, or
just a perform a switch in each function?
If the user wants windowed display but no OpenGL, use a BDirectWindow.
If the user wants windowed display but OpenGL, use a BDirectGLWIndow.
If the user wants full-screen but no OpenGL, use a BWindowScreen.
If the user wants full-screen with OpenGL, use a full-screen
BDirectGLWindow.
Oh, I think I understand. Are you suggesting that we continue to have
only one BeOS video device, but have that one device create a
BDirectGLWindow if the gl flag is passed, a BWindowScreen if the
fullscreen but not the gl flag is passed, and a BDirectWindow if
neither the fullscreen or the gl flag is passed? My only question, how
fast is inheritance compared to a switch? Would it really be faster
(execution speed) to derive separate classes for each window type, or
just a perform a switch in each function?
The way I understand it, separate classes need to be used for each
Window type, so that the correct event and screen managing behavior
is used for each display mode.
See ya,
-Sam Lantinga, Lead Programmer, Loki Entertainment Software
James Marr wrote:
My only question, how fast is inheritance compared to a switch?
Inheritance is faster than a switch, usually. Inheritance works like
function pointers, there is a small overhead, but the decision-making is
all done at once (when the object is created).–
“Unix is the worst operating system; except for all others.”
– Berry Kercheval
My only question, how fast is inheritance compared to a switch?
Inheritance is faster than a switch, usually. Inheritance works like
function pointers, there is a small overhead, but the decision-making is
all done at once (when the object is created).
Most modern CPUs do a fair job on predicting branches, but most do not
at all as well in the indirect function call prediction business.
(Most tests I’ve done confirm this.)
When you compare a switch to a virtual function call (which is basically
a indirect function call + the cost of fetching the pointer from the vtbl),
it depends on what code is emitted for the switch, how many branches etc.
Compilers often emit branch trees and/or jump tables for switches,
depending on the number and distribution of the case labels.
So the right answer is the one you don’t want: “It depends”
Mattias Engdeg?rd wrote:
Inheritance is faster than a switch, usually. Inheritance works like
function pointers, there is a small overhead, but the decision-making is
all done at once (when the object is created).Most modern CPUs do a fair job on predicting branches, but most do not
at all as well in the indirect function call prediction business.
(Most tests I’ve done confirm this.)When you compare a switch to a virtual function call (which is basically
a indirect function call + the cost of fetching the pointer from the vtbl),
it depends on what code is emitted for the switch, how many branches etc.Compilers often emit branch trees and/or jump tables for switches,
depending on the number and distribution of the case labels.
So the right answer is the one you don’t want: “It depends”
Unfortunately, you’re right.
But, if I understand this correctly, this is already going through a
C++ virtual method, so the cost of replacing that one with another one
through inheritance would be precisely “zero”. 
In a general manner, I would say that the cost of a virtual method call
is stable, and that for a switch it is variable. If the switch is small
enough, it probably is faster, but as it gets larger and larger and that
more tests needs to be done, they become slower. A virtual function call
costs the same, no matter how many classes implement it.–
/* you are not expected to understand this */
– from the UNIX V6 kernel source
Pierre Phaneuf wrote:
But, if I understand this correctly, this is already going through a
C++ virtual method, so the cost of replacing that one with another one
through inheritance would be precisely “zero”.
The other advantage of using virtual functions is elegence - once you’ve
created your object, your can manipulate it in exactly the same as
any other, regardless of the chosen display - the result is neater
code.
Switches will be required for eg. windowed mode, where the correct
blitting routine will be called depending on the desktop depth and
the source depth.
–
/* you are not expected to understand this */
– from the UNIX V6 kernel source
I read an explaination of how this comment actually came about - it
was something like a homework assignment where students were told
to read through some of the UNIX sourcecode. Some bits of it weren’t
relevent to what was being studied, hence the ‘you are not expected
to understand this’, ie. it’s not on your syllabus.–
C-YA
Jon
James Marr wrote:
Implementing BDirectWindow::DirectConnected will give an appreciable
speed increase for windowed mode, but hardware acceleration for fullDrawBitmap() takes into account junk things, like window overlap, but
if the window is the font window, no need for that trash. The
DrawBitmap() method for drawing should stay in there for compatibility
The fallback option, yes.
reasons (not all video cards support direct access to frame buffer),
but if DirectConnected() gets called, and gives a valid pointer to the
frame buffer, why the hell not use an asm blit for screen updates?
I agree 100%, that was my original proposal.
Oh, I think I understand. Are you suggesting that we continue to have
only one BeOS video device, but have that one device create a
BDirectGLWindow if the gl flag is passed, a BWindowScreen if the
fullscreen but not the gl flag is passed, and a BDirectWindow if
neither the fullscreen or the gl flag is passed? My only question, how
fast is inheritance compared to a switch? Would it really be faster
(execution speed) to derive separate classes for each window type, or
just a perform a switch in each function?
Faster? I don’t know. More elegent? Definitely.–
C-YA
Jon