SDL does emulate a "mouse" using touch though
SDL does emulate a "mouse" using touch though
Pso you will be able to use the mouse apis to do something
ROkay
RAre there plans for "real" touchscreen support?
RMouse might be enough for my use case though
Pit's something we'd want yeah, but we don't have a design for it at the moment which'd be the first step to getting it in
Tdoesn't SDL also have a normal touch API
Pyes
Pwe just don't expose it today
RDoes silk expose
SDL_HINT_ORIENTATIONS?RBy default SDL autorotates screen, and it also overrides Xamarins ScreenOrientation setting which is a bit annoying 
RAnd it also does not respect devices auto-rotate setting.
Pnot yet! we should be able to pretty easily
RCould it also be possible to add touch events?
The virtual mouse is more limited than I originally thought that it would be.
The virtual mouse is more limited than I originally thought that it would be.
RI could also look into designing proper touch screen support at some point.
Pwe'd probably want a proper design for that
Pand even then i don't think it's something we can add without breaking, so would have to wait for 3.0
Pbut it won't happen at all without a design, so it'd be great if you wanted to contribute a proposal 
proposal template: https://github.com/dotnet/Silk.NET/blob/main/documentation/proposals/template-proposal.md
example proposal: https://github.com/dotnet/Silk.NET/blob/proposal/all-3.0-proposals/documentation/proposals/Proposal%20-%20Enhanced%20Input%20Events.md
proposal template: https://github.com/dotnet/Silk.NET/blob/main/documentation/proposals/template-proposal.md
example proposal: https://github.com/dotnet/Silk.NET/blob/proposal/all-3.0-proposals/documentation/proposals/Proposal%20-%20Enhanced%20Input%20Events.md
RSure, I'll look into that when I have more time
RFor future reference: Infinite recursion on Android does not give an exception, the app just instantly closes and debug output says
[libc] Fatal signal 11 (SIGSEGV), code 2 (SEGV_ACCERR), fault addr 0x7c67fd0fe0 in tid 8893 (SDLThread), pid 8849 (SDLActivity) which looks super beautiful.RI did not just waste 30 minutes because of that...
DOh that's is peak error reporting right there
DCan somebody tell me what's going on here? I have my game's Resolution set to 640x480. The engine is rendering at 640x480 and everything works fine, except for that I am in fullscreen mode and it looks like this on my laptop.
D
Dwell your laptops native resolution probably isn't 640x480?
DWell yeah
DBut shouldn't the viewport scale up?
DOr in the case of hardware fullscreen, shouldn't the GPU reset the display mode?
DI'm not sure to be honest. But for reasons of keeping my sanity I'd just scale up myself if I was you
Dsince relying on someone to do something is usually not a great idea
Despecially since the quality of their doing may vary
Dat least that's my expectation
Dand if you do MSAA or such you can probably just resolve to native-sized texture anyways (not sure how it works in OpenGL, but I'd expect that to be possible there as well) and then you'd get better quality then doing MSAA -> 640x480 -> normal upscale to native
Dand also depending on the style of your game you may or may not want to use filtered upscaling since that'd loose pixel-perfectness
DI'm not doing MSAA
DI just wanna get fullscreen mode to work properly
Dif the viewport is 640x480 then it should set the hardware display mode to 640x480 when in fullscreen
DI'll do a frostbite 3 approach to windowed fullscreen, that is, gray out the resolution select and just run at native resolution
DI mean idk why you would specifically want to change the native resolution. That is just very awkward for the user imo, all background windows etc. Also change their size, so not sure why you'd want to change the native resolution
DI want to change the native resolution because the user is changing the native resolution.
DEvery game I've ever played, even modern ones, if you set the fullscreen mode to Fullscreen (instead of borderless or windowed) and you decrease the resolution, it sets the hardware display mode.
DChanging the resolution in windowed mode sets the client size of the window
DAnd changing it in borderless either resizes a framebuffer that gets scaled or just outright isn't possible because the UI disables it
D(mirror's edge catalyst does the latter)
DI'm not letting the user change the resolution so they can change the size of the UI on screen, I'm doing it so you can decrease the quality of the game and the amount of fragments that need to be shaded so your poor little iGPU doesn't suffer
Dnot that I expect that to happen in a hacking game
Dbut you never know
Dpeople have definitely tried running my code on crappy school computers
DYou are totally right, but the Fullscreen you see in most games is exclusive Fullscreen, so you basically take control over the monitor.
VWhich I am pretty sure is what they are asking to be able to do
D
