Funny coincidence. I've written a small 3D rendering engine for the ESP32 as well last week. It has standard 3d math, clipping, and rasterization of points, lines and triangles. all in ~1500 lines of code. The repo is not polished yet but you can find it here: https://github.com/aap/psiop
It's always exciting feeling to get some feedback from community, so here you go! The project looks fun, but could use a bit more docs. I was able to compile for esp but didnt test yet. I only have a cheap aliexpress esp with builtin lcd, might try to hack it
this is really cool thanks! totally i need of a good software renderer!. Not in c++ but this should be portable techniques i guess. my first attempts tryjng t draw 3d stuff to a framebuffer, needless to say, were so slow. didnt think it was possible to make something run that slow on a modern pc...
i am writing an operating system and want to make a software (batch) renderer inside that to draw things. i am not confident nor currently have the objective to port something like Vulkan and write a device driver. my video card will give me a framebuffer via legacy interfaces, so i think software renderer is my option to do 3d
You mention the point is to make it portable. Does the project have any other goals, like, what kind of games could be made with it, how fast does it need to be? Do you have any performance metrics to share?
Performance boosts and metrics I do intend to look into, in particular acceleration structures (probably a BVH?) for the ray tracer and more optimized methods (e.g. a better scanline triangle fill and some clipping algos) for the rasterizer.
As for portability, not sure yet, this is meant to more or less be a rendering/animation engine that is lightweight, probably portable to embedded processors like ESP32s?
Not OP, but I think AGPL is generally an excellent choice for my hard work that I want to showcase.
If I care about free software but also want to "protect" my work to prevent people from forking it without releasing their contributions because of strong copyleft. Many of my open source personal projects are licensed under AGPL.
AGPL makes no sense to me for projects that aren't focused on server use. This project is a good example of something that could just have a GPL license attached to it.
I personally don't use AGPL software if I intend on trying to expand on something as a business idea. I'd be fully willing to give back bugfixes and donate back, but I'm not about to hand off anything I pour months and years into to my competitors for free.
> I'm not about to hand off anything I pour months and years into to my competitors for free.
Library authors can pour "months and years" into their projects, and yet you expect them (but not yourself) to give away their code under more permissive terms, while you keep yours closed? The (A)GPL is a great choice because it forces people like you to either (1) open up your code or (2) pay for a closed-source license.
I don't expect anyone to do anything, but if they do I intend on respecting the license. I also expect myself to give back however I can. I just don't see how you dismiss someone else's efforts. It's like valuing a home you bought and did work on, solely on how it looked before you bought it. Even if you tore down most walls and redid the flooring and interior drastically.
If copyleft is desired, the EUPL is very similar to the AGPL, but isn't viral, so you can link it as a library to a closed-source program. It's also compatible with most open-source licenses.
Not sure if it's what the OP wants, but I think it's a neat license and I don't see it used anywhere.
I'm not actually a fan of make, I think mk is a much better language, but everything is relative. I still prefer make over any meta-build system or garbage like boost jam. In my experience the problem of modern codebases is that they're structured like crap in the first place. Too complicated and for very little real reason. OP's codebase is actually trivial, so the problem doesn't really exist. It would be trivial to adapt it to use msvc, but if you have make on windows, chances are you already have gcc so there's not much point unless you REALLY want to use microsoft's compiler.
It's inherently less portable as it relies on C++ and the cmake language is rather complicated, and thus making it harder to implement. Make and more preferable mk, are reliant on C, and are simpler languages making them easy to implement. It's simple portability calculus.
Portability-wise this was perhaps the case ~20 years ago but today I am not aware of any platform that doesn't have a decent C++ compiler so I don't think what you're saying is generally true.
I also don't agree on the second point - I don't see what makes the CMake "harder to implement" than make/mk. It's already implemented and all you need is a compiler, which we have plenty of.
Funny coincidence. I've written a small 3D rendering engine for the ESP32 as well last week. It has standard 3d math, clipping, and rasterization of points, lines and triangles. all in ~1500 lines of code. The repo is not polished yet but you can find it here: https://github.com/aap/psiop
It's always exciting feeling to get some feedback from community, so here you go! The project looks fun, but could use a bit more docs. I was able to compile for esp but didnt test yet. I only have a cheap aliexpress esp with builtin lcd, might try to hack it
Yeah I might make some docs for it soon.
this is really cool thanks! totally i need of a good software renderer!. Not in c++ but this should be portable techniques i guess. my first attempts tryjng t draw 3d stuff to a framebuffer, needless to say, were so slow. didnt think it was possible to make something run that slow on a modern pc...
thanks! super cool project to learn stuff from =)
"totally i need of a good software renderer!"
If I may ask, why?
Don't you like performance?
i am writing an operating system and want to make a software (batch) renderer inside that to draw things. i am not confident nor currently have the objective to port something like Vulkan and write a device driver. my video card will give me a framebuffer via legacy interfaces, so i think software renderer is my option to do 3d
Is this a recreation of the venerable POV-RAY https://www.povray.org/ (30 years old now, wow)?
povray is a raytracer, this is a rasterizer (like what openGL does, say). Different rendering techniques.
Well done!
You mention the point is to make it portable. Does the project have any other goals, like, what kind of games could be made with it, how fast does it need to be? Do you have any performance metrics to share?
Performance boosts and metrics I do intend to look into, in particular acceleration structures (probably a BVH?) for the ray tracer and more optimized methods (e.g. a better scanline triangle fill and some clipping algos) for the rasterizer.
As for portability, not sure yet, this is meant to more or less be a rendering/animation engine that is lightweight, probably portable to embedded processors like ESP32s?
Docs have largely been uploaded.
VSC? IS THAT A MOTHERFUCKING GEOMETRY DASH REFERENCE?!? :O
(sorry, I had to)
Read the readme and find out :3
Interesting! Some feedback:
- Try to make it clear in the description that it's software rendering (it's easy to miss this information).
- The readme should include a clear list of features.
- Be aware that the AGPL license might be a problem for many people.
Not OP, but I think AGPL is generally an excellent choice for my hard work that I want to showcase.
If I care about free software but also want to "protect" my work to prevent people from forking it without releasing their contributions because of strong copyleft. Many of my open source personal projects are licensed under AGPL.
AGPL makes no sense to me for projects that aren't focused on server use. This project is a good example of something that could just have a GPL license attached to it.
I personally don't use AGPL software if I intend on trying to expand on something as a business idea. I'd be fully willing to give back bugfixes and donate back, but I'm not about to hand off anything I pour months and years into to my competitors for free.
> I'm not about to hand off anything I pour months and years into to my competitors for free.
Library authors can pour "months and years" into their projects, and yet you expect them (but not yourself) to give away their code under more permissive terms, while you keep yours closed? The (A)GPL is a great choice because it forces people like you to either (1) open up your code or (2) pay for a closed-source license.
I don't expect anyone to do anything, but if they do I intend on respecting the license. I also expect myself to give back however I can. I just don't see how you dismiss someone else's efforts. It's like valuing a home you bought and did work on, solely on how it looked before you bought it. Even if you tore down most walls and redid the flooring and interior drastically.
If copyleft is desired, the EUPL is very similar to the AGPL, but isn't viral, so you can link it as a library to a closed-source program. It's also compatible with most open-source licenses.
Not sure if it's what the OP wants, but I think it's a neat license and I don't see it used anywhere.
> Be aware that the AGPL license might be a problem for many people.
Nothing prevents the author from selling closed-source licenses, as long as they retain sole copyright over the code.
> - Be aware that the AGPL license might be a problem for many people.
I'm more confused as to why it applies to this tbh. GPL would have sufficed no?
Working on some rudimentary docs right now, the README might also be updated directly.
If portability is a goal you might want to use CMake and Docker.
make is more portable than cmake. docker has zero value add from what I saw in the repo.
Make is quite a bit more headache these days to consume then make (in modern code bases anyway).
I'm not actually a fan of make, I think mk is a much better language, but everything is relative. I still prefer make over any meta-build system or garbage like boost jam. In my experience the problem of modern codebases is that they're structured like crap in the first place. Too complicated and for very little real reason. OP's codebase is actually trivial, so the problem doesn't really exist. It would be trivial to adapt it to use msvc, but if you have make on windows, chances are you already have gcc so there's not much point unless you REALLY want to use microsoft's compiler.
How about fixing the version of the compiler and the dependencies so you don’t get build errors ?
Yes it only works for Linux. But these days it’s pretty easy to get a Foam with WSL on Windows and Docker for desktop
Sticking with a Makefile is going get increasingly unwieldy for a large project
Definitely not true in my experience.
Want to describe your issues with CMake?
Maybe the community can help you.
It's inherently less portable as it relies on C++ and the cmake language is rather complicated, and thus making it harder to implement. Make and more preferable mk, are reliant on C, and are simpler languages making them easy to implement. It's simple portability calculus.
Portability-wise this was perhaps the case ~20 years ago but today I am not aware of any platform that doesn't have a decent C++ compiler so I don't think what you're saying is generally true.
I also don't agree on the second point - I don't see what makes the CMake "harder to implement" than make/mk. It's already implemented and all you need is a compiler, which we have plenty of.