2025-07-22 06:39 CEST

View Issue Details Jump to Notes ]
IDProjectCategoryView StatusLast Update
0005016Spring engineGeneralpublic2015-12-28 11:56
Reporteraeonios 
Assigned To 
PrioritynormalSeveritycrashReproducibilityalways
StatusclosedResolutionwon't fix 
Product Version100.0 
Target VersionFixed in Version 
Summary0005016: Unbinding GL Context Causes Spring to Crash
DescriptionI've been trying to get an openGL based 2D graphics library working for my AI. Threatmap drawing was dragging the game down to 1fps so I needed something faster.

Unfortunately because of the way AIs are called through events, each event behaves as though it were a separate thread (from OpenGL's perspective) and context passing is necessary. However, when I try to unbind the context (using glfwMakeContextCurrent(NULL)) at the end of init() it causes spring to crash as soon as init() returns.
Steps To ReproduceRun the AI (Zero-K): https://www.dropbox.com/s/8ucfp1t8igjdapf/ZKGBAI.7z?dl=0
Additional Informationinfolog: http://pastebin.com/yV5atv6y
TagsNo tags attached.
Checked infolog.txt for Errors
Attached Files

-Relationships
+Relationships

-Notes

~0015390

Kloot (developer)

Erhm, what?

A context needs to be associated with a GL-targetable window. Windows are handled by SDL, Spring only ever creates one and doesn't expect an AI to delete its context. Your lib is not going to be able to manage this properly unless it also has SDL bindings.

Use the DebugDrawAI interface?

~0015392

aeonios (reporter)

Last edited: 2015-12-22 09:38

View 2 revisions

DebugDrawAI isn't an interface the last time I checked, just an empty handle you can check to see if the ai should be drawing its debug info or not. That's irrelevant since the AI needs to draw threat whether or not any ui is enabled, because it queries the threatmap image (drawn offscreen to an FBO) as a database for making decisions.

EDIT: The issue is that spring does not save/restore its own context when calling the AIs, which prevents the AIs from managing their own. Even if I used SDL (and I won't) it probably would not work right, nor would that be the correct way to handle this situation (because an AI has no business babysitting spring's state when it doesn't control what spring does).

~0015393

Kloot (developer)

Last edited: 2015-12-22 11:26

View 2 revisions

"DebugDrawAI isn't an interface the last time I checked, just an empty handle you can check to see if the ai should be drawing its debug info or not."

Nothing in this sentence is true.


"needs to draw threat whether or not any ui is enabled, because it queries the threatmap image (drawn offscreen to an FBO) as a database for making decisions"

Use a gadget to draw into an FBO texture and read back from it if the threat array is not even kept in main memory, and AI<->Lua communications to exchange the data (commands to draw circles/rectangles/whatever) that needs to be drawn/read.


"The issue is that spring does not save/restore its own context when calling the AIs"

The issue is that AIs should not be messing with GL contexts to begin with, rather than Spring not saving/restoring its own *for every callin* on the off chance there is a rogue AI wanting to do GL operations present.


"it probably would not work right, nor would that be the correct way to handle this situation"

It would work right because at least one other AI has been down this road before. Theoretical correctness or practical progress, your choice.


As said above and in the forum thread you still have the option of letting game-side Lua handle your AI's drawing needs. I suggest you look into that.

~0015404

abma (administrator)

for the reference:
"As said above and in the forum thread" ->
https://springrts.com/phpbb/viewtopic.php?f=15&t=34177

~0015405

Kloot (developer)

seems no longer relevant anyway
+Notes

-Issue History
Date Modified Username Field Change
2015-12-21 18:26 aeonios New Issue
2015-12-21 19:24 Kloot Note Added: 0015390
2015-12-22 08:17 aeonios Note Added: 0015392
2015-12-22 09:38 aeonios Note Edited: 0015392 View Revisions
2015-12-22 11:22 Kloot Note Added: 0015393
2015-12-22 11:26 Kloot Note Edited: 0015393 View Revisions
2015-12-28 11:52 abma Note Added: 0015404
2015-12-28 11:56 Kloot Note Added: 0015405
2015-12-28 11:56 Kloot Status new => closed
2015-12-28 11:56 Kloot Resolution open => won't fix
+Issue History