Abstract input and rendering

[dazKind]

In my case I have my own 3d game-engine that uses foo3d and lime.

Currently gameconsole has a heavy dependency on openfl/flash when it comes to input and rendering.

It would be nice if those could be decoupled/abstracted in order to enable a user to roll custom implementations. It would require to add an extra layer of interfaces/root classes that would have to be derived and filled with api-specific code.

That way the console could be used with non-openfl-based projects.

As far as the actual implementation, it could be done in a similiar way like foo3d's renderdevice(https://github.com/dazKind/foo3d/blob/master/foo3d/RenderDevice.hx) and it's specific implementations(https://github.com/dazKind/foo3d/tree/master/foo3d/impl) via conditional compilation and typedefs.

Is that something you guys are interested in? Opinions? :)

[tiagolr]

Id always like have the console not depending on openfl and your idea seems very doable with some effort.

I'll decouple the rendering of the console for now, and create the lime rendering device.

After that I'll be very grateful to get some help on input + rendering using other libs.

Thanks for the suggestion!

[dazKind]

Awesome! Let me know if you need help.

[tiagolr]

Hey @dazKind i just finished abstracting input and rendering.

Now the only two classes that depend on openfl are GCInput and GCInterface.

I wouldn't worry too much on how the input and rendering classes are chosen, there is always a macro for that (#if openfl - is one of them).

It would be very interesting to have other solutions that don`t need openfl to make the console ready for other haxe projects (maybe even using STDIN and STDOUT may be possible?)

Glad if you can help with that, in any case the console is ready to do so, only GCInput and GCInterface public methods need to be implemented.

PS - in the future the console may use hxscript for more control over the application and data, then it will be awesome.

[dazKind]

Hiho @ProG4mr,

sounds cool! I'm gonna review the new code over the next week and see what it gonna be :)

[dazKind]

Ok, I had a closer look.

I just finished https://github.com/dazKind/hx-nanovg and now Im looking into using it with gameconsole.

What do you think, should there be a way for the User to supply input and rendering implementations, like through GC.init()?

As for the implementations I think it would be a better idea to create a general interface for input and interface which the specific implementations implement. Or fill the current GCInterface with #ifdefs and make the user derrive the class and override the functions if he needs custom stuff. Though, that could look very dirty.

Anyway I just forked the lib and will give it a shot. Do you have any preferences on the lib-design that I should keep in mind? Or can I modify the internals as I see fit? Ideally I'd submit the result back in pull-requests.

[tiagolr]

Hey,

Well now that you say it, it can be done via macro but doing GC.setRendering(IRenderMechanismClass) before everything else may work fine aswell.

The interface i agree as it makes things easier to maintain forward.

I would vote for that, an Interface and using GC.setRendering(IRenderMechanismClass) or even GC.init(IRenderMechanismClass) (optional parameter).

Sounds like a rough plan, but with more or less additions it may be enough. The default rendering or compile flags (if needed) may become more evident later.

Need assistance on anything? The interface? Let me know.

PS - Crazy work you're doing with nanovg and also foo3d (works great on my brower) and others, great great stuff!

[tiagolr]

Closing this for now.

[dazKind]

Hiho,

Thanks for the feedback! Much appreciated!

Not sure about how you would tackle it with a macro, but I quickly wip'ed up the interface-version. See https://github.com/dazKind/gameconsole/commit/f1f2bf4dcccf12bdd571578b1474f46614fc4cc6

Let me know if you have any thoughts on this.

[tiagolr]

Hey, it looks good, one question: you sure it needs #if flash || openfl on GCInput_Flash and GCInterface_Flash? I thought maybe when you compile the project without using those two classes they won't compile and it won't ask for openfl? If thats not the case well done anyway.

Looking forward for the opengl rendering, got version 4.0 mostly ready with hscript support and command registering, is working great, can even do stuff like object1.x = Math.sin(object2.y) , all types of haxe expressions, math, homework, everything.

btw it is #if (opengl || flash) on GCInput_Flash, should be openfl no?

[dazKind]

oh! thats a typo! Gonna fix it.

yes, the #ifdefs should be not needed upon closer inspection.

One thing thats missing right now is a crossplatform textfield(logic, no drawing). Once I have that the implementation should be straightforward.