The previous code made it possible to accidentally jump through thin objects
like laser barriers because it was not testing that the avatar could get to the
start point of the adjusted move. Added a sweep test to ensure the start point
is also valid.
Added support for InstallShield v6 cabinets, which can be made up of
multiple files. The interface for creating an Archive instance now takes
the base filename (e.g. the "data" in "data1.cab") for all cabinets,
including single-file ones.
Co-Authored-By: clone2727 <236052+clone2727@users.noreply.github.com>
Co-Authored-By: Walter van Niftrik <615114+waltervn@users.noreply.github.com>
Opcode 0x3E pushes a byte on to the stack as a 16-bit value. Previously we
assumed it should be treated as an unsigned value, but the code for conveyors
in Crusader clearly treats it as a signed value - they move at +3 or -3 per
tick. Confirmed in the disasm that both U8 and Cru use CBW to sign-extend
value in AL, so this may fix some things in U8 too.
- make the animations a bit faster to reduce the amount of time for which the engine is blocked
- separate the display updates from the engine delays
- register user input during the animations
This makes the playback a bit smoother. The original would scroll the text lines upwards by 2 pixels every 2 ticks. Now we just move them upwards by 1 pixel every 1 tick. Same speed, just smoother...
Crusader globs sometimes contain items with an odd z value - eg, stripey floors
or elevators. This is not done in U8 and probably a hack to make the paint
order right in the original, but our scan function was only checking +/-4 and
+/-8 pixels so the avatar would jump 4 pixels up then fall, which was nasty.
Add odd-pixel checks as well when doing a scan in Crusader, and clean up the
old hack. Also tidied up the scan function to make it more understandable.
* TESTBED: Add another PixelFormat test
I have noticed that Wintermute and FullPipe games are not working on PSP
port (and it looks like they never worked). This was caused by missing
ABGR8888@4 support on the backend, while some engines explicitly
requested this Pixel Format.
I have decided to add a test so that all the backends could be easily
checked for similar issues.
Surprisingly, "backends/graphics/null/null-graphics.h" holds up-to-date,
full and correct list of pixel formats requested by different engines.
There are lots of different Pixel Formats mentioned in different engines
code, but NullGraphicsManager lists all that are explicitly needed for
intGraphics(), not data reading, etc...
* TESTBED: Avoid using NullGraphicsManager at PixelFormat test
Avoid using NullGraphicsManager at PixelFormat test + other minor tweaks
