kohlrak: My advice to you in this regard is C. You might get some convenience improvements with C++, but not much and you could run into issues with the "binary compatibility" bs coming up (might not, too, it just really depends on how OSes bother to handle the drama [i'm honestly hoping they straight up reject ISO's new standard whenever it comes out, 'cause it's absolutely not necessary to change this, and they're probably doing it so they can add all the internal junk that java, C#, and such languages have that tends to be more bloat than benefit]).
dtgreene: Fortunately, you can use
extern "C"
to define functions that use the C API, which I would not expect to change (and which is the easiest way to interact with other languages, since every mainstream language has some way to call C functions).
I don't know if that's going to remain the case, though. You'd think they wouldn't bother changing the mangling for C++ (as it is right now, it's just _Z[function name here][parameter suffices here]), but that's precisely what they want to do, and possibly change internal handling of certain types. They specifically cite this as a problem for "why we can't move forward," which indicates to me that this is indeed what they want to change.
kohlrak: I'm actually trying to write an example for you in php right now. I thought about this before, but I had some problems getting LLVM on my tablet (android, ARM) to take this. It could be my lack of experience with LLVM/GCC. I'm curious what you did, 'cause if it's cleaner it'll probably be less hacky than my current stumbling block of trying to figure out how to make php output an int (as an int instead of string).
The code I use is literally this:
.data
.global pixel_shader
pixel_shader:
.incbin "pixel.glsl"
.word 0
.global vertex_shader
vertex_shader:
.incbin "vertex.glsl"
.word 0
It assembles (using GNU assembler) on both x86 and ARM, as it doesn't contain any actual assembly instructions. The ".word 0" at the end of each part is there to ensure that the strings are null terminated, so that C doesn't get confused.
See, that's what I tried to do, but I had trouble actually exporting that.
Also, you have to be careful with .word, because a word in ARM is 4 bytes, not 2, where as it's 2 bytes in x86. For your null terminators, there, that's not a problem. And then there's also the ugly trouble of forcing it to export it since it tries to make a.out into an ELF instead, which isn't trivial on all systems. For example, on my one system, ld is not available, and objcopy wants a target. And, given it has a specific target machine, sometimes this doesn't start at offset 0, which can be a problem, since it can vary per architecture.
This isn't too bad if you're trying to embed it into your program, but if you're trying to use this to make a binary format for something external to the program itself, that's a problem.
dtgreene: I like Python's indentation, as it makes it easy to tell what code is part of which block, and it avoids bad indentation style. Also, indentation is easier to type than curly braces. (The only issues with this are when you try tpo mix spaces and tabs in the same program, which can cause strange error messages in some cases, and when trying to post code in places that eat whitespace.)
It can make it unreadable if you have a long object chain or want to spread a long function call out over several lines to comment on each parameter. Also, trivial things like a quick "fprintf(stderr, "File not found!\n"); exit(1);" can't be thrown on one line (which makes things seem far less verbose, as you'll see in the php code above). And, let's not get into the forever into egypt stuff with excessive nesting.
kohlrak: (why not use a quad at that rate?)
OpenGL ES doesn't have quads.
(Some platforms, like the Raspberry Pi, only support OpenGL ES (unless you use something like LLVMpipe).)
Oh yeah, forgot about that. Still, it's easier to make a pseudo-quad and map the image to that ("draw_quad(x, y, xsize, ysize, texture);") so that you only have to deal with it that way. They'll be quads as far as you're concerned, but you just have to write the code that makes a quad out of triangles that you then texture. And I did google the alpha channel thing and indeed gles supports alpha channels. And, of course, for performance you'll want to cache as much as you can. The less you touch the FPU, the better.