Small surface question

Is it necessary that I Free and re-Create my various (SW_SURFACE) surfaces
if I change video mode? My program seems to work without this step, but the
docs aren’t explicit and I can’t be sure this isn’t just a freak of the
particular platform I’m developing on . . .

-Thomas

Is it necessary that I Free and re-Create my various (SW_SURFACE) surfaces
if I change video mode? My program seems to work without this step, but the
docs aren’t explicit and I can’t be sure this isn’t just a freak of the
particular platform I’m developing on . . .

SWSURFACE surfaces don’t need to be recreated, HWSURFACE surfaces do.
Actually you should explicitly free them before setting a new video mode.
SDL 1.3 will internally track hardware surfaces and free them automatically.

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

I must have missed this elsewhere… (if it was announced elsewhere)…

One word (said in Stimpy’s voice): “Joy!”

When this happens, if we still are freeing our surfaces, will that cause any
troubles (in other words, will I still be able to compile my SDL1.2 and
earilier apps under 1.3 without headache ;-)?

(Perhaps a bit early to ask… but I am very stoked about this ;-)On Sun, 08 Apr 2001, you wrote:

SDL 1.3 will internally track hardware surfaces and free them automatically.

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


Sam “Criswell” Hart <@Sam_Hart> AIM, Yahoo!:
Homepage: < http://www.geekcomix.com/snh/ >
PGP Info: < http://www.geekcomix.com/snh/contact/ >
Advogato: < http://advogato.org/person/criswell/ >

When this happens, if we still are freeing our surfaces, will that cause any
troubles (in other words, will I still be able to compile my SDL1.2 and
earilier apps under 1.3 without headache ;-)?

we haven’t discussed this seriously but it looks more and more like
it’s going to be a serious API cleanup, so don’t count on being able to
compile things right away. This is a bit far in the future but we can
do some things to make it less painful:

  • avoid silent changes - if a function changes semantics, change its
    name and/or parameters
  • provide a migration guide for translating to the new api
    (if you get this error/warning, do this…)
  • maybe have a small backward-compatibility lib

this probably means that it will be called 2.0 rather than 1.3 :slight_smile:
(we’ll maintain 1.2 as a stable release for a good time in the
future though)

This is a bit far in the future but we can
do some things to make it less painful:

  • avoid silent changes - if a function changes semantics, change its
    name and/or parameters
  • provide a migration guide for translating to the new api
    (if you get this error/warning, do this…)
  • maybe have a small backward-compatibility lib
  • assign an other name to the windows DLL

…otherwise, an old 1.2 app will be spoiled by installing
a new 1.4/2.0 app and its DLL(s), right?

Ciao,
Eike