Two questions

Uh…dear Sammy & dude s/ttes:

I have a question concerning SDL’s keyboard event system. It seems like
SDL_GetKeyState doesn’t work unless the event queue is empty…is this
true?

My other question is: is there a way to directly access the framebuffer
memory? I’m talking about going beyond the SDL_UpdateRect(Surface, x, x,
x, x) memory. I want to access the MIT mem itself. Is this possible?

ok make that three

Plus: under DirectX for Win32 when I draw pixels directly to
screen…they don’t look right. I’m using loser-ass 16 bits. (Don’t
worry though, I’ll see the light soon 32 bit color is just coming up my
alley right now) The color works great under X, but for Win32 it’s
screwed up. I can elaborate on this. But I noticed that in SDL’s blit
code there is a reference to a info->table structure. Then in the blit
code itself…there is like a surface->map? or info->map? Ok…just ask
for elaboration. See, I think the problem is being encountered because I
am taking a step beyond SDL and it’s “simplicity” he he, no offense sam
dude…but I needz da speed…my own “more versatile” framebuffer code
is needed. Is this realistic? Does I need to write my own graphix
subsystem…(I don’t want to).

ok ok…only one more, for you intellectual most excellent dudes:

Anyone here know the fundamentals to sprite rotation. I don’t have the
math skills, but don’t know where to start. I am currently in Algebra 2.

Thanx,

Paul Lowe
spazz at ulink.net

My other question is: is there a way to directly access the framebuffer
memory? I’m talking about going beyond the SDL_UpdateRect(Surface, x, x,
x, x) memory. I want to access the MIT mem itself. Is this possible?

Yes. That’s the whole idea.
OK, under X11, if you write to screen->pixels directly, you are writing to
the MIT shared memory. This is still offscreen memory however, and when
you call SDL_UpdateRect(), the X server copies it to the video RAM.
Using the DGA fullscreen extensions, it is possible to write directly to
the video memory, again by writing to screen->pixels.
If the screen surface has SDL_HWSURFACE set in the flags, then when you
write to screen->pixels, you are writing to the video memory. Note that
this is often slow and sometimes it’s hard to prevent flicker when you
do this.

When I don’t have SDL_HWSURFACE setup, what does SDL_UpdateRect actually do? If
screen->pixels is the shared mem, then could I write my own SDL_UpdateRect,
the reason I am asking this question is that I need a custom version of
UpdateRect to suit my needs (can’t explain now). Does updaterect copy memory to
anywhere? if so…where? cuz thatz da stuff I’m look’in for.

Plus: under DirectX for Win32 when I draw pixels directly to
screen…they don’t look right.

Did you check the pixel format? It’s probably RGB 555 (15 bits) rather
than RGB 565.

I didn’t check that! Thanks a lot! It’s probably is RGB555.

I’m using loser-ass 16 bits.

Loser-ass 16 bits is almost twice as fast to blit as 32 bits. :slight_smile:

Are you sure about this? I like the color accuracy. AGP rox ma bong! 32 bits is
cool man…that’s what fast-ass computers are for. (note, the aforementioned
statement may seem highly irrational / illogical / stupid to some people)

Besides it only takes me 13MB of memory to create a fade lookup table in 32
bpp. Oh BTW I really made some slick 16 bit fading code…oh man it’s sweet.

SDL is highly tuned, but if you can do the job better for your application,
by all means, go for it. SDL is designed to get out of your way when you
want speed. :slight_smile:

First: You need to let SDL pick the best pixel format for you.
Second: Your blit code needs to be able to convert to the available
graphics display. If your blit code only supports a few
modes, then you might have SDL set the best mode first, then
call SDL_SetVideoMode again with a mode you support. SDL will
convert for you, but again – let SDL pick the best mode first,

  1. let it pick the mode first
  2. then reset video mode
  3. conversion rox ma bong!
    so no conversion needs to be done.  Many people do run their
    desktops in 16-bit color, because it is the best balance of
    color and speed.

Third: Be sure and lock the SDL surface when you need to – use the
SDL_MUSTLOCK() macro. To get the fastest possible speed, you
may need to lock the video memory into your address space.

But if my program doesn’t really need direct HW access should I still call that
macro? I’m developing a gui toolkit, does that need to be fast?, and it’s 32
bit…yes…32 bit…sammy should the mouse get updated with the framebuffer?

Note that writing to video memory is generally a bad idea with new
video cards because it defeats bus-mastering.

OH BTW. At my job I am a waiter. There is a special task some people perform
when the place is very busy. It’s called “bussing”. The busser is very well
liked because he goes around and helps other waiters / waitresses “bus” (remove
plates / glasses that are dirty from their table) their tables. There is this
really weirdo dude there too, and he goes around saying “obey your master, the
bus master!” he he. Ok it’s not funny.

The next generation of DGA will be much improved, including changing the
color depth on the fly. :slight_smile:

We’ll see. However I wrote this poem about X fer yas:

Roses are red
Violets are black
X would look better
With a knife in it’s back

Comments? Compliments? MSG? -> spazz at ulink.net

Paul Lowe
spazz at ulink.net

My other question is: is there a way to directly access the framebuffer
memory? I’m talking about going beyond the SDL_UpdateRect(Surface, x, x,
x, x) memory. I want to access the MIT mem itself. Is this possible?

Doesn’t bypassing SDL kind of void the point of using SDL?
But regardless, you should be able to manipulate SDL’s internal structures
directly, just bypassing the functions. I haven’t looked at SDL source
yet, so I don’t know how feasible this is. I would imagine it is possible,
you’d just have to make the code conditional on the environment (ie, check
to make sure you’re using shared mem on X). Maybe some locking stuff, too.
But I have no doubt that it’s possible write a bypass; just a question of
how hard.

See, I think the problem is being encountered because I
am taking a step beyond SDL and it’s “simplicity” he he, no offense sam
dude…but I needz da speed…my own “more versatile” framebuffer code
is needed. Is this realistic? Does I need to write my own graphix
subsystem…(I don’t want to).

SDL just interfaces other graphics subsystems. If you want to bypass SDL
entirely, why use it? Just code straight to DirectX, GGI, DGA, or
whatever.

Anyone here know the fundamentals to sprite rotation. I don’t have the
math skills, but don’t know where to start. I am currently in Algebra 2.

Matrix math. You probably need a trig textbook.
Also, if you have access to old copies of Dr Dobbs Journal, look for
columns by Michael Abrash. His X-Sharp library covers some 3D basics,
including bitmaps (which requires sprite rotation, translation, and
scaling).

Justin Bradford
@Justin_BradfordOn Wed, 27 Jan 1999, Paul Lowe wrote:

Anyone here know the fundamentals to sprite rotation. I don’t have the
math skills, but don’t know where to start. I am currently in Algebra 2.

Do a web search on this! It is well documented. But basically, you use
the fact that sin(x+y) = sin(x)cos(y) + cos(x)sin(y) (and similarly for
cos) to form a rotation matrix:

cos(a) sin(a)
-sin(a) cos(a)

which you then use to step through the source image while outputing the
pixels rasterscan fashion to the dest. As the matrix takes the same time
no matter what its form, you can scale, shear, rotate, reflect the image.
Going from here it is only a small thought step to full blown n-d
texturemapping on an m-surface :slight_smile:

njhOn Wed, 27 Jan 1999, Paul Lowe wrote:

Uh…dear Sammy & dude s/ttes:

I have a question concerning SDL’s keyboard event system. It seems like
SDL_GetKeyState doesn’t work unless the event queue is empty…is this
true?

Two things are happening here. One, the keyboard state is only updated
when you pump the event loop with either SDL_PollEvent() or SDL_WaitEvent().
Two, the keyboard state is updated immediately. The net effect is
SDL_GetKeyState() shows you the current keyboard state as of the most
recent call to the SDL event functions.

I’ll take a look at the code to see if it bypasses the raw event reading
when the queue has something in it. I don’t believe that it does.

My other question is: is there a way to directly access the framebuffer
memory? I’m talking about going beyond the SDL_UpdateRect(Surface, x, x,
x, x) memory. I want to access the MIT mem itself. Is this possible?

Yes. That’s the whole idea.
OK, under X11, if you write to screen->pixels directly, you are writing to
the MIT shared memory. This is still offscreen memory however, and when
you call SDL_UpdateRect(), the X server copies it to the video RAM.
Using the DGA fullscreen extensions, it is possible to write directly to
the video memory, again by writing to screen->pixels.
If the screen surface has SDL_HWSURFACE set in the flags, then when you
write to screen->pixels, you are writing to the video memory. Note that
this is often slow and sometimes it’s hard to prevent flicker when you
do this.

The testsprite test program in the 0.9.x release of SDL shows various
ways of blitting sprites and how to detect the hardware capabilities.

Plus: under DirectX for Win32 when I draw pixels directly to
screen…they don’t look right.

Did you check the pixel format? It’s probably RGB 555 (15 bits) rather
than RGB 565.

I’m using loser-ass 16 bits.

Loser-ass 16 bits is almost twice as fast to blit as 32 bits. :slight_smile:

But I noticed that in SDL’s blit
code there is a reference to a info->table structure. Then in the blit
code itself…there is like a surface->map? or info->map? Ok…just ask
for elaboration. See, I think the problem is being encountered because I
am taking a step beyond SDL and it’s “simplicity” he he, no offense sam
dude…but I needz da speed…my own “more versatile” framebuffer code
is needed. Is this realistic?

SDL is highly tuned, but if you can do the job better for your application,
by all means, go for it. SDL is designed to get out of your way when you
want speed. :slight_smile:

First: You need to let SDL pick the best pixel format for you.
Second: Your blit code needs to be able to convert to the available
graphics display. If your blit code only supports a few
modes, then you might have SDL set the best mode first, then
call SDL_SetVideoMode again with a mode you support. SDL will
convert for you, but again – let SDL pick the best mode first,
so no conversion needs to be done. Many people do run their
desktops in 16-bit color, because it is the best balance of
color and speed.
Third: Be sure and lock the SDL surface when you need to – use the
SDL_MUSTLOCK() macro. To get the fastest possible speed, you
may need to lock the video memory into your address space.

Note that writing to video memory is generally a bad idea with new
video cards because it defeats bus-mastering.

The next generation of DGA will be much improved, including changing the
color depth on the fly. :slight_smile:

See ya!
-Sam Lantinga (slouken at devolution.com)

Lead Programmer, Loki Entertainment Software–
Author of Simple DirectMedia Layer -
http://www.devolution.com/~slouken/SDL/

Anyone here know the fundamentals to sprite rotation. I don’t have the
math skills, but don’t know where to start. I am currently in Algebra 2.

Do a web search on this! It is well documented. But basically, you use
the fact that sin(x+y) = sin(x)cos(y) + cos(x)sin(y) (and similarly for
cos) to form a rotation matrix:

cos(a) sin(a)
-sin(a) cos(a)

which you then use to step through the source image while outputing the
pixels rasterscan fashion to the dest. As the matrix takes the same time
no matter what its form, you can scale, shear, rotate, reflect the image.
Going from here it is only a small thought step to full blown n-d
texturemapping on an m-surface :slight_smile:

he said Algebra 2 - in my high school, at least (bear with me, this was 6
years ago), you didn’t learn any significant trigonometry until after
Algebra 2… YMMV.

Dont’ assume that it’s simple. It’s simple after you’ve had calculus and
a college-level class in matrices and vectors (that was a kick ass class,
btw).On Fri, 29 Jan 1999, Nathan Hurst wrote:

On Wed, 27 Jan 1999, Paul Lowe wrote:


Scott M. Stone
Head of TurboLinux English / Systems Administrator
Pacific HiTech, Inc. (http://www.turbolinux.com)

he said Algebra 2 - in my high school, at least (bear with me, this was 6
years ago), you didn’t learn any significant trigonometry until after
Algebra 2… YMMV.

I have never heard of Algebra 2, but I assumed it was a course at uni…
Don’t assume that everyone comes from the US - colleges in .au are 'K12’
schools. :-o

Dont’ assume that it’s simple. It’s simple after you’ve had calculus and
a college-level class in matrices and vectors (that was a kick ass class,
btw).

Yep, well if paul needs more assitance in form I am more than happy to go
through it with him, however, it would be advisable to look up the info on
the web because there are well written articles on this sort of thing all
over the place.

njhOn Fri, 29 Jan 1999, Scott Stone wrote:

When I don’t have SDL_HWSURFACE setup, what does SDL_UpdateRect actually do? If
screen->pixels is the shared mem, then could I write my own SDL_UpdateRect,

If screen->pixels is the shared mem, then SDL_UpdateRect will call the Xlib
routine that tells the X server to copy the memory to the screen. If it’s not,
then SDL is doing conversion and uses an accelerated blit function to convert
the data to the real screen, and then calls the X update function.

Loser-ass 16 bits is almost twice as fast to blit as 32 bits. :slight_smile:

Are you sure about this? I like the color accuracy. AGP rox ma bong!

Yup. If color accuracy is more important than speed for you, cool.
Keep in mind that not everyone has a machine that rox ya bong. :slight_smile:

Besides it only takes me 13MB of memory to create a fade lookup table in 32
bpp. Oh BTW I really made some slick 16 bit fading code…oh man it’s sweet.

Wow. And I thought 16-bit lookup tables were stretching it. Heheheh.

  1. let it pick the mode first
  2. then reset video mode
    Only if the mode that was picked (the native mode) isn’t good for you.
  3. conversion rox ma bong!

But if my program doesn’t really need direct HW access should I still call that
macro? I’m developing a gui toolkit, does that need to be fast?, and it’s 32
bit…yes…32 bit…sammy should the mouse get updated with the framebuffer?

Yes, you should call the macro. GUIs don’t need to be so fast, and yes, the
mouse should be updated with the framebuffer. SDL tries to handle it
internally, but doesn’t always work properly (I’m still working on it)

Comments? Compliments? MSG? -> spazz at ulink.net

Don’t spazz d00d. :slight_smile:

See ya!
-Sam Lantinga (slouken at devolution.com)

Lead Programmer, Loki Entertainment Software–
Author of Simple DirectMedia Layer -
http://www.devolution.com/~slouken/SDL/

he said Algebra 2 - in my high school, at least (bear with me, this was 6
years ago), you didn’t learn any significant trigonometry until after
Algebra 2… YMMV.

I have never heard of Algebra 2, but I assumed it was a course at uni…
Don’t assume that everyone comes from the US - colleges in .au are 'K12’
schools. :-o

I took Algebra 2 in High School, in 10th grade… that’s what I was
thinking. (just to clarify :slight_smile: )On Sat, 30 Jan 1999, Nathan Hurst wrote:

On Fri, 29 Jan 1999, Scott Stone wrote:

Dont’ assume that it’s simple. It’s simple after you’ve had calculus and
a college-level class in matrices and vectors (that was a kick ass class,
btw).

Yep, well if paul needs more assitance in form I am more than happy to go
through it with him, however, it would be advisable to look up the info on
the web because there are well written articles on this sort of thing all
over the place.

njh


Scott M. Stone
Head of TurboLinux English / Systems Administrator
Pacific HiTech, Inc. (http://www.turbolinux.com)