slouken
commented
1 week ago Can you please split each of these into a separate issue? The event documentation has improved for SDL3, so that may no longer be relevant, and the others sound like legitimate bugs. If you can provide repro steps with the SDL test programs, that would be great.
Thanks!
I'm still searching for exact documentation on the following events: (Looked at https://wiki.libsdl.org/SDL_EventType )
SDL_WINDOWEVENT_RESIZED vs SDL_WINDOWEVENT_SIZE_CHANGED (the latter causing an full redetection of the display resolution, the former not being implemented) SDL_WINDOWEVENT_HIT_TEST (what's the purpose of this?) SDL_RENDER_TARGETS_RESET vs SDL_RENDER_DEVICE_RESET (both doing the same: reallocating all but the SDL window and forcing a redrawing by forcing a call to getGPUsurface)
Can anyone explain these? The wiki doesn't say a lot about exactly what those are supposed to do(other than dumping examples)? What needs to be done with SDL_RENDER_TARGETS_RESET? Currently I have both of those RESET events triggering a SDL 1.2-style reset of the window (everything mentioned in the SDL 2.0 migration guide for the window, textures and SDL_Surface except recreating the SDL_Window structure (as it's already present after starting the app once)). All others (textures etc.) are destroyed and recreaten for said event?
Perhaps slightly related, but on Android I notice that after restoring my app from a minimized/background state (from the task manager), that somehow the entire display is shifted upwards somehow (seems to be exactly 1/17 of the screen (2 rows of 8x8 pixels with the screen filled with 480x272 pixels (Sony PSP display resolution, where my app started out on) in total, stretched accross the SDL surface by the app itself using a simple rendering method (much like to the SDL_gfx rotozoom method))).
My exact way of implementing it can be found in my common emulator framework (bitbucket.org/superfury/commonemuframework.git), to be exact in the emu/gpu/*.c and emu/io/input.c for the SDL events receiving itself, at the updateInput function). The emu/gpu/gpu.c itself contains the SDL 1.2 and 2.0 functionality for creating the surfaces etc. (getGPUsurface function mainly, others being the support and updating functions).
Then the getGPUsurface function is called to recreate all SDL structures in a SDL 1.2-compatible way, it will trigger a full screen redraw on the surface, so that the surface should be up-to-date.
So either Android isn't properly setting the display resolution (the first of the available list is taken always) or the bookkeeping is off in it's idea of the screen (as touched, which seems correct) vs what's drawn on the screen somehow?
I also see that the SDL events start spamming SDL_RENDER_TARGETS_RESET to the app once RDP disconnects somehow? It won't stop spamming until RDP is connected again or the user logs in into the app?