I’m trying to write a simple starfield effect using SDL. I’ve decided to
use a 8 bpp 320x240 screen mode, because it’s easy to understand and
program, even for a complete beginner. Unfortunately, I’m having an
awful problem with this mode (and others that have 8 bpp). Everything
works perfectly in windowed mode, but when I switch to fullscreen video,
it looks like my SDL surface takes only upper half of the screen. The
bottom half stays black (I can only go there with my mouse cursor, which
leaves there it’s track). The same thing happens under Windows and under
Linux, but in the latter case, only when my app tries to use DGA. I’ve
tried both SW_SURFACE and HW_SURFACE – no difference. There’s nothing
extraordinary in my code:
When you do that, does the art in the upper half of the screen get messed up
in any way?
If not…
Ive seen this problem before when setting “odd” video modes (like once i set
50x50 to see what would happen).
what’s happening is that for some reason, SDL is unable or unwilling to get
a 320x240x8 bits screen, so it’s getting a bigger screen than you requested,
but the size you requested is there, it’s just in the upper left (or just
upper) part of the screen.
I could be wrong but I think this is the issue that you are encountering> ----- Original Message -----
I’m trying to write a simple starfield effect using SDL. I’ve decided to
use a 8 bpp 320x240 screen mode, because it’s easy to understand and
program, even for a complete beginner. Unfortunately, I’m having an
awful problem with this mode (and others that have 8 bpp). Everything
works perfectly in windowed mode, but when I switch to fullscreen video,
it looks like my SDL surface takes only upper half of the screen. The
bottom half stays black (I can only go there with my mouse cursor, which
leaves there it’s track). The same thing happens under Windows and under
Linux, but in the latter case, only when my app tries to use DGA. I’ve
tried both SW_SURFACE and HW_SURFACE – no difference. There’s nothing
extraordinary in my code:
what’s happening is that for some reason, SDL is unable or unwilling to get
a 320x240x8 bits screen, so it’s getting a bigger screen than you requested,
but the size you requested is there, it’s just in the upper left (or just
upper) part of the screen.
Other probable reason could be that the monitor geometry isn’t setup for
such modes, since “nobody” uses them anymore. (Ofcourse, if you have
other programs/games that run in that mode and look ok, disregard this
post ). Try fiddling with your monitor controls to stretch the
visible area.
Other probable reason could be that the monitor geometry isn’t setup
for such modes, since “nobody” uses them anymore. (Ofcourse, if you
have other programs/games that run in that mode and look ok, disregard
this post ). Try fiddling with your monitor controls to stretch the
visible area.
You can easily find out if the modes are supported by compiling and
running test/testvidinfo.c which comes with the SDL package.
what’s happening is that for some reason, SDL is unable or unwilling
to get
a 320x240x8 bits screen, so it’s getting a bigger screen than you
requested,
but the size you requested is there, it’s just in the upper left (or
just
upper) part of the screen.
Other probable reason could be that the monitor geometry isn’t setup
for such modes, since “nobody” uses them anymore. (Ofcourse, if you
have other programs/games that run in that mode and look ok, disregard
this post ). Try fiddling with your monitor controls to stretch the
visible area.
He did say his mouse was visible on the bottom portion of the screen.On Sep 14, 2004, at 7:13 PM, Ivan Voras wrote:
W li?cie z wto, 14-09-2004, godz. 18:42, Alan Wolfe pisze:
When you do that, does the art in the upper half of the screen get messed up
in any way?
No, it looks alright. However, the whole surface is cleared on each step
of the main loop. I’ll try leaving the screen untouched and see what
happens, but I have a feeling that it will be okay.
Ive seen this problem before when setting “odd” video modes (like once i set
50x50 to see what would happen).
That’s what I was thinking of, but…
what’s happening is that for some reason, SDL is unable or unwilling to get
a 320x240x8 bits screen
But why? 320x240x8 should be supported by every graphic card, so why?
SDL_VideoModeOK tells that this mode is avaiable. What is more, it works
– under Linux, without DGA. What’s responsible for this weirdness,
then?
You can easily find out if the modes are supported by compiling and
running test/testvidinfo.c which comes with the SDL package.
Thanks for the tip. It is supported and I found what was wrong. It was
my fault.
I was drawing everything using my own putpixel() routine. I just didn’t
want to copy the one included with the docs, mainly because I like to do
as many as possible on my own I think it’s better for learning.
However I’ve made a simple mistake. My function was computing an address
of a pixel in the following way:
void putpixel( SDL_Surface scr, int x, int y, int color )
{
( (Uint8) scr->pixels )[ ( y << 8 ) + ( y << 6 ) + x ] = color;
}
(I know: it’s not the most human-friendly coding style and I shouldn’t
use all these shift operators and magic numbers, but hey! I was only
playing. ;)) Finally I found that (in fullscreen mode) scr->pitch was
not 320 but 512. Previously I tried to draw some pixels beyond the
excpected 320*240 bytes, but I forgot that I made putpixel() to check
both x and y parameters and don’t let me do anything unsafe Now
everything works perfectly, so thanks everybody for your help. Oh, BTW,
why are there 512 intead of 320 bytes per line? Is this some kind of
optimisation? I think this way there should be slightly less time needed
to compute pixel addresses. Is this all?On Wed, 15 Sep 2004 02:27:52 +0200 Michael Prager <X_X_L at gmx.net> wrote:
i thought it might be a problem w/ the pitch, especialy since you siad the
image was on the top only (not the top left) but you said the image wasnt
distorted so it must have been something simple like a line or random pixels
so you couldnt tell
you got it on the optomization thing.
512 bytes is the size of a “paragraph” of memory if i remember correctly so
it’s possible that each line is assigned it’s own paragraph.
as you probably know, aligning memory on boundaries like word,double word,
quad word, etc makes memory reads and writes go faster since the cpu etc can
do it in less operations so im sure it has something to do with that.> ----- Original Message -----
Sent: Wednesday, September 15, 2004 3:12 AM
Subject: Re: [SDL] Re: 8bpp in fullscreen (solved)
On Wed, 15 Sep 2004 02:27:52 +0200 Michael Prager <X_X_L at gmx.net> wrote:
You can easily find out if the modes are supported by compiling and
running test/testvidinfo.c which comes with the SDL package.
Thanks for the tip. It is supported and I found what was wrong. It was
my fault.
I was drawing everything using my own putpixel() routine. I just didn’t
want to copy the one included with the docs, mainly because I like to do
as many as possible on my own I think it’s better for learning.
However I’ve made a simple mistake. My function was computing an address
of a pixel in the following way:
void putpixel( SDL_Surface scr, int x, int y, int color )
{
( (Uint8) scr->pixels )[ ( y << 8 ) + ( y << 6 ) + x ] = color;
}
(I know: it’s not the most human-friendly coding style and I shouldn’t
use all these shift operators and magic numbers, but hey! I was only
playing. ;)) Finally I found that (in fullscreen mode) scr->pitch was
not 320 but 512. Previously I tried to draw some pixels beyond the
excpected 320*240 bytes, but I forgot that I made putpixel() to check
both x and y parameters and don’t let me do anything unsafe Now
everything works perfectly, so thanks everybody for your help. Oh, BTW,
why are there 512 intead of 320 bytes per line? Is this some kind of
optimisation? I think this way there should be slightly less time needed
to compute pixel addresses. Is this all?
Tomasz Olszewski wrote:>On Wed, 15 Sep 2004 02:27:52 +0200 Michael Prager <X_X_L at gmx.net> wrote:
You can easily find out if the modes are supported by compiling and
running test/testvidinfo.c which comes with the SDL package.
Thanks for the tip. It is supported and I found what was wrong. It was
my fault.
I was drawing everything using my own putpixel() routine. I just didn’t
want to copy the one included with the docs, mainly because I like to do
as many as possible on my own I think it’s better for learning.
However I’ve made a simple mistake. My function was computing an address
of a pixel in the following way:
void putpixel( SDL_Surface scr, int x, int y, int color )
{
( (Uint8) scr->pixels )[ ( y << 8 ) + ( y << 6 ) + x ] = color;
}
(I know: it’s not the most human-friendly coding style and I shouldn’t
use all these shift operators and magic numbers, but hey! I was only
playing. ;)) Finally I found that (in fullscreen mode) scr->pitch was
not 320 but 512. Previously I tried to draw some pixels beyond the
excpected 320*240 bytes, but I forgot that I made putpixel() to check
both x and y parameters and don’t let me do anything unsafe Now
everything works perfectly, so thanks everybody for your help. Oh, BTW,
why are there 512 intead of 320 bytes per line? Is this some kind of
optimisation? I think this way there should be slightly less time needed
to compute pixel addresses. Is this all?
It’s a hardware limitation of the video card. That’s what the pitch is
here for
Basically, a video card almost always works on aligned quantities (or
sometimes masks the lower bits). This ensures memory access is efficient
and requires less wiring inside the card (because it can ignore the
lower bits when computing addresses). This also saves some bits in the
command packets. The radeon for example uses these bits to store other
parameters.
). Try fiddling with your monitor controls to stretch the
I think it’s better for learning.