-
-
Notifications
You must be signed in to change notification settings - Fork 2.5k
[rcore][win32] Adding native win32 backend #4869
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: master
Are you sure you want to change the base?
Conversation
I believe it makes sense to only do this when there are no known touch points. I am not even sure if this should be done at all. See raysan5#4869 for more information.
@marler8997 Thanks for this new backend! Looks great! I want to test and review more carefully before merging. |
I don't understand OpenGL well enough to know the difference between SwapBuffers and wglSwapLayerBuffers but the former seems to double my FPS (from 2000 to about 4000 in core_vr_simulator).
Instead of calling BeginPaint/EndPaint in WM_PAINT which signals to the OS that our window content is updated, now when we encounter the WM_PAINT message instead we return back to the raylib application which will trigger it to render a new frame. We've replaced the call to BeginPaint and EndPaint with a call to ValidateRect in SwapBuffers, which, means we're now correctly telling the OS when our window content is actually up-to-date. Note that this doesn't fix the window content not being updated during a window resize/move beacuse thos have their own message loop which doesn't return early when it's time to paint.
@marler8997 I'm testing the new backend and it fails when tryin to compile with gcc:
Also noted that file does not follow the raylib code conventions, it should be reviewed. |
Ok I added a few commits to fix the errors compiling with GCC and updated the style to match raylib conventions. With this I can build on Windows with the w64devkit via |
Added some more missing spaces after conditional statements. Also made unsupported MSAA_4X an assert instead of an abort and also removed dpi-aware cases for older OS's. More changes would be needed to support those OS versions, namely, removing the dependency on shcore.
@marler8997 Reviewed it again, why does it require the When compiling I get an empty window, I guess it could be related to DPI: Also, it does not seem to consider the OpenGL 3.3 requested version. EDIT: Compiled with Notepad++ script and w64devkit included in raylib Windows installer. |
The
Also yes I can confirm, the backend currently doesn't do anything with the requested OpenGL version. After making the change to allow me to compile with w64devkit, building with a modified notepad++ script and the w64devkit, I was not able to reproduce the blank screen issue. Here's the two scripts I used to compile the core basic window example:
|
A native Win32 backend for your consideration. The main benefits are a smaller disk/memory footprint for raylib applications and less unexpected behavior. Here's some numbers to compare:
The implementation attempts to keep the actual state of the window and the raylib flags in sync. This is enforced before/after every window message which is overly paranoid but probably good for a first pass. The Win32 platform is full of gotchas and the benefit of using an abstraction like GLFW/RGFW are they have had a long time to fix all of them. However, I've made an effort to handle alot of them here.
The backend is not complete but it currently works with most examples.