Additionally:
- Operation Stealth specific: Make makeActionMenu() use canUseOnItemTable.
This would seem to be the correct way according to disassembly
(Although there is of course a possibility that I have overlooked
some part of the code).
svn-id: r47508
- Combines mouse position and button state fetching
from two branches (allowPlayerInput / !allowPlayerInput)
into a single loop with a little more exotic while-clause.
NOTE! Added manageEvents-call into the unified version although
there was no manageEvents-call in one of the versions that was
combined. Tested a little and didn't seem to matter, but hopefully
won't cause any regressions!
- Limit first possible 'renderer->setCommand(commandBuffer)' call
to Future Wars only (Checked with FW & OS disassembly).
- Combined all cases of 'left and right mouse buttons are down'
into a single if-clause (All those cases call makeSystemMenu).
svn-id: r47505
These are used as a sort of a backup for the
mouse position (x, y) variables 249 and 250.
Future Wars's VAR_MOUSE_Y_MODE and Operation Stealth's
VAR_MOUSE_X_POS_2ND (251) clash and that's possibly
why executePlayerInput currently works incorrectly
with Operation Stealth. More reverse engineering
is needed...
svn-id: r41915
- Made waitForPlayerClick updating more like in the original.
- Moved removeMessages to after the frame drawing in main loop hoping to be more like the original.
- Added an additional test to Operation Stealth's implementation of overlay type 2 drawing.
- Added an additional parameter incrementing and testing to Operation Stealth's removeMessages.
Hopefully this won't cause any regressions in Future Wars!
svn-id: r33686
Previously prompt didn't get updated all the time,
like e.g. when selecting EXAMINE and moving the
cursor over to DOOR and then moving the cursor to
a place where there was no selectable object. The
prompt would've still shown "EXAMINE DOOR", now
it shows just "EXAMINE" which is correct AFAIK.
svn-id: r33637
- Implemented Operation Stealth specific part of getObjectUnderCursor
which handles negative frame values.
- Fixed a test case (Should test for ydif <= 0 although tested for ydif < 0).
- Made part-value be anded with 0x0F in a test case to comply with disassembly.
- Added comment about a test case which isn't present in the disassembly.
Removing it makes things crash sometimes so letting it be.
svn-id: r33620
Renamed functions:
* addScriptToList0 -> addScriptToGlobalScripts
* executeList0 -> executeGlobalScripts
* executeList1 -> executeObjectScripts
* purgeList1 -> purgeObjectScripts (Also added a clarifying TODO to this function)
* purgeList0 -> purgeGlobalScripts (Also added a clarifying TODO to this function)
svn-id: r33409
- Emulating the Future Wars savegame loading routine and hoping for the best.
- Fixes an array out of bounds access when loading the global scripts.
Now the loading crashes in the mainloop in processSeqList!
But at least we got a bit farther this time. More fixing to come...
svn-id: r33404
- Music related settings and adBgVar0 & adBgVar1 aren't loaded currently.
Modified resetEngine to also reset more of the Operation Stealth specific variables.
Added getter for background scrolling value.
Changed additional background indices 1 & 2 from byte to uint16.
Made savegame loading functions return !in.ioFailed() as return value instead of true as previously.
svn-id: r33379
Added a stub for loading the Operation Stealth's temporary savegame format (Not yet implemented).
Made mouse cursor change to a disk icon when loading a savegame and back to normal after its done.
svn-id: r33362
Added backgrounds' name saving (8 names in Operation Stealth instead of just 1 like in Future Wars).
Added 256 color palette saving and restoring (One of the palettes isn't properly handled yet though).
svn-id: r33349
- Changed savegame loading related functions to use SeekableReadStream
rather than InSaveFile so MemoryReadStream can be used transparently.
- Fixed loadResourcesFromSave to load multiframe animations correctly
and to load 0.11.0/0.11.1 Future Wars savegames which used a slightly
different format.
- Added a savegame format detector that tries to detect between the old
Future Wars savegame format, the new one and a broken revision of the
new one.
- Changed makeLoad to first load the savegame fully into memory and only
then handle it (If the savegame's packed then it's unpacked first). If
the packed savegame can't tell its unpacked size (i.e. it's using zlib
format) then we'll try to load up to 256kB of the savegame data.
Thanks to wjp for his help with nailing this release critical bug.
svn-id: r33192