aboutsummaryrefslogtreecommitdiff
path: root/engines/scumm/script_v4.cpp
AgeCommit message (Collapse)Author
2011-07-13SCUMM: Fix bug #3306145: INDY3: EGA version script bugsEugene Sandulenko
Based on a patch presented in the bugreport. Fixes several bugs connected with calcualting IQ points in Amiga versions of Indy3.
2011-05-12GIT: Clean up: Suppress SVN tags, now uselessstrangerke
2011-02-07ALL: Fix whitespaces / indentionMax Horn
svn-id: r55818
2010-10-05SCUMM/FM-TOWNS: disable new graphics code in DS portFlorian Kagerer
svn-id: r53033
2010-10-01SCUMM/FM-TOWNS: fix palette and other graphics issuesFlorian Kagerer
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
2010-08-16SCUMM: More finely differentiate opcode tables between v3, v4 and v5Max Horn
This has been tested and verified as much as I can, but has a small risk of leading to (easily fixable) regressions. svn-id: r52130
2009-08-29Correct regression in V1 DOS version of Zak McKracken.Travis Howell
svn-id: r43802
2009-08-29Add patch #2846581 - MM C64: savedialog.Travis Howell
svn-id: r43801
2009-05-29Changed SaveFileManager methods to take Common::String params (instead of ↵Max Horn
char pointers) svn-id: r41000
2009-04-20SCUMM: Introduced new method ScummEngine_v5::jumpRelative; unified some v0 ↵Max Horn
and v2 opcodes svn-id: r40025
2009-04-19SCUMM: Moved o5_saveLoadGame and o5_saveLoadVars to ScummEngine_v4 (the ↵Max Horn
highest SCUMM version to implement these opcodes. Actually, our code was bugged in so far as we only ever invoked o5_saveLoadGame in V3 games, never in V4 games (but this properly never mattered ;) svn-id: r40014
2009-04-19SCUMM: o5_ifNotState and o5_ifState are actually not part of v5, only in v3 ↵Max Horn
& v4 -> renamed and moved them accordingly svn-id: r40013
2009-04-19SCUMM: ScummEngine_v5::o5_oldRoomEffect -> ScummEngine_v4::o4_oldRoomEffectMax Horn
svn-id: r40012
2009-04-19SCUMM: In v5, only opcodes 0x05 and 0x85 are mapped to o5_drawObject; in v3 ↵Max Horn
& v4, several other opcodes map to it. Capture this properly in the opcode tables svn-id: r40011
2009-04-19SCUMM: MovedScummEngine_v5:: o5_pickupObjectOld to ↵Max Horn
ScummEngine_v4::o4_pickupObject svn-id: r40009
2009-04-19SCUMM: Added stubs for V3 & V4 opcode tablesMax Horn
svn-id: r40007