But the latest emulators do not support it...
But the latest emulators do not support it...
Pvery odd
D@Perksey ok then I'll make a thread here
Pthe adoption of ES versions have always been inconsistent
Pi'm trying to find a graph but can't find one
PP3.2 is higher than i thought
RThanks
RWell, it came out 6 years ago and people usually have newer phones than PC's.
Ptrue
P3.2 is likely the last version of ES too
Pi hate to say it but OpenGL development is pretty much dead
Pwe're still getting Arm and Qualcomm updating OpenGLES, but there's pretty much noone left investing in OpenGL
RDoes Silk have a way to listen touchscreen on Android?
RInput package does not seem to have anything related to it.
Pwe don't have any dedicated touch apis
PSDL 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