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

Isolating the graphics engine #124

Open
clholtz73 opened this issue Jul 11, 2023 · 3 comments
Open

Isolating the graphics engine #124

clholtz73 opened this issue Jul 11, 2023 · 3 comments

Comments

@clholtz73
Copy link

Hey Eric. Great product! I've been working space simulation a long time and very impressed with what you have with 42, especially for the size of the code base. I'm actually interested in the possibility of extracting the 3d graphics code for use with other space simulations. Does that seem doable? Any thoughts, tips, or docs that would be helpful?

@ericstoneking
Copy link
Owner

Hi Corbin,

Thanks for the kind words.

Doable, yes. There will likely be labor in hooking up all the globals that the GUI expects. All the graphics-specific code is segregated in a few source and header files, but liberal use is made of non-graphics-specific globals, so the interface isn't what you might call modular :-/

I'll throw another idea at you. There are "game engines" out there that I've considered using as a graphics front end for 42 (there was a scare a few years back that OpenGL might become hard to sustain). I looked at Unity, Lumberyard, Godot, and (I think) Unreal. I settled on Godot for a few reasons (free open source, right-handed coordinates, expected support for VR). OpenGL is still here, so I haven't pursued it further. Depending on your needs and preferences, it might be just as easy for you to build a front end with these high-quality graphics tools as it would be to make all the connections to 42's graphics front end.

If you go that route, and don't mind sharing, keep in touch.

Regards,
-Eric (he/him)

@clholtz73
Copy link
Author

Thanks for the quick response, Eric. The game engine path is possible, but adds additional dependencies and my previous look at them showed some issues with planetary distances & such. We do have much higher fidelity capabilities, but they are difficult to deploy on a developer's desktop for daily use. 42 is so compact that having everyone popup the graphics when needed would be very lightweight.

I tried to identify the graphics code previously, but nothing really obvious popped out. If you can point me at the appropriate files, that would be much appreciated.

Thanks!

@ericstoneking
Copy link
Owner

Hi Corbin,

In Source:
42gl.c: Main OpenGL code
42glut.c: Interfaces using GLUT
42glfw.c: Interfaces using GLFW (use this or 42glut.c, not both)

In Include: 42gl.h, 42glfw.h, 42glut.h

In Kit/Source: glkit.c
In Kit/Include: glkit.h
In Kit/Shaders: Everything except Albedo*.glsl and TexReduce*.glsl

You'll probably also need some other *kit.c files, for utility functions. kit files are portable, eschewing globals. 42.c files assume globals are available.

One more suggestion, if you haven't already considered it. Read "Docs/TxRx Example.txt". If you don't mind having 42 as a "thick" front end, replacing the Tx/Rx socket interface with your back end might be easier than integrating the opengl code into something else. For what it's worth.

Regards,
-Eric (he/him)

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

No branches or pull requests

2 participants