ScummVM 2.8.0 released

Latest news in the Atari world

Moderators: Mug UK, Silver Surfer, Moderator Team

mikro
Hardware Guru
Hardware Guru
Posts: 4188
Joined: Sat Sep 10, 2005 11:11 am
Location: Kosice, Slovakia
Contact:

Re: ScummVM 2.8.0 released

Post by mikro »

AnachronyX wrote: Sat Apr 06, 2024 7:53 pmThe only thing, what's wrong are numpad keys (rotation left and right doesn't work right).
Wow, you are completely correct. I will have to investigate, I see all keypad keys are mapped so no clue what's going on there. Thanks for reporting it!

EDIT: ... aaand fixed. It was a combination of both bad documentation and bad mappings.
AnachronyX
Atari maniac
Atari maniac
Posts: 85
Joined: Sun Mar 08, 2009 12:33 pm

Re: ScummVM 2.8.0 released

Post by AnachronyX »

I just tried Amiga version of EoB, but it doesn't start. I still get error message about missing EOBF6.FONT and EOBF8.FONT even if they're both in the game main folder both with corresponding subdirectories and files in them.
You do not have the required permissions to view the files attached to this post.
mikro
Hardware Guru
Hardware Guru
Posts: 4188
Joined: Sat Sep 10, 2005 11:11 am
Location: Kosice, Slovakia
Contact:

Re: ScummVM 2.8.0 released

Post by mikro »

Seeing that those are long names, could it be that you run it from TOS FAT which can't handle more than 8+3 filenames? (Hatari does a nice job of translating its GEMDOS drive filenames into TOS 8+3 but in case of ScummVM it doesn't work so nicely so you have to use FreeMiNT/MagiC for such cases)
AnachronyX
Atari maniac
Atari maniac
Posts: 85
Joined: Sun Mar 08, 2009 12:33 pm

Re: ScummVM 2.8.0 released

Post by AnachronyX »

mikro wrote: Mon Apr 08, 2024 8:28 am Seeing that those are long names, could it be that you run it from TOS FAT which can't handle more than 8+3 filenames? (Hatari does a nice job of translating its GEMDOS drive filenames into TOS 8+3 but in case of ScummVM it doesn't work so nicely so you have to use FreeMiNT/MagiC for such cases)
According to this page on project wiki https://wiki.scummvm.org/index.php?titl ... e_Beholder the DOS version uses shortened file extension to *.FNT. Maybe the sources could be compiled slightly modified to obtain the same result. But I have no idea how difficult it could be.

I tried DOS version of The Legend of Kyrandia with FluidSynth in Hatari enabled and it work nearly flawlessly, better than any other game I tried :cheers:
AnachronyX
Atari maniac
Atari maniac
Posts: 85
Joined: Sun Mar 08, 2009 12:33 pm

Re: ScummVM 2.8.0 released

Post by AnachronyX »

Unbelievable... Works like a charm :)
You do not have the required permissions to view the files attached to this post.
User avatar
Eero Tamminen
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 3674
Joined: Sun Jul 31, 2011 1:11 pm

Re: ScummVM 2.8.0 released

Post by Eero Tamminen »

AnachronyX wrote: Mon Apr 08, 2024 8:23 pm I tried DOS version of The Legend of Kyrandia with FluidSynth in Hatari enabled and it work nearly flawlessly, better than any other game I tried :cheers:
Here's my list of games that work OK in (emulated) 32Mhz Falcon:
  • AGI: 13th Disciple (0.5MB fanmade)
  • AGI: Christmas card 1986 (non-interactive) (0.3MB)
  • AGI: Enclosure (1.3MB fanmade)
  • AGI: Space Quest 0, Replicated (1.4MB fanmade)
  • AGI: Space Quest X, The Lost Chapter (1.7MB fanmade)
  • AGI: AGI Tetris (0.2MB fanmade)
  • AGOS: Simon the Sourcerer 1 demo (1.2MB) - speech + MIDI music
  • AGOS: Simon the Sourcerer 2 ( 28MB) - speech + MIDI music
  • Dreamweb: Dreamweb (22MB) - non-MIDI music
  • Kyra: Lands of Lore, The Throne of Chaos (46MB, startup takes 45s) - speech
  • Kyra: The Legend of Kyrandia 1 demo (non-intractive) (1MB)
  • Kyra: The Legend of Kyrandia 2, the Hand of the Fate (69MB)
  • Lure: Lure of the Temptress (7.1MB)
  • SCUMM: Fatty Bear's Birthday Surprise (2MB) - speech
  • SCUMM: Indiana Jones and the Fate of the Atlantis (1.2MB)
  • SCUMM: Loom DOS EGA long demo (non-interactive) (0.9MB)
  • SCUMM: Maniac Mansion (non-interactive) (0.3MB) - beeps
  • SCUMM: Putt-Putt Goes to the Moon (2MB) - sounds in addition to MIDI
  • SCUMM: Putt-Putt Joins the Parade (2MB) - sounds in addition to MIDI
  • SCUMM: Sam & Max Hit the Road (1.8MB)
  • SCUMM: Zak McKracken and the Alien Mindbenders (non-interactive) (0.2MB) - beeps
  • Parallaction: Nippon Safes Inc. (0.7MB) - sound effects in Amiga version
  • Queen: Flight of the Amazon Queen (22MB) - speech
  • Sky: Beneath a Steel Sky (9MB)
  • Tinsel: Discworld I (3.5MB)
Working fine, but only with music / Adlib emu disabled:
  • SCUMM: Bear Stormin' (0.6MB) - sounds, no MIDI
  • SCUMM: The Passport to Adventure (Indy, SOMI, and Loom demos, 1MB)
  • SCUMM: The Secret of Monkey Island (0.5MB EGA demo, 46MB full VGA)
Sluggish, but playable:
  • AGI: Hero's Quest, So You Want to Be a Hero (non-interactive) (0.6MB)
  • AGI: King's Quest IV, The Perils of Rosella (non-interactive) (0.2MB)
  • BBVS: Beavis and Butt-Head (50MB) - speech
    - 3 intro AVI videos fail, so starts really fast
  • MADE: Return to Zork (188MB) - speech + MIDI / other music + sounds
  • SCI: Christmas card 1988 (non-interactive) (0.3MB)
  • SCI: Leisure Suit Larry 2 (1.6MB)
    - 1 min to Sierra logo on standard Falcon
  • SCI: Ms. Astro Chicken (0.6MB) - sound effects
  • Sherlock: The Case of the Serrated Scalpel (1.1MB)
  • Tucker: Bud Tucker in Double Trouble (83MB) - speech
    - 2 min to demo start on standard Falcon
  • Voyeur: Voyeur - intro speech OK, TV Gossip echoes horribly, sound runs faster than video
("Return to Zork" demo has rather impressive intro.)

The "Very slow, but potentially still somewhat enjoyable on 32Mhz" list:
  • Access: Amazon, Guardians of Eden (1.1MB)
  • Illusions: Duckman, The Graphic Adventures of a Private Dick (119MB)
  • Mohawk: Myst - sounds echo badly on transitions (115MB)
  • Mortevielle: Mortville Manor - really slow start (0.8MB)
  • SAGA: Inherit the Earth, Quest for the Orb (3.5MB Amiga)
  • SCI: Shivers (179MB)
  • SCI: Leisure Suit Larry I (remake, 0.5MB) - few sound effects
  • SCI: Space Quest 6: The Spinal Frontier (125MB)
    - over 20 minutes of black screen at start on standard Falcon
  • SCI: Police Quest (non-interactive) (early ones)
    - Screen transitions can take minutes on standard Falcon
  • SCI: Quest for Glory I (non-interactive) (1.2MB)
    - 1 min to Sierra logo on standard Falcon
  • SCI: Code-Name Iceman (non-interactive) (0.7MB)
    - 1 min to Sierra logo on standard Falcon
  • SCI: Conquests of the Longbow: The Legend of Robin Hood
    (non-interactive) (1.2MB) - has speech
  • SCI: Freddy Pharkas: Frontier Pharmacist (1.5MB)
    - 3 min to demo start on standard Falcon
  • SCUMM: Day of the Tentacle (non-interactive) (1.8MB)
    - has speech, disable Adlib music
  • SCUMM: The Dig (46MB) - speech, non-MIDI music
  • SCUMM: Full Throttle (170MB, full) - speech + non-MIDI music
  • Sword1: Broken Sword, The Shadow of Templars (159MB)
  • Toltects: 3 Skulls of Tolltecs (45MB)
(I'd recommend checking "Inherit the Earth, Quest for the Orb", "Freddy Pharkas" and "Full Throttle" demos.)

List of games using screen shaking feature:
  • AGI: Enclosure (on logo screen and later)
  • AGI: Space Quest X, The Lost Chapter (on intro crash landing)
  • AGI: Hero's Quest, So You Want to Be a Hero (non-interactive demo, at start)
  • SCI: Laura Bow I, The Colonel's Bequest (when dagger hits letter at start)
  • SCI: Pepper's Adventures in Time (after starting game, when the text drops down)
  • SCUMM: Full Throttle (demo only, when clicking on objects at start)
  • SCUMM: Sam & Max Hit the Road (demo, after going to Bosco's Liquor store)
Games with larger (typically 640x480) resolution (=not TT):
  • Gob: Woodruff and the Schnibble of Azimuth (non-interactive) (9.2MB)
    - Speech OK
  • Gob: The Last Dynasty (non-interactive) (13MB)
  • Gob: Playtoons Collection - Uncle Archibald (non-interactive) (17MB)
  • Hypno: Marvel Comics Spider-Man, The Sinister Six (32MB)
  • SAGA: I Have No Mouth, and I Must Scream (88MB) - speech OK
  • SCUMM: The Curse of Monkey Island (29MB)
  • Tinsel: Discworld II (53MB)
  • Toon: Toonstruck (95MB) - 640x400, bound by path finding:
    https://www.atari-forum.com/viewtopic.p ... 84#p445284
  • Touche: The adventures of the 5th musketeer (73MB) - 640x400, speech OK
(I'd recommend checking "Touche" demo.)
mikro
Hardware Guru
Hardware Guru
Posts: 4188
Joined: Sat Sep 10, 2005 11:11 am
Location: Kosice, Slovakia
Contact:

Re: ScummVM 2.8.0 released

Post by mikro »

Nice list Eero, thanks!
User avatar
leech
Atari God
Atari God
Posts: 1457
Joined: Tue Dec 01, 2015 3:26 pm

Re: ScummVM 2.8.0 released

Post by leech »

What's amusing to me, is this will actually allow Ultima VI to be played with VGA graphics on an Atari. :) It's awesome that the Atari port is part of the official upstream. Not sure why AmigaOS3 isn't on there, as Novacoder's port is quite excellent.
Atari 8Bits: 800xl, 600xl, XEGS, 800, 130xe, 130xe (VBXE, U1MB, Stereo POKEY)
Atari STs: 1040STf (broken shifter), 1040STe, Mega STe, TT030, Falcon (CT60e, SuperVidel)
mikro
Hardware Guru
Hardware Guru
Posts: 4188
Joined: Sat Sep 10, 2005 11:11 am
Location: Kosice, Slovakia
Contact:

Re: ScummVM 2.8.0 released

Post by mikro »

NovaCoder's port is now way slower than ours if I may say so -- it uses forced fullscreen double-buffering in comparison to Atari's rectangle-based triple-buffering. And as a bonus, it converts 16-bit GUI into 8-bit + C2P on the fly. This takes its toll.

Anyway, the main reason is that he chose to stick with older ScummVM (2.3.0 at this moment) for speed reasons (nah...) so that's why. There was some other Amiga guy who left the scene/porting for some drama reasons and he also chose to use some ancient version... I'd love to have one shared m68k backend, that would be pretty awesome (I wouldn't be alone for all that work!)
User avatar
leech
Atari God
Atari God
Posts: 1457
Joined: Tue Dec 01, 2015 3:26 pm

Re: ScummVM 2.8.0 released

Post by leech »

mikro wrote: Sat Apr 20, 2024 9:02 pm NovaCoder's port is now way slower than ours if I may say so -- it uses forced fullscreen double-buffering in comparison to Atari's rectangle-based triple-buffering. And as a bonus, it converts 16-bit GUI into 8-bit + C2P on the fly. This takes its toll.

Anyway, the main reason is that he chose to stick with older ScummVM (2.3.0 at this moment) for speed reasons (nah...) so that's why. There was some other Amiga guy who left the scene/porting for some drama reasons and he also chose to use some ancient version... I'd love to have one shared m68k backend, that would be pretty awesome (I wouldn't be alone for all that work!)
Nice! I need to try yours out. I need to get a newer set up working for my CT60e+SV setup going. Too much of the shenanigans that were tweaked for easymint... but definitely intend on trying out the new release very soon!
Atari 8Bits: 800xl, 600xl, XEGS, 800, 130xe, 130xe (VBXE, U1MB, Stereo POKEY)
Atari STs: 1040STf (broken shifter), 1040STe, Mega STe, TT030, Falcon (CT60e, SuperVidel)
User avatar
mfro
Atari God
Atari God
Posts: 1265
Joined: Thu Aug 02, 2012 10:33 am
Location: SW Germany

Re: ScummVM 2.8.0 released

Post by mfro »

mikro wrote: Sat Dec 30, 2023 4:40 pm ... P.P.P.S. FireBee users are still stuck with the SDL version, mostly due to its non-working video XBIOS. If somebody shows me a working fullscreen 320x240 / 640x480 screen with 8-bit chunky pixels+palette, I'm in...
Here's how: https://github.com/mfro0/fb_video

The example uses an extract of umc (a video mode calculator) and is more of a general showcase on how to set any video mode the FireBee is capable of.

Have fun!

The code does fine with 640x480 (8 bit chunky as requested), 320x240 does work as well, but my monitor hardly syncs on it.
mikro
Hardware Guru
Hardware Guru
Posts: 4188
Joined: Sat Sep 10, 2005 11:11 am
Location: Kosice, Slovakia
Contact:

Re: ScummVM 2.8.0 released

Post by mikro »

mfro wrote: Tue Apr 23, 2024 3:27 pmHere's how: https://github.com/mfro0/fb_video
Oh, that's really nice stuff, thanks!

However I have a few questions:
The example uses an extract of umc (a video mode calculator) and is more of a general showcase on how to set any video mode the FireBee is capable of.
1. So assuming I keep the FB register writes, can I take values from TOS4 (HHT, VFT etc) and omit the calculations?

2. Why isn't this part of EmuTOS? ScummVM currently just calls VsetMode(BPS8 / BPS8C) (Videl / SuperVidel = chunky 8-bit) and that's how I envision my work for the FireBee as well. :) Also, your fVDI driver code would suddenly become trivial.
The code does fine with 640x480 (8 bit chunky as requested), 320x240 does work as well, but my monitor hardly syncs on it.
3. I find this very surprising, 320x240 is nothing but double pixels/lines, there's no reason why any of the modeline parameters should drastically change, especially those affecting frequency, polarity etc. Maybe you can try to calculate 640x480 modeline and set Videl registers for 320x240?
User avatar
Eero Tamminen
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 3674
Joined: Sun Jul 31, 2011 1:11 pm

Re: ScummVM 2.8.0 released

Post by Eero Tamminen »

leech wrote: Sat Apr 20, 2024 7:54 pm What's amusing to me, is this will actually allow Ultima VI to be played with VGA graphics on an Atari. :) It's awesome that the Atari port is part of the official upstream. Not sure why AmigaOS3 isn't on there, as Novacoder's port is quite excellent.
Ultima engine is disabled in Miro's versions, for good reasons: https://www.atari-forum.com/viewtopic.p ... 52#p455352

(Ultima-1 support could be included after this is fixed: https://bugs.scummvm.org/ticket/14790)

I.e. you would need to use Keith's complete SDL version, which in upstream downloads page is a Coldfire build: https://www.scummvm.org/downloads/
User avatar
mfro
Atari God
Atari God
Posts: 1265
Joined: Thu Aug 02, 2012 10:33 am
Location: SW Germany

Re: ScummVM 2.8.0 released

Post by mfro »

mikro wrote: Tue Apr 23, 2024 7:13 pm ...
1. So assuming I keep the FB register writes, can I take values from TOS4 (HHT, VFT etc) and omit the calculations?
I don't think so. The FireBee has 5 possible video (pixel) clock sources: 4 fixed clocks (13, 17, 25 and 33 MHz) and one freely programmable clock (being the most universal clock source, obviously). The code is using the latter with the included modeline calculator.
The 8 bit chunky mode is a special FireBee mode and as soon as you activate that, the 13 and 17 MHz clocks aren't available anymore, and - worse - some of the Videl registers slightly change their behaviour. I have to study the HDL if there is a way to work around that or what exactly needs to change. The video mode calculator ends up with a programmed clock at 24 MHz, it might well be the 25 MHz clock is close enough to work (I can check that, but that might take a while).

2. Why isn't this part of EmuTOS? ScummVM currently just calls VsetMode(BPS8 / BPS8C) (Videl / SuperVidel = chunky 8-bit) and that's how I envision my work for the FireBee as well. :) Also, your fVDI driver code would suddenly become trivial.
I assume because it's not Falcon compatible? My fVDI driver, for now, is 16 bit only, so for that there isn't a problem.
The code does fine with 640x480 (8 bit chunky as requested), 320x240 does work as well, but my monitor hardly syncs on it.
3. I find this very surprising, 320x240 is nothing but double pixels/lines, there's no reason why any of the modeline parameters should drastically change, especially those affecting frequency, polarity etc. Maybe you can try to calculate 640x480 modeline and set Videl registers for 320x240?
I didn't yet find (again, I still need to check the HDL more thoroughfully) a way to activate double lines for the FireBee mode.
User avatar
mfro
Atari God
Atari God
Posts: 1265
Joined: Thu Aug 02, 2012 10:33 am
Location: SW Germany

Re: ScummVM 2.8.0 released

Post by mfro »

Ah, forgot one thing: the code allocates screen memory in ST RAM. This works with BaS_gcc (instead of Fredi's BaS) in flash that maps FPGA memory as ST RAM (while the real memory is at the address that Mxalloc() returned + an offset of 0x40000000). It also requires EmuTOS.

I have no idea about how to allocate video RAM with FireTOS, but would assume if you don't intend to return to TOS at game end, you should get away with just using screen memory from 0x40000000 onwards.
mikro
Hardware Guru
Hardware Guru
Posts: 4188
Joined: Sat Sep 10, 2005 11:11 am
Location: Kosice, Slovakia
Contact:

Re: ScummVM 2.8.0 released

Post by mikro »

This is definitely good progress (against "it just doesn't work" as I used to believe) however this code is still a bit too much to swallow.

I wouldn't be so reluctant to take the EmuTOS route, though: if you check videl.c, it has pretty huge tables with values for every (PAL/NTSC/VGA) mode, so one #ifdef for the FireBee with its specific values shouldn't pose a problem.

Oh and the 320x240 is also quite essential for ScummVM. In theory, we could cheat the same way as on the TT (320x480 with every second line empty) but I'd rather provide normal picture.
User avatar
leech
Atari God
Atari God
Posts: 1457
Joined: Tue Dec 01, 2015 3:26 pm

Re: ScummVM 2.8.0 released

Post by leech »

Eero Tamminen wrote: Tue Apr 23, 2024 7:49 pm
leech wrote: Sat Apr 20, 2024 7:54 pm What's amusing to me, is this will actually allow Ultima VI to be played with VGA graphics on an Atari. :) It's awesome that the Atari port is part of the official upstream. Not sure why AmigaOS3 isn't on there, as Novacoder's port is quite excellent.
Ultima engine is disabled in Miro's versions, for good reasons: https://www.atari-forum.com/viewtopic.p ... 52#p455352

(Ultima-1 support could be included after this is fixed: https://bugs.scummvm.org/ticket/14790)

I.e. you would need to use Keith's complete SDL version, which in upstream downloads page is a Coldfire build: https://www.scummvm.org/downloads/
Boo! No value? Literally would be the only way to play Ultima VI on an Atari with VGA graphics. The native version was an EGA only port. Though yes, Ultima 1 is not available on the ST. Though, neither is the VGA upgrade of Ultima IV. VIII definitely doesn't run yet on any Atari computer, though could through ScummVM.
Atari 8Bits: 800xl, 600xl, XEGS, 800, 130xe, 130xe (VBXE, U1MB, Stereo POKEY)
Atari STs: 1040STf (broken shifter), 1040STe, Mega STe, TT030, Falcon (CT60e, SuperVidel)
mikro
Hardware Guru
Hardware Guru
Posts: 4188
Joined: Sat Sep 10, 2005 11:11 am
Location: Kosice, Slovakia
Contact:

Re: ScummVM 2.8.0 released

Post by mikro »

leech wrote: Tue Apr 23, 2024 10:25 pmBoo! No value? Literally would be the only way to play Ultima VI on an Atari with VGA graphics. The native version was an EGA only port. Though yes, Ultima 1 is not available on the ST. Though, neither is the VGA upgrade of Ultima IV. VIII definitely doesn't run yet on any Atari computer, though could through ScummVM.
The Ultima ports are not very well suited for retro hardware. Despite their original requirement of 320x200@256c, their implementations require 16-bit highcolor, huge asset data files and most likely are not very well optimised.

ScummVM as is on Atari already supports more engines than it should ;-), opening the can of worms with 16-bit graphics would result in yet another flood of bug reports / performance request improvements etc... I think I have stated it somewhere in the dev thread, if it were me, ScummVM would be just SCUMM, Revolution and Gob engines, so everything else is just a bonus.
User avatar
mfro
Atari God
Atari God
Posts: 1265
Joined: Thu Aug 02, 2012 10:33 am
Location: SW Germany

Re: ScummVM 2.8.0 released

Post by mfro »

Well, it turns out double line mode and 8-bit chunky (FireBee video) are right now set mutually exclusive in the HDL, so unfortunately no ready to use 320x240 double line chunky mode available. With normal mode 320 x 240 @ 120 Hz my screen grabber (kind of) syncs (flickering), but my monitor doesn't. YMMV.

There is - as far as I can see - however no real technical reason why this is not permitted in FireBee mode. Requires a (hopefully rather simple) HDL change. I promise to look into that (but please don't expect a solution by next week, I'm pretty busy currently with other tasks).
User avatar
leech
Atari God
Atari God
Posts: 1457
Joined: Tue Dec 01, 2015 3:26 pm

Re: ScummVM 2.8.0 released

Post by leech »

mikro wrote: Wed Apr 24, 2024 7:19 am
leech wrote: Tue Apr 23, 2024 10:25 pmBoo! No value? Literally would be the only way to play Ultima VI on an Atari with VGA graphics. The native version was an EGA only port. Though yes, Ultima 1 is not available on the ST. Though, neither is the VGA upgrade of Ultima IV. VIII definitely doesn't run yet on any Atari computer, though could through ScummVM.
The Ultima ports are not very well suited for retro hardware. Despite their original requirement of 320x200@256c, their implementations require 16-bit highcolor, huge asset data files and most likely are not very well optimised.

ScummVM as is on Atari already supports more engines than it should ;-), opening the can of worms with 16-bit graphics would result in yet another flood of bug reports / performance request improvements etc... I think I have stated it somewhere in the dev thread, if it were me, ScummVM would be just SCUMM, Revolution and Gob engines, so everything else is just a bonus.
All true for a stock Falcon, or maybe even one with a faster 030. But an 060 build with a SuperVidel or the Vampire/Apollo Core with EmuTOS would open up the requirements quite a bit.

How clean is the build, maybe I'll look into compiling it myself and doing a test (since I have access to both pieces of hardware).

It is kind of nuts when you think about how much extra overhead it actually adds to run this via ScummVM over what a dos base system needed for those old games. (The first game that made me think 'holy crap, that is huge!' Was Ultima 6 (which my memory may be fuzzy, but the DOS version was basically a 4mb install, the ST version was 2mb (at the time I simply surmised that it was because the ST only supported EGA graphics, and DOS supported both EGA and VGA.) The next massive game was Ultima VII at 21mb... ha, these days, 100gb+ games are becoming far too common!
Atari 8Bits: 800xl, 600xl, XEGS, 800, 130xe, 130xe (VBXE, U1MB, Stereo POKEY)
Atari STs: 1040STf (broken shifter), 1040STe, Mega STe, TT030, Falcon (CT60e, SuperVidel)
mikro
Hardware Guru
Hardware Guru
Posts: 4188
Joined: Sat Sep 10, 2005 11:11 am
Location: Kosice, Slovakia
Contact:

Re: ScummVM 2.8.0 released

Post by mikro »

Everything is pushed upstream, scripts to build are in backends/platform/atari. The change to support 16-bit games is not complex (both for UI and engines), you could even skip the UI part if supplied the name as a command line parameter.

As for the overhead, well, it depends on the person who is doing the reverse engineering. Some prefer nearly 1:1 port, some prefer reimplementation in a more modern way, adding bloat. Discworld and Lucasarts games run just great, when the DSP mixer will be done I'm sure they will run on stock Falcon (well, with some TT RAM...) fluently.
User avatar
leech
Atari God
Atari God
Posts: 1457
Joined: Tue Dec 01, 2015 3:26 pm

Re: ScummVM 2.8.0 released

Post by leech »

mikro wrote: Wed Apr 24, 2024 10:11 am Everything is pushed upstream, scripts to build are in backends/platform/atari. The change to support 16-bit games is not complex (both for UI and engines), you could even skip the UI part if supplied the name as a command line parameter.

As for the overhead, well, it depends on the person who is doing the reverse engineering. Some prefer nearly 1:1 port, some prefer reimplementation in a more modern way, adding bloat. Discworld and Lucasarts games run just great, when the DSP mixer will be done I'm sure they will run on stock Falcon (well, with some TT RAM...) fluently.
Awesome. Scummvm is definitely a great way to bring more games to a platform, and getting the Atari build to be official is amazing. I'll keep chipping away at getting my Falcon set up to where I want it to be, and start doing some testing.
Atari 8Bits: 800xl, 600xl, XEGS, 800, 130xe, 130xe (VBXE, U1MB, Stereo POKEY)
Atari STs: 1040STf (broken shifter), 1040STe, Mega STe, TT030, Falcon (CT60e, SuperVidel)
mikro
Hardware Guru
Hardware Guru
Posts: 4188
Joined: Sat Sep 10, 2005 11:11 am
Location: Kosice, Slovakia
Contact:

Re: ScummVM 2.8.0 released

Post by mikro »

Btw, I'm not completely against adding 16-bit support. Before I start considering it, one other thing should happen and that's adding support for dynamically loaded engines (it's already there, just needs an Atari implementation). That way it wouldn't matter whether we support 20 or 200 engines, as the base scummvm.ttp will be just 4-5 megs. In the present state, adding 16-bit games would be like 80 MB executable.
User avatar
leech
Atari God
Atari God
Posts: 1457
Joined: Tue Dec 01, 2015 3:26 pm

Re: ScummVM 2.8.0 released

Post by leech »

mikro wrote: Wed Apr 24, 2024 4:57 pm Btw, I'm not completely against adding 16-bit support. Before I start considering it, one other thing should happen and that's adding support for dynamically loaded engines (it's already there, just needs an Atari implementation). That way it wouldn't matter whether we support 20 or 200 engines, as the base scummvm.ttp will be just 4-5 megs. In the present state, adding 16-bit games would be like 80 MB executable.
That would be fantastic. I'll still try and get around to testing the stuff it currently supports. After all, there should still be all the Leisure Suit Larry games that I need to 'experience'. (I still remember playing part 3(?) on the ST and it asking 'adult' questions to be able to play the game... I just happen to be a smart enough kid to be able to answer them!)
Atari 8Bits: 800xl, 600xl, XEGS, 800, 130xe, 130xe (VBXE, U1MB, Stereo POKEY)
Atari STs: 1040STf (broken shifter), 1040STe, Mega STe, TT030, Falcon (CT60e, SuperVidel)
User avatar
Eero Tamminen
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 3674
Joined: Sun Jul 31, 2011 1:11 pm

Re: ScummVM 2.8.0 released

Post by Eero Tamminen »

LSL games are supported, but are on heavy side for 32Mhz machines.

SCI VM code in ScummVM is split to very small pieces which adds up to a noticeable overhead. It's the engine that requires Atari ScummVM to be built with Doug Lea's malloc, as malloc+free overhead was at worst 1/3 of all CPU cycles in some SCI engine based games with MiNTlib's own allocator!
Post Reply

Return to “News & Announcements”