sokol_entry about sokol

[floooh]

Looks nice :) I'll give it a try ASAP and try to give some feedback. One reason why I didn't do this right away was the overlap with GLFW, and I also didn't want to accidently limit sokol_gfx to a frame-callback model (but for a general entry-point lib this is the only way to go).

Oh and another thing: I was thinking that only the sokol_gfx header should use the sg_ prefix (for sokolgfx. Other headers would use something different, e.g. an sokol_input.h would use si_.

[floooh]

I think I finally made up my mind about an application wrapper sokol header... My main problem was what needs to be different from GLFW to justify the effort. I'll start sketching out a sokol_app.h header, this will be fairly low prio until I have finished the move of Oryol to sokol-gfx.

I hope you don't mind that I'm not forking sokol_entry.h ;)

Here's what I thought up so far:

• no support for multiple windows, at least in the beginning (mobile and web cannot support multiple windows anyway, this would be the 1st thing that's different from GLFW)
• likewise no multimonitor support (only the minimum needed for HighDPI)
• minimal HighDPI support like implemented in Oryol
• initial platform support same as Oryol: Win32+GL+D3D11, OSX+GL+Metal, iOS+GL+Metal, Linux+GL, emscripten+WebGL+WebGL2, Android+GLES2+GLES3, RaspberryPi+GLES2,
• must use a frame-callback function because of restrictions on some platforms (3nd thing that's different from GLFW)
• needs to completely hijack the main() function (since some platforms don't have a main function, another point that's different to GLFW)
• keep the API for input as small as possible (most likely only a single input event struct and event handler callback - have a separate sokol_input.h later with a more convenient input API)
• ...still have a SOKOL_GLFW define to fallback to GLFW (mainly for testing and robustness)

The main difference to sokol_entry.h would be that there will be less API functions for window control, basically I want to avoid functions that are not needed on mobile platforms as long as possible :)

[pjako]

I don't mind at all, its pretty sketchy in its current state anyways.

Reducing the input api sounds like a good idea to me. I was even thinking about delivering everything you need to do a frame update in a single big struct as a parameter of your frame update callback. (But this approach has some problems in some cases)

So I guess we can close this issue, looking forward to sokol_app.h :)