| Age | Commit message (Collapse) | Author |
|---|
|
The Backyard Baseball series calls the function with negative numbers, but expects a positive result. The games are now actually playable.
Thanks to Kirben for assistance in tracking this bug down.
svn-id: r53630
|
|
svn-id: r53617
|
|
(used in the MI1 circus scene after Guybrush gets shot out of the cannon)
svn-id: r53616
|
|
(improves MI1 intro)
svn-id: r53597
|
|
svn-id: r53582
|
|
svn-id: r53581
|
|
thanks to aquadran for helping verify the fix)
svn-id: r53575
|
|
svn-id: r53574
|
|
svn-id: r53573
|
|
In particular, it might happen that ScummEngine::resStrLen is called
while the _scriptPointer is stale. In that case, it would be working
with the stale pointer. If the code calling it then uses fetchScript*()
methods to read the string whose length was just computed, then it would
read potentially *different* data (e.g. copyScriptString or
loadPtrToResource could have been affected).
I am not sure if this actually could have caused bugs somewhere; it might
even be provable that a script relocation cannot happen in all places
that invoke resStrLen. But for now it's much easier to make the code
safe than to verify that theory ;).
Also simplified some related code.
svn-id: r53572
|
|
The new method is called refreshScriptPointer(). Also renamed
getScriptEntryPoint() to resetScriptPointer() in an attempt to highlight
both the similarity and difference between the two.
svn-id: r53571
|
|
svn-id: r53567
|
|
svn-id: r53562
|
|
svn-id: r53561
|
|
svn-id: r53560
|
|
(MI1 intro is still not right)
svn-id: r53558
|
|
svn-id: r53557
|
|
- made use of LordHotos graphics/sjis code to reduce code duplication
- japanese mode for version 3 and 5 works fine now with few exceptions (some line spacing glitches in MI1 intro etc.)
svn-id: r53554
|
|
color.
svn-id: r53552
|
|
svn-id: r53523
|
|
svn-id: r53519
|
|
svn-id: r53518
|
|
svn-id: r53510
|
|
svn-id: r53484
|
|
svn-id: r53483
|
|
Bug #2952298: "HE (16Bit): Inventory items (Cursors) have wrong color"
This appeared to be generic BE bug. Thanks to jvprat for nailing it down
and providing the patch.
svn-id: r53456
|
|
This includes an rather hacky attempt to merge all the recent gp2x backend
changes into the branch. I suppose the gp2x backend and probably all new
backends, i.e. gph, dingux etc., might not compile anymore.
Since I have no way of testing those it would be nice if porters could look
into getting those up to speed in this branch.
svn-id: r53399
|
|
svn-id: r53196
|
|
svn-id: r53117
|
|
svn-id: r53113
|
|
svn-id: r53103
|
|
svn-id: r53095
|
|
svn-id: r53074
|
|
svn-id: r53073
|
|
svn-id: r53061
|
|
svn-id: r53055
|
|
svn-id: r53053
|
|
svn-id: r53052
|
|
svn-id: r53033
|
|
svn-id: r53016
|
|
svn-id: r53000
|
|
svn-id: r52999
|
|
svn-id: r52995
|
|
svn-id: r52991
|
|
svn-id: r52987
|
|
svn-id: r52981
|
|
8 bit mode makes no sense for these games since colors will be too messed up.
SCUMM 3 games (Indy 3, Loom, Zak) are still supported in 8bit mode.
svn-id: r52977
|
|
This commit should fix at least the following bugs/feature requests: #1032859, #1252088, #1055391, #1315968, #1315938, #1742106, #812891.
The FM-Towns version of Scumm games use a mixed graphics mode with 2 layers (one with 32767 colors and one with 16 colors). Among other things I have added a screen output class which emulates this dual layer approach which allows specific hardware effects like enabling and disabling layers (e.g. in the voodoo priestess scene in MI1).
Old savegames (saved before this update) will load, but you’ll encounter palette glitches in the verb/inventory screen, since the 16 color palette for layer 2 is not contained in your savegame. This will be true at least for version 5 games. Certain scene change actions (which require the verb/inventory part to be redrawn) might correct this (e.g. try looking at the treasure map in MI1 and closing it). Version 3 games should be okay, since they use a static text palette which is never changed and which will be reset after loading a savegame.
This update requires a USE_RGB_COLORS setting for proper operation. 8 bit users will get a warning that they’ll have to expect palette glitches . Apart from that the engine in 8 bit mode should not only still work okay, but also benefit from some of the other (non palette related) improvements (e.g. bug #1032859 should be fixed even in 8 bit mode).
Japanese font drawing hasn’t been improved much yet. This will be a separate task.
svn-id: r52966
|
|
svn-id: r52891
|
|
in revision 42737.
svn-id: r52798
|
