Huge stack of questions

SDL Development
1

7.I have got a hardware surface by passing the SDL_HWSURFACE flag(& checked to make sure this flag is set).
Then SDL_DisplayFormat() when used on any surface will AUTOMATICALLY put that surface in video memory ?
If the SDL_HWSURFACE is set for any surface then its GURANTEED to exist in video memory ? & not in s/w(main) memory?

6.if i ask choose the “Maximize Speed” optimization in projects>>settings(/O2 cmd line switch) then SDL hangs if i choose GO(F5) ,but works fine with ctrl+F5 in VC++6.0.

5.For some of my sprites i need to examine the pixels before putting them into video buffer. So i cant use SDL blitting functions & must work with pixel data directly. So is putting them in main memory faster than in video memory as if in main memory then the pixels need not be called up from video memory in the reverse direction than the AGP bus is meant for ?

4.With reference to above is there any way of setting up a PALLETTE in h/w memory so my surfaces also exist in h/w memory but store pallette INDICES there to reduce space consumed in scarce h/w memory(just like 8 bit surfaces)?

3.Does memcpy() copy correctly & fast from main memory–>video memory or from video memory -->video memory ? Are there any functions available for carrying out faster pixel movement in video memory ? How does memcpy() distinguish between a video & main memory pointers?

2.If i do not use SDL functions for blitting (instead use memcpy)then i guess i also by pass ALL video card features like RLE(Run Length Encodong?) & hardware blits/color fills ? Any way to still take advantage of this using SDL in a h/w independent way?

1.Is there any way to find out how much of FREE video memory remains?

0.The pixels member in SDL_Surface remains NULL till surface locked …but this correct behaviour is shown only for hardware surfaces?Why not for s/w too?

Abhijit---------------------------------
How low will we go? Check out Yahoo! Messenger?s low PC-to-Phone call rates.

2

Abhijit Nandy wrote:

7.I have got a hardware surface by passing the SDL_HWSURFACE
flag(& checked to make sure this flag is set).
Then SDL_DisplayFormat() when used on any surface will
AUTOMATICALLY put that surface in video memory ?

You only get video ram if you allocate your surface using
SDL_CreateSurfaceRGB() or so using this flag. Setting it in the
structure afterward is a) wrong and b) wont do anything.

If the SDL_HWSURFACE is set for any surface then its GURANTEED
to exist in video memory ? & not in s/w(main) memory?

Yes (see above). If there isn’t enough video ram to do it, or theres no
hardware video ram support on the target, the allocation will fail and
you then retry with SDL_SWSURFACE.

6.if i ask choose the “Maximize Speed” optimization in
projects>>settings(/O2 cmd line switch) then SDL hangs
if i choose GO(F5) ,but works fine with ctrl+F5 in VC++6.0.

What do you mean by SDL hangs ? What do you build with the /O2 setting,
SDL ? Your app ?

5.For some of my sprites i need to examine the pixels before putting
them into video buffer. So i cant use SDL blitting functions & must
work with pixel data directly. So is putting them in main memory faster
than in video memory as if in main memory then the pixels need not be
called up from video memory in the reverse direction than the AGP bus
is meant for ?

If you are doing a custom blitter of any kind, use system ram or you
will get a big slowdown as reads over the AGP bus have a heavy penalty.

4.With reference to above is there any way of setting up a PALLETTE
in h/w memory so my surfaces also exist in h/w memory but store
pallette INDICES there to reduce space consumed in scarce h/w
memory(just like 8 bit surfaces)?

Not quite sure what you mean here.

3.Does memcpy() copy correctly & fast from main memory–>video
memory or from video memory -->video memory ?

From system->video ram yes. From video->video it will copy correctly
but will be slow due to having to read over AGP. To do this you are
better doing a blit.

Are there any functions available for carrying out faster pixel movement
in video memory ?

Yes, SDL_BlitSurface(), which on Windows and the DirectX renderer, will
do a hardware blit provided the source and destination surface formats
are the same.

How does memcpy() distinguish between a video & main memory pointers?

It doesn’t, ram is ram as far as it’s concerned. Video ram is mapped
into the processor address space the same way as any other kind of ram is.

2.If i do not use SDL functions for blitting (instead use memcpy)then
i guess i also by pass ALL video card features like RLE(Run Length
Encodong?) & hardware blits/color fills ? Any way to still take
advantage of this using SDL in a h/w independent way?

RLE isn’t a hardware feature that I know of. The only way to get
hardware accelerated blits is to use the SDL_BlitSurface() function.

1.Is there any way to find out how much of FREE video memory remains?

Not in SDL 1.2.

0.The pixels member in SDL_Surface remains NULL till surface
locked …but this correct behaviour is shown only for hardware
surfaces?Why not for s/w too?

Because for video ram, the section of ram must be mapped into the
processes address space (in DirectX this is called locking), and then
unmapped again so that the hardware can use it. For system ram based
surfaces this is unneccesary, although locking and unlocking the
surfaces will still work.

Pete.