| Age | Commit message (Collapse) | Author |
|---|
|
svn-id: r24343
|
|
svn-id: r24339
|
|
announce as supported. Future Wars is completable.
svn-id: r24321
|
|
svn-id: r24320
|
|
the linker dependency graph). Porters will have to update project files
svn-id: r23974
|
|
svn-id: r23888
|
|
copy protection if we know there were versions sold that either didn't have the
protection, or failed to include the information needed to get past it.
Besides, this particular bypassing doesn't work. The game appears to start
just fine, but the transporter early in the game is rendered non-functional.
svn-id: r23801
|
|
really is there. I hope this is the right way of fixing bug #1534073.
svn-id: r23660
|
|
* Modified about dialog to list all available plugins with their resp. copyright
* Modified about dialog credits to show the GPL last (like movie end credits do with their legal text, too)
svn-id: r23645
|
|
game detectors.
svn-id: r23558
|
|
* Renamed common.rules to rules.mk
* Removed explicit declaration of MODULE_DIRS in various spots (instead we let rules.mk compute it)
svn-id: r23275
|
|
Rationale: backend implementations belong to backends/, but portable APIs meant to be used by high level code is for common / sound / graphics / ... (compare also with backends/midi vs. sound/mididrv.h)
svn-id: r23274
|
|
svn-id: r22795
|
|
times per second.
This doesn't appear to make a visible difference on PC, but allows the game to run on PSP and probably several other consoles/ports that wait for 50/60hz vsync.
Since I'm not familiar with this engine I've added a 'FIXME' comment, because maybe this can be fixed/improved in a different manner.
svn-id: r22758
|
|
to be packed, so I've removed the packing and added the 'refresh' field to
AnimData instead of having it as a separate array.
On the other hand, animHeaderStruct and animHeader2Struct *should* have been
packed, but weren't. I've changed they way they are initialised so that the
packing should no longer matter for them either.
svn-id: r22651
|
|
recently added (cursor) palette manager) so that the cursor can be properly
restored after returning from the GUI.
If there's any C++ magic that can keep the backend functions from being called
by anything else than these managing classes, that would probably be a good
idea. Also, since the cursor manager keeps a copy of the cursor image, perhaps
there are at least some backends that will no longer need to?
svn-id: r22639
|
|
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
|
