spazz at ulink.net
Thu Jan 28 11:09:29 PST 1999
> > 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. :)
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. :)
> 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. :)
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
spazz at ulink.net
More information about the SDL