The TODO section at the end of olive.c shows that there's lots more to do, and decisions to make about how much to do (e.g. what about bezier curves?), but that's quibbling: it is refreshing (and educational) to see everything here done in such a perfectly self-contained way. Godspeed!
Olive.c: a simple graphics library that does not have any dependencies
81–90 of 96 posts
Re: Olive.c: a simple graphics library that does not have any dependencies
#82Earlier quoted context omitted.
Sure, but let's look at the larger picture. If you have one file, then that's your deliverable. You can host that file somewhere, send it as an e-mail body, drop it into a paste-bin or whatever. It is one self-contained unit. If you have two files: .h and .c, the use scenario may be simpler. Not a lot though. And now youu have two files which have to stay together somehow, yet remain distinct. If you combine them in…
Can you do something like what SQLite does an squash the .h and .c into one file, but also have multiple files for those who are doing development or just like separate files?
If I wanted to distribute a single file library, but have the two file option for users, I'd make it so that a specific Awk one-liner produces the two. For instance, the file might look like this:
#ifndef FOOBAR_LIB_H_D3B94F3C
#define FOOBAR_LIB_H_D3B94F3C
// header stuff here
#endif // FOOBAR_LIB_H_D3B94F3
#if FOOBAR_LIB_IMPL
// impl here
#endif
Then to people who want two, I would say, just run this command in your shell and paste the content into it: awk 'BEGIN { print "#include \"foobar.h\"" > "foobar.c"
print "#define FOOBAR_LIB_IMPL" > "foobar.c" }
/#ifndef FOOBAR_LIB/,/#endif.*FOOBAR_LIB/ { print > "foobar.h"; next }
{ print > "foobar.c" }'
that way I wouldn't need a build step on my end to generate parallel files.I would have the extra build step if it were a large project of multiple .c files that I wanted to deploy as a single file for the users who want that. (Not only would I build the single file out of multiple files, but also have some test cases which actually use it. Things have ways of breaking when you combine files, like giving the same name two two static variables or functions in different files.)
Re: Olive.c: a simple graphics library that does not have any dependencies
#83Nice to see tsoding on the top of HN, this guy does amazing streams and youtube video
It's a damn shame that he's unable to get paid from Twitch and Youtube due to the war.
Re: Olive.c: a simple graphics library that does not have any dependencies
#84I also found this Cairo-like vector graphics library that runs in a shader interesting: https://www.shadertoy.com/view/lslXW8
Re: Olive.c: a simple graphics library that does not have any dependencies
#85The name is pronounced as "olivets" which is a Ukrainian word for "pencil" ("олівець"). From the readme.
Neat.. of course it seems obvious now, but that's funny - I'm Ukrainian and I think that without explicit explanation it would have never occurred to me to read, let alone pronounce it this way - the dot before the extension somehow puts an insurmountable boundary after "olive".
Re: Olive.c: a simple graphics library that does not have any dependencies
#86this is very impressive, how is this done? the executable is only a few hundred KB and it runs for me, wasm is doing the magic here but I don't know too much about how the process works. I added -I/usr/include/SDL2 to build.sh, made sure wasm-ld is in place, and it builds and runs smoothly.
It's a simple software rasterizer. If you're interested in writing your own, I've written a tutorial explaining the basics. https://magcius.github.io/xplain/article/rast1.html
Re: Olive.c: a simple graphics library that does not have any dependencies
#87Earlier quoted context omitted.
It depends how fast “fast” is. PCs in the 90s could run games like quake in lower quality mode with lower framerates, but they ran. CPUs that we have now are many orders of magnitude more powerful, so imagine what you can do with that. Though most games don't bother so we don't really have actual evidence.
Quake used hand-coded assembly for blitting pixels. That could be a bit less efficient when using this engine. I would expect multi+GHz CPUs hardware to be able to overcome that, though, especially if you’re happy with the tiny (for today) screen resolution of Quake. Quake also did a few hacks to stay performant ( https://en.wikipedia.org/wiki/Quake_engine#Engine_design_and... ). If necessary you would have to do the…
Also, I think handmade hero started with a software renderer. Not sure how far they went with that, but I remember Casey mentioning once that software rendering is viable if you do it right. Certain art styles are easier to do as well — I'm not expecting PBR to be fast, but you could pull off a cel shaded look with simple lighting, and make it look good.
It's also worth mentioning that even with portable APIs like OpenGL, drivers are terrible and porting to other operating systems (and even other GPUs!) can be a chore. Software rendering can be an asset in those cases.
Re: Olive.c: a simple graphics library that does not have any dependencies
#88Earlier quoted context omitted.
It's an implementation, not an API.
... and it is opengl-ish, namely seriously castrated (shaders). Borrowing maths from Mr. Bellard's tinygl.
And the only math from Bellard's TinyGL that I use is his clipping code, maybe 80 lines of code give or take. Not to diminish Bellard at all, if anything I'm saying any problems with PortableGL are mine not his.
Re: Olive.c: a simple graphics library that does not have any dependencies
#89Nice! PortableGL is also great, OpenGL api that is defined in entirely in C and writes the “framebuffer” into an SDL window https://github.com/rswinkle/PortableGL
Re: Olive.c: a simple graphics library that does not have any dependencies
#90Earlier quoted context omitted.
... and it is opengl-ish, namely seriously castrated (shaders). Borrowing maths from Mr. Bellard's tinygl.
Depends on how you define castrated. It's not like using C or C++ is really limiting and using a C++ math library (like my own rsw_math or more complete glm) lets you basically write it in GLSL. It's not like there's anything you can't do. And the only math from Bellard's TinyGL that I use is his clipping code, maybe 80 lines of code give or take. Not to diminish Bellard at all, if anything I'm saying any problems wi…