ScummVM/Falcon060 pre-release

[mikro]

OK, except the PQ all the hard bugs should be gone:

https://mikro.naprvyraz.sk/private/scum ... i-lite.zip
https://mikro.naprvyraz.sk/private/scum ... i-full.zip

I reworked / simplified graphics resolution handling a bit, so it's possible there are bugs (TT and/or lite version are good candidates for that).

EDIT 20:38: everything should be fixed now. I was about to give up on the PQ bug (as it looked like an issue during processing of the game script) but at the last moment I nailed it down: https://github.com/scummvm/scummvm/pull/6234. So PQ demo not only doesn't freeze but also plays music! Although it's true that for some reason it insists on using its own MIDI emulator.

Also, a small speed optimisation has been added, unaligned memory accesses were disabled for m68k, resulting in a slower code at some places.

[mikro]

I have updated source code to latest master and recompiled again. Why? I have noticed that my https://bugs.scummvm.org/ticket/14843 was fixed as part of https://bugs.scummvm.org/ticket/15016 therefore no more scanning for the weird _MACOSX paths!

[Eero Tamminen]

EDIT 20:38: everything should be fixed now. I was about to give up on the PQ bug (as it looked like an issue during processing of the game script) but at the last moment I nailed it down: https://github.com/scummvm/scummvm/pull/6234. So PQ demo not only doesn't freeze but also plays music! Although it's true that for some reason it insists on using its own MIDI emulator.

Verified:

• Police Quest: does not freeze any more
• Eco Quest: massively faster startup now
• 3 Skulls of the Toltecs: does not crash any more
• Touche: cursor is fine now (I hadn't realized Touche was using wrong cursor...)
• Wetlands: palette is OK now

Great work!

Btw. If you're on some ScummVM chat, maybe you could mention there those demo regressions, that happen also on PC?

(Polish LSL & Hebrew Magic Tales not running, Ctrl-Q not working for Discworld.)

Also, a small speed optimisation has been added, unaligned memory accesses were disabled for m68k, resulting in a slower code at some places.

I reworked / simplified graphics resolution handling a bit, so it's possible there are bugs (TT and/or lite version are good candidates for that).

Did some checking also for the lite version, seemed to work fine.

E.g. "Simon the Sorcerer 2" worked surprisingly well under TT emulation. Speech worked nearly perfectly.

[Eero Tamminen]

I have updated source code to latest master and recompiled again. Why? I have noticed that my https://bugs.scummvm.org/ticket/14843 was fixed as part of https://bugs.scummvm.org/ticket/15016 therefore no more scanning for the weird _MACOSX paths!

It still seems to go out of the game directory, up to drive root?

Code: Select all

User picked target 'rama-demo' (engine ID 'sci', game ID 'rama')...
WARN : No GEMDOS dir '/home/user/hatari/build/scummvm-comparison/scummvm-2.9-20241112-full/__MACOSX'
7 repeats of: WARN : No GEMDOS dir '/home/user/hatari/build/scummvm-comparison/scummvm-2.9-20241112-full/__MACOSX'
GEMDOS 0x3D Fopen("scummvm\rama-dos\resmap.001", read-only) at PC=0x278C032
-> FD 64 (read-only -> read+write)
GEMDOS 0x3E Fclose(64) at PC 0x278B940
GEMDOS 0x3D Fopen("scummvm\rama-dos\ressci.001", read-only) at PC=0x278C032
-> FD 64 (read-only -> read+write)
GEMDOS 0x3E Fclose(64) at PC 0x278B940
WARN : No GEMDOS dir '/home/user/hatari/build/scummvm-comparison/scummvm-2.9-20241112-full/__MACOSX'
8 repeats of: WARN : No GEMDOS dir '/home/user/hatari/build/scummvm-comparison/scummvm-2.9-20241112-full/__MACOSX'
[00537945] Running RAMA (Demo/DOS/English)

Any why it needs to check for existence of the same dir for 8-9 times?

[mikro]

Hmm, I'll check it at home. I presume your C: is "/home/user/hatari/build/scummvm-comparison/scummvm-2.9-20241112-full" and that folder contains a "scummvm" folder with games?

As for the bug reports, you know, it's just hassle for me. They would tell me to create a ticket, I would be getting updates about it and ... I don't really care whether some demo doesn't work due to internal application logic. If somebody wants to run that demo, he will report it. I have to really filter out most of the stuff on their Discord to keep me sane. ScummVM is a huge project, I could work on it fulltime and still not have everything under control. So I focus only on obvious performance and compatibility issues.

I dug into the PQ issue because in the end it seemed quite intriguing and I love intriguing issues. ;-)

Btw Eero, you once mentioned that there's a visible performance boost when changing GUI scale from "Normal" (I guess you meant the default 100% one) to "Small" (75%), is this still true? Do you see something different in the profiler? If so, I could make it default, at least for the lite version.

[Eero Tamminen]

Hmm, I'll check it at home. I presume your C: is "/home/user/hatari/build/scummvm-comparison/scummvm-2.9-20241112-full" and that folder contains a "scummvm" folder with games?

Yes, the game outputting those messages was in "scummvm\rama-dos\" subfolder under "scummvm-2.9-20241112-full".

Btw Eero, you once mentioned that there's a visible performance boost when changing GUI scale from "Normal" (I guess you meant the default 100% one) to "Small" (75%), is this still true? Do you see something different in the profiler? If so, I could make it default, at least for the lite version.

Are you sure it was between those? I did not profile them, only tested them quickly manually with lite version under TT emulation, and "100%" seemed potentially faster (maybe because with fewer lines it moves larger part of screen on scrolling, and there's less text to draw on screen).

As for the bug reports, you know, it's just hassle for me. They would tell me to create a ticket, I would be getting updates about it and ... I don't really care whether some demo doesn't work due to internal application logic. If somebody wants to run that demo, he will report it. I have to really filter out most of the stuff on their Discord to keep me sane. ScummVM is a huge project, I could work on it fulltime and still not have everything under control. So I focus only on obvious performance and compatibility issues.

Maybe you could copy-paste something like this to their chat:

ScummVM regressions (git at 2024-11-12)

Users of my ScummVM backend reported following issues, for demos from ScummVM demo page.

Because I could reproduce them on PC, they are of no interest to me, and I will NOT be filing any bugs on them, but I thought to mention them here in case somebody wants to look at them.

Regressions compared to previous ScummVM release:
* Polish "Leasure Suit Larry in the land of lounge lizards" demo startup fails to "Error running game: reading data failed" dialog
* ScummVM quits during Hebrew "Magic Tales" demo startup, after outputting "Invalid section name: ~:\demo\splash!" warning

Other reported issues:
* Demos for "The Big Red Adventure" and "Kingdom: Far Reaches" crash to NULL pointer error => why completely non-working games are enabled?
* RAMA demo logging says it tries to (unsuccesfully) patch "supernova.dat" and "teenagent.dat" files, which are for different game engines!
* Discworld I & II demos ignore Ctrl-Q key, i.e. do not return to back to ScummVM menu

[mikro]

Yes, the game outputting those messages was in "scummvm\rama-dos\" subfolder under "scummvm-2.9-20241112-full".

Confirmed. I have reopened the ticket: https://bugs.scummvm.org/ticket/15016#comment:16 and fought to keep it open so you see, I do care about some bug reports. ;)

Are you sure it was between those?

Yup: viewtopic.php?p=442345#p442345

Maybe you could copy-paste something like this to their chat:

When you go through that list, that's about 5 different issues to look at and investigate. I can't blame anybody wanting me to file them in. Some time ago I did ask them whether we consider broken demos as bug and the reply was positive. So you see, the best we can do here is that you report them personally. :D

Btw, I think the engines are not non-working, just the demos are. IIRC @Teki or someone was successfully testing at least BRA (full).

[Eero Tamminen]

Are you sure it was between those?

Yup: viewtopic.php?p=442345#p442345

Ah, it was from (almost) 2 years ago. I think how ScummVM interface scaling worked changed completely after that (maybe in summer 2023?). I.e. that comment is not relevant any more.

[mikro]

I don't remember any drastic changes in that area but if you don't see any slowdowns anymore, cool.

Btw that __MACOSX search in the path where scummvm.{exe,ttp} is located is meant to be a feature. So the bug has been (again) closed. Perhaps those duplicate searches will be fixed only when/if I look into that search algorithm: i.e. not to iterate over all file tables looking for a certain file in the game dir but do it the other way around, collect the files and for each one search the match only once.

[Eero Tamminen]

I don't remember any drastic changes in that area but if you don't see any slowdowns anymore, cool.

I remember there being some change that made GUI (fonts?) look broken on Atari, until something with GUI scaling was fixed.

[mikro]

I can't run Falcamp without crashing the system, so does CAB and Litchi with memory protection on, so no, it's not easy, because there are so many possibilities and no centralised point as reference to understand what part of the system do what.

Btw, how did you solve the Litchi crashing with MP on latest snapshots? My Falcon setup is in pieces so I had to quickly improvise and create a temporary boot disk with FreeMiNT, NVDI etc and got this crash as well.

[mikro]

A small update, as the release cut-off is nearing (December 6) I am trying to push the final changes (there aren't that many but...). So the following archives are build on top of the new 2.9 branch:

- removed move16 code based on my recent investigation: https://www.atari-forum.com/viewtopic.p ... 52#p471952 (so CT60 users should see a small speedup... in theory this decreases performance a bit on AB040 but since there aren't any known users...)

- removed all (engine) debug messages for release builds: this shaves off a good 800 KB and makes some engines a bit faster for sure. Also, if natfeats are available, (atari) debug output is printed only there, so no need to watch the console anymore (and perhaps it's faster, too)

- final refactoring of screen resolution handling code, now I really like the way it is (some bugs might have been fixed, some might have been introduced ;))

The aim of the last point was also to making the transition (overlay -> game -> overlay) without any visual artefacts but for some reason this still doesn't work 100%. The idea was that if you are setting a new video mode (e.g. overlay's 640x480), which is done using VsetMode(), which in TOS waits for Vsync() and then sets the Videl registers, code like:

- set black palette (done in nearest vbl)
- call vsetmode (this makes sure that the black palette is set)
- disable vblsem (nothing is set: neither palette nor screen address)
- update palette/screen address for the upcoming vbl
- restore palette (again in nearest vbl)
- enable vblsem

should lead to a perfect resolutions witch. And yet it doesn't. Perhaps I'll look into it for 2.9.1, now I'm really running out of time for other duties... I'm not aware of any serious bugs or limitations, these builds should be as good as ever for some serious testing:

https://mikro.naprvyraz.sk/private/scum ... i-lite.zip
https://mikro.naprvyraz.sk/private/scum ... i-full.zip

[guibrush]

I can't run Falcamp without crashing the system, so does CAB and Litchi with memory protection on, so no, it's not easy, because there are so many possibilities and no centralised point as reference to understand what part of the system do what.

Btw, how did you solve the Litchi crashing with MP on latest snapshots? My Falcon setup is in pieces so I had to quickly improvise and create a temporary boot disk with FreeMiNT, NVDI etc and got this crash as well.

It solved itself when I re-installed the system from scratch. I muss confess that I'm mostly running without memory protection, mostly because I'm playing with Basilisk II a bit. But I just checked with memory protection ON and it works, here a connection with my Amiga.





I'm using MINT 1-19-BC6 with XaAES and Jinnie as desktop (I know, I know, but I love it), the program flag on Litchi is set on Private and I'm using Litchi version 1.3I

[mikro]

Interesting. OK, perhaps I'll do some testing later - it worked for me in the past as well so I was just wondering whether there wasn't a single PRG in AUTO/mint.cnf which made it working with MP again.

[koji77]

I'm late to this party but very interested. Whats the latest update and what version should I download at this point ... Yes I am an ignorant total novice

[mikro]

Look at the links two posts above yours. ;) If you have a CT60, download the "full" version, if something like an accelerated TT, CT2 or DFB Falcon (030@50 MHz), download the "lite" version.

[Eero Tamminen]

A small update, as the release cut-off is nearing (December 6) I am trying to push the final changes (there aren't that many but...). So the following archives are build on top of the new 2.9 branch:
...
https://mikro.naprvyraz.sk/private/scum ... i-lite.zip
https://mikro.naprvyraz.sk/private/scum ... i-full.zip
...
I'm not aware of any serious bugs or limitations, these builds should be as good as ever for some serious testing:

I tested lite version under TT emulation, with things that had produced error dialogs earlier, before returning to menu.

Mission Supernova: https://familie-dingel.de/simplicity/

Shows error dialogs about not finding "supernova.dat" (8+3 filename issue), and not finding English text, after which ScummVM exits, instead of returning back to menu:

Code: Select all

[00211680] Failed reading game strings!
[00211680] OSystem_Atari::quit()
[00211680] OSystem_Atari::~OSystem_Atari()

Blue Force: https://downloads.scummvm.org/frs/demos ... emo-en.zip

ScummVM quits when demo starts:

Code: Select all

GEMDOS 0x3D Fopen("scummvm\blueforc\blue.rlb", read-only) at PC=0x2073AEE
-> FD 64 (read-only -> read-only)
[00607755] Unknown resource type 4 num 1!
[00607755] OSystem_Atari::quit()
[00607755] OSystem_Atari::~OSystem_Atari()

MADS game demos: Dragonsphere / Return of the Phantom / Rex Nebular

All give "not yet fully supported" dialog, after which ScummVM quits:

Code: Select all

[00066735] Could not open file - *FONTINTR.FF!
[00066735] OSystem_Atari::quit()
[00066735] OSystem_Atari::~OSystem_Atari()

Then rechecked with full version...

Magic Tales (Hebrew demo)

Still exits ScummVM on error, instead of returning to menu:

Code: Select all

[00360435] failed to find key '100' in section '~:\demo\splash' of book config!
[00360435] OSystem_Atari::quit()
[00360435] OSystem_Atari::~OSystem_Atari()

=> Are these a ScummVM error handling regression, or is this new behavior intended?

[mikro]

I don't know but they surely do not look look like our backend's errors so they don't bother me that much. I'm mostly worried about rendering errors, sound glitches and so on.

I'm aware of one case (well, except the tooltips): sometimes the cursor rectangle is incorrectly restored. IIRC one of the test cases is that I run Eco Quest demo (up to the point when the arrow cursor is shown), exit to the launcher, launch Discworld demo and sometimes I see a rectangle written over DW's game screen. Sometimes it goes as far as the actual DW's cursor is broken and I have to enter the overlay menu (CTRL+F5) and leave to restore it properly. Anyone reproducing it in some other way would help me a lot as it's quite annoying (but not fatal). It's with default settings (triple buffer, full version).

[Eero Tamminen]

LBA demo: https://downloads.scummvm.org/frs/demos ... o-mult.zip

Seems a bit faster than earlier, but the onscreen button menus (at start & during game) were annoyingly slow, so I profiled them a bit:

Code: Select all

Time spent in profile = 60.51220s.
...
Used cycles:
  35.58%  35.94%  35.95%   690749186 697774641 698017971   Graphics::ManagedSurface::blitFromInner(Graphics::Surface const&, Common::Rect const&, Common::Rect const&, Graphics::Palette const*)
  18.59%  18.78%  19.02%   360896512 364613282 369186578   TwinE::Menu::plasmaEffectRenderFrame()
  10.90%  11.02%  11.02%   211621537 213868195 214025554   TwinE::Interface::shadeBox(Common::Rect const&, int)
   9.71%                   188545176                       c2p1x1_8_rect_start
   7.51%                   145895463                       c2p1x1_8_rect_pix16
   4.89%   5.02%  57.58%    94866092  974431261117997106   TwinE::Menu::processPlasmaEffect(Common::Rect const&, int)
   3.60%   3.65%   7.39%    69804315  70779697 143545234   TwinE::Text::drawCharacter(int, int, unsigned short)
   2.05%                    39817719                       copy256
   1.81%   1.83%   3.88%    35213364  35550235  75424331   Common::MemoryReadStream::read(void*, unsigned int)
   1.19%                    23151029                       ROM_TOS

=> Over half of the time goes to plasma effect for the button highlighting:

lba-dialog.png

Maybe you could just patch "return" to start of that effect function: https://github.com/scummvm/scummvm/blob ... u.cpp#L252 ?

According to comment there, that effect code is not used for LBA v2, so maybe just skipping it could be fine...

PS. Here's the Intel asm for the effect in original LBA game: https://github.com/2point21/lba1-classi ... S/FIRE.ASM

[mikro]

Oofff... in the end I had a quite stable repro of that cursor bug so I told myself "why not give it a chance to find a quick fix?"

Well, 12 hours and one huge commit later I can happily report that:

- *all* cursor bugs are gone, past, present and future :)
- the video transition artefacts are gone as well

When I found out the true nature of the cursor problem, I just couldn't let it exist in code anymore. Unfortunately it required rewriting some core parts of the graphics manager but here we are, I'm very pleased with the result - many hacks and fragile parts could be removed. Now if something will look wrong, it will be much easier to debug (I saw some weird stuff on SV+direct rendering but this will have to wait for 2.9.1 -- my Falcon setup is currently unusable for some serious work).

Those should be considered as 2.9-beta releases, hopefully I haven't introduced any regression (I gave it an honest test session in Aranym and on real hardware - yes, the one in pieces - and eliminated many loose ends so fingers crossed):

https://mikro.naprvyraz.sk/private/scum ... i-lite.zip
https://mikro.naprvyraz.sk/private/scum ... i-full.zip

[Eero Tamminen]

Tested several games with the lite version, both ones that I had tested earlier, and ones I had not.

Did not notice any issues, except for resolution warnings also exiting ScummVM instead of returning back to main menu.

Was annoyed by the very long freezes during Drascula intro, so I profiled few of those, and all time in those freezes goes to ARJ depacking:

drascula-freezes.png

=> Don't see easy way to speed that up, except changing to some less demanding algorithm and recompressing data, which is not worth the trouble for just single game.

Miro, the LBA button menu fix seems trivial though, could you try it (adding "return" to start of Twine engine Menu::processPlasmaEffect() method)?

[mikro]

Did not notice any issues

That must be our first! ;-)

exiting ScummVM instead of returning back to main menu.

Are you sure this isn't just the effect of the option in GUI tab? IIRC there's exactly this, quit to launcher enable/disable.

Miro, the LBA button menu fix seems trivial though, could you try it (adding "return" to start of Twine engine Menu::processPlasmaEffect() method)?

This is the kind of change which would have to stay out of the main tree I'm afraid. Is that game worth playing on Atari? ;-)

[Eero Tamminen]

Did not notice any issues

That must be our first!

Heh, now that you mentioned, I see some minor effect from the cursor, it sometimes leaves trails to the GUI.

So far I've seen it only when moving cursor from one highlighted text element to another one, and mostly it's so minor that IMHO it's no problem:

gui-cursor-effect.png

exiting ScummVM instead of returning back to main menu.

Are you sure this isn't just the effect of the option in GUI tab? IIRC there's exactly this, quit to launcher enable/disable.

Yes, I'm sure:

Code: Select all

$ grep -e gfx_ -e gui_ -e vsync scummvm.ini | grep -v save
vsync=true
gui_theme=builtin
gfx_mode=single
gui_scale=100
gui_return_to_launcher_at_exit=true
gui_disable_fixed_font_scaling=true
gui_browser_show_hidden=false
gui_renderer=normal
original_gui_text_status=1

Miro, the LBA button menu fix seems trivial though, could you try it (adding "return" to start of Twine engine Menu::processPlasmaEffect() method)?

This is the kind of change which would have to stay out of the main tree I'm afraid.

That single "return;" statement would be just to check whether mouse highlight still works in button menus after plasma effect is skipped.

If it does, there could be some #ifdef that can be used for retro machine builds, or even GUI option for "[x] Plasma effect on menus".

(IMHO only after that is fixed, it would make sense for me to look more into rest of the game perf.)

Is that game worth playing on Atari?

According to Wikipedia, it's got good ratings, and was one of the games coming for Jaguar CD version, so there's an Atari angle to it too: https://en.wikipedia.org/wiki/Little_Bi ... evelopment

While game intro is fast enough, game play itself is still very slow on emulated TT, but I think it could be playable on accelerated (060) Falcon.

=> Maybe Teki could try out the LBA demo to check how playable it's on his machine: : https://downloads.scummvm.org/frs/demos ... o-mult.zip ?

[mikro]

Trails in the GUI: I think that's all the side effect (let's say 95% implementation) of the tooltips branch. I really have to get back to it one day and get it merged.