#8493 closed patch
New Lure of the Temptress module
| Reported by: | dreammaster | Owned by: | Kirben |
|---|---|---|---|
| Priority: | normal | Component: | Engine: Lure |
| Version: | Keywords: | ||
| Cc: | Game: | Lure of the Temptress |
Description
Hi everyone. As a part time project I've been gradually disassembling the executable for Lure of the Temptress, since it's now freeware, to make a ScummmVM module for it, and I'm now at a stage where I figured others might like to see my work.
So far, the full introduction sequence runs (without music), and the first screen is displayed (although without foreground objects like the player or any animations). The menu works, so you can see the credits or quit game.
The zip file attached to this message contains three files.. the new ScummVM Lure module, a new file 'disk0.vga' that contains resources I've identified and extracted so far from the Lure.exe file, and a zip file for a simple tool I wrote to create the disk0.vga from a copy of the lure.exe file.
To get the module up and running, you'll just need to uncompress the lure.zip file in your ScummVM folder and add an entry for it in the plugins.cpp file.
I'm currently in the middle of figuring out the formats for the room data - since I'm disassembling the original executable, this project isn't going to see rapid development, but I'm going to be sticking at it.
DreamMaster.
Ticket imported from: #1374870. Ticket imported from: patches/598.
Attachments (6)
Change History (32)
by , 19 years ago
| Attachment: | lure_scummvm.zip added |
|---|
by , 19 years ago
| Attachment: | lure-update1.patch added |
|---|
Update to the module to make it compilable under gcc
comment:1 by , 19 years ago
Excellent! I tried to run your module, but it required several fixes to compile under gcc. Also I split out some functionality out of your LureEngine constructor into detectGame() method, as it is the correct way to do. I.e. no file access should be in the constuctor because extrapaths aren't set at that time.
Then I went and killed most of the warnings. Also module.mk file was created.
I attach the patch file with all mentioned changes.
Your code isn't formatted consistently and also it isn't formatted according to our formatting conventions. See http://www.scummvm.org/documentation.php?view=conventions
I didn't dig directly into your code, but overall it looks impressive.
comment:2 by , 19 years ago
I'd also recommend renaming disk0.vga to something which makes it a bit clearer that this is for Lure -- e.g. lure.dat, or whatever.
comment:3 by , 19 years ago
Thanks for the pointer on formatting - I just generally followed the example of code I saw in existing ScummVM code. I'll go back and reformat it where necessary for the next release, and make the chances sev provided. I've been using Microsoft Visual Studio, and barring some problems I had with access violations I had with calls to stdio functions, it's been great for debugging my code.
As for the filename, I can easily change it; I figured that since the only other required files for Lure are disk1.vga through disk4.vga, that naming the support file disk0.vga would fit in well. But I guess for someone having to download it, it would be better for it to be clear as to what game it's for.
Work on the room format is already well underway.. I've figured out the code that loads in the graphical layers for a given room and am now starting to figure out how animations in a room work, not to mention the player.
comment:4 by , 19 years ago
Just as a heads up: As soon as the issues mentioned here are fixed (mainly, the code formatting and the things for which Eugene already provided a patch), the engine could probably be added to CVS...
comment:5 by , 19 years ago
Hey thanks. I've spent some time formatting the code, and I intend to try installing gcc on my computer so I can make sure the code compiles properly in it as well.
As for the decompiling work, I've made the following progress in decompiling the executable / extending the ScummVM module. I can now: * Decode basic room data to get a room's graphical layers * I've added a debug key to cycle through available rooms * I've decoded the string encoding method * I've added the ability to show hotspots in a given room, as well as the right click menu for actions. * I've also gotten the room description to work when the Look command is selected.
I'm still in the middle of trying to decode the animation format.. it's somewhat complicated by the fact that the raw data of animations are stored separately from the details of their position and size, and are loaded via a simplified scripting engine.
It's very kind of you to offer putting it into the CVS. What with Christmas and all coming up in a few days, I obviously won't have a lot of time to work on it, but shortly after Christmas I'll see about submitting a new version for you all to review.. with the new functionality added, it'll provide more oppurtunity for people to play around with the game.
comment:6 by , 19 years ago
Attached is the new release of the Lure module. It has the following new functionalities:
* Basic animation support. Some of the animations are still glitchy, and all are currently being animated even if they shouldn't, or shouldn't be animated repeatedly. * You can change the current room by using the + or - key * The right click menu for Look and Status. The Look action will give the room description. The Status menu, rather than showing the inventory, will currently give a list of the hotspots for the current room * The cursor can now detect room hotspots and give their description. It will also show their actions if they're right-clicked, although their functionality hasn't been implemented yet * I've added a debug menu accessible via F1 that currently has two options - to toggle showing information on-screen, and changing to a specific room number
Please note I'm currently on holiday with only limited Internet access at the moment, so I haven't yet had a chance to try installing GCC. Thus I've only been able to verify that it compiles under Visual Studio. If someone could validate it and provide an updated Makefile, my thanks. Remember that there's now a debug subfolder where I've started putting in code that will be only for debugging functionality.
by , 19 years ago
| Attachment: | lure_scummvm.2.zip added |
|---|
comment:7 by , 19 years ago
Well, it's _strictly_ MSVC-specific. First thing where it bails out is union Register_Union(). Properly it should be defined as following:
#pragma START_PACK_STRUCTS
union Register_Union { union { uint16 v; struct { uint8 l; uint8 h; } GCC_PACK s; }; } GCC_PACK;
#pragma END_PACK_STRUCTS
I.e. use of our portable macros for struct packing and avoid useage of unnamed structures.
But. This is not endian-safe and should be redone. It just will not work on Macs and handhelds which are big-endian.
Will look into compiling it further, as that struct is used all over decode.cpp, so too many places to fix.
Another thing. Fingolfin mentioned that this is a good thing to have in CVS, but please, do not create unnecessary directories there. I.e. all you debug stuff could be prefixed with something like debug-blah.cpp
comment:8 by , 19 years ago
Well, made it compilabel and runnable. Great stuff! Patch is attached. I didn't fix warnings, though.
It is not a good idea to use x() and y() as class members, as I get these
lure/anim.cpp:57: warning: declaration of 'y' shadows a member of 'this'
Also there are many similiar to above warnings on local level. Those are very unsafe.
Another class of warnings is:
lure/game.cpp:134: warning: deprecated conversion from string constant to `char*'
I get lots of these.
Also please, investigate these warnings:
lure/disk.cpp:128: warning: comparison is always true due to limited range of data type lure/game.cpp:79: warning: comparison is always true due to limited range of data type
min() is not portable, so is itoa(). I replaced first one with our portable MIN, and second one with sprintf().
Also I eliminated bunch of #pragma pack()'s, though these generally should be avoided if possible for the sake of alignment-aware platforms. Use MemoryReadStreams instead of those, particularly in disk.h, anim.h. Fore lure.cpp it is better to use readXXX() and writeXXX() methods of class ReadWriteStream, where File is subclassed from. And as I mentioned, pragma in decode.h should be avoided at all.
Please, always keep your CVS tree up to date. There were recent changed in MIDI stuff, so your midi initialization was obsolete. Fixed that as well.
Also, please, give unique names to attached files as long as they stay here, so there will be no confustion on which version particular file belongs to.
comment:9 by , 19 years ago
Thanks Eugene :-).
As for the string stuff, the proper type would be "const char *" (just mention it because a lot of people get tripped by that one :-).
comment:10 by , 19 years ago
Thanks for the help people; I'm definitely going to get GCC installed before the next major release, because obviously MSVC is suppressing a lot of the warnings that I should take care of. I'll also be looking at making the animation decoder a bit more generic - it's a good point about endian issues; now that I've got a code base that works (if only in certain circumstances), I'll work on making it generic without needing to use a register structure.
comment:12 by , 19 years ago
I'm still hard at work on it :). One of the things I've been working on is making the game properly platform independant, such as wrapping raw data file structure access in READ_* macros. I'm also still going to rewrite the animation decoder to use proper variables rather than the register kludge in the previous version.
Of course, I've been interspersing this with further work of disassembly of the Lure executable and doing some enhancements to the module source. These include the following:
* I further understand the way hotspots are animated - I've reimplemented the simplistic script interpreter used by the game which allows the specification of a sequence of instructions for changing the frame, position, etc. of a hotspot. So now, for example, the drip in the first room actually falls properly.
* I've also mostly reimplemented the script engine used by the game. The script language, for example, is used to load out of room hotspots such as the Skorl actor that moves between rooms. I also suspect that the script engine will be used to handle the responses to the various actions you can do on hotspots.
* I've mostly decoded the data structures for room exits.
I'm also currently trying to see if I can decode and implement either some basic player movement and/or hotspot action handling for the next release.. something that will give some basic playing ability. Give me another week or two, and I'll try for another release.
by , 19 years ago
| Attachment: | scummvm_lure_v3.zip added |
|---|
comment:14 by , 19 years ago
Presenting the next version of my ScummVM Lure of the Temptress module, with lots of new functionality. It includes:
* Basic walking support - Click on any part of the screen and you'll walk there. Note that I haven't yet decoded walking boundaries, so you can walk anywhere on the screen. It's currently somewhat of a functionality prototype that ensured my understanding of the movement frames information for characters was correct. I've also added a keypress of '*', which will bring Diermot to whatever screen is active (using the +/- keys)
* Room layering for Walk behind functionality. It's not perfect yet.. Ratpouch, for example, doesn't show up currently because he's considered to be behind the rack rather than on it, but for most other situations, you'll properly show up behind those things that you should.
* Many hotspots now work, both for looking at and right-click actions; I'm still in the process of disassembling the code for the various actions and methods the scripting language can call. So, for example, you can now set your bedding on fire, or get the bottle and fill it up from the barrel. NOte that for now, I don't make Diermot walk to the hotspot (or be present in the room) before doing an action - it's just done.
* Preliminary support for room exits.. this was something I'd started on before switching over to working on hotspots and room display - the cursor should correctly highlight over any exit, but the actual moving between rooms still needs some work.
* I've properly encapsulated all of the resource readings with READ* calls, so there shouldn't be any problem running the module on big-endian systems.
* Finally, I've installed MinGW and fixed up any problems compiling the code under GCC - thanks to MD5 for his excellent article in the Wiki for how to set up everything in Windows XP.
Enjoy :)
comment:15 by , 19 years ago
Is "lure.dat" = "disk0.vga" (which create_disk0.cpp talks about? Speaking of which, that tools in not yet endian safe (I am only pointing this out because I just noticed it -- it can easily be fixed at a later time, no worries :-).
comment:16 by , 19 years ago
And two more quesions: * Do you also have a patch that modifies configure / Makefile / etc.? * Do the french/german versions of Lure work, too? * If not, any idea how hard it would be to get those supported, too?
I can't currently try the module because I lack disk0.vga... I tried renaming lure.dat to disk0.vga, but that didn't seem to work either :-/
comment:17 by , 19 years ago
OK, I figured out that the error message is wrong -- it actually was looking for "lure.dat" when it complained about disk0.vga.
It still dies here because it tries to open entry 16130 (=0x3F02 = ALT_PALETTE_RESOURCE_ID) in lure.dat. This is due to an endian bug in Disk::openFile: You are reading whole structs with a single file read, but that leaves entries in the wrong endianess. When reading structs, you must either read them one field at a time; or run a loop that "fixes" all entries on the fly after reading; or modify all of the code to only access those fields with the correspondinf READ_* macros.
comment:18 by , 19 years ago
I added this to the end of Disk::openFile; now I see a few screens with images/text before it crashes :-):
#ifdef SCUMM_BIG_ENDIAN for (int i = 0; i < NUM_ENTRIES_IN_HEADER; ++i) { _entries[i].id = FROM_LE_16(_entries[i].id); _entries[i].size = FROM_LE_16(_entries[i].size); _entries[i].offset = FROM_LE_16(_entries[i].offset); } #endif
comment:19 by , 19 years ago
Thanks for the feedback people. I thought I'd handled all the big endian cases properly. Looks like I missed one
In answer to the questions: * disk0.vga was renamed to lure.dat - it was suggested earlier that since it would be needed as a separate download to play the game, it should be clearer what game it was intended for. * I'm aware that the create_disk0.cpp still has the wrong name now, and isn't endian compliant - it wasn't as critical since I'm already providing the extracted lure.dat, and it's still an evolving work in progress, so I'm providing it at the moment mostly for those that are curious. * I'll likely eventually support the other languages of Lure as well, but for now, it's simpler for my disassembly efforts to focus solely on the English version. When the time comes to handle the other language versions, it should be, hopefully, a simple matter of figuring out the offsets at which each of the needed tables start in their executable so I can extract them properly. * Fingolfin, sorry about missing the old filename in that error message, and thanks for providing the code fragment. I am aware of a problem in my current handling of active hotspots that can cause problems when switching rooms - I'm still trying to hunt down the exact cause. * Sorry that I didn't think to include a diff.. I'll make a new release tonight with the fixes applied and include one.
comment:20 by , 19 years ago
No worries. And the different language stuff is a low priority for now, of course, I was simply curious :-).
From my point of view, this is almost ready to go to CVS... Maybe we just wait with this till after we switched to Subversion (well, OK, techincally that means it'll never be in CVS, but rather in SVN... err, but whatever... :-)
comment:21 by , 19 years ago
I've attached a patch file containing the changes I've made to the core files to add the lure module in. It also contains fingolfin's code fragment to change disk.cpp to add the big endian fix in.
I don't mind waiting to have the module added to the repository.. as cool as it would be to have my work finally part of the official build, I can just as easily work with my local copy for now and keep posting zips at regular intervals.
by , 19 years ago
| Attachment: | scummvm.patch added |
|---|
comment:22 by , 19 years ago
I added the lure engine and data file to ScummVM SVN.
The lure engine is currently disabled by default.
The create_disk0 tool should be added in the future, once it is more complete.
comment:23 by , 19 years ago
Paul, I hope you are willing to work on this from inside the ScummVM subversion repository.
If you want to join up, please contact me via email (fingolfin AT scummvm.org) ASAP, so that I can add you.
comment:24 by , 19 years ago
| Owner: | set to |
|---|---|
| Status: | new → closed |
comment:26 by , 6 years ago
| Component: | → Engine: Lure |
|---|---|
| Game: | → Lure of the Temptress |
Lure of the Temptress plugin module