Issues using OpenGL with an AI

[aeonios]

I had some problems with painting the threatmap being pathologically slow (as in dragging spring down to 1fps) using java's built-in graphics functionality, so I ended up implementing my own GL-based 2D graphics library because there wasn't one that I could find.

While I got the library basically working I'm having problems using GL from the AI due to the fact that all of its code is called from events. A GL Context created during init() becomes unreachable from update(), and if I try to unbind the context at the end of init to make it available later it causes spring to crash immediately after init() returns (some graphics-related dll error).

Does anyone have any idea how to deal with this sort of thing?

[AF]

I believe you're the first to try this, but AIs have never been given a render/draw callin. My recommendation would be to draw it in a widget or gadget, and send the data over the interface

[lamer]

I think mantis issue is related. The heck glfwMakeContextCurrent(NULL) for? Try

Code: Select all

previousContext = glfwSomethingGetCurrentContext();
...init...
glfwMakeContextCurrent(previousContext);

Regardless, CircuitAI's DebugDrawer.cpp proves that context switch works.

[aeonios]

I think mantis issue is related. The heck glfwMakeContextCurrent(NULL) for? Try

Code: Select all

previousContext = glfwSomethingGetCurrentContext();
...init...
glfwMakeContextCurrent(previousContext);

Regardless, CircuitAI's DebugDrawer.cpp proves that context switch works.

Tried it, failed. glfw does not see spring's context so I can't save/restore it. It just ends up binding to no context which crashes spring again.

You can only have one context active in a thread, and each context can only be active in one thread at a time. Therefore in order to pass a context from thread A to thread B first you have to unbind it from A (using glfwMakeContextCurrent(NULL)) and then make it current in B. For whatever reason the events that AIs are called through behave like threads wrt gl context, so if I create a context during init() it will no longer be available during update().

Also, I can save and restore the GL context that I manage, but I cannot make spring do the same for its own.

EDIT: I think a better solution might be to spawn a new thread and keep all my GL content there. That way (in theory) spring couldn't tamper with it anymore. On the other hand that requires putting all of the ai's implementation behind synchronized methods. x.x

[lamer]

You can only have one context active in a thread, and each context can only be active in one thread at a time.

Not exactly, threads has nothing to do with context. In simple case: there is GPU controled by OpenGL which is a state machine. Context describes its state. All there is to do is properly switch state descriptors (contexts). Here's how it is possible to achieve:
On init:

Code: Select all

previousContext = glfwSomethingGetCurrentContext();
aiContext = glfwSomethingCreateContext();
glfwMakeContextCurrent(aiContext);
...init...
glfwMakeContextCurrent(previousContext);

On update:

Code: Select all

previousContext = glfwSomethingGetCurrentContext();
glfwMakeContextCurrent(aiContext);
...update...
glfwMakeContextCurrent(previousContext);

Context switch in AI already done and working (except it goes through SDL bindings, like Kloot mentioned):
Circuit's init, update, release.

Though switching context has own cost (not sure if that cost matters if it's done once per second or so).

EDIT: With gadget and AI<->Lua communication you don't even need to switch context. OpenGL in spring-AI is an ugly hax.

[AF]

I'd recommend lua <-> AI comms. AIs themselves are intended to be headless, with a handful of call-ins to allow for limited debugging. I'd much prefer it if AIs sent the relevant data to the game in such a way that it's stored in the replays. Imagine an end user giving you a replay and being able to run the replay and see all the data displayed without needing the AI installed, just the widgets. It'd be a massive boon to AI debugging and tweaking

[aeonios]

I tried using glfwGetCurrentContext to save and restore spring's context, and spring still crashed. I'm not entirely sure why, but it's probably because I'm using lwjgl/glfw instead of sdl. I also tried running all of the openGL code in separate threads and binding the context to each as needed, which crashed both the ai and spring.

Using lua is stupid. AIs don't have the rights to use lua, and I'd have to have my stupid hacked drawing gadget accepted into zk stable even though the ai isn't even part of the game right now. That also pisses me off because I just spent 3 weeks writing a stupid 2D graphics library so that I could make this work. Not to mention I'd have to take extra measures to avoid cheating and the lua gadget would be horribly disconnected from the ai's main logic.

At this point the only thing I could try would be to either port the library to SDL (which I have no idea about, except that it has a java interface.. probably) or to give up on having a debugging interface at all and use direct arrays to store threatmap data.

EDIT: nevermind, the SDL bindings for java are terrible and don't include anything remotely related to openGL. Arrays it is.

[gajop]

Using lua is stupid.

+1
AIs should still be able to run in headless. I guess this is only for your development needs.

Your thing seems like a bug/feature request.

EDIT: I've read up on the mantis issue you made. Seems you're a bit out of luck

[hokomoko]

Headless runs LuaUI.

[Kloot]

Not OpenGL though (all stubbed), so relying on it+Lua for your AI's decision making would give you a nasty surprise in HL mode anyway.

[AF]

OpenGL is a graphics library, it shouldn't be used to perform AI logic. Visualising what's happening inside an AI is tooling, and the AI interface is ill suited to raw OpenGL work, as is rebuilding the entire lua UI toolchain in a new interface and language

Using lua is stupid. AIs don't have the rights to use lua, and I'd have to have my stupid hacked drawing gadget accepted into zk stable even though the ai isn't even part of the game right now. That also pisses me off because I just spent 3 weeks writing a stupid 2D graphics library so that I could make this work. Not to mention I'd have to take extra measures to avoid cheating and the lua gadget would be horribly disconnected from the ai's main logic.

That would be stupid, you'd write a gadget that hands stuff off into widget land, and have it do nothing but provide a method to hand off data to widgets. Having the gadget itself do the rendering would be a logistical nightmare, running your AI debugging on every single machine.. it makes no sense. Widgets are the far better approach.

Said gadget would also be useful for other purposes that are unrelated to debugging and tweaking AI performance

[aeonios]

OpenGL is a graphics library, it shouldn't be used to perform AI logic. Visualising what's happening inside an AI is tooling, and the AI interface is ill suited to raw OpenGL work, as is rebuilding the entire lua UI toolchain in a new interface and language

I'm not the first to use GPGPU and I certainly won't be the last. That said I give up on this crap. Arrays seem to be fast enough in general and actually getting GL to work without breaking spring is something I'm not going to bother doing. I've already wasted 3 weeks of my time doing things besides making my AI better and I'm sick of it.

[Kloot]

GPGPU can be done with more libs than just raw GL.

We've all wasted time on something at some point or another, get over it.

[AF]

Ah you're not interested in rendering things visually in the engine, you mean to use stuff like OpenCL? I see