I had problems getting values back from Lua to Java, it drove me mad for a while until I looked at some examples again and decided to try out another method of doing things; namely setting a global 'engine' to a Java object and just calling functions from script. Turns out LuaJava handles plenty plenty stuff behind the scene to deal with all of this.
So, with that in mind my below got ripped out and I set about making the gfx system go.
Currently the system has 2 whole classes!
- Actor which represents a graphic in the world
- Engine which does the grunt work
Actor basically holds an image and when asked draws it's self into the graphics context supplied.
Engine is, for the most part, a thin layer over the Java Graphics2D class, however it does transform state management and is slowly generating 'convinence functions' as I need them, such as renderActorTiled and a version of rotate which rotates about the center point of a given actor [smile]
Current test program just tests out these functions, so we have one ghost which floats across the screen, a line of tiled ghosts and one which moves as the first but rotating around it's own local center point.
This is all control via a 'render' Lua function as shown below;
val = engine:createActor("data\\ghost.png")x = 0y = 0dirx = 1scale = 1.0rot = 0.0function render() engine:beginObject() engine:translate(x,y) engine:renderActor(val) engine:endObject() engine:beginObject() pos = x - val:getWidth() if pos > 0 then pos = 0 end engine:translate(pos,val:getHeight()) xrep = engine:getWidth() / val:getHeight() xrep = math.ceil(xrep) + 2 engine:renderActorTiled(val,xrep,1) engine:endObject() engine:beginObject() engine:translate(x,val:getHeight()*2) engine:rotate(rot,val) engine:renderActor(val) engine:endObject() scale = scale + 0.01 rot = rot + 0.1 x = x + dirx if x + val:getWidth() > engine:getWidth() or x < 0 then dirx = -dirx endendOn another note;
On GUIs redux...
Quote:Original post by MARS_999
Hey Phantom, have you checked out gui-chan? I am using it now and it's great.
After I took a moment to stop thinking "4chan made a gui?" I went and took a look at this little library.
Having taken a look at the doxygen generated documentation I'm struck by one thing right away; Image loaders.
*sigh*
And this is where the library fails imo.
"But it needs images to display on buttons and the like!" I hear people cry.
"Yes, yes it does", I say, "but can't I supply my own data from my already intergrated image load?"
"But how would it know what store or call?" the reply comes back
"Easy", I say, "if you stay in C++ then use templates and program to the interface. Or if using a scripting language as a backend you don't have to worry about 'type' and just stick to an interface"
"But what about speed?" the predicable reply comes back
"the Unreal Engine is mostly script" I reply before walking away...
Or I would if that happened.
My point is, and this is something I've mentioned before, libraries like this shouldn't need to worry about these things. They should define an interface required and allow such interchangeable things as texture/image objects to be defined at compile time, certainly with C++.
Basically, there is no excuse for it.
Coupled with my thoughts that, frankly, C++ is the wrong language to hook all this stuff together with anyways; the benifits of a scripted backend should far out weight the runtime cost, which I very much doubt would be significant anyways.
So, the quest for the GUI continues, as there really doesn't appear to be a good one out there yet...
For now; back to Java...
