[Scummvm-devel] Decompiler: Documentation feedback

[Max Horn]

Am 09.08.2010 um 19:43 schrieb Michael Madsen:
> 
[...]

> 
>> 
>>> You could add an engine-specific switch, but (and I admit I may be
>>> missing something here...) Boost.ProgramOptions does not appear to
>>> provide a good way of doing so, unless you're just going to send a
>>> string (or an array of strings) into the engine/disassembler/code
>>> generator and let it deal with them however it wants.
>> 
>> Hm, that's of course not that pretty either. But then having a "talkie"
>> command line switch in a decompiler seems not so pretty to me, either -
>> - no offense intended, I just mean that both feel quite hackish to me.
>> Now I read that you also are thinking about adding a platform option.
> 
> The "difference" is that talkieness and platforms can be applied in a more general fashion; it's not tied to a single engine. You can also add demos to that list; I don't know of any cases where that property would make a difference, but I can easily see that it could.

Hehe, seems we have exactly opposite views of what should be general and what specific :). In a nutshell, in "your" approach, there are specific properties (one being "talkiness", one being a list of "platforms") which can be applied to engines in general. In contrast, I am thinking more of having non-specific properties (subenegine", variants, whatever one would call them).

I just think that specific properties don't scale too well. They may work well for Kyra, and model its needs adequately, but they already don't do that for the SCUMM v5 setting, and I wonder what happens if one turns to say, SCI, which has tons of engine subvariants.

And, is there a way for my engine to signal that it does not support the talkie property? I guess not, so if the user supplies it, I'll just ignore it. Now for the platforms, which platforms would the decompiler know? All 19 listed in ScummVM's common/util.h ? Each of these (or whatever subset you pick) could then be passed to my engine. Now say that list contains Amiga, Mac, DOS, FM-TOWNS, because Kyra and SCUMM together need these (hypothetically). What is my engine (which only really knows DOS and FM-TOWNS, again hypothetically) supposed to do when it is told that the platform is "amiga" ?



> 
>> 
>> Hrm. How about this alternative suggestion then: Every engine class can
>> (optionally) provide a list of "variants" or "subengines". I.e. add a
>> new method which returns a (possibly empty) list of strings. Such as
>> "pc", "amiga", "talkie", "amiga-talkie", "pc-demo". The "-l" option
>> would print next to each engine the list of subengines (each could have
>> a custom description text). The user could *optionally* specify a
>> subengine via a new command line flag.
>> 
>> This way, you can combine both the platform selector and the talkie bit,
>> as well as cover the SCUMM cases I have in mind. Of course, this starts
>> to get ugly if you have lots of independent flags that can occur in
>> multiple combinations: If e.g. a game comes in
>> | {pc, amiga, mac} x {talkie, non-talkie} x {demo, non-demo} | = 12
>> variants, it would be nicer to have three separate flags, instead of 12
>> combined "subengine" names (also for the user, who would dislike having
>> to remember if it was "demo-pc-talkie" or "talkie-pc-demo" or any of
>> the other 4 possible orderings).
> 
> That seems like it's going to require some form of pattern matching to find the "best" available subengine. I can see the point in letting engines tell you what switches that can affect them, but I'm not completely sure it's a good idea to actually use subclasses for every combination; I suspect that the changes required for each one are relatively isolated, so perhaps it's better to do what is generally done in ScummVM itself and just use if statements where necessary.

I never had subclasses in mind here, to the contrary: My idea was that the "subengine" value would be passed to the Engine's constructor, so that it can set some internal flags internally. Though I guess one could have both, if one wanted to: These flags could be passed to a factor method for the Engine, which could then either pass it to the constructor, or choose among different Engine subclasses.


Cheers,
Max