Found on Blue Byte News Version III/97.
From README.TXT:
Dies ist eine Demo-Version von "Chewy - Esc von F5". Sie enthalt nur
einen kurzen Ausschnitt des kompletten Adventures. Wenn Sie wissen
wollen, wie die Geschichte anfängt und ob sie ein Happy-End hat, dann
fragen Sie Ihren Software-Handler nach der Komplettversion.
Translation:
This is a demo version of "Chewy - Esc from F5". It contains only a
short part of the complete adventure game. If you want to know how the
story begins and whether it has a happy ending, then ask your software
dealer for the full version.
This employs a "lazy" approach: the "format" for the credits stays
exactly as it was, i.e., perl code. Of course one may want to change
this to another format (e.g. YAML, JSON, XML; or also shell script or
AWK, like `configure.engine` uses). But I deliberately kept it simple,
to get a minimal change that is easy to verify. Any further changes to
e.g. the format can be layered atop this.
For each engine:
- Make a new folder detection
- Move detection-related files inside the folder
- Add a new module "enginename/detection"
- Add DETECT_OBJS here
- Adjust the normal engine module to remove detect_objs
- Adjust every file for the new changes.
This flag is removed for a few reasons:
* Engines universally set this flag to true for widths > 320,
which made it redundant everywhere;
* This flag functioned primarily as a "force 1x scaler" flag,
since its behaviour was almost completely undocumented and users
would need to figure out that they'd need an explicit non-default
scaler set to get a scaler to operate at widths > 320;
* (Most importantly) engines should not be in the business of
deciding how the backend may choose to render its virtual screen.
The choice of rendering behaviour belongs to the user, and the
backend, in that order.
A nearby future commit restores the default1x scaler behaviour in
the SDL backend code for the moment, but in the future it is my
hope that there will be a better configuration UI to allow users
to specify how they want scaling to work for high resolutions.
Various engine variables are passed down to sub-objects, but never used
currently causing compiler warnings. It is unclear if these are intended
to be used in future, but have removed for now, rather than commenting
out as that would be messier. Can be restored easily if necessary in
future.
Now that a lot of the game's resources have been figured out, it turns
out that using comic.tgp was a bad idea, as it's the same in both the
English and German versions. atds.tap contains all of the game's texts,
so it is probably the best candidate for detection
