| Age | Commit message (Collapse) | Author |
|---|
|
|
|
find -name '*.h' -or -name '*.cpp' | xargs sed -r -i 's@\(([A-Za-z0-9]+)\*\)@(\1 *)@g'
This seems to have caught some params as well which is not undesirable IMO.
It also caught some strings containing this which is undesirable so I
excluded them manually. (engines/sci/engine/kernel_tables.h)
|
|
Based on a patch presented in the bugreport. Fixes several bugs
connected with calcualting IQ points in Amiga versions of Indy3.
|
|
|
|
svn-id: r55818
|
|
svn-id: r53033
|
|
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
|
|
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
|
|
svn-id: r43802
|
|
svn-id: r43801
|
|
char pointers)
svn-id: r41000
|
|
and v2 opcodes
svn-id: r40025
|
|
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
|
|
& v4 -> renamed and moved them accordingly
svn-id: r40013
|
|
svn-id: r40012
|
|
& v4, several other opcodes map to it. Capture this properly in the opcode tables
svn-id: r40011
|
|
ScummEngine_v4::o4_pickupObject
svn-id: r40009
|
|
svn-id: r40007
|
