[Scummvm-devel] Decompiler: Documentation feedback

[Michael Madsen]

> -----Original Message-----
> From: Max Horn [mailto:max at quendi.de]
> Sent: Monday, August 09, 2010 10:19 PM
> To: Michael Madsen
> Cc: 'ScummVM devel'
> Subject: Re: [Scummvm-devel] Decompiler: Documentation feedback
> 
> 
> 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" ?

For talkie and demo flags, the way I see it, it's not about *supporting* talkie property, it's about whether or not the information *matters* to you. If one (or both) of these does not make sense for your engine, then you can simply ignore it; it doesn't apply to your engine and the output won't be affected.

For platforms, it depends. You either use some default code path (possibly outputting a warning that this hasn't been tested), and only use the platform field to determine whether a specific workaround needs to be applied (e.g. the difference for PC98 and FM-TOWNS in Kyra1), or you draw a hard line and throw an error if you get a platform you don't know (in which case you should probably state what you CAN handle). It depends on the platform; if you know there are lots of differences around across platforms, or you know that a specific workaround is required for some platform, but you haven't implemented that yet, then I'd go for the error.

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

Well, you should have just said so straight away. :) I can totally support that idea.

I think it might be good enough to just start with internal flags; choosing different subclasses would require rewriting the Engine factory to allow for that, and it doesn't seem like it would add much benefit; if you have to be that different in your handling for one platform, then it might be a good idea to *keep* them as separate engines.

Michael