- 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
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
Bug #3039004: "MANIACNES: Ed does not appear at doorway."
Actually whole thing is a gross hack on top of SCUMM v1.5 hack
with extra wide screen. It all calls for review and writing
specified methods.
svn-id: r52375
- Start rewriting audio code for FM-TOWNS versions of Loom, Indy3 and Monkey Island 1 using the recently added code in towns_audio.cpp (Zak should work the same way, but I can't test, since I don't own that one).
- All sound types (pcm, euphony and cd audio) now support volume and balance control (e.g. try walking into/out of the kitchen and opening/closing the door in the Scumm Bar in Monkey Island 1 or walking into/out of the circus tent).
- Pcm sounds now support proper loop start/end and note offsets (e.g. try out the hammer sound in the forge in LOOM for example).
- some other minor improvements
- The FM-Towns versions of Indy 4 and Monkey Island 2 are not affected. I don't have Monkey Island 2, but I presume that it will work like Indy 4. Adding support for these will be a separate task, since they work quite differently.
svn-id: r52198
These devices are not able to create appropriate drivers.
The only purpose for now is having proper gui options and flags and music types for the device detector.
The corresponding GUIO flags for the new devices have been added, too.
svn-id: r51995
Apart from adding the necessary detector flags, in cases where we used
to only check for PC Speaker we now also need to check for PCjr. Note
that I have only tested this with the VGA version. And even with that
one, I've only given it the briefest of tests.
svn-id: r51988
* Remove _isAttached member var and isAttached method
* Engines now always call the onFrame method; whether it does
something is decided by the debugger class resp. its subclasses
* Make detach() protected instead of private, so that subclasses
can invoke it
* Remove _detach_now member var (call detach() instead).
* Rename _frame_countdown to _frameCountdown and properly
document it.
* Add more doxygen comments
* Cleanup
svn-id: r50963
Bug #1328120: "MANIACNES: Screen width incorrect, camera halts sometimes".
Fixed by workaround and was tested with intro and on the kitchen,
where now it is possible to see Edna without her noticing you
first.
svn-id: r49764
These functions are only used internally be Engine subclasses, and
by moving them to a separate header we can reduce indirect header
dependencies.
svn-id: r48934
The idea behind this is exactly the same as behind r48620,
but it affects all engines, thus engine authors can now use
CursorMan.replaceCursor without having to worry about possible
memory leaks or the like.
svn-id: r48626
The problem here was that SCUMM only uses CursorMan.replaceCursor. When no
cursor had been setup before it would cause the SCUMM cursor to be never
removed from CursorMan, since in this case replaceCursor just uses pushCursor.
To avoid this problem I am just pushing a dummy cursor (and palette, since
that is used in SCUMM HE games too) on engine setup and removing it on engine
destruction.
Actually every engine should setup their first cursor via CursorMan.pushCursor
and then on quit remove it again via CursorMan.popCursor. Using
CursorMan.replaceCursor is *no* good idea for the first cursor to setup, since
that might either replace an existing cursor, thus destroying the caller's
cursor, or pushing a new cursor on the stack, which might result in a leak.
This would also result in making a call to CursorMan.popCursor unsafe, since
that might also impact the caller's cursor setup again.
svn-id: r48620
