BeOS fullscreen problem

I just compiled SDLRoids on BeOS (all I had to fix was the delay code
which I hadn’t converted to SDL yet). Now it works great, except when
I try to run in full screen mode. When I use a window size that
doesn’t have a corresponding real resolution (say the default
480x480), my code is all screwed up. Basically it seems like I really
do get a 640x480 screen area, but that SDL tells me it’s 480x480. All
my on-the-screen drawing is off - I access the framebuffer directly
using a drawpixel function. Might the problem be that the pixel buffer
actually us 640x480, and that I simply write “too early” in it?
Perhaps the w/h reported by SDL (screen->h etc) should be the correct
values? I’m somewhat confused since X doesn’t have this problem. :slight_smile:

Also, I can’t seem to resize my SDL window on BeOS. Is this really
correct behavior?

Now a couple of unrelated questions about BeOS - how / where are BeOS
apps usually distributed / installed? I’ve noticed something called
".pkg" - where can I read about creating those? Also, how do I set the
icon of an app (in the Tracker that is)? Also, when I try to link with
libSDL.a (to get rid of SDL dependance), I get tons of errors. Is
there a trick to static linking on BeOS? (btw, -static to GDB didn’t
seem to help).–
[ Below is a random fortune, which is unrelated to the above message. ]
In charity there is no excess.
– Francis Bacon

I just compiled SDLRoids on BeOS (all I had to fix was the delay code
which I hadn’t converted to SDL yet). Now it works great, except when
I try to run in full screen mode. When I use a window size that
doesn’t have a corresponding real resolution (say the default
480x480), my code is all screwed up. Basically it seems like I really
do get a 640x480 screen area, but that SDL tells me it’s 480x480. All
my on-the-screen drawing is off - I access the framebuffer directly
using a drawpixel function. Might the problem be that the pixel buffer
actually us 640x480, and that I simply write “too early” in it?
Perhaps the w/h reported by SDL (screen->h etc) should be the correct
values? I’m somewhat confused since X doesn’t have this problem. :slight_smile:
Are you locking the surface before accessing the surface? Remember, the
value of surface->pixels may be invalid before a call to SDL_LockSurface.

MartinOn 11 Jul 2000, David Hedbor wrote:

Bother! said Pooh, as he fell off the prostitute.

Martin Donlon writes:

Are you locking the surface before accessing the surface? Remember, the
value of surface->pixels may be invalid before a call to SDL_LockSurface.

Yeah, I’m using locking.–
[ Below is a random fortune, which is unrelated to the above message. ]
Famous, adj.:
Conspicuously miserable.
– Ambrose Bierce, “The Devil’s Dictionary”

Martin Donlon writes:

Are you locking the surface before accessing the surface? Remember, the
value of surface->pixels may be invalid before a call to SDL_LockSurface.

Yeah, I’m using locking.

Are you respecting the pitch variable? The pitch may be a multiple of 640,
even though the “video mode” is 480x480.

See ya!
-Sam Lantinga, Lead Programmer, Loki Entertainment Software

Also, I can’t seem to resize my SDL window on BeOS. Is this really
correct behavior?

Resizing is not yet implemented on BeOS (one of the things holding up
the 1.2 release)

See ya!
-Sam Lantinga, Lead Programmer, Loki Entertainment Software

Sam Lantinga writes:

Also, I can’t seem to resize my SDL window on BeOS. Is this really
correct behavior?

Resizing is not yet implemented on BeOS (one of the things holding up
the 1.2 release)

Ok. Anything that I might be able to help with? (of course, I just
started using BeOS, to see if SDLRoids would work so I don’t know the
OS details). Know what needs to be done etc?–
[ Below is a random fortune, which is unrelated to the above message. ]
Turnaucka’s Law:
The attention span of a computer is only as long as its
electrical cord.

Sam Lantinga writes:

Martin Donlon writes:

Are you locking the surface before accessing the surface? Remember, the
value of surface->pixels may be invalid before a call to SDL_LockSurface.

Yeah, I’m using locking.

Are you respecting the pitch variable? The pitch may be a multiple of 640,
even though the “video mode” is 480x480.

I’m using the draw routines from the example starfield demo/program:

void fast_putpixel1(Uint16 x, Uint16 y, Uint32 pixel)
{
*((Uint8 *)screen->pixels + y * screen->pitch + x) = pixel;
}
void fast_putpixel2(Uint16 x, Uint16 y, Uint32 pixel)
{
*((Uint16 *)screen->pixels + y * screen->pitch/2 + x) = pixel;
}
void fast_putpixel3(Uint16 x, Uint16 y, Uint32 pixel)
{
Uint8 *pix;
int shift;

/* Gack - slow, but endian correct */
pix = (Uint8 )screen->pixels + y * screen->pitch + x3;
shift = screen->format->Rshift;
*(pix+shift/8) = pixel>>shift;
shift = screen->format->Gshift;
*(pix+shift/8) = pixel>>shift;
shift = screen->format->Bshift;
*(pix+shift/8) = pixel>>shift;
}
void fast_putpixel4(Uint16 x, Uint16 y, Uint32 pixel)
{
*((Uint32 *)screen->pixels + y * screen->pitch/4 + x) = pixel;
}

I run in 32 bpp so it’s the last one that’s actually used. I’ll add
some debug and stuff later tonight to see if I can figure anything
else out.–
[ Below is a random fortune, which is unrelated to the above message. ]
COBOL is for morons.
– E.W. Dijkstra

void fast_putpixel3(Uint16 x, Uint16 y, Uint32 pixel)
{
Uint8 *pix;
int shift;

/* Gack - slow, but endian correct */
pix = (Uint8 )screen->pixels + y * screen->pitch + x3;
shift = screen->format->Rshift;
*(pix+shift/8) = pixel>>shift;
shift = screen->format->Gshift;
*(pix+shift/8) = pixel>>shift;
shift = screen->format->Bshift;
*(pix+shift/8) = pixel>>shift;
}

No, that is not endian correct. This is better:

void fast_putpixel3(unsigned x, unsigned y, Uint32 pixel)
{
Uint8 *pix = (Uint8 *)screen->pixels + y * screen->pitch + x * 3;
if(SDL_BYTEORDER == SDL_BIG_ENDIAN) {
pix[2] = pixel;
pix[1] = pixel >> 8;
pix[0] = pixel >> 16;
} else {
pix[0] = pixel;
pix[1] = pixel >> 8;
pix[2] = pixel >> 16;
}
}

This is also faster. Note that the coordinates need not have any particular
number of bits.

“Mattias Engdeg?rd” writes:

Void fast_putpixel3(Uint16 x, Uint16 y, Uint32 pixel)
{
Uint8 *pix;
int shift;

/* Gack - slow, but endian correct */
pix = (Uint8 )screen->pixels + y * screen->pitch + x3;
shift = screen->format->Rshift;
*(pix+shift/8) = pixel>>shift;
shift = screen->format->Gshift;
*(pix+shift/8) = pixel>>shift;
shift = screen->format->Bshift;
*(pix+shift/8) = pixel>>shift;
}

No, that is not endian correct. This is better:

Void fast_putpixel3(unsigned x, unsigned y, Uint32 pixel)
{
Uint8 *pix = (Uint8 *)screen->pixels + y * screen->pitch + x * 3;
if(SDL_BYTEORDER == SDL_BIG_ENDIAN) {
pix[2] = pixel;
pix[1] = pixel >> 8;
pix[0] = pixel >> 16;
} else {
pix[0] = pixel;
pix[1] = pixel >> 8;
pix[2] = pixel >> 16;
}
}

This is also faster. Note that the coordinates need not have any particular
number of bits.

Ok. Perhaps Stars, http://www.libsdl.org/projects/stars/index.html,
should be fixed as well? :)–
[ Below is a random fortune, which is unrelated to the above message. ]
It is impossible to experience one’s death objectively and still carry a tune.
– Woody Allen

If you have BeOS-specific programming questions, please become a member of
one of those lists:
members at beunited.org (www.BeUnited.org The BeOS development open source
movement)
or subscribe to BeDevTalk - enter ‘subscribe bedevtalk’ in the subject field
of your email to:
lyris at be.com

Eugenia.

David Hedbor wrote in message
news:m3k8es60xw.fsf at nyarlathotep.home.hedbor.org…> Sam Lantinga writes:

Also, I can’t seem to resize my SDL window on BeOS. Is this really
correct behavior?

Resizing is not yet implemented on BeOS (one of the things holding up
the 1.2 release)

Ok. Anything that I might be able to help with? (of course, I just
started using BeOS, to see if SDLRoids would work so I don’t know the
OS details). Know what needs to be done etc?


[ Below is a random fortune, which is unrelated to the above message. ]
Turnaucka’s Law:
The attention span of a computer is only as long as its
electrical cord.

Martin Donlon writes:

Are you locking the surface before accessing the surface? Remember, the
value of surface->pixels may be invalid before a call to SDL_LockSurface.

You know, looking at my code again, it seems like I’m NOT locking the
code. Argh! I’ll have to fix that and try again. Too late today
though. yawn
[ Below is a random fortune, which is unrelated to the above message. ]
Whistler’s Law:
You never know who is right, but you always know who is in charge.

No, that is not endian correct. This is better:

Void fast_putpixel3(unsigned x, unsigned y, Uint32 pixel)
{
Uint8 *pix = (Uint8 *)screen->pixels + y * screen->pitch + x * 3;
if(SDL_BYTEORDER == SDL_BIG_ENDIAN) {
pix[2] = pixel;
pix[1] = pixel >> 8;
pix[0] = pixel >> 16;
} else {
pix[0] = pixel;
pix[1] = pixel >> 8;
pix[2] = pixel >> 16;
}
}

This is also faster. Note that the coordinates need not have any particular
number of bits.

Ok. Perhaps Stars, http://www.libsdl.org/projects/stars/index.html,
should be fixed as well? :slight_smile:

Yep! Thanks, this is now fixed. :slight_smile:

See ya,
-Sam Lantinga, Lead Programmer, Loki Entertainment Software