Hi,

I know that you guys are probably going to tell me to check "Useful Prizm Routines" but I was wondering if we could take those routines (circele, rectangel, line, and plot) and put them in a file that can be use with #include?

This way it wouldn't clutter up the C file.

Any comments?

Yes, there's nothing wrong with that. To do it the proper C way, you should put all the graphics functions you want in a .c file, such as stdgfx.c. Then, prototype all of the functions in stdgfx.c in a file called stdgfx.h. In your main file, #include "stdgfx.h", and in your Makefile, add stdgfx.c as one of the sources. This way, GCC will generate <mainfile>.o and stdgfx.o, then link them together into <mainfile>.bin.

I had started compiling together such a library at one point; I'd share it, but it's really just a .c/.h set that copied and renamed most of the graphics commands in the useful routines thread. Plus, never compiled. It was a 30-minute project I got bored of and stopped working on. Perhaps it's time to actually follow through on it!

Yes, please

If you do so, be sure to have it in a public (D)CVS repository somewhere so that multiple people can contribute to it. Perhaps it could go in the same repository as Tari's Python work for the Prizm?

My work lives in the libfxcg repo. I'd be willing to accept some handy libraries into libfxcg, though it's very easy to build a static library.
Makefile sample:
Code:
Just build some object files and use ar to package them, then all you need is some headers for the public functions.

CVS: I'd absolutely go this route Partly because other people can work on it, and partly because I know I'll have to get other people to help me finish it when I (foreseeably) lose interest.

libfxcg: was actually thinking of making it a seperate "libfxcg-gfx" static lib all along, since over time I feel it'll be rather large and in turn make libfxcg large as well. Which would suck for add-ins linking against libfxcg that were like Periodic and only really used the graphical routines already in libfxcg!

There's no additional overhead for functions that aren't used, since it's a static library (assuming the final linking phase uses -gc-sections, which we do by default).
It would be a slightly different situation if we had a dynamic linker, but that's just wishful thinking at this point.

Later in the summer I'll probably try and port SDL_gfx and that does most drawing tasks.

Sounds good, I'm a big fan of SDL so even if it has a bit more overhead to use in terms of efficiency over the more primitive routines we have now, I'd personally be using jointly with the primitive functions I'm pulling together.

That being said, thanks for the info Tari, I actually didn't know that static libs only linked used functions into the binaries they're linked against. In which case, I can pull the routines together and organize them (as cleanly as possible) into libfxcg

Indeed, for programs that need a bit more graphics pizazz, I think that pSDL will be a great tool. I think for simpler programs, though, a graphics library based on the line/fill/rectangle/gradient/sprite routines would be great.

I definitely will not be able to work on that till august though so for now I have to work on fixing events which seem to be non-functional for now

Fair enough; best of luck on it.