attached is a working directfb driver diff which works with the current
changes. There are a number of changes around it as well, e.g.
configure.in.
The directfb renderdriver right now still depends on a some "includes"
from src/video/directfb. That's why it is not yet moved to the new
render folder.
when .cc files are used due to bad sed substitution on multiple passes:
$(objects)/SDL_BeApp.lo:
$(objects)/SDL_BeApp.lo: ./src/main/beos/SDL_BeApp.c
$(LIBTOOL) --mode=compile $(CC) $(CFLAGS) $(EXTRA_CFLAGS) -c $< -o $@c
$(LIBTOOL) --mode=compile $(CC) $(CFLAGS) $(EXTRA_CFLAGS) -c $< -o $@
Signed-off-by: François Revol
The configure script was breaking the substitutions into multiple fragments, breaking them across the substitution for the build rules. This of course totally hosed the process.
I switched to using a more modern usage of AC_OUTPUT and added a post-process step that appends the build rules to the Makefile.
I *think* the patch below works correctly: sdl-config gets the -march
flag and SDL builds fine. Perhaps there's a better way to get the
-march flag into both CFLAGS and SDL_FLAGS w/o dragging along more
cruft, but adding it to BASE_CFLAGS seemed the best bet to my eyes.
Changed the CAS return value to bool, so it's efficient with OSAtomicCompareAndSwap32Barrier()
Added an atomic test adapted from code by Michael Davidsaver
(1) SDL_atomic dummy version in SDL 1.3 is not used.
Because src/atomic/dummy/*.c are not used.
(2) Typo in src/joystick/bsd/SDL_sysjoystick.c.
Thanks,
IWATSUKI Hiroyuki
I made a video driver GAPI/RAW for WinCE (SDL-1.3).
RAW mode has a priority, and also, GAPI mode works with environment
"SDL_VIDEO_RENDERER=gapi" and for RAW mode "SDL_VIDEO_RENDERER=raw".
I checked the work on the screens of VGA, WVGA, QVGA, WQVGA, HVGA,
+ tested all modes with WindowsMobile Emulator.
Also, correctly draws the pointer position and the scale of the pointer
for VGA/WVGA modes,
correctly draws top left position for DM orientation screen, and
portrait/landscape/square geometry the screen also correct.
Also, I added a small fix for GDI fullscreen mode.
Patch for latest revision SDL-1.3 in an attachment.
Also added small path for mingw32ce build.
Ozkan Sezer 2010-02-06 12:31:06 PST
Hi:
Here are some small fixes for compiling SDL against mingw-w64.
(see http://mingw-w64.sourceforge.net/ . Despite the name, it
supports both win32 and win64.)
src/audio/windx5/directx.h and src/video/windx5/directx.h (both
SDL-1.2 and SDL-1.3.) I get compilation errors about some union
not having a member named u1 and alike, because of other system
headers being included before this one and them already defining
DUMMYUNIONNAME and stuff. This header probably assumes that those
stuff are defined in windef.h, but mingw-w64 headers define them
in _mingw.h. Easily fixed by moving NONAMELESSUNION definition to
the top of the file.
src/thread/win32/SDL_systhread.c (both SDL-1.2 and SDL-1.3.) :
The __GNUC__ case for pfnSDL_CurrentBeginThread is 32-bit centric
because _beginthreadex returns uintptr_t, not unsigned long which
is 32 bits in win64. Changing the return type to uintptr_t fixes
it.
video/SDL_blit.h (and configure.in) (SDL-1.3-only) : MinGW-w64
uses msvcrt version of _aligned_malloc and _aligned_free and
they are defined in intrin.h (similar to VC). Adding proper
ifdefs fixes it. (Notes about macros to check: __MINGW32__ is
defined for both mingw.org and for mingw-w64 for both win32 and
win64, __MINGW64__ is only defined for _WIN64, so __MINGW64__
can't be used to detect mingw-w64: including _mingw.h and then
checking for __MINGW64_VERSION_MAJOR does the trick.)
SDL_win32video.h (SDL-1.3-only) : Tweaked the VINWER definition
and location in order to avoid multiple redefinition warnings.
Hope these are useful. Thanks.
Patrice Mandin
Hello,
I originally added pth support for threads in SDL 1.2 because on the Atari
platform we did not have any thread library.
I think pth support could be removed from SDL 1.3 for two reasons:
- Atari platform removed
- pth does not provides real (preemptive) threads, because it is user space,
and expect the application to call one of its function to give CPU to another
thread. So it is not exactly useful for applications, that expect threads to
run simultaneously.
GNU-isms should be avoided wherever possible for portability, please avoid the use of GNU-isms in your code, this may be problematic when using this library in projects which use non-GNU-compliant compilers.
Jack Jansen 2009-11-05 14:20:22 PST
I'm building "fat" SDL 1.3 libraries for MacOSX, but now I am running into the
issue that audio does not work on PowerPC macintoshes if you build the library
on an Intel.
The problem is that configure hard-codes the byteorder, which is then stored in
SDL_config.h
Actually after my patch commited in r4928 MinGW configure seems to generate broken Makefile due MSYS bash bug. (Attaching cure/patch below)
The problem is that:
TEST=`echo 'one\\
two\\
three\\'`
echo "$TEST"
Should echo:
one\
two\
three\
Does it on Linux, Mac.. all UNIX but not on MSYS (MinGW) which outputs:
one\two\three\
(new lines removed, probably it doesn't like backslashes)
Probably this bug should be submitted to MSYS team, but not waiting till MSYS gets it fixed (they have very slow release cycles) here goes simple cure...
My patch simply replaces single quoted SED rules where we needed newlien injection with double quoted ones.
Tested on Mac, Linux & MinGW. Please review it ASAP coz this may be showstopper for everybody compiling with MinGW.
Matej 2009-01-08 09:25:34 PST
Hello,
I maintain a cross-platform project that uses SDL.
One of the users who runs OSX has told me that he has problems with linking to
SDL due to missing -framework option.
I think that the problem is because of this:
'sdl-config --libs' outputs '-L/opt/local/lib -lSDLmain -lSDL
-Wl,-framework,Cocoa'
All the options are passed to the linker except the last one. I think that the
good output should be just:
'-L/opt/local/lib -lSDLmain -lSDL -framework Cocoa'
since those options (--libs) are passed to the linker, so the '-Wl' option is
redundant and possibly harmful in this very case
I use autotools with libtool to do the build...
Regards,
Matej
Wade Berrier 2008-05-28 11:09:42 PDT
configure.in will enable dynamic loading by default for modules, but some of
the checks only check /lib, /usr/lib, /usr/local/lib, etc...
It needs to also account for systems using /lib64, /usr/lib64, and
/usr/local/lib64.
For example, openSUSE x86_64 distro uses these style paths. Otherwise, i586
gets dynamically loaded, but x86_64 doesn't.
It also update configure.in to compile the linux version of the library. The three versions are all dummies
implementations that do nothing. They are being checked in as place holders. Mostly, I just wanted to get
place holders and the configure.in checked in.
I have prepared a set of patches to readd WindowsCE support to SDL 1.3.
I've created a new GAPI/Rawframebuffer and a DirectDraw renderer.
Both renderers are work in progress and there are several unimplemented
cases. (Notably
RenderLine/RenderPoint/RenderFill/QueryTexturePixels/UpdateTexture and
texture blending )
Nevertheless I am successfully using these renderers together with the
SDL software renderer. (On most devices the SDL software renderer will
be much faster as there are only badly optimized vendor drivers available)
I send these patches now in this unpolished state because there seems to
be some interest in win ce and someone has to start supporting SDL 1.3
Now on to the patches:
wince_events_window_fixes.patch
fixes some wince incompatibilities and adds fullscreen support via
SHFullScreen. NOTE: This patch shouldn't have any side effects on
Windows, but I have NOT tested it on Windows, so please double-check.
This patch doesn't dependent on the following ones.
wince_renderers_system.patch
This patch does all necessary modifications to the SDL system.
- it adds the renderers to the configure system
- it adds the renderers to win32video
SDL_ceddrawrender.c
SDL_ceddrawrender.h
SDL_gapirender_c.h
SDL_gapirender.c
SDL_gapirender.h
these files add the new render drivers and should be placed in
src/video/win32
Some notes to people who want to test this:
- I have only compiled sdl with ming32ce, so the VisualC files are not
up to date
- As mingw32ce has no ddraw.h this file must be taken from the MS SDK
and modified to work with gcc
- I had to modify line 2611 in configure.in to
EXTRA_LDFLAGS="$EXTRA_LDFLAGS -lcoredll -lcommctrl -lmmtimer
-Wl,--image-base -Wl,0x10000"
otherwise GetCPinfo wouldn't link. If someone knows whats causing this
I'd be happy to hear about it.
It would be great if these patches could make their way into SVN as this
would make collaboration much much easier.
I'm out of office for the next week and therefore will be unavailable
via email.
Regards
Stefan
