Page 1 of 1
SDL 1.3...
Posted: Mon Sep 05, 2011 1:44 pm
by brainspank
I'm frustrated by the switch to SDL 1.3. It isn't generally available for most (any?) linux distributions yet, and installing the beta in the standard place would break most/all SDL 1.2 apps. I have to compile for 64-bit to run ToME - seems kindof alienating. I'm just assuming this switch was vital to ToME development...
Re: SDL 1.3...
Posted: Mon Sep 05, 2011 7:24 pm
by greycat
Install libsdl 1.3 in
parallel to 1.2, not over top of it. You should have both, and 1.3 should be in one of the non-standard places (/usr/local or /opt) that your distribution does not manage.
Instructions (worked for me, Debian).
Re: SDL 1.3...
Posted: Mon Sep 05, 2011 7:59 pm
by brainspank
greycat wrote:Install libsdl 1.3 in parallel to 1.2, not over top of it. You should have both, and 1.3 should be in one of the non-standard places (/usr/local or /opt) that your distribution does not manage.
fair enough, and good compile notes btw. I had started down that path myself, but was hesitant to get into managing/compiling two beta trees instead of one everytime a new update was released. maybe I'm just old and tired.
note: I also ran into an additional issue:
Code: Select all
../src/physfs/physfsrwops.c:23:68: fatal error: ../../../local/include/SDL/stdio.h: Permission denied
doesn't appear to make sense, but I noticed that SDL was installed with only 750 permissions on /usr/local/include/SDL. fixed with:
Code: Select all
$ sudo chmod 755 /usr/local/include/SDL
Re: SDL 1.3...
Posted: Fri Sep 09, 2011 9:01 pm
by Laerte
I finally put everything together (installed SDL-hg in /opt and also have to edit te4core.lua to include the png lib - Arch Linux here), but now the t-engine executable links to both SDL 1.2 and 1.3. Probably because the companions SDL libs (ttf, image, mixer) on my system still link to SDL-1.2. I have tried to compile my own versions ons SDL_ttf, SDL_mixer etc. but they still links to SDL-1.2 anyway, and I cannot remove it without break my system. I hope the only side effect is a little waste of RAM.
Re: SDL 1.3...
Posted: Thu Feb 09, 2012 12:06 pm
by schuay
Unfortunately I have to agree that the decision to use the development version of SDL has made tome4 an unmaintainable mess.
There is no standard way of installing SDL 1.2 and 1.3 side by side. Only recently has installing both versions at the same time even been supported by the SDL devs. The tome4 build system apparently just assumes sdl to be in /opt/SDL-1.3/.
The 1.3 API isn't stable and keeps changing without tome4 keeping up. Matching the installed snapshot date of SDL 1.3 to the version used during development of tome4 is not a feasable option.
The builds have - while they were still working - resulted in a tome4 that partially uses SDL 1.2 and partially 1.3.
All of this is somewhat less than ideal
On Archlinux, SDL 1.3 is now located in /usr/include/SDL2/ and /usr/lib/libSDL2.so, built from the most recent mercurial snapshot. After patching 7 (!) files (fixing the build system to look in right locations, fixing includes to point to the correct SDL headers, fixing changed function signatures), I'm finally stuck in core_lua.c - apparently another API change in the new SDL?
Code: Select all
core_lua.c
../src/core_lua.c: In function ‘lua_get_mod_state’:
../src/core_lua.c:186:2: error: unknown type name ‘SDLMod’
../src/core_lua.c:191:59: error: ‘KMOD_META’ undeclared (first use in this function)
../src/core_lua.c:191:59: note: each undeclared identifier is reported only once for each function it appears in
../src/core_lua.c: In function ‘lua_key_set_clipboard’:
../src/core_lua.c:219:14: warning: initialization discards ‘const’ qualifier from pointer target type [enabled by default]
../src/core_lua.c: In function ‘sdl_font_draw’:
../src/core_lua.c:622:56: error: ‘SDL_SRCALPHA’ undeclared (first use in this function)
../src/core_lua.c: In function ‘sdl_new_tile’:
../src/core_lua.c:856:19: error: ‘SDL_SRCALPHA’ undeclared (first use in this function)
../src/core_lua.c: In function ‘sdl_new_surface’:
../src/core_lua.c:897:19: error: ‘SDL_SRCALPHA’ undeclared (first use in this function)
../src/core_lua.c: In function ‘init_blank_surface’:
../src/core_lua.c:951:19: error: ‘SDL_SRCALPHA’ undeclared (first use in this function)
../src/core_lua.c: In function ‘sdl_surface_alpha’:
../src/core_lua.c:1357:20: error: ‘SDL_SRCALPHA’ undeclared (first use in this function)
../src/core_lua.c: In function ‘sdl_get_modes_list’:
../src/core_lua.c:2112:34: error: ‘SDL_FULLSCREEN’ undeclared (first use in this function)
make[1]: *** [../obj/Debug/TEngine/core_lua.o] Error 1
Any ideas?
It would make life for tome4 package maintainers much easier if the game would follow the most current SDL API from hg and if the build system would be a little more flexible.
Since nothing about SDL1.3 is standardized, both includes and the build system should be able to handle all possible locations of libs and headers.
If you're sticking with SDL1.3, it would help to stay up to date on their latest API changes.
The current packages for tome4 (including patches) and sdl-1.3 are located at:
https://aur.archlinux.org/packages.php?ID=40788 and
https://aur.archlinux.org/packages.php?ID=39387
Re: SDL 1.3...
Posted: Fri Feb 10, 2012 7:38 am
by tiger_eye
Since last June, DarkGod's prebuilt binaries use SDL-1.3 hg-5557 for windows and SDL-1.3 hg-5580 for linux. I am currently using hg-6166 (in linux) and I can compile just fine with the minimal changes described here to music.c, profile.c, and particles.c:
http://forums.te4.org/viewtopic.php?f=4 ... 10&start=7
As for modifying the configuration or make files, I only need to modify "build/TEngine.make" to point to where to find my local installation of libSDL-1.3.
`sdl-config --libs` and
`sdl-config --cflags` can be your friends. Hope this helps!
Re: SDL 1.3...
Posted: Fri Feb 10, 2012 11:21 am
by schuay
tiger_eye wrote:Since last June, DarkGod's prebuilt binaries use SDL-1.3 hg-5557 for windows and SDL-1.3 hg-5580 for linux. I am currently using hg-6166 (in linux) and I can compile just fine [...]
Unfortunately, these changes aren't enough anymore after SDL hg-6204 (see the first comment on the tome4 AUR link I posted above).
Re: SDL 1.3...
Posted: Fri Feb 10, 2012 7:16 pm
by yufra
schuay wrote:
Unfortunately, these changes aren't enough anymore after SDL hg-6204 (see the first comment on the tome4 AUR link I posted above).
So move back to hg-6166 with the following command:
I cannot personally attest to why DG moved from SDL-1.2 to SDL-1.3, but please have a little faith in the man. I have yet to see any changes that could not be explained once you ask.
Re: SDL 1.3...
Posted: Fri Feb 10, 2012 7:55 pm
by tiger_eye
Ah, so schuay wants to make tome into a package that you can install in linux distros. As per normal, it has dependencies: in this case, SDL-1.3 (or perhaps soon to be SDL2).
schuay, if you want to help DarkGod modify the code to use the latest SDL, he's usually very open, appreciative, and helpful. Similar deal if you want to help make the build scripts better.
Re: SDL 1.3...
Posted: Thu Feb 23, 2012 1:04 am
by tiger_eye
*bump*
Has anybody been able to successfully build t-engine with an SDL-1.3 (or SDL-2) version newer than hg6166?
Re: SDL 1.3...
Posted: Sun Feb 26, 2012 3:08 am
by Rectifier
I can tell you that I *have* tried, and the short answer is no.
My last attempt was with one of the SDL2 revisions as part of trying to compile tome for a 64-bit windows environment. Basically to make this game compatible with SDL2 AND newer versions of SDL1.3, you are *required* to make numerous hackish edits to many of the files in the source code in addition to edits to premake.lua in the main directory and edits to both te4core.lua and runner.lua in the /build folder.
If you want to try compiling for a 64-bit version you have to compile ALL the libraries tome uses in 64-bit mode in addition to the aforementioned edits.
Re: SDL 1.3...
Posted: Tue Aug 21, 2012 8:56 pm
by greycat
So, I'm not sure what an "SDL-2.0" is, but this is how I got ToME4 beta 42 to build on Debian. This post describes how I went from able-to-compile-beta-40 to able-to-compile-beta-42. If you weren't previously able to compile beta 40, then there'll be other steps you must undertake as well. (In particular, you must install the SDL_ttf and SDL_image libraries, which are NOT part of SDL!)
I already had an hg checkout (or whatever the hell word they use for "checkout" in hg land -- clone? repository? directory? thingamajig?) of SDL. Based on this thread, I attemped to update that to revision 6166 by issuing the command "hg update 6166". This failed with an error. Long story short, it appears the only way to update from SDL 5580 to SDL 6166 is to remove the SDL directory entirely, and then recreate it:
rm -rf SDL
hg clone
http://hg.libsdl.org/SDL
cd SDL
hg update 6166
./autogen.sh && ./configure && make && sudo make install
This puts SDL 6166 (1.3? 2.0? whatever) into /usr/local.
Now, the ToME4 build system assumes that SDL is in /opt/SDL-2.0 rather than /usr/local. So you have to edit two files, thus:
Code: Select all
Index: premake4.lua
===================================================================
--- premake4.lua (revision 5511)
+++ premake4.lua (working copy)
@@ -18,7 +18,8 @@
"src/physfs",
"src/physfs/zlib123",
"src/bzip2",
- "/opt/SDL-2.0/include/SDL2/",
+ "/usr/local/include/SDL",
+ "/usr/include/SDL",
"/usr/include/GL",
}
if _OPTIONS.lua == "default" then includedirs{"src/lua"}
Index: build/te4core.lua
===================================================================
--- build/te4core.lua (revision 5511)
+++ build/te4core.lua (working copy)
@@ -57,8 +57,8 @@
configuration "linux"
- libdirs {"/opt/SDL-2.0/lib/"}
- links { "dl", "SDL2", "SDL2_ttf", "SDL2_image", "png", "openal", "vorbisfile", "GL", "GLU", "m", "pthread" }
+ libdirs {"/usr/local/lib/"}
+ links { "dl", "SDL", "SDL_ttf", "SDL_image", "png", "openal", "vorbisfile", "GL", "GLU", "m", "pthread" }
defines { [[TENGINE_HOME_PATH='".t-engine"']], 'SELFEXE_LINUX' }
configuration {"Debug"}
Then do the premake/make dance. When I did this, I got an error due to the redefinition of SDL_VideoInfo in the ToME source code. It appears to contain a direct pasting of the same definition from the SDL library code (as indicated by the compiler), so I just commented out the ToME definition:
Code: Select all
Index: src/core_lua.c
===================================================================
--- src/core_lua.c (revision 5511)
+++ src/core_lua.c (working copy)
@@ -60,6 +60,7 @@
return 0;
}
+#if 0
typedef struct SDL_VideoInfo
{
Uint32 hw_available:1;
@@ -81,6 +82,7 @@
int current_w;
int current_h;
} SDL_VideoInfo;
+#endif
static int
GetVideoDisplay()
After that, it built and ran successfully.