Use the md5 hash to directly load the game without having to iterate through the game list. Also rename detect_game to load_game and move the resource loading to resource.cpp.
Version 2 of the engine already has at least one opcode where the
implementation slightly changed and I had to have a version check.
To make things cleaner, there are new v1 and v2 game classes that
derive from ComprehendGame, and the opcode map setup has also been
moved into them.
Currently, the V1 engine has all the opcodes implementation. I need
to start reviewing the opcode calls in v2 again, and shift stuff
that is actually unchanged to the base class shared by both 1 & 2
- Creating an instance of GLK requires searching through all sub-engine detection lists.
- So, these must be there at the time of creating an instance of GLK.
- Hence, all these objects will ONLY be skipped from static-detection, if GLK itself is static.
- The above point is because it will need to avoid duplicate symbols.
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.
The resource file format Hugo uses has named entries.
Because of this, the original Glk code added to Hugo
does a whole mess of reading in a picture, then copying
it to a dummy pic file with a dummy number, just so a
call to glk_image_draw could detect it.
Since this isn't the first time I've had to deal with
named resources, it ended up being cleaner to add a new
variation of glk_image_draw and glk_image_draw_scaled
that can take in a string image parameter. That way, I
was able to set up an archive class to represent the
resource file, and pass the resource name directly
without worrying about dummy picture numbers & files
All the other sub-engines use the engine or authoring system
name, not the name of particular interpreters. So I felt it
best to rename frotz to zcode for consistency