Apparently, as I have been told, there are (still) OS'es with non-compositing window managers which may cause glitches when drawing windows over the ScummVM window, unless the engine keeps updating the screen. So, now we do that, even if there isn't any actual on-screen activity. The whole thing is a bit more tricky than it would appear at first glance, since one misplaced/untimely screen update may cause palette glitches. I have implemented a timer which is reset whenever actual on-screen activity happens. That should work around any such glitches.
Maybe the rates for the timer have to be tweaked some more. I have also added an ifdef so this could be disabled or restricted to certain platforms if required.
- make the animations a bit faster to reduce the amount of time for which the engine is blocked
- separate the display updates from the engine delays
- register user input during the animations
The explosion and cone of cold pixel "animations" have somehow become extremely slow. At least in MSVC debug mode. No idea whether this is a regression from recent OSystem or backend graphics updates. I now set these pixel updates on a strict timer based schedule. If the machine/backend/whatever is too slow it will just get less screen updates...dfdsfsf
The first level will now load up when selecting 'start default party' and it is possible to walk around a bit. The Gui (playfield, compass, inventory) is still completely broken, but at least the level blocks and some of the decoration shapes are drawn correctly. Monsters will be drawn, but their anim frames are mixed up, so they will always face the wrong direction and cannot visibly attack.
- add support for the Sega Font and add text display methods at least for the sequence player
- finish sequence player (add all missing opcodes and other missing code portions)
- some improvement to the resource class
- some renaming and cleanup
This also (hopefully) involves most of the necessary graphics code. Text support is still missing. Otherwise, the intro and outro play mostly fine (except for some special opcodes).
Initial file handling, palette and graphics support. The opening credits get played satisfactory. Following up with the cinematics player will be much easier now...
The assumption till now was that PC-9801 games in 16 color mode will always use text mode for text display. However, EOB1 uses text mode for intro and ending sequence and graphics mode for ingame.
Add new font variant for this and also do some cleanup, since the text displayer code really needs it.
(The problem is that at least 3 different Japanese publishers did the Japanese ports for the various games and every one of them did his own hacks for his specific target.)
- add warning for wrong font file: The German version of EOB II has a font file with more characters than the English version or the EOB I fonts. Users now get a warning/instruction if they have the wrong file.
- add translation support for all AmigaDOS font related warnings/errors
First efforts to get this running. The intro is shown with severe palette glitches. The Main Menu does not show, thanks to the lack of font drawing.
- implement endian aware stream wrapper for amiga files
- implement sound file handling
- implement some Amiga palette handling
- etc
Reorganize all files in sub directories. The file placement isn't as intuitive as it might be for other engines, which is probably the reason why this hasn't been done before.