I updated and wanted to compile SDL, but it does not work.
The reason is the new pre-build step.
Currently it says:
"if exist $(SolutionDir)\..\include\SDL_config.h goto SDLCONFIGOKAY
echo Copying SDL_config_win32.h to SDL_config.h...
copy $(SolutionDir)\..\include\SDL_config_win32.h $(SolutionDir)\..\include\SDL_config.h
:SDLCONFIGOKAY
if exist $(SolutionDir)\..\include\SDL_revision.h goto SDLREVISIONOKAY
echo Creating stub SDL_revision.h file...
echo #define SDL_REVISION 0 >$(SolutionDir)\..\include\SDL_revision.h
:SDLREVISIONOKAY"
So ... the problem with this lines is, that they lookup the SolutionDir...
I think it should use the ProjectDir here!
I - for example - want to use SDL within my engine...
So my engine is the solutionDir...not SDL...SDL is just a sub-project.
I think you should change this, shouldn't you?!
Regards,
Stefan
--HG--
extra : convert_revision : svn%3Ac70aab31-4412-0410-b14c-859654838e24/trunk%404052
we actually have to include the core autoconf C compiler macro suite.
--HG--
extra : convert_revision : svn%3Ac70aab31-4412-0410-b14c-859654838e24/trunk%404048
If this causes problems on any compiler, please report a bug to
http://bugzilla.libsdl.org/
and include the platform and version of compiler you're using.
--HG--
extra : convert_revision : svn%3Ac70aab31-4412-0410-b14c-859654838e24/trunk%404021
Added support for --disable-dependency-tracking to configure.in
--HG--
extra : convert_revision : svn%3Ac70aab31-4412-0410-b14c-859654838e24/trunk%403992
http://wiki.libsdl.org/
Please contact Lauren MacDonell laleh_aziz cox.net who is coordinating it.
--HG--
extra : convert_revision : svn%3Ac70aab31-4412-0410-b14c-859654838e24/trunk%403986
Also noticed the SDL.h header in 1.3 didn't have the /** for the methods while testing. Attached is a quick fix patch.
--HG--
extra : convert_revision : svn%3Ac70aab31-4412-0410-b14c-859654838e24/trunk%403978
Sorry, here's another small fix.
I changed two options in the Doxyfiles in the XcodeDocSet directories which should allow at least a brief description to be seen in Quick Help.
--HG--
extra : convert_revision : svn%3Ac70aab31-4412-0410-b14c-859654838e24/trunk%403977
Ken Bull 2009-10-04 09:51:30 PDT
2009/10/4 E. Wing <ewmailing@gmail.com>:
> Hi Kenneth,
> I noticed that SDL_SetColorKey and SDL_GetColorKey start with
> /*
> instead of
> /**
> in SDL_Surface.h in SDL 1.3.
>
> I haven't scrutinized the headers and I don't know if you had an
> automated process to add these, but I thought I would let you know in
> case there might be others that have the same problem.
>
> Thanks,
> Eric
>
The attached patch corrects this and other documentation errors in
SDL_surface.h
--HG--
extra : convert_revision : svn%3Ac70aab31-4412-0410-b14c-859654838e24/trunk%403966
Mike Frysinger 2007-12-10 16:47:36 PST
it's much easier to manage .pc files for cross-compiling setups than it is for
random *-config scripts ... the cross-compiled pkg-config files can all be
easily/tightly controlled and separate from the host pkg-config files. the
*-config files however are to be found in $PATH and can easily pick the wrong
one.
can we get the sdl.m4 macro updated so that it checks for libsdl.pc first via
the standard PKG_CHECK_MODULES() m4 macro, and if that fails, fall back to the
normal sdl-config voodoo.
--HG--
extra : convert_revision : svn%3Ac70aab31-4412-0410-b14c-859654838e24/trunk%403965
Included is the fix for the missing SDL_revision.h in the framework.
Also, I include the project template fixes for the prefix header files. But since this is in SVN directly, you must rename the files named
SDLApp_Prefix.pch
to
___PROJECTNAMEASIDENTIFIER____Prefix.pch
in the TemplatesForXcodeSnowLeopard and TemplatesForXcodeLeopard directories. (Do not rename the Tiger ones.)
--HG--
rename : Xcode/TemplatesForXcodeLeopard/SDL Application/SDLApp_Prefix.pch => Xcode/TemplatesForXcodeLeopard/SDL Application/___PROJECTNAMEASIDENTIFIER____Prefix.pch
rename : Xcode/TemplatesForXcodeLeopard/SDL Cocoa Application/SDLApp_Prefix.pch => Xcode/TemplatesForXcodeLeopard/SDL Cocoa Application/___PROJECTNAMEASIDENTIFIER____Prefix.pch
rename : Xcode/TemplatesForXcodeLeopard/SDL OpenGL Application/SDLApp_Prefix.pch => Xcode/TemplatesForXcodeLeopard/SDL OpenGL Application/___PROJECTNAMEASIDENTIFIER____Prefix.pch
rename : Xcode/TemplatesForXcodeSnowLeopard/SDL Application/SDLApp_Prefix.pch => Xcode/TemplatesForXcodeSnowLeopard/SDL Application/___PROJECTNAMEASIDENTIFIER____Prefix.pch
rename : Xcode/TemplatesForXcodeSnowLeopard/SDL Cocoa Application/SDLApp_Prefix.pch => Xcode/TemplatesForXcodeSnowLeopard/SDL Cocoa Application/___PROJECTNAMEASIDENTIFIER____Prefix.pch
rename : Xcode/TemplatesForXcodeSnowLeopard/SDL OpenGL Application/SDLApp_Prefix.pch => Xcode/TemplatesForXcodeSnowLeopard/SDL OpenGL Application/___PROJECTNAMEASIDENTIFIER____Prefix.pch
extra : convert_revision : svn%3Ac70aab31-4412-0410-b14c-859654838e24/trunk%403963
Daniele Forghieri 2009-09-30 15:48:24 PDT
Some tests doesn't use the correct include statement (and there are some
missing declaration) and some test use C++ variable after statement, preventing
compile wicth Open Watcom
The patch attached fixes this
--HG--
extra : convert_revision : svn%3Ac70aab31-4412-0410-b14c-859654838e24/trunk%403962
Daniele Forghieri 2009-09-30 15:40:53 PDT
To compile the source in libm the variable huge must be renamed, I choose
huge_val
The patch attached change it so it compiles
--HG--
extra : convert_revision : svn%3Ac70aab31-4412-0410-b14c-859654838e24/trunk%403961
will end up getting locked and never unlocked and sound will never play.
Added a FIXME for Ryan to look at, too. :)
--HG--
extra : convert_revision : svn%3Ac70aab31-4412-0410-b14c-859654838e24/trunk%403960
Since current DirectFB implementation is incomplete for YUV surfaces (actually causes segmentation faults when trying Lock and use YUV planar textures) I decided to fix it a bit.
Here's a patch that should make DirectFB properly support YUV both packed and planar (3 planes).
(1) Removed SDL_BYTESPERPIXEL at all in favor of DFB_BYTES_PER_PIXEL(SDLToDFBPixelFormat(fmt)) which does return always proper BPP for YUVs too, coz SDL_BYTESPERPIXEL returns incorrect values for FOURCCs
(2) Fixed data->pixels allocation for planar YUVs in CreateTexture, it should allocate 150% more space
(3) Copy other planes for planar YUVs in UpdateTexture
(4) Moved checking if format is supported at all with DirectFB on CreateTexture at the beginning of the code
Waiting for comments,
--
Adam Strzelecki | nanoant.com
--HG--
extra : convert_revision : svn%3Ac70aab31-4412-0410-b14c-859654838e24/trunk%403959
