Live data from Hacker News

Olive.c: a simple graphics library that does not have any dependencies

tsoding.org

81–90 of 96 posts

Re: Olive.c: a simple graphics library that does not have any dependencies

#81

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!

Hell, half the letters in alphabet is not implemented in that glyph list. That is a weird place to leave a work halfway done. I wonder if he only added the letters for his hello world

Re: Olive.c: a simple graphics library that does not have any dependencies

#82

Earlier 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?

Yes, I can, and so can you, without a doubt.

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

#83
post #21

Nice to see tsoding on the top of HN, this guy does amazing streams and youtube video

I agree, he's pretty great. Really intelligent guy.

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

#85

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

As a long-time beginner student of several Slavic languages, I like that word play too, with ".c" being "ts". It makes me wonder what missed opportunities there are for C library names with a funny pun.

Re: Olive.c: a simple graphics library that does not have any dependencies

#86
post #23

this 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

Nice website. Looking forward to the next rasterization article!

Re: Olive.c: a simple graphics library that does not have any dependencies

#87
post #67

Earlier 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…

I'm not giving this library as an example of very fast code. I mean, it's really cool, but at the moment it doesn't even use SIMD (which dramatically improves performance).

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

#88
post #68

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

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 with PortableGL are mine not his.

Re: Olive.c: a simple graphics library that does not have any dependencies

#89
post #15

Nice! 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

Minor correction/clarification, the library doesn't depend on SDL, it just writes into a 32 bit color frame buffer, but all the demos/examples use SDL for getting it to the screen since that's the best option. The test suite just writes frames to disk as png images to compare against expected for example.

Re: Olive.c: a simple graphics library that does not have any dependencies

#90
post #68

Earlier 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…

My bad, I used "castrated", it is not what I really wanted to say. I should have said a subset of opengl features. Namely, it is not a software GL implementation you can run an opengl4 3D game on (only those horrible c++ diarehas which are llvm with things like llvmpipe or the other one from intel are supposed to be able to do so).
Post reply on HN