Jump to content
Sign in to follow this  
Trasd

pelya and SDL 2.0

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.

Edited by Trasd

Share this post


Link to post

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?

Share this post


Link to post

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.

Share this post


Link to post

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!

Share this post


Link to post

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.

Share this post


Link to post
Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Sign in to follow this  

×
×
  • Create New...