[Scummvm-devel] OSystem changes

[Max Horn]

So since nobody seems to disagree, here's what I plan to do with 
OSystem. Porters, feel free to speak up if you perceive any problems, 
and/or if you would like to see other changes:

1) Use our naming conventions for methods in OSystem, too. So rename 
stuff like "create_mutex" to "createMutex". This is a fairly trivial 
change, and is easily done semi-automated.

2) set_sound_proc (might be called "setSoundCallback" in the future) 
currently has a SoundFormat param, which currently is always set to 
16-bit mode. I want to get rid of it. It currently servers absolutely 
no purpose and only causes confusion.

3) The "property()" method (and everything related to it) will be 
replaced by new explicit API. A draft of what I have in mind is this 
(imagine it being inserted into OSystem):
   ...
	struct GraphicsMode {
		const char *name;
		const char *description;
		int id;
	};
	
	virtual GraphicsMode *listGraphicsModes() const = 0;
	virtual void setGraphicsMode(int mode) = 0;
	virtual int getGraphicsMode() const = 0;
	
	virtual void setWindowCaption(const char *caption) {}
	virtual void openCDTray() {}
	virtual int getOutputSampleRate() const = 0;
	
	enum Features {
		kFeatureFullscreenMode,
		kFeatureAspectRatioCorrection,
		kFeatureVirtualKeyboard,
		kFeatureAutoComputeDirtyRects
	};
	bool hasFeature(Feature f) { return false; }
	void setFeatureState(Feature f, bool enable) {}
	bool getFeatureState(Feature f) { return false; }
   ...
Note that the term "feature" is not set in stone. We can just as well 
call it "property" or "attribute" (or something more fitting, I welcome 
good suggestions :-).
Anyway, I hope the API is self explanatory, if not, please don't 
hesitate to ask about specifics. Of course, in the final version I'll 
add doxygen comments to the API explaining what each method should do 
exactly.

This covers most of the PROP_* property flags, with the following 
exceptions:
* PROP_TOGGLE_MOUSE_GRAB:
     No need for this to be a global property/feature, it's completely
     internal to the SDL backend
* PROP_GET_FMOPL_ENV_BITS / PROP_GET_FMOPL_EG_ENT:
     For these I simply haven't yet decided what to do about 'em. They
     always seemed a bit like an evil hack... I never quite understood
     why a hack like that has to use an OSystem API, instead of simply
     adding an #ifdef to adlib.cpp and sky/music/adlibmusic.cpp
     On a slightly related side note, the OPLCreate calls in those two
     files are very similar, might pay off to extract them into a
     factory method (put into fmopl.h/.cpp).


Please voice your opinions soon so that work on implementing this can 
start eventually.


Cheers,

Max