Skip to content
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

make RGFW a custom platform #3941

Merged
merged 5 commits into from
May 7, 2024
Merged

make RGFW a custom platform #3941

merged 5 commits into from
May 7, 2024

Conversation

ColleagueRiley
Copy link
Contributor

@ColleagueRiley ColleagueRiley commented Apr 28, 2024

This adds the custom platform for RGFW.

it also removes GLAD.h and loads opengl 3.3 directly in RLGL.h

src/rcore.c Outdated Show resolved Hide resolved
src/Makefile Outdated Show resolved Hide resolved
examples/models/models_skybox.c Outdated Show resolved Hide resolved
examples/Makefile Outdated Show resolved Hide resolved
src/rmodels.c Outdated Show resolved Hide resolved
@raysan5
Copy link
Owner

raysan5 commented Apr 28, 2024

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.

@ColleagueRiley
Copy link
Contributor Author

I replied to two of your comments and I agree that the RLGL part should be in its own PR.

@ColleagueRiley ColleagueRiley changed the title add a custom platform for RGFW and replace GLAD with a custom opengl loader add a custom platform for RGFW Apr 28, 2024
@ColleagueRiley ColleagueRiley changed the title add a custom platform for RGFW make RGFW a custom platform Apr 28, 2024
src/Makefile Outdated Show resolved Hide resolved
src/rcore.c Outdated Show resolved Hide resolved
src/rcore.c Outdated Show resolved Hide resolved
@raysan5
Copy link
Owner

raysan5 commented Apr 29, 2024

@ColleagueRiley thanks for the review, added some comments...

@ColleagueRiley
Copy link
Contributor Author

ColleagueRiley commented Apr 29, 2024

All the comments have been resolved. (I'm not sure if you've seen that yet)

@raysan5
Copy link
Owner

raysan5 commented Apr 30, 2024

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!

@ColleagueRiley
Copy link
Contributor Author

Yep, Rob posted about it here! #3945 (reply in thread)

@raysan5
Copy link
Owner

raysan5 commented May 1, 2024

@ColleagueRiley I'm trying to compile core_basic_window example with VS202 on PLATFORM_DESKTOP_RGFW and I get this issue:
image

@raysan5
Copy link
Owner

raysan5 commented May 1, 2024

When I try to compile with w64devkit (GCC 13.2.0), I got some warnings but libraylib.a is correctly generated:
image

but when I try to compile a core_basic_window example I got this:

image

@ColleagueRiley
Copy link
Contributor Author

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
Copy link
Contributor Author

GLAD should work with RGFW now!

@raysan5
Copy link
Owner

raysan5 commented May 5, 2024

@ColleagueRiley Testing it again and I'm still getting this issue on x86 configuration with MSVC
image

@ColleagueRiley
Copy link
Contributor Author

@ColleagueRiley Testing it again and I'm still getting this issue on x86 configuration with MSVC

image

Ensure you're using the newest pull.

@raysan5
Copy link
Owner

raysan5 commented May 5, 2024

@ColleagueRiley Updated to latest PR version and now I'm getting this issue:
image

@ColleagueRiley
Copy link
Contributor Author

ColleagueRiley commented May 5, 2024

@ColleagueRiley Updated to latest PR version and now I'm getting this issue:

image

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.

@raysan5
Copy link
Owner

raysan5 commented May 5, 2024

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...

@ColleagueRiley
Copy link
Contributor Author

In any case, is timeBeginPeriod really required for RGFW? I see that PLATFORM_DESKTOP_SDL just 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.

@ColleagueRiley
Copy link
Contributor Author

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.

@ColleagueRiley
Copy link
Contributor Author

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...

That's because SDL uses it's own timer system Iirc...
GLFW and RGFW use winapi's timer system.

@raysan5
Copy link
Owner

raysan5 commented May 5, 2024

@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.

@ColleagueRiley
Copy link
Contributor Author

ColleagueRiley commented May 5, 2024

See if these fix the issue. This issue didn't happen for me, but this might fix it.

@raysan5
Copy link
Owner

raysan5 commented May 5, 2024

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...

@ColleagueRiley
Copy link
Contributor Author

ColleagueRiley commented May 5, 2024

unsigned int __stdcall timeBeginPeriod(unsigned int uPeriod);

@raysan5
Copy link
Owner

raysan5 commented May 5, 2024

@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
Copy link
Contributor Author

ColleagueRiley commented May 5, 2024

@ColleagueRiley Good catch! That functionality should be probably moved from rcore.c to 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.

@raysan5
Copy link
Owner

raysan5 commented May 7, 2024

@ColleagueRiley Please, let me know when ready to merge!

@ColleagueRiley
Copy link
Contributor Author

Should be ready to merge now.

@raysan5 raysan5 merged commit 9805fe0 into raysan5:master May 7, 2024
@raysan5
Copy link
Owner

raysan5 commented May 7, 2024

@ColleagueRiley Thank you very much for all the work put on integrating this new platform! Merged! 😄

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants