raylib
raylib copied to clipboard
raysan5
make RGFW a custom platform
This adds the custom platform for RGFW.
~~it also removes GLAD.h and loads opengl 3.3 directly in RLGL.h~~
Added some notes, it seems some changes from raylib master branch get into the changelist. I also note glad removal implies a considerable review of rlgl, I think it should be on a separate PR for proper review.
I replied to two of your comments and I agree that the RLGL part should be in its own PR.
All the comments have been resolved. (I'm not sure if you've seen that yet)
Compile RGFW directly with Rcore_desktop_Rgfw.h via RGFW_IMPLEMENTATION
@ColleagueRiley Wow! Does it really work??? I didn't know collisions could be avoided that way!
Yep, Rob posted about it here! https://github.com/raysan5/raylib/discussions/3945#discussioncomment-9277152
@ColleagueRiley I'm trying to compile core_basic_window example with VS202 on PLATFORM_DESKTOP_RGFW and I get this issue:
When I try to compile with w64devkit (GCC 13.2.0), I got some warnings but libraylib.a is correctly generated:
but when I try to compile a core_basic_window example I got this:
Yep, RGFW doesn't seem to be working with GLAD for some reason. This only seems to be a problem on windows machines however.
My next PR will remove GLAD and fix this issue.
@ColleagueRiley Testing it again and I'm still getting this issue on x86 configuration with MSVC
@ColleagueRiley Testing it again and I'm still getting this issue on
x86configuration with MSVC
Ensure you're using the newest pull.
@ColleagueRiley Updated to latest PR version and now I'm getting this issue:
@ColleagueRiley Updated to latest PR version and now I'm getting this issue:
This is because Raylib needs to link with winmm. You should already be linking with winmm I think. Raylib links with winmm when it uses GLFW as well.
This is because Raylib needs to link with winmm. You should already be linking with winmm I think.
Yes, I am, just reviewed it but issue is similar to previous one, for some reason the symbols are not detected despite linking with the appropiate libraries...
In any case, is timeBeginPeriod really required for RGFW? I see that PLATFORM_DESKTOP_SDL just skips that line...
In any case, is
timeBeginPeriodreally required forRGFW? I see thatPLATFORM_DESKTOP_SDLjust skips that line...
I'm not sure why SDL skips that line. Both RGFW and GLFW use that line. For some reason without that line the timing is off on windows. I'm not sure why this didn't happen to you before, but this is not an issue with this PR.
I'm not sure why SDL skips that line. Both RGFW and GLFW use that line. For some reason without that line the timing is off on windows. I'm not sure why this didn't happen to you before, but this is not an issue with this PR.
Also, I don't think I got that issue in my tests so I could be an issue with your setup.
This is because Raylib needs to link with winmm. You should already be linking with winmm I think.
Yes, I am, just reviewed it but issue is similar to previous one, for some reason the symbols are not detected despite linking with the appropiate libraries...
In any case, is
timeBeginPeriodreally required forRGFW? I see thatPLATFORM_DESKTOP_SDLjust skips that line...
That's because SDL uses it's own timer system Iirc... GLFW and RGFW use winapi's timer system.
@ColleagueRiley I reviewed it again and it keeps failing. When I change to PLATFORM_DESKTOP (GLFW) it works ok but PLATFORM_DESKTOP_RGFW complaints about that missing symbol. WinMM is passed to the linker. It only happens for x86.
See if these fix the issue. This issue didn't happen for me, but this might fix it.
See if these fix the issue. This issue didn't happen for me, but this might fix it.
Just applied the same fix on my end and it worked. I don't know why it is not required for GLFW...
https://github.com/raysan5/raylib/blob/3d9aafed3b5d183f35a1e8060d0985475101f6db/src/platforms/rcore_desktop.c#L68
@ColleagueRiley Good catch! That functionality should be probably moved from rcore.c to every specific platform... rcore.c tries to be as much platform-independant as possible...
@ColleagueRiley Good catch! That functionality should be probably moved from
rcore.cto every specific platform...
That would be silly. This is a one line thing and plus you already use 4 other winapi functions for file I/O.
@ColleagueRiley Thank you very much for all the work put on integrating this new platform! Merged! 😄