Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

tsoding.org

Post reply on HN
Print view View original

31–40 of 96 posts

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

#31

Post by Brian_K_White »

jandrese wrote: post #11
kazinator wrote: post #6

Earlier quoted context omitted.

It looks like olive.c is a "single header" library. They chose a .c suffix rather than .h. If OLIVE_IMPLEMENTATION is defined before including "olive.c", then the full implementation is produced. Otherwise, just declarations, so that it behaves like a header file. It's a valid technique. If you have a library all in one source file, the requirement to have a separate .h doubles your file count. One small reason to ha…

This feels far messier to me than just having a .h file.

In this case, 2 files is a failure and blows the whole point. 2 files means a tgz and might as well be 50 files.

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

#32

Post by collegeburner »

mcmuffin6o wrote: post #4
jandrese wrote: post #3

It pains me to see #include at the top of the file. It makes the project feel like a toy.

Sorry, why does it make the project feel like a toy? I'm not trying to argue, I just don't understand. Is it because you're including a source file instead of a header file?

single-file libraries almost always feel like toys because most serious projects i'd want them integrated into a real build system. vcpkg is a good one these days for c/cpp. nothing wrong with a toy library ofc.

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

#35

Post by TillE »

collegeburner wrote: post #32
mcmuffin6o wrote: post #4

Earlier quoted context omitted.

Sorry, why does it make the project feel like a toy? I'm not trying to argue, I just don't understand. Is it because you're including a source file instead of a header file?

single-file libraries almost always feel like toys because most serious projects i'd want them integrated into a real build system. vcpkg is a good one these days for c/cpp. nothing wrong with a toy library ofc.

Unless it contains C++ templates, it's fairly trivial to compile a "header-only" library and use it as normal, even in unusual cases where the author has made no effort to support that.

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

#36

Post by MobiusHorizons »

andai wrote: post #17

Does this use WebGL2? It doesn't run on my phone (which does support WebGL 1). Edit: According to the JS source file it appears to be a plain 2D canvas. Now I am even more confused, those should definitely load! https://github.com/tsoding/olive.c/blob/master/js/vc.js

If you read the linked article, it is a c cpu rendering library compiled to web assembly.

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

#38

Post by mrweasel »

kazinator wrote: post #20
jandrese wrote: post #11

Earlier quoted context omitted.

This feels far messier to me than just having a .h file.

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?

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

#39

Post by p1necone »

skulk wrote: post #5
dlivingston wrote: post #2

Cool project! What’s the motivation? Since it eschews any graphics API, is it safe to assume this only does CPU-based rendering?

From demos/triangle.c ( https://github.com/tsoding/olive.c/blob/master/demos/triangl... ) // This idea is that you can take this code and compile it to different platforms with different rendering machanisms: // native with SDL, WebAssembly with HTML5 canvas, etc. The goal seems to be to maximize portability.

Unfortunately only portable to systems with fast CPUs though. Although I guess rendering simple 3d shapes probably runs just fine on low end hardware.

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

#40

Post by unwind »

KMnO4 wrote: post #30
jandrese wrote: post #3

It pains me to see #include at the top of the file. It makes the project feel like a toy.

Just wait till you find out that you can do: const char *s = #include "test.txt" ;

Sure, but only if the text file looks like a C string literal, i.e. starts and ends with double quotes (which would make it into a weird text file).

Doing

    const char *s = "
    #inclued "test.txt"
    ";
won't work, since the preprocessor won't interpret directives inside string literals of course.

In many assemblers, there is a directive called "incbin" which pastes in unstructured binary data at the point of usage. I just found a very clever C and C++ wrapper [1] for that, which gives you an INCBIN() macro. Nice!

[1]: https://github.com/graphitemaster/incbin

Post reply on HN