Re: [glob2-devel] Optimization suggestions

[Erik Søe Sørensen]

Kai Antweiler skrev:

> > 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.
>  

I believe there is another issue with the --nox option - that it 
combines three behaviour changes:
- Load a game automatically
- Don't use GUI
- Stop after $n game steps (or game end); maybe repeat from start $m times.

These behaviours are more or less orthogonal (though "don't use GUI" 
implies "load a game").
Indeed, --host also does "load a game".
So: instead of one flag, GlobalContainer::runNoX, and the associated values
   runNoXGameName, runNoXCountRuns, runNoXCountSteps
it might be better to have more telling names, separating the behaviours:
 - runNoX      // Graphics is disabled when this is true
 - autoLoadGameName // auto-load happens when this is non-null
 - doAutoStop   // Auto-stopping (and perhaps repeating? Maybe this is 
not the best name then) happens when this is tru
 - autoStopRuns, autoStopSteps

/Erik