Spring RTS Engine

Basically, I think that there should be a simpler Lua call-in for drawing stuff that we want displayed in front of the camera, for UI elements. Having spent the last few hours reading over how this is apparently getting done, I'm of the opinion that we should just have a standardized call-in for this:

Spring.DrawToPOV(string mode, location x, location y,[options])

"Mode" should be 'text' or 'image'.

Location x/y are relative positions on the screen, to keep things simpler.

[options] depend on Mode:

If mode == 'text', then options should include:

Color. in RGBA values, 1.0 --> 0.0

Font. Self-explanatory, should use the VFS (I saw notes indicating that this isn't currently true).

Size. Self-explanatory, should use the same sizes as current gl.Text.

imageAlpha(nameoftexture, basically turns on gl.Blend, uses the texture to apply an alpha).

imageColor(nameoftexture, uses an image to color the resulting text).

So, an example would be Spring.DrawToPOV('text',0.5,0.5,options.font='LucidaSansSerif',options.size = 30,options.color = 1.0,1.0,1.0)

Which would draw some text in the center of the screen, size 30, in white.

If mode == 'image', then options should include:

Color. in RGBA values, 1.0 --> 0.0

imageAlpha(nameoftexture, basically turns on gl.Blend, uses the texture to apply an alpha blend to the rectangle).

imageColor(nameoftexture, uses an image to color the resulting rectangle).

sizex, sizey(size of rectangle, in pixels xy).

Spring.DrawToPOV('texture',0.5,0.5,options.color = 1.0,1.0,1.0,options.sizex = 30, options.sizey = 30, options.imageColor = 'mybitmap.png',options.imageAlpha = 'mybitmap_alpha.png')

Which is a 30 by 30 pixel white rectangle using mybitmap.png to provide color information (via GL_ADDITIVE, I'm thinking).



Putting something like this into Spring would make building and deploying GUI elements a lot more straightforward, and would mean that there would be a lot less Lua code running, to do these things. It'd be a win-win for developers wanting to do more GUI stuff, imo.

You could write these functions in Lua as well and include it as library for example.

Yeah, but why bother, when it'd run faster in the engine anyhow?

That may not be totally true, the lua compiler could optimize away the slowdown defeating your whole argument. Either way the work is already being done in lua every time UI is drawn as it is, what your proposing is moving the code duplication into a standard lua file.

gUi?

iceui works like a charm for my lua guis.

Not all of us want to use IceUI, and inherit the choices made there.

At any rate, I've actually made some progress on this, on the rectangle-display part. That was surprisingly easy, thankfully.

Good to hear it, I want to use soemthing like this as well.

Um, what are you suggesting, a wrapper for gl.TexRect and gl.Text that can be called outside of DrawScreen and stll draw on the screen or something? Seems silly to me.

Keep in mind that the gl calls are just thin wrappers, there's very little overhead and probably none that would be removed by merging it all into one function.

Also your proposal just makes it harder to read and AFAIK doesn't even qualify as Lua syntax (options.sizex = 30 does not qualify as a parameter AFAIK).

Instead of that unreadable mess you use for your image I'd just write Having a separate color and alpha image is nonsense, there's a reason formats like PNG and TGA support an alpha channel, just merge it into the same file (I'd wager drawing two textures like that would waste more time than your dreaded if-statements).

Seriously, drawing stuff on the screen is trivial. Making buttons clickable is a headache because you can't do that with a gadget and need interaction between widgets and gadgets for that.

Um, what are you suggesting, a wrapper for gl.TexRect and gl.Text that can be called outside of DrawScreen and stll draw on the screen or something? Seems silly to me.

Meh, you'd be able to use it in synced code, within Gadgets, among other things. I'm not saying it'd be a magic cure-all or anything, it'd just make the process a little less clunky.

At any rate, there are plenty of workarounds, as you've said. I'm still working on GUI stuff for P.U.R.E., and this was an issue that kept coming up, is all.

Calling it in synced code would be silly, the synced code doesn't run once per video frame so the graphic would flicker on and off all the time.

This really looks MORE clunky to me than the regular code. Ever heard of MVC?

No, it'd just run the whole frame, lol. At any rate, seeing how I'm a minority of one on this, I'll just keep working on the Lua side of it.