Trasd Posted August 29, 2013 Share Posted August 29, 2013 For those who have had luck compiling GemRB for Android, pelya has now added SDL 2.0 support (experimental). If it's been there and I missed it before, I apologize... Until the regular SDL adds 16bit capability, it might be well worth compiling with pelya's new library! It can be found here. Link to comment
SyntaxError Posted August 29, 2013 Share Posted August 29, 2013 its not that easy unfortunately, you wont just be able to swap his libsdl for the standard one. Link to comment
Trasd Posted August 29, 2013 Author Share Posted August 29, 2013 its not that easy unfortunately, you wont just be able to swap his libsdl for the standard one. Figures! It was worth a shot... Would it be easier to use a pre 0.8 build that used pelya's in the first place and update it to SDL 2.0, or would that be a step backwards and or just as hard? Link to comment
SyntaxError Posted August 30, 2013 Share Posted August 30, 2013 that would be a total step backwards. there would be nothing gained at all. even if we could just swap the libraries that wouldnt solve anything since we would still be using software rendering layered over the SDL render API. The only thing it would get you is the pelya interface that would be of marginal use under the circumstances. no performance gains to be had at all. if we want to see speedup somebody needs to do one of the following: 1. marry the SDL render API (SDL_texture, SDL_Renderer) with native opengl so that we can simulate palettes. the gl shader logic is easy, but SDL doesnt allow access to the gl texture handle anymore so without patching SDL I don't know of an easy way to do this. It would be nice if the SDL people simply added palette simulation to SDL, but I wouldn't count on it. 2. write a new renderer using opengl only (we could still use SDL for context management for x-platform support etc). If I had sufficient knowledge of this I would probably be able to do 1 instead. 3. revert or create a new SDL2 renderer that uses the software surface blit API instead of the render API (SDL_UpdateWindow etc). This fairly is trivial for even a novice programmer, but it doesnt get us any closer to hardware acceleration, so I refuse to waste my time on it. If somebody else wants to do it i can offer guidance, however. To clarify why I wont waste my time on 3: things would be faster, but still not fast enough. you would be the same performance of the pelya builds which were still pretty darn slow. Features that I am interested in implementing require hardware acceleration, I really want to implement the BG:EE zoom feature so playing on a tablet is less painful among other things. Link to comment
Trasd Posted August 30, 2013 Author Share Posted August 30, 2013 It definitely sounds like the opengl API hardware acceleration is the way to go. There is so much to know with Android programming, I feel like I will never catch up. I guess I just have to learn it a little at a time, and as needed, the way I learned Windows programming (and am still learning). Thanks for the lessons! Link to comment
SyntaxError Posted August 30, 2013 Share Posted August 30, 2013 This problem actually has nothing to do with Android, its just more pronounced on that platform for various reasons. for somebody to make the stopgap patch to get "pelya level" performance would be simple C/C++ which anybody with any programming know how could do even if they didnt explicitly know C++. It would be a good learning exercise for anybody interested. Link to comment
Recommended Posts
Archived
This topic is now archived and is closed to further replies.