Finally got joystick tested. Competition Pro seemed to work. (AmigaInput doesn't recognise my Xbox controller). Added CompPro also to game controller database. We can add new devices as soon as tester binary is released.
Regarding SDL_image2 and showimage: I have just commited r80 that fixes potential issue where showimage renders with 1*1 window size.
Speaking of showimage, it had bugs after all. It doesn't destroy renderer, which means that with HW renderer, MiniGL context hangs. So add SDL_DestroyRenderer(renderer) call at the end.
Similarly, even though it does call SDL_Quit(), SDL_VideoQuit() is not done since there was no symmetrical SDL_Init(). So add SDL_VideoQuit() before SDL_Quit() as well and it should behave better, no more hanging signals.
Tested png, tiff and webp, and bmp succesfully. There was some issue with loading error with jpeg though (have to check it later).
By the way, I had to disable dependency tracking while configuring SDL_image2. Anybody else had this issue?
Today I built Starfighter project and can confirm the slowness, fullscreen issue and potentially some keyboard issue.
Game was faster in SW mode, especially with 32-bit workbench (game uses internally 32-bit surfaces). To my surprise HW mode doesn't seem to suffer from texture updating, but a whopping 250 milliseconds is spent during glBegin/glEnd. Possibly the large texture (800*600*4) is the culprit here, because when I decreased the resolution to 400*300, drawing became something like 60 ms so it looks linear. But 250 ms is really slow. I tried vertex array with glDrawElements but it wasn't faster. After all, it's only 2 triangles drawn here. Next step would be to profile MiniGL but it will take some hours. You could decrease the in-game resolution but unfortunately game uses hardcoded magic values here and there. Nasty. Still, maybe you can replace all "800" with screenWidth and "600" with screenHeight and then just use a smaller reso like 640*480.
Regarding fullscreen mode, probably desktop mode fullscreen is not sensibly implemented or something, have to do some more testing.
Regarding keyboard, either game uses really exotic controls or there is some mapping issue in SDL. I had a hard time figuring out the controls. And I couldn't bother reading the code :)
Regarding CODE, once again it:
a) doesn't destroy renderer b) doesn't destroy texture c) doesn't free the screen surface
@Capehill Uploading large textures into VRAM is can kill the framerate, but with one large texture (800*600 -> 1024*1024) per frame, it shouldn't matter that much. Plus in that case most of the time would be spent in glTexSubImage2D. Using vertex arrays would only help with a large number of triangles, because inside MiniGL both are buffered.
Edited by BSzili on 2016/3/17 10:05:31
This is just like television, only you can see much further.
Texture update takes 15-20 ms for the same 800*600*32 texture. These time figures are from SDL_GetTicks().
Tried to alter texture filtering and blend mode but no visible change. Unless there is something with the texture format, I don't know can anything be done on the SDL_render_gl.c side.
I might start compositing renderer next week as there isn't much else to do with SDL2 port...well OpenGL code needs probably some work (context attributes and bitmap depth) but it can be used.
Mouse cursors are missing too. And window backfill hooks. And those asm optimized converters are also not merged yet.
@Capehill Have some general question: is it possible to compile programs done for SDL1, by SDL2 includes ? I mean did SDL2 have legacy compatability with SDL1 ?
Why i ask, because i have some projects in hands, which are just slow over current SDL1 software/hardware renderers. And, while i do not want to speed up every SDL app manually, i somehow was in hope that someone, someday, will speed up SDL by adding compositing accleration in some SDL functions. And as i see it it, you have plans to do so for SDL2. Will it possilbe to recompile old SDL1 based apps then ?
@kas1e Generally no. Some parts are are backwards compatible, like the audio, but the event/video handling is completely different. I remember planned SDL1.2 backward compatibility mentioned on the official website, but it didn't happen yet.
This is just like television, only you can see much further.
There are many different SDL applications so a general speedup is hard to do.
With SDL1 blitting opaque HWSURFACEs is already accelerated.
If you are looking for alpha blitting speedup, you could try my fork of SDL1. In fullscreen mode HWSURFACEs are blitted using compositing. So if you have a bunch of HWSURFACEs waiting to be blitted, this is the way to go.
But if the application plots the pixels (surface->pixels) by CPU, there is very little that can be done. It depends how fast your CPU can write RAM or VRAM.