vintagepc / MK404

A functional Simulator for Prusa (Mini/Einsy) Rambo based printers
https://vintagepc.github.io/MK404/
GNU General Public License v3.0
69 stars 9 forks source link

Makefile for c++ compiling #85

Closed leptun closed 4 years ago

leptun commented 4 years ago

I was trying to play a bit with a high level graphics library. It’s called raylib. Unfortunately, it needs c++ to function properly. Is it possible to compile to c++ as well or is the simavr source c only?

If it is possible to compile to c and c++ (a combination of both, just like in Prusa-Firmware), could you give me some indications as where to start?

vintagepc commented 4 years ago

Right now we're inheriting a bunch of templates from the parent SimAVR library (makefile.openg, makefile.common) and we link against the SimAVR core.

Technically what's required is having it build our stuff with G++ instead of GCC. It should be possible to decouple that, but I think modifying the existing makefile might get tricky.

I think my suggestion here might be to instead scrap the makefile for the project and instead use CMake, particularly for #79 as CMake is cross platform and it can then be used to generate a VS project, Qt creator .pro, or whatever.

I'm excited at this, I would not mind having C++ classes available for this so we can clean up a lot of the pointer overhead and cruft that standard C introduces...

Are you familiar with CMake? If not, I can take a crack at setting one up later. I've found it easier to alter and less obscure than regular makefiles to some degree.

Raylib says it's written in C99 though, that shouldn't need C++. We may just need to set a flag somewhere to use C99 instead of C89/C90 or whatever is currently in use.

What does raylib offer over OpenGL? I skimmed the page and it seems to be similarly low-level, so I'm genuinely curious.

leptun commented 4 years ago

I have absolutely 0 experience in anything graphical. I’ve never used openGL, so I’m not really sure what it’s capable of.

The idea was to just have a simple 3d void with fixed camera looking down at 45deg (the user’s view) and 4 independent “bodies”

I looked at the examples for raylib and it looks to me as if it’s extremely easy to create what I just said. The most complicated part might actually b feeding the drawing function the required data from the steppers and generating the obj files.

vintagepc commented 4 years ago

Hmm... seems to be a little higher level than openGL in terms of primitives. But of course I'm going to be partial to what I have the most (or this case, any) experience in. GL is pretty procedural, just like G-code so I don't think it's too hard to wrap one's head around. Except instead of filament, you're printing vertices XD

https://open.gl/drawing

Longer term before we get too graphics crazy it might also be worth starting to use some advanced core libraries like Qt just to avoid much of the rote low level stuff in terms of file manipulation, pointers, and whatnot. But that's a ways out and we can figure it out as we go.

vintagepc commented 4 years ago

And yeah, regardless of the graphics library we choose, the hardest parts will be getting the models in, and then the bits to draw.

vintagepc commented 4 years ago

Also... if it truly uses C++ then it's not an out of the box usage. You can't call C++ code from C, so we'd have to convert everything first.

leptun commented 4 years ago

@vintagepc Not sure where to write this... I think I'm giving up on raylib for now. I managed to create some of the basic examples and they worked in parallel to the simulation, but that's where the fun ends. As soon as I try to load a model from file I get a segfault on runtime. :(

vintagepc commented 4 years ago

Sounds fun... maybe post your model here and I'll give it a try with OpenGL

In terms of the parent topic (Makefile for C++) is that satisfied by the cmake change? I've been poking at the C++ conversion and the cmake build is setup to build .cpp files correctly

leptun commented 4 years ago

Cmake works perfectly now. I only had an issue once where the Einsy.elf became broken for some really odd reason. I just cleaned with make clean, ran make and then used cmake again and everything was fixed

leptun commented 4 years ago

obj.zip Stationary.obj contains all printer parts that don't ever move. It's rather large. xyzCalibration_cube.obj is exactly what you'd expect.

I originally had these models as SLDASM files. I can easily get you STEP and STL files. OBJ files are obtained from the STL files.

vintagepc commented 4 years ago

thanks, that looks like I can work with it.

3d-gussner commented 4 years ago

I had an issue with factory reset and changed https://github.com/vintagepc/MK3SIM/commit/363ff326a006f8160e8adddebbb91490ebbf15ef

hope that is okay.

vintagepc commented 4 years ago

Sure. Just note we'll be moving away from the makefile at some point. It's still there for convenience but functionality has already been moved to cmake.

since the cmake build resides in build/ I think make clean will take care of that by default; but if not we should add a similar cmake rule to that extent, e.g. a "make extra clean" that also removes the bin files. (This might not be something you always want to do, in cases where you would like to delete stale .o files but keep your system state)

leptun commented 4 years ago

I think I can close this as for now cmake has c++ support, while our Makefile doesn't.