Using OpenGL and Mojo together?
Monkey Forums/Monkey Programming/Using OpenGL and Mojo together?
| ||
| I'm just looking at doing some lower level rendering. Previously I've done this sort of thing by writing native functions but I thought I'd look at the opengl modules to see if this can be done at the Monkey level for OGL targets now. What I'm wondering is whether there's a model for using opengl.gles11 alongside standard mojo calls. Is there something that stores the mojo OpenGL state so you can go ahead and do your stuff and then restore that state after? |
| ||
| depends on the target. you can do your opengl calls in OnRender() and then glFlush() when you're done. for returning to mojo, i generally add these command per target (different per target, valid for V66): Function BeginMojo:Void() = "app->GraphicsDevice()->BeginRender" Function EndMojo:Void() = "app->GraphicsDevice()->Flush" This is changing in V67, so I don't know if it'll be available since some of the options are being locked under 'private'. |
| ||
| Thanks. So nothing has been officially added? Okay, one more mojo hack to maintain then. |
| ||
| So nothing has been officially added? no, and combined with the way Mark privatizes variables, it makes plug-n-play features difficult. |
| ||
| Muddy, I took the pragmatic solution and locked off all the games I have released to a specific monkey version. It avoided having to dump any blame on things I had no control over. |
| ||
| That's fair enough if you're looking at short enough dev cycles or your code is only used for one project. Neither is true for me though (sadly in the first instance). I do hold off taking newer versions of Monkey, and I'm certainly in no rush to take v67+, but I have to update occasionally or the merge pain gets worse, not better. I'm not sure what is meant by "dumping the blame" though. Blame for what? I just asked if there was an official path to using the opengl module alongside the mojo calls. It seems a relatively natural desire to want to be able to do that. As there is no official route and the required calls aren't publicly exposed in Mojo I've had to make the changes myself. If anything I'm taking responsibility for my own needs. |
| ||
| Fair enough. |
| ||
| I also stay a few steps behind the bleeding edge and only update occasionally. I think the 'lock-off' mode for releases is a reasonable option, though, you could just strip out anything extraneous from your Monkey dev directory and lock the release away with its own version of mojo. A good plan IMO if you've hacked the latter. Really it's just an insurance option: if you want to issue a quick bug fix you need worry only about that. Current projects and your own module updates can stay in sync with the version you're currently using. |
| ||
| Adam, how do you do that BeginMojo/EndMojo stuff? Do you have a small example and would that work with your Minib3d module at least for some targets? |
| ||
| @Xaron: I took a path of fewer changes but it's pretty much what Adam does. I exposed the graphicsdevice Flush() and BeginRender() calls and mapped them via new BeginMojo() and EndMojo() functions in graphics.monkey: Added to graphicsdevice.monkey: [monkeycode] Method Flush() Method BeginRender() [/monkeycode] graphics.monkey: [monkeycode] Function EndMojo() renderDevice.Flush() End Function BeginMojo() renderDevice.BeginRender() End [/monkeycode] The GLFW stuff works as is but the android native mojo code will require changes because the current BeginRender signature takes a gl context argument (for unknown reasons as it isn't unused). Then in my render code where I do my own OGL stuff I just do something like: [monkeycode] EndMojo() InitMyGLState() DoGLRendering() ResetGLState() BeginMojo() [/monkeycode] What you need to reset varies by target (and could change with mojo updates) so it's not exactly a no-worries solution. |
   |