- #Simple linux game frontend how to#
- #Simple linux game frontend code#
- #Simple linux game frontend windows#
Why do we need pure Xlib and GDI+ is they are so ugly? They are bad for big semi-transparent images only. The situation without alpha enabled is even worse: Also, it is really slow on big images with alpha. But X11 supports only bit-transparency, as in a GIF-files. Why? The game’s background is assembled from semi-transparent PNG images. There are really many differences now: logo, the lights of a sun, sharp girl’s edge, font. The worst case is a pure X11 renderer (it was even unable to load images before my pull request): Also, GDI+ renderer is not very fast on big images. The difference is a font: hinting, anti-aliasing, size etc. It’s supports semi-transparent PNG images, the picture looks almost the same as original OpenGL render. OpenGL options do not affect GDI+ - it’s always WinAPI only. Do not define NKC_USE_OPENGL if you want to use pure X11. You can define NKC_USE_OPENGL=3 for OpenGL 3, or NKC_USE_OPENGL=NGL_ES2 for Open GL ES 2.0 if supported.
#Simple linux game frontend how to#
How to select backend? In general OpenGL 2 will be used by default. If there are any differences - it’s just a JPEG’s compression artifacts. So do not forget to test your application for your selected frontend+backend pair.Īs you can see, the picture is the same. The OpenGL renderers will give pretty similar picture since they use equal functions for drawing and stb_image for pictures rendering. The backend is making an actual rendering. How to select frontend? Define NKCD=NKC_x where x is one of: SDL, GLFW, XLIB, GDIP. For example, X11 frontend can’t change display resolution in fullscreen mode yet (pull requests are welcome). The implemented abilities are not equal too. So the resulting picture can be different. For example, GDI+ uses WinAPI even for font rendering and image loading. Currently supported: SDL, GLFW, X11, GDI+ frontends. You can see implementation in the nkc_frontend folder. Frontend, in that case, means the part that initializes all OS-specific stuff.
The most interesting part of the Nuklear+ is supported frontends and backends. If you follow the example (use of nkc_set_main_loop) than you will get web-version of your application for free.
#Simple linux game frontend code#
I do not write any web-specific code in the game - it’s C89 application, compiled with Emscripten. It was pretty simple, I just replaced all initialization with one function call nkc_init, events handling with nkc_poll_events, render with nkc_render and finalization with nkc_shutdown.īut let’s return to Wordlase. Also, I moved my dxBin2h and nuklear-webdemo to Nuklear+ too. As you can see, the code is pretty simple. You can see the complete code example on GitHub Readme file. The library can load images and fonts, can manage OS window and drawing context for you. Nuklear+ aims to hide all OS code from the programmer and give him ability to focus on GUI code. In my previous article I started to work on Nuklear+, read as “Nuklear cross”, means “Cross-platform Nuklear”. Even background images have nk_image type. The low-level rendering functions are completely hidden by Nuklear. And it does not matter for the game, which concrete renderer used in the game.
There are no OpenGL functions used in the game. That’s why the Wordlase game was made completely on Nuklear. But I have always been interested, can Nuklear make more complicated GUI or not?
#Simple linux game frontend windows#
The task was pretty simple - to make a small cross-platform utility, that will look the same way on Windows and Linux. I have already written about Nuklear GUI library.
0 kommentar(er)
