Jump to content

pelya and SDL 2.0


Trasd

Recommended Posts

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

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

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

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

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

Archived

This topic is now archived and is closed to further replies.

×
×
  • Create New...