Hello !
Is it already possible to have
both SDL-1.2 and SDL-1.3 sitting in
/usr/local ?
If not is this planned ?
When FLTK went to FLTK2
there was also the discussion to make it possible
or not. Nearly all the developers wanted to be able
to do this.
CU
Is it already possible to have
both SDL-1.2 and SDL-1.3 sitting in
/usr/local ?
Not yet…
If not is this planned ?
Yes. I’m leaning towards calling SDL 1.3 “SDL2”, thoughts?
-Sam Lantinga, Senior Software Engineer, Blizzard EntertainmentHello !
Yes. I’m leaning towards calling SDL 1.3 “SDL2”, thoughts?
For me this would be really good.
Then the developer can choose if he
wants to use sdl-config for SDL-1.2 or sdl2-config
for SDL-1.3. FLTK2 uses this for some time now and
the users and developers have been happy with it this way.
CU
Yes. I’m leaning towards calling SDL 1.3 “SDL2”, thoughts?
I think it makes sense to:
So the first SDL2 release would be:
2.0.0
Then the first bug fix:
2.0.1
Then the first binary incompatible change:
2.1.0
And so on and so on.
Isn’t it done something like this at the moment? Or are the numbers
arbitrary?
MC
Hello !
I think it makes sense to:
- Increment major version numbers when source incompatible.
- Increment minor version numbers when binary incompatible.
- Increment release numbers when fixing bugs.
Yeah, but more needs to be done than only this.
include/SDL needs to be changed to include/SDL2
sdl-config to sdl2-config and so on.
CU
Is it already possible to have
both SDL-1.2 and SDL-1.3 sitting in
/usr/local ?Not yet…
If not is this planned ?
Yes. I’m leaning towards calling SDL 1.3 “SDL2”, thoughts?
Sounds like a good idea to me. There are significant enough changes (multiple
windows, APIs, etc) to justify calling it SDL2.
JeffOn Wednesday 26 July 2006 16:54 pm, Sam Lantinga wrote:
This may not be the place to ask this but people on this list are more
apt to understand the SDL_Surface structure than other forums. This is
probably more of a C/C++ behavior question but someone familiar with the
structures involved might give me a quicker answer. Please feel free to
contact me off-list if necessary.
The problem popped us as logos I’d been blitting to my screen surface
quit showing up. A debug session showed that the rectangles I was using
to tell it what portion of the screen to draw them were getting set to
zero, an indication that SDL_BlitSurface was having a problem with it.
This meant something else was messing up other factors. Here’s my
scenario and here’s what I found…
SCR_Object is a class that has as a member SDL_Surface *image and
SDL_Rect rect. Everything’s fine up to a point. I wrote a function
outside the class to position another surface against the first one and
centered on either top, bottom, left or right. It looks like this:
void SCR_SetDishPos (SCR_Object *dish, SCR_Object companion, Uint8
side)
{
SDL_Rect ctemp = companion.GetRect();
SDL_Rect dtemp = dish->GetRect();
switch (side) {
case right:
ctemp.x += ctemp.w;
ctemp.y += (ctemp.h - dtemp.h)/2;
break;
case top:
ctemp.x += (ctemp.w - dtemp.w)/2;
ctemp.y -= dtemp.h;
break;
case left:
ctemp.x -= dtemp.w;
ctemp.y += (ctemp.h - dtemp.h)/2;
break;
case bottom:
ctemp.x += (ctemp.w - dtemp.w)/2;
ctemp.y += ctemp.h;
break;
default:
break;
}
ctemp.h = dtemp.h;
ctemp.w = dtemp.w;
dish->SetRect(ctemp);
}
And a call to the function looks like this:
SCR_SetDishPos (&CVCDish, CVC, right);
The function calculates and (properly) sets the rectangle for CVCDish
to that it nests against the right side of the logo called CVC.
Everything about CVC is fine in the debug session up to the end of the
function. But when I return from the function (which returns nothing)
EVERYTHING that CVC.image points to is set to 0xFEEE. Every pair of
bytes pointed to by image is FEEE.
There’s nothing in the function or the call to the function that
references image. This happens with any “companion” object I pass to
the function. I can see that even a copy of the object can allow a
function to access the address of the image surface but there’s nothing
in the code that even remotely does that. I’ve checked the value of
image for each object and it isn’t that image, as a pointer, is getting
pointed elsewhere.
I can certainly rewrite the code in at least two other ways but I’d
rather try to nail this.
Help?
Lilith
Lilith, if you haven’t tested this yet, in your default case for your switch
I’d make it log to a file that it hit the default just to see if it’s ever
getting an invalid value for the “side” parameter.> ----- Original Message -----
From: sdl-bounces+atrix2=cox.net@libsdl.org
[mailto:sdl-bounces+atrix2=cox.net at libsdl.org] On Behalf Of Lilith Calbridge
Sent: Wednesday, July 26, 2006 8:48 PM
To: sdl at libsdl.org
Subject: [SDL] Surface getting mungedThis may not be the place to ask this but people on this list are more
apt to understand the SDL_Surface structure than other forums. This is
probably more of a C/C++ behavior question but someone familiar with the
structures involved might give me a quicker answer. Please feel free to
contact me off-list if necessary.The problem popped us as logos I’d been blitting to my screen surface
quit showing up. A debug session showed that the rectangles I was using
to tell it what portion of the screen to draw them were getting set to
zero, an indication that SDL_BlitSurface was having a problem with it.
This meant something else was messing up other factors. Here’s my
scenario and here’s what I found…SCR_Object is a class that has as a member SDL_Surface *image and
SDL_Rect rect. Everything’s fine up to a point. I wrote a function
outside the class to position another surface against the first one and
centered on either top, bottom, left or right. It looks like this:void SCR_SetDishPos (SCR_Object *dish, SCR_Object companion, Uint8
side)
{
SDL_Rect ctemp = companion.GetRect();
SDL_Rect dtemp = dish->GetRect();switch (side) {
case right:
ctemp.x += ctemp.w;
ctemp.y += (ctemp.h - dtemp.h)/2;
break;
case top:
ctemp.x += (ctemp.w - dtemp.w)/2;
ctemp.y -= dtemp.h;
break;
case left:
ctemp.x -= dtemp.w;
ctemp.y += (ctemp.h - dtemp.h)/2;
break;
case bottom:
ctemp.x += (ctemp.w - dtemp.w)/2;
ctemp.y += ctemp.h;
break;
default:
break;
}
ctemp.h = dtemp.h;
ctemp.w = dtemp.w;dish->SetRect(ctemp);
}And a call to the function looks like this:
SCR_SetDishPos (&CVCDish, CVC, right);
The function calculates and (properly) sets the rectangle for CVCDish
to that it nests against the right side of the logo called CVC.
Everything about CVC is fine in the debug session up to the end of the
function. But when I return from the function (which returns nothing)
EVERYTHING that CVC.image points to is set to 0xFEEE. Every pair of
bytes pointed to by image is FEEE.There’s nothing in the function or the call to the function that
references image. This happens with any “companion” object I pass to
the function. I can see that even a copy of the object can allow a
function to access the address of the image surface but there’s nothing
in the code that even remotely does that. I’ve checked the value of
image for each object and it isn’t that image, as a pointer, is getting
pointed elsewhere.I can certainly rewrite the code in at least two other ways but I’d
rather try to nail this.Help?
Lilith
SDL mailing list
SDL at libsdl.org
http://www.libsdl.org/mailman/listinfo/sdl
Just ran a test and it never hits the default case.
Lilith
Lilith, if you haven’t tested this yet, in your default case for your
switch
I’d make it log to a file that it hit the default just to see if it’s
ever
getting an invalid value for the “side” parameter.[mailto:sdl-bounces+atrix2=cox.net at libsdl.org] On Behalf Of Lilith
Calbridge>>> On 7/26/2006 at 10:54 PM, in message <001e01c6b130$4f3b7100$6501a8c0 at ALAN>, Atrix2 at cox.net wrote:
-----Original Message-----
From: sdl-bounces+atrix2=cox.net at libsdl.org
Sent: Wednesday, July 26, 2006 8:48 PM
To: sdl at libsdl.org
Subject: [SDL] Surface getting mungedThis may not be the place to ask this but people on this list are
more
apt to understand the SDL_Surface structure than other forums. This
is
probably more of a C/C++ behavior question but someone familiar with
the
structures involved might give me a quicker answer. Please feel free
to
contact me off-list if necessary.The problem popped us as logos I’d been blitting to my screen
surface
quit showing up. A debug session showed that the rectangles I was
using
to tell it what portion of the screen to draw them were getting set
to
zero, an indication that SDL_BlitSurface was having a problem with
it.
This meant something else was messing up other factors. Here’s my
scenario and here’s what I found…SCR_Object is a class that has as a member SDL_Surface *image and
SDL_Rect rect. Everything’s fine up to a point. I wrote a function
outside the class to position another surface against the first one
and
centered on either top, bottom, left or right. It looks like this:void SCR_SetDishPos (SCR_Object *dish, SCR_Object companion, Uint8
side)
{
SDL_Rect ctemp = companion.GetRect();
SDL_Rect dtemp = dish->GetRect();switch (side) {
case right:
ctemp.x += ctemp.w;
ctemp.y += (ctemp.h - dtemp.h)/2;
break;
case top:
ctemp.x += (ctemp.w - dtemp.w)/2;
ctemp.y -= dtemp.h;
break;
case left:
ctemp.x -= dtemp.w;
ctemp.y += (ctemp.h - dtemp.h)/2;
break;
case bottom:
ctemp.x += (ctemp.w - dtemp.w)/2;
ctemp.y += ctemp.h;
break;
default:
break;
}
ctemp.h = dtemp.h;
ctemp.w = dtemp.w;dish->SetRect(ctemp);
}And a call to the function looks like this:
SCR_SetDishPos (&CVCDish, CVC, right);
The function calculates and (properly) sets the rectangle for
CVCDish
to that it nests against the right side of the logo called CVC.
Everything about CVC is fine in the debug session up to the end of
the
function. But when I return from the function (which returns
nothing)
EVERYTHING that CVC.image points to is set to 0xFEEE. Every pair of
bytes pointed to by image is FEEE.There’s nothing in the function or the call to the function that
references image. This happens with any “companion” object I pass
to
the function. I can see that even a copy of the object can allow a
function to access the address of the image surface but there’s
nothing
in the code that even remotely does that. I’ve checked the value of
image for each object and it isn’t that image, as a pointer, is
getting
pointed elsewhere.I can certainly rewrite the code in at least two other ways but I’d
rather try to nail this.Help?
Lilith
SDL mailing list
SDL at libsdl.org
http://www.libsdl.org/mailman/listinfo/sdl
SDL mailing list
SDL at libsdl.org
http://www.libsdl.org/mailman/listinfo/sdl
Is it already possible to have
both SDL-1.2 and SDL-1.3 sitting in
/usr/local ?Not yet…
If not is this planned ?
Yes. I’m leaning towards calling SDL 1.3 “SDL2”, thoughts?
I have a few different thoughts, none of them complete…
First, is this really SDL 1.3 or is it 2.0? I ask because FreeBSD
ports already places their stuff in /usr/local/include/SDL11 and you
have to link against libSDL-1.1 (I haven’t seen a versionless libSDL
symlink. I haven’t seen an sdl-config there either, not that I ever
use it.) I don’t know the logic behind “11” considering we are are the
1.2 branch, but if this is going to be 1.3, it seems to make sense to
do a SDL13.
A completely different thought on the total opposite end deals with
Mac OS X frameworks because they are a bit different. The framework
name has some fallout on both how you #include and how you link.
The most famous case of this is the OpenGL.framework which breaks
everybody’s code because the #include path uses the framework name. So
#include <GL/gl.h> breaks and you have to use #include <OpenGL/gl.h>
SDL has already mitigated this point by recommending #include "SDL.h"
be used instead of #include <SDL/SDL.h> and setting the proper search
paths. But this may be something to think about if this recommendation
is destined to change.
The link linen changes too. So if we name it SDL2.framework, the link
line must be -framework SDL2.
But there is another wildcard in OS X frameworks as well. Frameworks
have the notion of versioning. In principle, you can bundle multiple
versions of a library into one unified framework. So both SDL 1.2 and
1.3 can be placed together in a single all encompassing framework
called SDL.framework, each with its own headers and dynamic libraries.
In practice however, I’ve heard its not as useful as it could be. It
turns out the versioning is focused to allow legacy apps built under
the old version to continue to run, but there is minimal support for
new compiling and linking against older versions of headers and
libraries in the framework and usually involves manually specifying
include paths and link paths or changing the symlinks around. (I think
Bob Ippolito has talked about this somewhere.) Despite thisI am
somewhat drawn to elegance of having a unified package that can handle
multiple versions.
So I’m wondering what path we should take for the OS X framework.
Thanks,
Eric> From: Sam Lantinga
Hello !
First, is this really SDL 1.3 or is it 2.0?
It is really SDL 1.3. There was a plan and ideas
about 2.0, somewhere on the net you can find SDL_2.0.txt about it.
But it would be much more work than SDL 1.3 already means.
So I’m wondering what path we should take for the OS X framework.
Personally i have no idea about how to handle
the naming scheme of Frameworks or how to
put them together the best way.
I use the commandline way on most OSes, even Win32.
For me it would be okay to cheat so that SDL 1.3 becomes SDL 2.0
if you look at sdl2-config or include/SDL2 or whatever.
CU
Stupidity. FBSD refuses to fix their broken SDL installation (sdl-config is
named something like sdl11-config, and theres a slew of other sdl -> sdl11
changes).
I ran into this when I was porting ZSNES to linux and bsd, and I reported the
bug. Comes to find out, everyone has reported the bug, and they just refuse
to fix it.On Friday 28 July 2006 02:38, E. Wing wrote:
I haven’t seen an sdl-config there either, not that I ever
use it.) I don’t know the logic behind “11” considering we are are the
1.2 branch,
–
Patrick McFarland || www.AdTerrasPerAspera.com
"Computer games don’t affect kids; I mean if Pac-Man affected us as kids,
we’d all be running around in darkened rooms, munching magic pills and
listening to repetitive electronic music." – Kristian Wilson, Nintendo,
Inc, 1989