Age | Commit message (Collapse) | Author |
|
the ability to select menu items. There will be cleanups later, but for now we
try to match the original.
svn-id: r22395
|
|
svn-id: r22264
|
|
Wars. (I had originally left them as question marks because I didn't know what
characters they were supposed to be.)
svn-id: r22259
|
|
subclasses to namespace Audio
svn-id: r22231
|
|
error code (the engine is now passed indirectly via a double pointer)
* Removed Engine_Empty (obsolete now that engines can return actual error codes)
svn-id: r22199
|
|
new getActiveDomain method that returns a pointer to the actual active *domain*
- Added Engine::_targetName whose value is computed from the name of the active domain
- Removed GameDetector::_targetName, instead code now uses either Engine::_targetName or the name of the active domain
- This in turn allowed for removing usage of GameDetector in many places
svn-id: r21916
|
|
svn-id: r21844
|
|
I walked back to the room where I first arrived. At that point, maskPtr was
NULL for reasons yet unknown.
svn-id: r21839
|
|
if, for some reason, messagePtr is NULL.
svn-id: r21833
|
|
responses. (Before, nothing would happen.)
svn-id: r21832
|
|
printing default responses to commands.
svn-id: r21829
|
|
svn-id: r21826
|
|
caused getObjectUnderCursor() select the wrong object because the object list
was no longer guaranteed to be sorted on priority ("mask").
In Future Wars, this made it difficult (impossible?) to pick up the tunic,
because the game would pick the bushes instead, even though the tunic had a
higher priority.
svn-id: r21825
|
|
svn-id: r21820
|
|
svn-id: r21819
|
|
svn-id: r21816
|
|
svn-id: r21815
|
|
the AnimData struct.
svn-id: r21809
|
|
The previous commit should ensure that the elements that need to be loaded are.
svn-id: r21774
|
|
element to the savefile, including data pointers. After reading the savefile,
it would then test if ptr1 was NULL, to see if it should load the object.
I've extended the savefile format with a byte to indicate whether or not ptr1
was non-NULL. This seems to fix the problems I had with with loading savegames,
but of course any old savegame is now even more broken than before.
I still can't seem to get out of the room with the machine, though. Another
regression when migrating the code from cinE, or just my ability to get past
this annoying, timed puzzle?
svn-id: r21772
|
|
instead of putting them in the current working directory.
svn-id: r21741
|
|
svn-id: r21733
|
|
thing to do. This replacement hopefully works as intended.
svn-id: r21724
|
|
svn-id: r21720
|
|
interface, so it's still even worse than in the original interpreter (just like
in cinE, presumably), but at least it no longer crashes when loading the saved
game, and hopefully the correct palette is saved.
svn-id: r21718
|
|
svn-id: r21699
|
|
svn-id: r21698
|
|
svn-id: r21697
|
|
svn-id: r21696
|
|
* When I introduced the getNext* helper functions I accidentally used
getNextWord() instead of getNextByte() in one case.
* When splitting the opcodes into separate functions, I noticed that Operation
Stealth has no opcode 0x40, yet it's used. So for now we only warn when
trying to execute an undefined opcode.
svn-id: r21695
|
|
svn-id: r21694
|
|
regressions, but hopefully not too many. While doing this, I noticed I had
gotten at least one of the stubs I added recently wrong. That's hopefully
fixed now.
svn-id: r21693
|
|
trailing semicolon (this helps certain tools to parse our code better)
svn-id: r21689
|
|
distinguish them)
svn-id: r21686
|
|
svn-id: r21683
|
|
function. It's now possible to choose between English and French menus, and the
command string preposition in English is "on", not "sur".
There are still plenty of hard-coded French messages to do with savegame
handling. I haven't done anything about them.
svn-id: r21682
|
|
svn-id: r21681
|
|
the opcode decoder a bit easier to read. The same change could be made to
decompileScript() as well, but I have a feeling that this function should be
made a standalone tool instead. Particularly considering how much memory it
currently uses.
svn-id: r21679
|
|
eight bits. Perhaps it is. But it seems to match the output from DOSbox when
running Future Wars, and I tend to trust DOSbox in such matters.
svn-id: r21658
|
|
svn-id: r21655
|
|
stubs should print a warning, though I may have missed some.
svn-id: r21654
|
|
to interact with the objects in the second room. We were passing the wrong
pointer to gfxConvertSpriteToRaw() in loadCt(), causing page3Raw (which I
believe is an "image" mapping screen coordinates to objects) to be wrong.
svn-id: r21646
|
|
generating mono data, and let it worry about how to handle it.
svn-id: r21645
|
|
command menu. There are still some other hard-coded French messages in the code,
though.
svn-id: r21634
|
|
objects that were actually loaded from the file, not the ones that were
skipped. This bug was introduced when porting cinE to the ScummVM framework,
and would cause Future Wars to crash after the copy protection screen. Quite
possibly other bugs, as well.
svn-id: r21632
|
|
svn-id: r21630
|
|
svn-id: r21629
|
|
member vars
svn-id: r21532
|
|
to ~250). Many greetings to eriktorbjorn, and have fun recompiling.
svn-id: r21500
|
|
svn-id: r21415
|