looking for testers for sdl2 support
looking for testers for sdl2 support
I've tried to add support for sdl2 in this branch: lp~armagetronad-ct/armagetronad/0.4-sdl2
It works fine on my laptop and desktop computer (osx) but it might behave differently on others so I would be interested if other able to compile it would like to test and give feedback.
Note that as sdl2 change the way keyboard is handled (for better unicode support), it partly brokes sdl1.2 key binding so you might want to keep a backup of your user config file.
Also it's full of preprocessor directive and it would probably be better to dump sdl 1.2 code completely in the future as sdl2 bring better support for unicode, multiscreen, fullscreen support, etc.
It might also help simplifying rScreen code as things seems to be easier and more straightforward with sdl2.
Last revision (1536) from this branch fix the color issue I faced and report here: 0.4 on os x and texture channels
It works fine on my laptop and desktop computer (osx) but it might behave differently on others so I would be interested if other able to compile it would like to test and give feedback.
Note that as sdl2 change the way keyboard is handled (for better unicode support), it partly brokes sdl1.2 key binding so you might want to keep a backup of your user config file.
Also it's full of preprocessor directive and it would probably be better to dump sdl 1.2 code completely in the future as sdl2 bring better support for unicode, multiscreen, fullscreen support, etc.
It might also help simplifying rScreen code as things seems to be easier and more straightforward with sdl2.
Last revision (1536) from this branch fix the color issue I faced and report here: 0.4 on os x and texture channels
- AI-team
- Shutout Match Winner
- Posts: 1020
- Joined: Tue Jun 23, 2009 6:17 pm
- Location: Germany/Munich
- Contact:
Re: looking for testers for sdl2 support
I'll see if I can get this compiled on windows and if so, provide an executable
"95% of people believe in every quote you post on the internet" ~ Abraham Lincoln
Re: looking for testers for sdl2 support
I tried to compile it with no luck. I am on debian sid and run apt-get install libsdl2-image-dev libsdl2-mixer-dev before.
Code: Select all
make[4]: Entering directory `/home/arma/sources/0.4-sdl2/src/thirdparty/scrap'
g++ -DHAVE_CONFIG_H -I. -I../../.. -I/usr/include/libxml2 -I/usr/include/SDL2 -D_REENTRANT -I/usr/include/libpng12 -I/usr/include/FTGL -I/usr/include/freetype2 -I/usr/include/freetype2 -I../../../src -I./ -O2 -MT libscrap_a-scrap.o -MD -MP -MF .deps/libscrap_a-scrap.Tpo -c -o libscrap_a-scrap.o `test -f 'scrap.cpp' || echo './'`scrap.cpp
scrap.cpp:43:15: error: ‘Window SDL_Window’ redeclared as different kind of symbol
static Window SDL_Window;
^
In file included from /usr/include/SDL2/SDL_events.h:33:0,
from /usr/include/SDL2/SDL.h:76,
from scrap.cpp:7:
/usr/include/SDL2/SDL_video.h:89:27: error: previous declaration of ‘typedef struct SDL_Window SDL_Window’
typedef struct SDL_Window SDL_Window;
^
scrap.cpp: In function ‘int init_scrap()’:
scrap.cpp:259:27: error: ‘SDL_GetWMInfo’ was not declared in this scope
if ( SDL_GetWMInfo(&info) )
^
scrap.cpp:267:22: error: expected unqualified-id before ‘=’ token
SDL_Window = info.info.x11.window;
^
scrap.cpp:268:40: error: ‘struct SDL_SysWMinfo::<anonymous union>::<anonymous>’ has no member named ‘lock_func’
Lock_Display = info.info.x11.lock_func;
^
scrap.cpp:269:42: error: ‘struct SDL_SysWMinfo::<anonymous union>::<anonymous>’ has no member named ‘unlock_func’
Unlock_Display = info.info.x11.unlock_func;
^
scrap.cpp:273:46: error: invalid conversion from ‘int (*)(const SDL_Event*)’ to ‘SDL_EventFilter {aka int (*)(void*, SDL_Event*)}’ [-fpermissive]
SDL_SetEventFilter(clipboard_filter);
^
scrap.cpp:273:46: error: too few arguments to function ‘void SDL_SetEventFilter(SDL_EventFilter, void*)’
In file included from /usr/include/SDL2/SDL.h:76:0,
from scrap.cpp:7:
/usr/include/SDL2/SDL_events.h:655:30: note: declared here
extern DECLSPEC void SDLCALL SDL_SetEventFilter(SDL_EventFilter filter,
^
scrap.cpp: In function ‘int lost_scrap()’:
scrap.cpp:304:72: error: expected primary-expression before ‘)’ token
retval = ( XGetSelectionOwner(SDL_Display, XA_PRIMARY) != SDL_Window );
^
scrap.cpp: In function ‘void put_scrap(int, int, char*)’:
scrap.cpp:340:63: error: expected primary-expression before ‘,’ token
XSetSelectionOwner(SDL_Display, XA_PRIMARY, SDL_Window, CurrentTime);
^
scrap.cpp: In function ‘void get_scrap(int, int*, char**)’:
scrap.cpp:440:49: error: expected primary-expression before ‘)’ token
if ( (owner == None) || (owner == SDL_Window) )
^
scrap.cpp:450:27: error: expected primary-expression before ‘;’ token
owner = SDL_Window;
^
scrap.cpp:461:50: error: ‘SDL_SysWMmsg’ has no member named ‘event’
XEvent xevent = event.syswm.msg->event.xevent;
^
scrap.cpp: In function ‘int clipboard_filter(const SDL_Event*)’:
scrap.cpp:581:29: error: ‘SDL_SysWMmsg’ has no member named ‘event’
switch (event->syswm.msg->event.xevent.type) {
^
scrap.cpp:591:32: error: ‘SDL_SysWMmsg’ has no member named ‘event’
req = &event->syswm.msg->event.xevent.xselectionrequest;
^
make[4]: *** [libscrap_a-scrap.o] Fehler 1
make[4]: Leaving directory `/home/arma/sources/0.4-sdl2/src/thirdparty/scrap'
make[3]: *** [all-recursive] Fehler 1
make[3]: Leaving directory `/home/arma/sources/0.4-sdl2/src/thirdparty'
make[2]: *** [all-recursive] Fehler 1
make[2]: Leaving directory `/home/arma/sources/0.4-sdl2/src'
make[1]: *** [all-recursive] Fehler 1
make[1]: Leaving directory `/home/arma/sources/0.4-sdl2'
make: *** [all] Fehler 2
Re: looking for testers for sdl2 support
oh, yeah, this file in not used on osx. I'll check it...
edit:
This might be a solution but I can't test it as I don't have windows at home. Do you think you can give it a try ?
edit2:
Same issue on ubuntu, the above solution seems to work. 1 known bug remains on ubuntu: failed to open the wav file at start...
I'm installing windows dev environment so I'll be able to provide a compilable stuff to test on different hardware.
edit:
This might be a solution but I can't test it as I don't have windows at home. Do you think you can give it a try ?
edit2:
Same issue on ubuntu, the above solution seems to work. 1 known bug remains on ubuntu: failed to open the wav file at start...
I'm installing windows dev environment so I'll be able to provide a compilable stuff to test on different hardware.
Re: looking for testers for sdl2 support
BUILD SUCCESSFUL
The game starts and I can play.
The default key bindings are very strange. E.g. "turn left" is assigned to the brightness key etc.
Toggel fullscreen doesn't work well. When started in fullscreen, it toggles to window mode but when I press again, it shortly toggles to fullscreen than back to window again. When I start in window mode it's the other way around.
I can do a debug recording if that helps.
The game starts and I can play.
The default key bindings are very strange. E.g. "turn left" is assigned to the brightness key etc.
Toggel fullscreen doesn't work well. When started in fullscreen, it toggles to window mode but when I press again, it shortly toggles to fullscreen than back to window again. When I start in window mode it's the other way around.
I can do a debug recording if that helps.
Re: looking for testers for sdl2 support
Yes, I've noticed that. As I said, sdl2 change the way keyboard is handled and it partly breaks sdl1.2 key binding. Correct binding has to be provided by default for sure but I don't know if there's a way to keep backward compatibility without handling a lookup table (to be able to convert new key code from/to old ones.
- kyle
- Reverse Outside Corner Grinder
- Posts: 1876
- Joined: Thu Jun 08, 2006 3:33 pm
- Location: Indiana, USA, Earth, Milky Way Galaxy, Universe, Multiverse
- Contact:
Re: looking for testers for sdl2 support
page up and page down don't work for the chat. It took it time before i could type my password to authenticate
Re: looking for testers for sdl2 support
Kyle, Jip, I've fixed both fullscreen toggling and key binding issues, as well as some others I've noticed (like repeating key press). You should be able to check that.
Also, I've added some touchpad/touchscreen support with the following setting:
enable_touch <int> (should be enable_touches right?)
0 means disabled
1: touch device is divided into 3 equal parts horizontally allowing to turn left/brake/turn right
2: up is assumed current cycle direction and you can swipe left/right to turn. You can also draw you path on it so a 8 like drawing would do a triple l/r-triple r/l depending on the orientation.
3: is similar to 2 except it is taking current camera orientation into account so if your cycle goes left on the screen, a swipe up/down will turn right/left.
There's for sure some tweaking required to adjust sensitivity and avoid unwanted turns...
edit: key binding is actually half fixed and still requires to adjust default binding in cfg files
Also, I've added some touchpad/touchscreen support with the following setting:
enable_touch <int> (should be enable_touches right?)
0 means disabled
1: touch device is divided into 3 equal parts horizontally allowing to turn left/brake/turn right
2: up is assumed current cycle direction and you can swipe left/right to turn. You can also draw you path on it so a 8 like drawing would do a triple l/r-triple r/l depending on the orientation.
3: is similar to 2 except it is taking current camera orientation into account so if your cycle goes left on the screen, a swipe up/down will turn right/left.
There's for sure some tweaking required to adjust sensitivity and avoid unwanted turns...
edit: key binding is actually half fixed and still requires to adjust default binding in cfg files
Last edited by voodoo on Tue Jan 28, 2014 8:37 am, edited 1 time in total.
Re: looking for testers for sdl2 support
With a default install (no custom settings): Start game and do the first time setup. Turn fullscreen off, apply settings and quit the game. Start again → The title screen never disappears.
Also on OS X, SDL2_mixer has a sub-framework with an incorrect install_name that prevents you from being able to "make run" the game (you'll need to "make install" and run the .app). You can run this from the toolkit directory Or apply this patch and reinstall SDL2_mixer:
Also on OS X, SDL2_mixer has a sub-framework with an incorrect install_name that prevents you from being able to "make run" the game (you'll need to "make install" and run the .app). You can run this from the toolkit directory
Code: Select all
install_name_tool -change "@executable_path/../Frameworks/SDL2.framework/Versions/A/SDL2" "@rpath/SDL2.framework/Versions/A/SDL2" libraries/Frameworks/SDL2_mixer.framework/Frameworks/smpeg2.framework/smpeg2
Code: Select all
=== modified file 'os-x-toolkit.rb'
--- os-x-toolkit.rb 2014-01-17 11:29:11 +0000
+++ os-x-toolkit.rb 2014-01-27 19:32:52 +0000
@@ -23,8 +23,17 @@
libs["SDL_mixer"] = Builder.new { |config, arch|
archive = fetch("http://www.libsdl.org/projects/SDL_mixer/release/SDL2_mixer-2.0.0.dmg")
source = open_dmg(archive)
- copy_framework(source, "SDL2_mixer", arch)
+ framework = copy_framework(source, "SDL2_mixer", arch)
close_dmg(source)
+
+ # Correct install name for smpeg2
+ system(
+ "install_name_tool",
+ "-change",
+ "@executable_path/../Frameworks/SDL2.framework/Versions/A/SDL2",
+ "@rpath/SDL2.framework/Versions/A/SDL2",
+ File.join(framework, "Frameworks/smpeg2.framework/smpeg2")
+ )
}
libs["libpng"] = Builder.new("lib/libpng.a") { |config, arch|
Re: looking for testers for sdl2 support
Title screen issue should be fixed now. I've applied your patch on corresponding os-x-toolkit branch.
I've also added special cfg files for sdl2 key binding. The way sdl2 is working should make those binding layout independent so it should be fine if I didn't mess up again. Sadly previous custom key binding can't be saved without remapping the whole key sdl encoding with the new sdl2 one. That would be error prone and it does not worth the effort I guess...
I've also added special cfg files for sdl2 key binding. The way sdl2 is working should make those binding layout independent so it should be fine if I didn't mess up again. Sadly previous custom key binding can't be saved without remapping the whole key sdl encoding with the new sdl2 one. That would be error prone and it does not worth the effort I guess...
Re: looking for testers for sdl2 support
Compiling fails now for me:
Code: Select all
$ make -j2
(CDPATH="${ZSH_VERSION+.}:" && cd . && /bin/bash /home/arma/sources/0.4-sdl2/missing autoheader)
rm -f stamp-h1
touch aa_config.h.in
cd . && /bin/bash ./config.status aa_config.h
config.status: creating aa_config.h
config.status: aa_config.h is unchanged
make all-recursive
make[1]: Entering directory `/home/arma/sources/0.4-sdl2'
Making all in src
make[2]: Entering directory `/home/arma/sources/0.4-sdl2/src'
Making all in first
make[3]: Entering directory `/home/arma/sources/0.4-sdl2/src/first'
make[3]: Für das Ziel »all« ist nichts zu tun.
make[3]: Leaving directory `/home/arma/sources/0.4-sdl2/src/first'
Making all in protobuf
make[3]: Entering directory `/home/arma/sources/0.4-sdl2/src/protobuf'
g++ -DHAVE_CONFIG_H -I. -I../.. -I/usr/include/libxml2 -I/usr/include/SDL2 -D_REENTRANT -I/usr/include/libpng12 -I/usr/include/FTGL -I/usr/include/freetype2 -I/usr/include/freetype2 -I. -I./ -O2 -MT libprotobuf_a-tColor.pb.o -MD -MP -MF .deps/libprotobuf_a-tColor.pb.Tpo -c -o libprotobuf_a-tColor.pb.o `test -f 'tColor.pb.cc' || echo './'`tColor.pb.cc
g++ -DHAVE_CONFIG_H -I. -I../.. -I/usr/include/libxml2 -I/usr/include/SDL2 -D_REENTRANT -I/usr/include/libpng12 -I/usr/include/FTGL -I/usr/include/freetype2 -I/usr/include/freetype2 -I. -I./ -O2 -MT libprotobuf_a-tCoord.pb.o -MD -MP -MF .deps/libprotobuf_a-tCoord.pb.Tpo -c -o libprotobuf_a-tCoord.pb.o `test -f 'tCoord.pb.cc' || echo './'`tCoord.pb.cc
In file included from tCoord.pb.cc:4:0:
tCoord.pb.h:17:2: error: #error This file was generated by an older version of protoc which is
#error This file was generated by an older version of protoc which is
^
tCoord.pb.h:18:2: error: #error incompatible with your Protocol Buffer headers. Please
#error incompatible with your Protocol Buffer headers. Please
^
tCoord.pb.h:19:2: error: #error regenerate this file with a newer version of protoc.
#error regenerate this file with a newer version of protoc.
^
In file included from tColor.pb.cc:4:0:
tColor.pb.h:17:2: error: #error This file was generated by an older version of protoc which is
#error This file was generated by an older version of protoc which is
^
tColor.pb.h:18:2: error: #error incompatible with your Protocol Buffer headers. Please
#error incompatible with your Protocol Buffer headers. Please
^
tColor.pb.h:19:2: error: #error regenerate this file with a newer version of protoc.
#error regenerate this file with a newer version of protoc.
^
make[3]: *** [libprotobuf_a-tCoord.pb.o] Fehler 1
make[3]: *** Warte auf noch nicht beendete Prozesse...
make[3]: *** [libprotobuf_a-tColor.pb.o] Fehler 1
make[3]: Leaving directory `/home/arma/sources/0.4-sdl2/src/protobuf'
make[2]: *** [all-recursive] Fehler 1
make[2]: Leaving directory `/home/arma/sources/0.4-sdl2/src'
make[1]: *** [all-recursive] Fehler 1
make[1]: Leaving directory `/home/arma/sources/0.4-sdl2'
make: *** [all] Fehler 2
Re: looking for testers for sdl2 support
Looks like protoc bin used to generate files *.pb.h and *.pb.cc is different than protobuf libraries. Remove those *.pb.* files and regenerate them should fix the issue.
Re: looking for testers for sdl2 support
Works pretty fine now. When does it get merged?
Re: looking for testers for sdl2 support
How does a lowly user do this? Can this be done by me, (I have the source (I have the 0.4 trunk and I have this problem) ,or does a developer have to do this?voodoo wrote:Looks like protoc bin used to generate files *.pb.h and *.pb.cc is different than protobuf libraries. Remove those *.pb.* files and regenerate them should fix the issue.
Every time I update opensuse I have to recompile and protoc gives me a headache.
Re: looking for testers for sdl2 support
Before compiling, do: $ rm src/protobuf/*.pb.*