LÖVE

ivan wrote:Nah, we haven't done batching yet

Hmm ... I must have thought of another engine, then. But yeah, I agree with you ... batch rendering wait for a long while.

Another 2D primitive problem: how to set the color on each vertex in order to draw gradients? We don't need this feature right away (or ever), but the current interface should be created in such a way that this extension is possible later without breaking consistency.

Another 2D primitive problem: how to set the color on each vertex in order to draw gradients? We don't need this feature right away (or ever), but the current interface should be created in such a way that this extension is possible later without breaking consistency

I've done a little research in this area. Gradients are not that difficult to implement. There are different types of gradients too, but for a simple linear gradient you would need a list of primitives (onto which the gradient is to be mapped) a rect (for the corners of the gradient area) with rotation (direction) 2 colors and possibly a 'pan' value.
Gradients are actually quite similar to mapping a texture onto a bunch of primitives. By the way, looking at the Love docs I see that you don't have texture mapping. Will there be a way to draw a portion of an 'image' onto the screen?

ivan wrote:

Another 2D primitive problem: how to set the color on each vertex in order to draw gradients? We don't need this feature right away (or ever), but the current interface should be created in such a way that this extension is possible later without breaking consistency

I've done a little research in this area. Gradients are not that difficult to implement. There are different types of gradients too, but for a simple linear gradient you would need a list of primitives (onto which the gradient is to be mapped) a rect (for the corners of the gradient area) with rotation (direction) 2 colors and possibly a 'pan' value.
Gradients are actually quite similar to mapping a texture onto a bunch of primitives. By the way, looking at the Love docs I see that you don't have texture mapping. Will there be a way to draw a portion of an 'image' onto the screen?

I know you didn't ask me, but that functionality has been on the repo for some time

Ehe. ^.^)' We actually forgot to expose that function to Lua ... so yes, it's there, but currently unavailable directly. (You can use Animation to generate subimages.)

Will be fixed in next release!

Hmm, complex polygons.. gradient vertexes.. it's starting to sound less like primitive shape rendering and more like you're trying to emulate OpenGL's shape system.. which could be the way to do it.
You start a mode (for the sake of simplicity you have lines and fills only) and then you just specify vertex positions, setting colors as you go. It wouldn't be the end of the world to wrap OGLs own functions, but is that really what we want to do? Seeing as the majority of the graphics used will be created beforehand (talking for myself only, if you have any wonderful plans for the future involving shapes and such then please share) I just need some way to show basic shapes in single colors. Nothing much else...
Perhaps more complicated shapes as we go along, but perhaps we can do this: Or is transferring arrays across the lua chasm impossible?


Note: I pulled that code out of my ass, so if that is not how you create an array in lua, please forgive me. I am still sick, ffs.

Unless you absolutely need >100fps, don't worry about transferring arrays. (yes, yes, rawgeti, or not, whatever.) My suggestion for coping with all that would be to just have a tables with x,y,(z?,)r,g,b,a, ... clipped to the intersäction of features of your underlying layer. And then, when you need to spray this at GL (I assume DirectX is similar) you just copy it to a full-featured array, setting each value to the value from the table, or the previous. (then gldrawarray() or wtf)

E.g. line({}, {}, {}), line({{}, {}, {},}) would draw a non-triangle (0,0),(0,0),(0,0) in the default (or previous) color.

But that's a bit out there, I'd be more interested in having a few (half-done? open-ended?) kits, like square tile machine, isotile-machine, a more lüxurious input system with input-mappings-stack, menu-system, etc. But all those thing will wok themselves out when there's a first game with any of those things.

Now that I think about it, a nice R2 vector class, together with M33 matrices perhaps? That way, one could treat positions as atomic values. Axis-aligned rectangles might be nice any number of things, AABB<->AABB intersection tests, etc. But that's all your fun part an' allyall ain't doin too bad so far...

aes
edit: I am error: M33 needed for translating R2.. d'oh

Yeah, maybe something like:
And iterating the table in C isn't that hard. From the reference manual:
No problem.

By the way: your avatar is quite epic.

rude wrote:No problem.

Yes, of course, but I was thinking of what happens after that. If you do glBegin() ... glEnd or glDrawArray. I'm thinking the right way to do it (later, much later) is to keep special vertex- and vertexarray classes to keep this tidy and speedy. But that's Premature Optimization, so let's not worry about it.

The thing which does worry me a little is that there are no general 2d transforms. With a more square transform system moving the 'camera' to zoom in on a new level, for instance, would be a snap. As it is, keeping track of x,y,z,Θ,scale separately is as good as it gets, and even then you need to queue your own drawing to respect z.

rude wrote:By the way: your avatar is quite epic.

Thank you! (Being drunk helped... )

Hehe, okay. So you want general 2D transformations: Or were you thinking C++ classes?