[scummvm-devel] Hello from Atari world!

[Eugene Sandulenko]

Welcome!

On Sat, 4 Mar 2023 at 20:12, Miro Kropáček via scummvm-devel <
scummvm-devel at lists.scummvm.org> wrote:

> Hi everyone,
>
> Sev was brave enough to offer me a permanent ScummVM developer status and
> asked me to introduce myself.
>
> Well, I'm from Slovakia, 40+ y.o. and since the 90s my biggest computer
> love is the Atari brand. I started with an 8-bit Atari in 1993, had an ST
> in 1997 and finally Atari Falcon in 2001. Since the 2000s I've been
> enjoying programming in m68k assembler and C for the Falcon, you can find
> some of my works on my website.
>
> Professionally I work as a C++ developer for about 15+ years, currently at
> Bohemia Interactive Simulations.
>
> I'm sort of maintaining various Atari projects like SDL, FreeMiNT,
> gcc+binutils, Atari800, ... and have done some ports just for fun,
> including an early version ScummVM, Descent or OpenTTD. Those were never
> officially released because I wasn't satisfied with the quality but you
> know how it is, over the time you kind of let go.
>
> Maybe you have noticed another Atari porter of ScummVM, OpenTTD or even
> gcc, Keith Scroggins (KeithS), we have been passing the torch so to say
> to each other, when I was busy/lazy, he did some work on his own and vice
> versa.
>
> Current situation of ScummVM for Atari is not so good: it is built against
> an old SDL version, it doesn't even seems to work anymore and most
> importantly: it's very resource-hungry because of the SDL backend (every
> additional surface creation/conversion hurts performance on a <100 MHz
> machine). Over the christmas holidays I was highly inspired by an AmigaOS3
> port of ScummVM done by NovaCoder:
> https://forums.scummvm.org/viewtopic.php?t=9673 and told myself to "give
> it a week or two" to measure how quick it would be without any additional
> layers. And happily, it seemed to be good enough not only to justify a more
> serious work but maybe even to create a version for *really* low-end Atari
> machines for some games (say, 32 MHz as the bare minimum). Especially after
> I have discovered Vladimir Serbinenko's work on RGB332 format, I am amazed
> how well that works despite the bit depth limitations (before that I was
> about to go down the
> https://forums.scummvm.org/viewtopic.php?p=57964#p57964 road...).
>
> So, fast forward two months and here I am, on the verge of accepted pull
> request and signing my soul for future work / releases for the Atari Falcon
> backend (called "atari" in source code).
>
> Except the atari backend I might contribute to other areas of ScummVM,
> like:
>
>    - engine optimisations (my big dream is to see somehow unified calls
>    to copyRectToScreen() function - perhaps using the Screen class - it hurts
>    my eyes to see that some engines basically do all their work "in house" and
>    then in copyRectToScreen() I basically just copy the whole game buffer to
>    my buffer and then copy that buffer to screen in updateScreen() ... but
>    many engines don't do this so I have to keep copyRectToScreen() versatile
>    with that one additional buffer)
>    - audio optimisations (https://bugs.scummvm.org/ticket/14267 is a good
>    candidate)
>    - generic refactoring / bugfixes found during my development (as I
>    usually work in quite a different environment / setup)
>
> but for those I'd of course always open a PR to see how plausible my idea
> / approach is.
>
> I guess that covers the introduction, thanks for having me onboard!
>
> Miro
>
> --
> http://mikro.atari.org
> _______________________________________________
> scummvm-devel mailing list
> scummvm-devel at lists.scummvm.org
> https://lists.scummvm.org/listinfo/scummvm-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.scummvm.org/pipermail/scummvm-devel/attachments/20230304/9e2428e9/attachment.htm>