> > > A potential fix is to change the minimap in GameGUI
> > > from an object to a pointer, and only create it in the first place if
> gfx
> > > exists.
> >
> > Which also only works because no minimap code is executed after
> > initialization ...
>
> I don't understand what your saying.
No problem, I'll try to explain it:
If you have a minimap point which is null and you want to execute code minimap
code you get a segmentation fault.
This is similar to what happens right now. We have this
GraphicContext pointer gfx
in our GlobalContainer class. This pointer is null in the runNoX case.
In src/GameGUI.cpp line 132:
minimap(globalContainer->gfx->getW()-128, 0, 128, 14,
Minimap::HideFOW)
We try to access this GraphicContext object through a null pointer and
get a segmentation
fault.
In the same way using a pointer for minimap will change nothing. We
have to check
whether the operations we want to do are valid under given conditions.
Yes thats the whole idea.
>If there is code being executed after initialization, then the second
will stop it,
>which is the proper way to do things.
No, it would produce a segmentation fault, because the pointer is null.
The idea is that code makes sure that what its doing is valid. If there is no mini map, don't try to execute code.
> The first is only a lazy hack that should work when there isn't any
> code after execution, but I don't know for sure with nox
And that is the real problem. It happens quite often, that new high
quality graphic
features are executed when low quality is selected, or that nox does not work.
We need a more generic way that forces the programmer to state under which
conditions a graphic object/function will work. An object that does
work with nox
must only access functions that work with nox. The same is true for low quality
graphics. If someone writes a minimap, he should care about either
writing a nox
case too, or state that this object is not conform with nox.
If I talk about stating something, I mean in a way that the compiler
can check this.
Alternatively this could be done with inheritance and different
objects for different
graphical options.
I fear everything else will be just a lazy fix and it won't take long
until it breaks again.
ps:
I didn't fix enough of the bug.
Glob2 is this segmentation faulting, because in its constructor it
tries to create a
DrawableSurface object. So my fix is too lazy to actually fix something.
--
Kai Antweiler
_______________________________________________
glob2-devel mailing list
address@hidden
http://lists.nongnu.org/mailman/listinfo/glob2-devel