yeah, if you don't set your preferred bits each library is free to do whatever the hell it wants
yeah, if you don't set your preferred bits each library is free to do whatever the hell it wants
DI have to say Silkynvg looks awesome!
Qwell that's because it's the same as NanoVG...
Qthat might of course be a point...
Pwell it's awesome nonetheless
Qthank you 
DYeah, regardless of it being the same as NanoVG you can still take some credit :)
Pso it looks like you're probably missing a stencil buffer
Pjudging from the sdl code
QI am. Although I do have no idea how this backend works, which is why I am here.
DI think that's normal for graphics programming 
DI'd try to help you, but I don't know what the hell a stencil buffer is used for other then that it can be used to track how often a pixel is accessed
QIt’s a binary mask if a render call affects a certain area of the framebuffer
DI suppose that's interesting, though I'm not sure what it could be used for 
Best guess would be you could use it for partially presenting, but the performance of that isn't too great to sacrifice space in my framebuffer
Best guess would be you could use it for partially presenting, but the performance of that isn't too great to sacrifice space in my framebufferPrecommend doing this
where opts is your
where opts is your
WindowOptionsViewOptionsIt seems stencil buffer bits is 0. That of course would fix it
QIn NVG it’s used to just render a big rectangle shaded and then only present the bits that are wanted, this multi vertex stuff doesn’t require shading then only the simple rectangle.
Dah interesting
QBut don’t ask me about the stencil ops, no idea what they do...
DI read that you could use them to make a cool overdraw overlay
QGitHub
NanoVectorGraphicsExceptItUsesSilkNETNowWooHoo (Thank KoziLord for the name) - SilkyNvg/FillCall.cs at b616d7dcdae63980d93b0917c6d47f8269e462d0 · MatijaBrown/SilkyNvg
P@_queenvictoria did this fix your issue
Qsorry, was away for a moment. Yes, it worked - thank you for your concern 
RAnyone got ideas why my Framebuffer does not work on an Android emulator, but on a physical device it works.
RAfter calling
gl.TexParameterI[libEGL] called unimplemented OpenGL ES APII tried couple different Android API versions, virtual devices and also tried changing hw.gpu.mode on Android device manager settings, but nothing changed.
Pprobably because it's unimplemented
PglTexParameterI is a very brand new ES API
Pso it's unlikely to be implemented on lots of embedded systems
RThis says that it would be available on ES 2.0 and 3.0 https://www.khronos.org/registry/OpenGL-Refpages/es3.0/html/glTexParameter.xhtml
PglTexParameterI isn't available until 3.2
Plook at the table at the bottom
P
RUmmh, are we getting the same page?
PROh
RSo is Silks
gl.TexParameterIglTexParameterIiv
TPthat depends if you pass in an int or a uint
RSo what would call
glTexParameterigl.TexParameterOh, right
RAnd it works
Payyy awesome
Palso holy crap is someone actually using our android support
Rofc
RBut that was kinda strange, since my "real" device is Oneplus 3T which is from 2016.
RBut the latest emulators do not support it...
Pvery odd
D@Perksey ok then I'll make a thread here