[Scummvm-git-logs] scummvm branch-2-8 -> 35f40fddab23c9f6844713b4c3c604f273dc26b3
mikrosk
noreply at scummvm.org
Sat Dec 16 09:12:57 UTC 2023
This automated email contains information about 1 new commit which have been
pushed to the 'scummvm' repo located at https://github.com/scummvm/scummvm .
Summary:
35f40fddab BACKENDS: ATARI: Prepare for release
Commit: 35f40fddab23c9f6844713b4c3c604f273dc26b3
https://github.com/scummvm/scummvm/commit/35f40fddab23c9f6844713b4c3c604f273dc26b3
Author: Miro Kropacek (miro.kropacek at gmail.com)
Date: 2023-12-16T10:12:21+01:00
Commit Message:
BACKENDS: ATARI: Prepare for release
Changed paths:
backends/platform/atari/build-release.sh
backends/platform/atari/build-release030.sh
backends/platform/atari/readme.txt
configure
diff --git a/backends/platform/atari/build-release.sh b/backends/platform/atari/build-release.sh
index bcc0caf2a19..b80160cd59b 100755
--- a/backends/platform/atari/build-release.sh
+++ b/backends/platform/atari/build-release.sh
@@ -19,6 +19,8 @@ then
--backend=atari \
--host=${PLATFORM} \
--enable-release \
+ --disable-png \
+ --disable-enet \
--disable-mt32emu \
--disable-lua \
--disable-nuked-opl \
@@ -31,7 +33,8 @@ then
--opengl-mode=none \
--enable-verbose-build \
--enable-text-console \
- --disable-engine=director,cine
+ --disable-engine=director,cine \
+ --disable-detection-full
fi
make -j 16
diff --git a/backends/platform/atari/build-release030.sh b/backends/platform/atari/build-release030.sh
index 12deebf233e..e80ea0fd6b5 100755
--- a/backends/platform/atari/build-release030.sh
+++ b/backends/platform/atari/build-release030.sh
@@ -19,6 +19,8 @@ then
--backend=atari \
--host=${PLATFORM} \
--enable-release \
+ --disable-png \
+ --disable-enet \
--disable-mt32emu \
--disable-lua \
--disable-nuked-opl \
@@ -32,7 +34,8 @@ then
--opengl-mode=none \
--enable-verbose-build \
--enable-text-console \
- --disable-engine=hugo,director,cine
+ --disable-engine=hugo,director,cine \
+ --disable-detection-full
fi
make -j 16
diff --git a/backends/platform/atari/readme.txt b/backends/platform/atari/readme.txt
index 1524c76d774..89b1665f3e4 100644
--- a/backends/platform/atari/readme.txt
+++ b/backends/platform/atari/readme.txt
@@ -1,84 +1,135 @@
-ScummVM
-=======
+ScummVM 2.8.0
+=============
-This is a new port of ScummVM (https://www.scummvm.org), a program which allows
-you to run certain classic graphical adventure and role-playing games, provided
-you already have their data files.
+This is a port of ScummVM (https://www.scummvm.org), a program which allows you
+to run certain classic graphical adventure and role-playing games, provided you
+already have their data files.
You can find a full list with details on which games are supported and how well
on the compatibility page: https://www.scummvm.org/compatibility.
-Yet another port?
------------------
+New port?
+---------
-Yes, I am aware of the official Atari/FreeMiNT port done by KeithS over the
-years (https://docs.scummvm.org/en/v2.7.0/other_platforms/atari.html). It is
-even updated every release and put on the official ScummVM website. That port
-is basically just a recompiled SDL backend for our platform - that certainly
-has some advantages (works in GEM, can be easily compiled for the FireBee etc.)
-but I have decided to take a different route:
+Keith Scroggins (aka KeithS) has been providing ScummVM (and many other) builds
+for the Atari community for unbelievable 17 years. He put quite a lot of time
+into testing each release, updating ScummVM dependencies to their latest
+version and even regularly upgrading his compiler toolchain to get the best
+possible performance.
-- Reduced executable size, basically whatever is not essential or plausible on
- our platform is left out. That reduces the file size to half. See also the
- next point.
+However ScummVM (and SDL to some extent) is a beast, it requires quite a lot of
+attention where the cycles go, e.g. an additional screen refresh can easily
+drop frame rate to half.
-- Because there's a limited horsepower available on our platform, features like
- hi-res 16bpp graphics, software synthesizers, scalers, real-time software
- MP3/OGG/FLAC playback etc., are omitted. This saves memory and disk space,
- making the whole port more lightweight.
-
-- This port natively talks to the hardware, avoiding intermediate layers like
- SDL. Thus, it has more optimisations, fewer redraws, fewer data copying and
- is less crash-prone.
+After I had seen how snappy NovaCoder's ScummVM on the Amiga is (who coded his
+own backend), I decided to check whether there isn't a way to get a better
+performing port on our platform. And there is!
-- Because we limit scope only to 8bpp games, it opens a door to more thorough
- testing and there is a certain interest in this in the community. 16bpp games
- could be played only in ARAnyM or similar, limiting the test audience a lot.
+I have managed to create a "native" Atari port talking directly to hardware,
+skipping the SDL layer altogether, which is in some cases usable even on plain
+32 MHz Atari TT.
-After I had seen how snappy NovaCoder's ScummVM on the Amiga is (who coded
-his own backend), I decided to do the same and see whether I could do better.
-And I could!
+Differences between the versions
+--------------------------------
-Hardware requirements
----------------------
+After talking to Keith we have decided to provide three flavours of ScummVM.
+Please refer to https://docs.scummvm.org/en/v2.8.0/other_platforms/atari.html
+for more details (TBD).
-This port requires an Atari computer with TT or Falcon compatible video modes
-with at least 4+32 MB of RAM (this applies to the "slim" version, the "fat" one
-requires more due its file size). It runs fine also in Hatari and ARAnyM but in
-case of ARAnyM don't forget to disable fVDI to show Videl output.
+Atari Full package
+~~~~~~~~~~~~~~~~~~
+Minimum hardware requirements: Atari Falcon with 4 + 64 MB RAM, 68040 CPU.
-Main features
--------------
-
-- Optimised for the Atari TT/Falcon: ideally the CT60/CT63/CT60e but some games
- run fine on the AfterBurner040, CT2/DFB at 50 MHz, Speedy at 48 MHz or even less!
-
-- Full support for the SuperVidel, incl. the SuperBlitter (!)
+- Because there's a limited horsepower available on our platform, features like
+ 16bpp graphics, software synthesisers, scalers, real-time software
+ MP3/OGG/FLAC playback etc., are omitted. This saves CPU cycles, memory and
+ disk space.
-- Removed features found too demanding for our platform; the most visible
- change is the exclusion of the 16bpp games (those are mostly hi-res anyway)
- but games in 640x480 at 8bpp work nicely (Falcon only, unfortunately).
+- Tailored video settings for the best possible performance and visual
+ experience (Falcon RGB overscan, chunky modes with the SuperVidel, TT 640x480
+ for the overlay, ...)
- Direct rendering and single/triple buffering support.
-- Custom (and optimal) drawing routines (especially for the cursor).
+- Blitting routines optimised for 68040 / 68060 CPU.
-- Tailored video settings for the best possible performance and visual
- experience (Falcon RGB overscan, chunky modes with the SuperVidel, TT 640x480
- for the overlay, ...)
+- Custom (and optimal) surface drawing (especially for the cursor).
- Custom (hardware based) aspect ratio correction (!)
+- Full support for the SuperVidel, incl. the SuperBlitter (!)
+
+- External DSP clock support for playing back samples at PC frequencies
+ (Falcon only). Dual clock input frequency supported as well (Steinberg's FDI).
+
- Support for PC keys (page up, page down, pause, F11/F12, ...) and mouse wheel
(Eiffel/Aranym only)
- Native MIDI output (if present).
-- AdLib emulation works nicely with many games without noticeable slow downs
- (on a poweful machine, ideally 68060/66 MHz).
+- Runs also in Hatari and ARAnyM but in case of ARAnyM don't forget to disable
+ fVDI to enable Videl output.
+
+- FreeMiNT + memory protection friendly.
+
+Atari Lite package
+~~~~~~~~~~~~~~~~~~
+
+Minimum hardware requirements: Atari TT / Falcon with 4 + 32 MB RAM.
+
+As a further optimisation step, a 030-only version of ScummVM is provided, aimed
+at less powerful TT and Falcon machines with the 68030 CPU. It further restricts
+features but also improves performance and reduces executable size.
+
+- Compiled with -m68030 => 68030/68882-specific optimisations enabled.
+
+- Disabled 040+/SuperVidel code => faster code path for blitting.
+
+- Doesn't support hires (640x480) games => smaller executable size.
+
+- Overlay is rendered in 16 colours => faster redraw.
+
+- Overlay during gameplay has no game background => even faster redraw.
+
+- Overlay doesn't support alternative themes => faster loading time.
+
+- "STMIDI" driver is automatically enabled (i.e. MIDI emulation is never used
+ but still allows playing speech/sfx samples and/or CD audio)
+
+FireBee package
+~~~~~~~~~~~~~~~
+
+Hardware requirements: MCF5475 Evaluation Board or FireBee.
+
+This one is still built and provided by Keith.
+
+- Based on most recent SDL
+
+- Contains various optimisations discovered / implemented from the Atari
+ backend.
+
+- Works in GEM (in theory also in XBIOS but that seems to be still broken on
+ FireBee).
+
+- Support for all engines is included in the build, this does not mean all
+ games work. For instance, support for OGG and MP3 audio is included but the
+ system can not handle playback of compressed audio, not enough processing
+ power for both gameplay and sound at the same time.
+
+ Scalers can be utilized to make the GEM window larger on the Firebee.
+ Performance is best when not usimg AdLib sound, using STMIDI would be
+ optimal, but untested as of yet (I have been unable to get MIDI to work on my
+ FireBee).
+
+- Removed features: FLAC, MPEG2, Network/Cloud Support, HQ Scalers,
+ GIF Support, MOD Support.
+
+
+The rest of this document describes things specific to the Full / Lite package.
+For the FireBee (SDL) build please refer to generic ScummVM documentation.
Platform-specific features outside the GUI
@@ -87,17 +138,33 @@ Platform-specific features outside the GUI
Keyboard shortcut "CONTROL+ALT+a": immediate aspect ratio correction on/off
toggle.
-"output_rate" in scummvm.ini: sample rate for mixing, can be 49170, 32780,
-24585, 19668, 16390, 12292, 9834, 8195 on the Falcon and 50066, 25033, 12517,
-6258 on the TT (the lower the value, the faster the mixing but also worse
-quality). Default is 24585/25033 Hz (16-bit, stereo).
+"output_rate" in scummvm.ini: sample rate for mixing. Allowed values depend on
+the hardware connected:
+ - TT030: 50066, 25033, 12517, 6258 Hz
+ - Falcon030: as TT030 (except 6258) plus 49170, 32780, 24585, 19668, 16390,
+ 12292, 9834, 8195 Hz
+ - External 22.5792 MHz DSP clock: as Falcon030 plus 44100, 29400, 22050,
+ 17640, 14700, 11025, 8820, 7350 Hz
+ - External 24.576 MHz DSP clock: as Falcon030 plus 48000, 32000, 24000,
+ 19200, 16000, 12000, 9600, 8000 Hz
+The lower the value, the faster the mixing but also worse quality. Default is
+24585/25033 Hz (16-bit, stereo). Please note you don't have to enter the value
+exactly, it will be rounded to the nearest sane value.
+
+"output_channels" in scummvm.ini: mono (1) or stereo (2) mixing. Please note
+that Falcon doesn't allow mixing in 16-bit mono, so this will have no effect on
+this machine.
+
+"print_rate" in scummvm.ini: used for optimising sample playback (where
+available). It prints input and output sample format as well as name of the
+converter used. See below for details.
"audio_buffer_size" in scummvm.ini: number of samples to preload. Default is
2048 which equals to about 83ms of audio lag and seems to be about right for
most games on my CT60 at 66 MHz.
-If you want to play with those two values, the rule of thumb is: (lag in ms) =
-(audio_buffer_size / output_rate) * 1000. But it's totally OK just to double
+If you want to play with "audio_buffer_size", the rule of thumb is: (lag in ms)
+= (audio_buffer_size / output_rate) * 1000. But it's totally OK just to double
the samples value to get rid of stuttering in a heavier game.
@@ -110,9 +177,8 @@ rectangles and this port offers following options to render them:
Direct rendering
~~~~~~~~~~~~~~~~
-This is direct writing of the pixels into the screen buffer. On SuperVidel
-it is done natively, on Videl a chunky to planar conversion takes place
-beforehand.
+This is direct writing of the pixels into the screen buffer. On SuperVidel it is
+done natively, on Videl a chunky to planar conversion takes place beforehand.
Pros:
@@ -129,12 +195,12 @@ Cons:
- screen tearing in most cases
- on Videl, this may not work properly if a game engine uses its own buffers
- instead of surfaces (which are aligned on a 16pix boundary). Another source
- of danger is if an engine draws directly to the screen surface. Fortunately,
- each game can have its own graphics mode set separately so for games which
- do not work properly one can still leave the default graphics mode set.
+ instead of surfaces (which are aligned on a 16pix boundary). Another source of
+ danger is if an engine draws directly to the screen surface. Fortunately, each
+ game can have its own graphics mode set separately so for games which do not
+ work properly one can still leave the default graphics mode set.
-- on Videl overlay background isn't rendered (the gui code can't work with
+- on Videl, overlay background isn't rendered (the gui code can't work with
bitplanes)
SuperBlitter used: sometimes (when ScummVM allocates surface via its create()
@@ -186,20 +252,20 @@ Cons:
- slightly irregular frame rate (depends solely on the game's complexity)
-- in case of extremely fast rendering, one or more frames are dropped in favor
+- in case of extremely fast rendering, one or more frames are dropped in favour
of showing only the most recent one
SuperBlitter used: yes, for rectangle blitting to screen and cursor restoration.
Sometimes also for generic copying between buffers (see above).
-Triple buffering is the default mode for this port.
+Triple buffering is the default mode.
SuperVidel and SuperBlitter
---------------------------
-As mentioned, this port uses SuperVidel and its SuperBlitter heavily. That
-means that if the SuperVidel is detected, it does the following:
+As mentioned, this port uses SuperVidel and its SuperBlitter heavily. That means
+that if the SuperVidel is detected, it does the following:
- uses 8bpp chunky resolutions
@@ -208,9 +274,9 @@ means that if the SuperVidel is detected, it does the following:
SuperBlitter copying)
- when SuperVidel FW version >= 9 is detected, the async FIFO buffer is used
- instead of the slower sync blitting (where one has to wait for every
- rectangle blit to finish), this sometimes leads to nearly zero-cost rendering
- and makes a *huge* difference for 640x480 fullscreen updates.
+ instead of the slower sync blitting (where one has to wait for every rectangle
+ blit to finish), this sometimes leads to nearly zero-cost rendering and makes
+ a *huge* difference for 640x480 fullscreen updates.
Aspect ratio correction
@@ -218,8 +284,8 @@ Aspect ratio correction
Please refer to the official documentation about its usage. Normally ScummVM
implements this functionality using yet another fullscreen transformation of
-320x200 surface into a 320x240 one (there is even a selection of algorithms
-for this task, varying in performance and quality).
+320x200 surface into a 320x240 one (there is even a selection of algorithms for
+this task, varying in performance and quality).
Naturally, this would pose a terrible performance anchor on our backend so some
cheating has been used:
@@ -237,47 +303,47 @@ cheating has been used:
"1:1" or "dot by dot")
Yes, it's a hack. :) Owners of a CRT monitor can achieve the same effect by the
-analog knobs -- stretch and move the 320x200 picture unless black borders are
-no longer visible. This hack provides a more elegant and per-game
-functionality.
+analog knobs -- stretch and move the 320x200 picture unless black borders are no
+longer visible. This hack provides a more elegant and per-game functionality.
Realtime aspect ratio correction (CTRL+ALT+a) should be used with caution in
Direct rendering mode because there's no way to refresh the screen. So if you
change the setting and there isn't any game screen update coming, screen will
stay black.
+
Audio mixing
------------
-ScummVM works internally with 16-bit stereo samples so on the TT a simple
-downsampling to 8-bit resolution is used. However there's still one piece
-missing - an XBIOS emulator (so ScummVM doesn't have to access hardware
-directly). There are two options (both available from
-https://mikrosk.github.io/xbios): STFA and X-SOUND, any of these will do. Or
-executing ScummVM in EmuTOS which contains the same routines as X-SOUND.
+ScummVM works internally with 16-bit samples so on the TT a simple downsampling
+to 8-bit resolution is used. However there's still one piece missing - an XBIOS
+emulator (so ScummVM doesn't have to access hardware directly). There are two
+options (both available from https://mikrosk.github.io/xbios): STFA and X-SOUND,
+any of these will do. Or executing ScummVM in EmuTOS which contains the same
+routines as X-SOUND.
Performance considerations/pitfalls
-----------------------------------
-It's important to understand what affects performance on our limited platform
-to avoid unpleasant playing experiences.
+It's important to understand what affects performance on our limited platform to
+avoid unpleasant playing experiences.
Game engines with unexpected performance hit
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-A typical example from this category is Gobliiins (and its sequels) and SCI
-engine games (Gabriel Knight, Larry 2/7, ...). At first it looks like our
-machine or Atari backend is doing something terribly wrong but the truth is
-that it is the engine itself which is doing a lot of unnecessary redraws and
-updates, sometimes even before reaching the backend. The only solution is to
-profile and fix those engines.
+A typical example from this category is Gobliiins (and its sequels), some SCI
+engine games (Gabriel Knight, Larry 2/7, ...) or Sherlock engine (The Case of
+the Rose Tattoo). At first it looks like our machine or Atari backend is doing
+something terribly wrong but the truth is that it is the engine itself which is
+doing a lot of redraws, sometimes even before reaching the backend. The only
+solution is to profile and fix those engines.
Too many fullscreen updates
~~~~~~~~~~~~~~~~~~~~~~~~~~~
Somewhat related to the previous point - sometimes the engine authors didn't
-realize the impact of every update on the overall performance and instead of
+realise the impact of every update on the overall performance and instead of
updating only the rectangles that really had changed, they ask for a fullscreen
update. Not a problem on a >1 GHz machine but very visible on Atari! Also, this
is (by definition) the case of animated intros, especially those in 640x480.
@@ -285,7 +351,7 @@ is (by definition) the case of animated intros, especially those in 640x480.
MIDI vs. AdLib vs. sampled music
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-It could seem that sample music replay must be the most demanding one but on
+It could seem that sampled music replay must be the most demanding one but on
the contrary! Always choose a CD version of a game (with *.wav tracks) to any
other version. With one exception: if you have a native MIDI device able to
replay the given game's MIDI notes (using the STMIDI plugin).
@@ -293,15 +359,16 @@ replay the given game's MIDI notes (using the STMIDI plugin).
MIDI emulation (synthesis) can easily eat as much as 50% of all used CPU time
(on the CT60). By default, this port uses the MAME OPL emulation (which is said
to be fastest but also least accurate) but some engines require the DOSBOX one
-which is even more demanding. By the way, you can put "FM_high_quality=true"
-or "FM_medium_quality=true" into scummvm.ini if you want to experiment with a
-better quality synthesis, otherwise the lowest quality will be used (applies
-for MAME OPL only).
+which is even more demanding. By the way, you can put "FM_high_quality=true" or
+"FM_medium_quality=true" into scummvm.ini if you want to experiment with a
+better quality synthesis, otherwise the lowest quality will be used (applies for
+MAME OPL only).
-On the TT, in most cases it makes sense to use ScummVM only if you own a
-native MIDI synthesizer (like mt32-pi: https://github.com/dwhinham/mt32-pi).
-MIDI emulation is out of question and downsampling to 8-bit resolution takes
-a good chunk of CPU time which could be utilized elsewhere.
+On TT, in most cases it makes sense to use ScummVM only if you own a native MIDI
+synthesiser (like mt32-pi: https://github.com/dwhinham/mt32-pi). MIDI emulation
+is out of question and downsampling to 8-bit resolution takes a good chunk of
+CPU time which could be utilised elsewhere. However there are games which are
+fine with sampled music/speech even on plain TT (e.g. Lands of Lore).
CD music slows everything down
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
@@ -313,8 +380,8 @@ intro sequence (and during the game as well). Increasing "audio_buffer_size"
makes the rendering literally crawling! Why? Because disk I/O is busy with
loading even *more* sample data so there's less time for video loading and
rendering. Try to put "musdisk1.bun" and "musdisk2.bun" into a ramdisk (i.e.
-u:/ram in FreeMiNT), you'll be pleasantly surprised with the performance boost
-gained.
+symlink to u:/ram in FreeMiNT), you'll be pleasantly surprised with the
+performance boost gained.
Mute vs. "No music"
~~~~~~~~~~~~~~~~~~~
@@ -328,43 +395,68 @@ music (and therefore avoiding the expensive synthesis emulation) but beware, it
doesn't affect CD (*.wav) playback at all! Same applies for speech and sfx.
The least amount of cycles is spent when:
-- "No music" as "Preferred device": this prevents MIDI sythesis of any kind
+- "No music" as "Preferred device": this prevents MIDI synthesis of any kind
- "Subtitles" as "Text and speech": this prevents any sampled speech to be
mixed
- all external audio files are deleted (typically *.wav); that way the mixer
wont have anything to mix. However beware, this is not allowed in every game!
+Sample rate
+~~~~~~~~~~~
+
+It's important to realise the impact the sample rate has on the given game. The
+most obvious setting is its value: the bigger, the more demanding audio mixing
+becomes. However if you inspect many games' samples, you will notice that most
+of them (esp. the ones from the 80s/90s) use simple samples like mono 11025 Hz
+(sometimes even less).
+
+Obviously, setting "output_channels" to "1" is the easiest improvement
+(unfortunately only on TT). Next best thing you can do is to buy an external DSP
+clock for your Falcon: nearly all games use sample frequencies which are
+multiplies of 44100 Hz: 22050, 11025, ... so with the external clock there wont
+be the need to resample them.
+
+There's one caveat, though: it is important whether your replay frequency is
+equal, multiply of or other than the desired one. Let's consider 44100 and 22050
+frequencies as an example (also applies to all the other frequencies):
+
+- if you set 44100 Hz and a game requests 44100 Hz => so called "copyConvert"
+ method will be used (fastest)
+- if you set 22050 Hz and a game requests 44100 Hz => so called "simpleConvert"
+ method will be used (skipping every second sample, second fastest)
+- if you set 44100 Hz and a game requests 22050 Hz => so called
+ "interpolateConvert" method will be used (slowest!)
+- any other combination: "interpolateConvert" (slowest)
+
+So how do you know which frequency to set as "output_rate" ? This is where
+"print_rate" comes to rescue. Enabling this option in scummvm.ini will tell you
+for each game which sample converters are being used and for what input/values.
+So you can easily verify whether the given game's demands match your setting.
+
+Unfortunately, currently per-game "output_rate" / "output_channels" is not
+possible but this may change in the future.
+
Slow GUI
~~~~~~~~
Themes handling is quite slow - each theme must be depacked, each one contains
quite a few XML files to parse and quite a few images to load/convert. That's
the reason why the built-in one is used as default, it dramatically speeds up
-loading time. To speed things up in other cases, the "fat" version is
+loading time. To speed things up in other cases, the full version is
distributed with repackaged theme files with compression level zero.
-"Slim" vs. "Fat" version
-------------------------
-
-As a further optimisation step, a 030-only version of ScummVM is provided,
-aimed at accelerated TT and Falcon machines with the 68030 CPU. It further
-restricts features but also improves performance:
-
-- compiled with -m68030 => 68030/68882-specific optimisations enabled
-
-- disabled 040+/SuperVidel code => faster code path for blitting
+Changes to upstream
+-------------------
-- doesn't support hires (640x480) games => smaller executable size
+There is a few features that have been disabled or changed and are not possible
+/ plausible to merge into upstream:
-- overlay is rendered in 16 colours => faster redraw
+- the aforementioned "print_rate" feature, too invasive for other platforms
-- overlay during gameplay has no game backround => ever faster redraw
-
-- overlay doesn't support alternative themes => faster loading time
-
-- "STMIDI" driver is automatically enabled (i.e. MIDI emulation is never used
- but still allows playing speech/sfx samples and/or CD audio)
+- this port contains an implementation of much faster tooltips in the overlay.
+ However there is a minor rendering bug which sometimes corrupts the
+ background. But since its impact is huge, I left it in.
Known issues
@@ -375,8 +467,8 @@ Known issues
there only relative paths (mintlib bug/limitation).
- when run on TT, screen contains horizontal black lines. That is due to the
- fact that TT offers only 320x480 in 256 colours. Possibly fixable by a Timer
- B interrupt.
+ fact that TT offers only 320x480 in 256 colours. Possibly fixable by a Timer B
+ interrupt.
- horizontal screen shaking doesn't work on TT because TT Shifter doesn't
support fine scrolling. However it is "emulated" via vertical shaking.
@@ -384,29 +476,27 @@ Known issues
- aspect ratio correction has no effect on TT because is not possible to alter
its vertical screen refresh frequency.
-- tooltips in overlay are sometimes drawn with corrupted background.
-
- the talkie version of MI1 needs to be merged from two sources: first generate
the DOS version and then additionally also the flac version. Then convert all
*.flac files into *.wav and replace monkey.sof (flac) with monster.sou (DOS).
And of course, don't forget to set the extra path in Game options to the
- folder where *.wav files are located! For MI2 just use the DOS version,
- there are no CD tracks available. :(
+ folder where *.wav files are located! For MI2 just use the DOS version, there
+ are no CD tracks available. :(
- following engines have been explicitly disabled:
- - Cine (2 games)
- - incompatible with other engines / prone to freezes
- - https://wiki.scummvm.org/index.php?title=Cine
- - Director (many games)
- - huge game list slows detection for other games, and would require
- require (currently missing) localization support
- - only small subset of games actually supported by upstream, but none
- of them detected on TOS 8+3 file system
- - https://wiki.scummvm.org/index.php?title=Director
- - Hugo (3 games)
- - Uses (lot of) overlay dialogs which are problematic for Atari backend
- - Engine GUI (for save/load/etc) does not support 8-bit screens
- - https://wiki.scummvm.org/index.php?title=Hugo
+ - Cine (2 games)
+ - incompatible with other engines / prone to freezes
+ - https://wiki.scummvm.org/index.php?title=Cine
+ - Director (many games)
+ - huge game list slows detection for other games, and would require
+ (currently missing) localization support
+ - only small subset of games actually supported by upstream, but none of
+ them detected on TOS 8+3 file system
+ - https://wiki.scummvm.org/index.php?title=Director
+ - Hugo (3 games)
+ - Uses (lot of) overlay dialogs which are problematic for Atari backend
+ - Engine GUI (for save/load/etc) does not support 8-bit screens
+ - https://wiki.scummvm.org/index.php?title=Hugo
- Indy4 (the adventure) may have a bug in the screen when you K.O. the bouncer.
I was able to get a freeze when he fell to the ground but currently I am
@@ -426,8 +516,8 @@ Future plans
- cached audio/video streams (i.e. don't load only "audio_buffer_size" number
of samples but cache, say, 1 second so disk i/o wont be so stressed)
-- using LDG or Thorsten Otto's sharedlibs: https://tho-otto.de/sharedlibs.php
- for game engine plugins to relieve the huge binary size
+- using Thorsten Otto's sharedlibs: https://tho-otto.de/sharedlibs.php for game
+ engine plugins to relieve the huge binary size
- true audio CD support via MetaDOS API
@@ -437,13 +527,10 @@ Future plans
Closing words
-------------
-This backend is part of ScummVM 2.8.0 onwards. Let's see whether we can make it
-to the official website. :-)
-
Many optimisations and improvements wouldn't be possible without help of Eero
-Tamminen, so thank you for all the help.
+Tamminen, so thank you for all the help with profiling in Hatari.
-Miro Kropacek a.k.a. MiKRO / Mystic Bytes, XX.XX.2023
+Miro Kropacek aka MiKRO / Mystic Bytes, 16.12.2023
Kosice / Slovakia
miro.kropacek at gmail.com
http://mikro.atari.org
diff --git a/configure b/configure
index b8a943b6ae8..d93a048e7b7 100755
--- a/configure
+++ b/configure
@@ -3732,7 +3732,7 @@ if test -n "$_host"; then
append_var DEFINES "-DNDEBUG"
#append_var DEFINES "-DDISABLE_TEXT_CONSOLE"
append_var CXXFLAGS "-I$($_host_alias-gcc -print-sysroot)/opt/mintlib-dlmalloc/include"
- append_var LDFLAGS "-L$($_host_alias-gcc -print-sysroot)/opt/mintlib-dlmalloc/lib/m68020-60"
+ append_var LDFLAGS "-L$($_host_alias-gcc -print-sysroot)/opt/mintlib-dlmalloc/lib/$($_host_alias-gcc $LDFLAGS -print-multi-directory)"
fi
_seq_midi=no
More information about the Scummvm-git-logs
mailing list