What? I only copied the headers, static library, and a Makefile to build it (and similarly for zlib).

Oops, I didn't look at the content, just the amount of lines (>20.000)
BTW: You removed fdlibm without mentioning it in the commit message. That's not an issue, but it's better to document any (non-subtle) changes.

git submodules sounds like a good idea, since we won't have to have prebuilt stuff in the repo, and we can build the libs from source.

Yeah, compling nSDL, nspireio and the other two shouldn't take long.

Quote from: Vogtinator on April 29, 2014, 08:44:28 am

I updated to GCC 4.9.0 by the way and the problem with elf2flt sucking all RAM out (if iostream is used) is there again

What do you think about making our own tool to convert elf to bflt? I think everyone agrees by now that elff2flt is an unmaintained piece of crap.

It definitely is. With libelfELFIO that should be possible, IIRC tangrs already tried something similiar.
But I'd rather invent a better-documented format, with support for generic sections with attributes (e.g. for exceptions).
Basically elf, but without requiring symbol information for relocation.

As for using freetype in crafti, just choose whatever works best. If you think FreeType is a good choice, just take a look at the sample, and put whatever font you use in a header file using "xxd -i" so people don't have to copy an extra file.

I'll try some solutions. I'll probably end up rendering a font table with freetype into a buffer and use it to directly blit to the screen buffer.
Or without freetype, prerendered using CBFG.

Is this being compiled on a linux machine?

Yeah, I'm not using windows, even if I wanted to, I couldn't. I haven't got a license key anymore, let alone free space on my drive.

As I created the poll there was a checkbox "Allow everyone to change their vote" which I enabled.
Bug? Anyway, I reseted it.

Nice to see that I'm finally in the majority. 

Quote

For fonts, you can use nGC or Freetype (which works without any changes)

Does nGC support rendering into (raw) buffers with different width than the screen?

It maybe does, but never managed to do so. The OS simply uses a gui_gc_clipRect before gui_gc_blit_buffer in order to draw part of the 3D engine (splitted app for example).
gui_gc_blit_buffer is not that slow IIRC, Of course I never had the opportunity to test it with a real 3D buffer.

Two ways offer to you :
static char* screen_buffer[SCREEN_BYTES];
void draw()
{
  ngl(screen_buffer, scene);
  gui_gc_blit_buffer(gc, screen_buffer); /* syscall */
  gui_gc_drawString(gc, "H\0e\0l\0l\0o\0 \0W\0o\0r\0l\0d\0\0", 0, 10);
  gui_gc_blit_to_screen(gc); /* part of libndls */
}

static Gc text_gc;
void init()
{
  text_gc = gui_gc_copy(gc, 100, 100)
  gui_gc_setColorRGB(255, 255, 255);
  gui_gc_fillRect(0, 0, 100, 100);
  gui_gc_setColorRGB(0, 0, 0);
  gui_gc_drawString(text_gc, "H\0e\0l\0l\0o\0 \0W\0o\0r\0l\0d\0\0", 0, 10);
}

void draw()
{
  ngl(scene);
  gui_gc_blit_to_screen_region(text_gc, 0, 0, 100, 100); /* You can even redefine this function in order to handle alpha */
}


nGC uses the OS' font routines AFAIK which are slow and ugly

Slow because of syscalls, and in my second example the draw method doesn't use any syscall on time critical code.
Ugly ? Their code is mainly a top level API over Nucleus GRAFIX in order to define primitive like in Java's Graphic2D.
The only thing you need to bother with nGC is utf16 which is simpler to use with the String API.

I also hit a bug in GCC 4.9.0, but it should be faster now, as one of the major features in 4.9.0 is a optimized LTO.

What bug? I'm intrigued.

Quote from: Vogtinator on May 01, 2014, 05:06:31 pm

I also hit a bug in GCC 4.9.0, but it should be faster now, as one of the major features in 4.9.0 is a optimized LTO.

What bug? I'm intrigued.

A segmentation fault: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=61008

I have voted for water and lava

Well, with 7 votes this is probably going to be it. v0.9 will take a while, though. I want to fix most of the graphical glitches and add some more "stuff" I don't know yet.