The demo scrolling is not yet as refined as in the final products. An adjustment to the timing that was made for the final products is not present in the demo. This adjustment will actually make the scrolling more sloppy in the demo (due to different scumm timer parameters set by the scripts) , so I disable it here.
Please note that the scrolling still won't be as smooth as it is in the final products. This is the same when viewing the demo in an emulator, though (I actually think it is slightly better in ScummVM). It is probably the reason why they made the change for the final products.
The engine now measures whether it can perform one screen update within a 60Hz tick. Unfortunately the calls to OSystem::updateScreen() may take very long, depending on the backend and the filter setting. In this case the engine will start to catch up to the current frame. It should still look fine, unless the platform is way too slow for the selected filter setting (with the wrong settings it is not too difficult to achieve OSystem::updateScreen() durations of over 100ms).
These changes are currently pointless, since the affected function variants won't be called. The Japanese game versions for which they would be used are not supported in non-USE_RGBCOLOR builds. But the code should be correct nonetheless...
("drawing" in this case means the data conversion and transfer from the gfx layers to the screen buffer)
From my measuring experiments in the MSVC debugger this speeds up the drawing 2 - 3 times. Not sure about release builds, whether these profit even more.
(partly revert fb8f1084)
There is no simple solution that would still leave the "butter smooth" scrolling for faster platforms intact. I have measured times between several code points to find any bottlenecks. My finding is that even single script opcodes may well take over 200ms to execute. And exceeding a singe 60 Hz tick happens way more often (which makes the scrolling fall behind and have to catch up, thus becoming a bit sloppy). So, for the "butter smooth" scrolling I'll probably implement a timer for the screen updates (which will then really behave much more like the interrupt handler of the original). But that's for a separate commit. This one is mostly about the bug ticket..
I have made the scrolling more smooth and still hopefully managed not to break the sync with the engine (which really is a bit tricky).
I've tested playing the ZAK and LOOM intros and also walking around in ZAK and MI2, since there are some good test cases there. I've also compared all these side by side with the UNZ emulator.
This is mostly based on ZAK and MI2 disasm (and a bit LOOM). For MI1 and INDY4 I have at least checked with the FM-Towns UNZ emulator to ensure that they actually have the smooth scrolling.
The smooth scrolling is a bit tricky with regard to the timing. The scrolling tends to be a bit too slow for the engine, since it happens at a speed of 1 pixel per 60Hz tick, while the engine sometimes writes one or more new 8 pixel strips at the same time. So the scrolling often has to catch up to the engine. The original has a compensation mechanism which I tried to adapt. We'll see if it needs more fine tuning...
The Loom intro even glitches in the UNZ FM-Towns emulator due overflowing the scrolling surface (and causing a wraparound). But I made a fix for that.
Since we do have a bug report about the speed of the ZAK intro (and the new scrolling code does affect the timing) I have run the ZAK intro in ScummVM and in the FM-Towns UNZ emulator (with i80386DX, 16 MHz setting) side by side and they seem totally in sync. If I reduce the MHz setting in the emulator to 10 MHz on the emulator the intro will play slower, but still not play through the whole song. With 8 MHz I get close to finishing the song, but this seems to be almost to slow to run the game properly. So I'll leave that bug ticket open...
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)
This tries to make our code a bit more compliant with our code formatting
conventions. For future use, this is the command I used:
git ls-files "*.cpp" "*.h" | xargs sed -i -e 's/[ \t]*$//'
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
athrxx
Torbjörn Andersson
Eugene Sandulenko
Orgad Shaneh
Johannes Schickel
Christoph Mallon
Tarek Soliman
Max Horn
strangerke
athrxx