Now double-click works also on really slow hardware. And Hatari.
Also, partially revert commit 01a2d2ed because events can't be passed
to the (multitasking) OS. So basically let's hope that it works fine now
even without handling IKBD overruns. I'm not able to replicate the issue
with Hatari + FF + slow UI + mouse movement anymore.
This helps to solve the issue when one pushes 'Return' immediately after
Hatari's start. This issue appeared after introducing the
interrupt-driven audio mixer.
Not sure whether this was a real bug but it's much cleaner
implementation now anyway.
- every malloc is now aligned on 16 bytes
- no need for the hidden pointers
- ct60_vmalloc() is called only once, the rest is handled
by dlmalloc (SV XBIOS' vmalloc is pretty fragile)
- The only non-hires ultima engine is ultima1, not worth it. See
also https://bugs.scummvm.org/ticket/14790. This prevents adding
the 15 MB ultima.dat to the release archive.
- Disable hugo also in full version (oversight).
- Mention freemint version in readme.txt.
As it seems to be used in some lowres games as well. Also remove
hugo.dat (which is explicitly disabled in the full version).
Change 'rm -f' to 'rm' to see what is actually deleted for real.
- composer unaligned pitch fix
- error() doesn't work while in OSystem_Atari c-tor
- when a crash occurs, restore at least the cursor
- fix a crash when "data" doesn't exist
It was wrong (other engines are allowed to do infinite recursions?) and
Future Wars still isn't working properly at all times. I've decided to
remove it (i.e. Future Wars and Operation Stealth are not supported
anymore).
Small updates in readme.txt.
exit() can be handled at user level via atexit(), there's no need to use
the critical handler routine.
Removed GEM restore from the critical handler as this uncovered its
instability while being in the critical handler.
Similar to SuperVidel's but requires an additional C2P pass.
Also, a few optimizations added like cursor is being assumed to be in
a persistent memory so we don't copy it over. And it's using a mask
instead of key.
This graphics mode is not perfect though and works reliably only with
source surfaces allocated via Surface::init() otherwise wrong memory
location is being read.
Still, can gain quite a few CPU cycles, especially on 640x480 screens.
- surface setup for optimized 4-bit C2P routine wasn't properly detected
- STFA pretends to support Falcon sampling frequencies on TT leading to
suboptimal sample mixing
- delayMillis() should check also for other events (fixes Future Wars)
but avoid doing it for SCI as its MIDI timer would call itself in a
recursive loop
- SuperVidel doesn't need to use VsetScreen() in VBL anymore
- Wetlands, Teen Agent, Shivers and Private Eye need non-aligned
surface widths
- However Wetlands and Private Eye use setCursorPalette, see
https://bugs.scummvm.org/ticket/14524
- Added warning for Phantasmagoria's 630x450, nothing can be done there
as the game also requires non-aligned surfaces and at the same time
the buffer has to be aligned on 16 bytes.
- BDF scaling disabled by default
- Atari TT support
- all video and audio is now handled via XBIOS
- reworked IKBD handling using Kbdvbase vectors, esp. Kbdvec()
- video uses proper triple buffer
- arbitrary game screen size support
- many fixes and optimizations
- "fat" version uses repacked (zip -0) archives; also separate "data"
and "themes" folders
- "slim" version doesn't use any external themes (for speed reasons)
- consolidate public #define's (just ATARI)
- cpu compiler flags are specified in the script
- allow explicit move16, SV and SV Blitter features enabled/disabled
Provide two build scripts:
1. "Fat" one targeted at 040/060 machines (possibly with SuperVidel)
This one is optimized for 68020-60 (so it's still possible to try
highres engines on 68030 machines).
2. "Slim" one targeted at 030 machines (Falcon030+DFB/CT2 or TT030)
This one is optimized for 68030 and stripped from even more features:
"fancy" (highres) themes, move16 & SuperVidel routines and most
importantly the highres engines.
ScummVM engines are not built for synchronous screen locking (i.e.
updateScreen() can't be really used for any sort of blocking updates
otherwise performance suffers).
Single buffering now means deliberate tearing as a speed optimization
and triple buffering provides a tearingless picture with slight overhead.
"make dist-generic" doesn't automatically look for files in "data"
folder. Commit be98f2a8 is somewhat related to this problem but only
for debugging purposes.
As relative "data" clashes with game's relative "data" (e.g. Full
Throttle demo), do the right thing and add it as absolute path.
- fix restoration of dirty rects from overlay
- fix vsync handling (don't try to be too smart; we can't store "vsync"
from anywhere because that wouldn't play nicely if a game has its own
"vsync" set) ... so keep the checkbox as is
- overlay restore for 640x400
- never wait for vbl in overlay
- readme.txt