SCUMM: Some graphics rendering cleanup #2382
Conversation
Makes implementation of additional blit functions and allocation of purpose-specific VirtScreens easier.
A generic masked blit function for blitting only the pixels not matching the mask color to the destination buffer.
Consolidate the consortium of function-specific code to use blit and masked blit instead.
The _compositeBuf allocated in the ScummEngine constructor was never actually used for anything, and could instead sometimes result in a null pointer free(). Added a larger _compositeBuf for V8 layered rendering.
This commit is a bit unwieldly, since it required editing a lot of rendering functions with previously hardcoded destination surfaces in order to be able to render to and erase from specific layers. Does not seem to impact performance negatively in any game, lowers CPU load in CoMI by a relative lot, since it avoids a ton of data copying.
|
Very cool, do you have some metrics around impact to CPU usage for these changes? |
|
I don't have any precise metrics, unfortunately. The V6/V7 games all hovered around 0% CPU usage on my main PC, any difference was too small for even |
I had managed to nuke the Day of the Tentacle text/verb virtual screens, so the inventory and status line were invisible. Noticed while testing on Amiga that the virtual screens were still being reallocated, apparently I forgot to actually set the byte size of an initialized virtual screen when creating it.
According to the description, restoreCharSetBg would only restore the pixels that had been affected by any displayed text, but instead it cleared and redrew the entire screen. Many thanks to mheyer32 for noticing that something strange was up with this.
ghost
closed this
ghost
deleted the
|
Any reason why did you close this? |
|
Uhh, I was cleaning up some of my old github stuff earlier, and figured that since there had been no activity here for months that it wasn't interesting for the main ScummVM branch. The changes themselves are still available in my scummvm-amigaos3 branch. |
|
@beeanyew I believe it will worth merging as your modifications could also be useful for those who use ScummVM on slow computers running OS4 and MOS |
|
Hm. It does sound rather unlikely, considering that even the slowest PPC running MorphOS or AmigaOS 4 should be multiples of tens times the speed of say a 50MHz 68030, or even a 50MHz 68060 with a massively higher memory bandwidth. If they're having issues updating a 320x200 screen, the problems are probably somewhere else in their Platform implementation. |
|
Yep maybe, however there are multiple reasons to have that changes included also in main repository .. also for others who eventually in the future would want to continue your port on AmigaOS 3.x |
|
I haven't dropped the AmigaOS 3.0 port at all, which is why I'm saying that the changes are still in that repo on my github. All I've said is that the AmigaOS 3.0 port can't be made up to date with the main branch anymore due to the use of features such as UTF-32 strings and engine dependencies on libraries that are either nearly impossible to build or do not perform to any reasonable degree on this operating system from 1992. Just grab my code and make it your PR, I don't want credit for it or anything. |
|
Well, if from the analysis of the code no problems will emerged (or any other changes that need to be made) I think we could already do the merge .. What do you think, can you merge the current code ? |
|
Yes, I think, the code is worth merging. |
|
Any news ? :-) |
|
@samo79 what news? @beeanyew needs to restore his branch... |
|
Just to make this clear, there's no branch to restore. I removed the scummvm repo fork from my github account because I have no interest in the main ScummVM branch. All the code I changed is still available in the commits displayed on the page for this pull request, and the changes are also in my amigaos3 repo over at https://github.com/beeanyew/scummvm-amigaos3/tree/zz9k-stuff Like I said, I want no credit for this, or anything to do with it. Take my code and make it your own PR. It's a bit of work, sure, but not anything impossible. |
|
I meant if you had the time to merge these changes into the main repo, of course once you have verified the correctness of the changes.. eventually once merged i'm availible to test these under AmigaOS4 @beeanyew Among classic Amiga of today there is also the Vampire with cpu 68080 .. |
|
Please stop tagging me. I know of the Vampire accelerator boards, and they don't need any of these changes either, because they're essentially 4x the speed of a 50MHz 68060 with an infinitely faster memory interface for their RTG. |
|
Okay, the topic is closed then. |
|
Ok the topic was closed but the code was not merged yet in main branch, can you do that when you have the time? |
|
@samo79 There's nothing to merge as the changes require additional work, someone will have to pick it up and submit a new PR before this can be considered. |
|
@beeanyew As I'm working on something similar (Atari Falcon 060@66 MHz), @samo79 was kind enough to point me to your PR.
Maybe this was true when you were working on this PR but from my experience, basically everything is possible to switch off. I'm linking my scummvm only with zlib, nothing else, out of the box.
Unfortunately, it seems you've removed the whole repository at some point. Any chance of bringing it back? I don't see your scummvm flavour even on aminet. :-( |
|
Hello, unfortunately I cannot assist you with this, if you had caught me last year, it would have been possible.
I have since that time permanently blocked and signed out of GitHub, left all development and Amiga communities and deleted all of my code locally as I no longer wish to participate in anything. (I am replying to you using email, I cannot access the web site.)
Keeping GPL licensed source code in a fashion where it is unavailable to everyone else is not something the license allows.
The only thing I can think of is checking the “PiStorm” and “Amiga dev” (the ScummVM channel specifically) Discord servers, see if anyone forked or cloned one of my repos, I physically no longer have any of my old files that were available exclusively on GitHub.
From: Miro Kropáček ***@***.***>
Sent: Tuesday, February 7, 2023 4:15 PM
To: scummvm/scummvm ***@***.***>
Cc: beeanyew ***@***.***>; Mention ***@***.***>
Subject: Re: [scummvm/scummvm] SCUMM: Some graphics rendering cleanup (#2382)
@beeanyew <https://github.com/beeanyew> As I'm working on something similar (Atari Falcon ***@***.*** MHz), @samo79 <https://github.com/samo79> was kind enough to point me to your PR.
All I've said is that the AmigaOS 3.0 port can't be made up to date with the main branch anymore due to the use of features such as UTF-32 strings and engine dependencies on libraries that are either nearly impossible to build or do not perform to any reasonable degree on this operating system from 1992.
Maybe this was true when you were working on this PR but from my experience, basically everything is possible to switch off. I'm linking my scummvm only with zlib, nothing else, out of the box.
the changes are also in my amigaos3 repo over at https://github.com/beeanyew/scummvm-amigaos3/tree/zz9k-stuff
Unfortunately, it seems you've removed the whole repository at some point. Any chance of bringing it back? I don't see your scummvm flavour even on aminet. :-(
—
Reply to this email directly, view it on GitHub <#2382 (comment)> , or unsubscribe <https://github.com/notifications/unsubscribe-auth/AFAHSG6Q34AP7RBT2L5YPFDWWJRHZANCNFSM4PIPU6WQ> .
You are receiving this because you were mentioned.Message ID: ***@***.***>
|
|
@mikrosk : There are several clone / trees available on Github for scummvm-amigaos3. The first one is based on v1.8.1 release and was last updated in 2016: The second one is more up to date, based on v2.0.0 release: The most up to date one I could find is based on v2.2.0 release: Hope that helps. |
|
Versions 1.8.1 and 2.0.0 for AmigaOS 3 68k were lastly updated in 2016 and 2020, so for sure they cannot include the changes of this PR that beeanyew is looking for... The most updated fork for AmigaOS 3 68k are the one of betajean based on the 2.2.0 release. Aniway even if the repo was shutten down, i suggest to pick the code directly from here, and then eventually do a manually merge: |
|
Okay, I've managed to rebase beeanyew's code. It goes cleanly for 2.2.0 (that can be done with zero effort), relatively effortless for 2.5 and with some sweat on the later versions. As soon as I manage to finish the master branch for 100%, I'll test it and try to measure some numbers (I use COMI as one of my test cases so I should see some improvement). After that, I can proudly presents someone else's code as a new PR. ;) |
|
@mikrosk |
|
Actually, in the end I took the opposite route - to be sure that the fix/patch is really working, I backported my Atari changes to And I have bad news -- I simply wasn't able to reproduce any significant speedup on Atari Falcon 060@66 MHz. I even tried to disable the whole rendering part (using the null renderer), no difference either. I've been in touch with beeanyew, he could remember some explicit cases of huge speedup he'd seen (e.g. the intro credits in Full Throttle) but to no avail. There can be various reasons for this:
So I'm leaving this for some fellow Amiga coder. Fetching & creating this PR's branch is easy: |
|
68060 are maybe powerfull enough to spot any differences, eventually you may try asking someone in the Atari community to try this executable with a slower 68020/68030/68040 processors |
|
@samo79 let's discuss the question of merging here. As mentioned, it's not so easy. For 2.2 - 2.5, sure, it is but when it comes to master, I couldn't even vouch for this code to be doing something. And as you have seen in the Atari PR, guys here can be pretty thorough when it comes to reviews, so I'd feel pretty uncomfortable defending the patch, especially if parts of it will have to be removed due to a different way how master solves the problem in the present. Not to mention my inability to reproduce the issue in the first place. So the best I can do for you is to offer a rebased As for the 68030 CPU, I do have a Falcon with 50 MHz 030 and Fast RAM but it is disassembled now. What could be a nice push why to assemble it again, indeed. ;) |
While working on the AmigaOS 3 port of ScummVM, I ran into issues
with a lot of spread out code and looparounds, making it difficult to
add any optimizations that would allow the m68k processors in these
machines to run things better, so I wanted to clean up at least a bit
of the main graphics rendering loop.
There are still quite a few different memcpy/rendering loops in the
other files (charset, actor, etc.), but I will continue to look at
these as I make progress with getting the AmigaOS 3 port back
in better shape.
This lowers CPU load in games that do a lot of blast object/text
rendering, such as Curse of Monkey Island (naturally) and the
V6/V7 games by avoiding data copying in favor of just erasing dirty
rects from layers directly. The simple two layer rendering for
games like INDY4 may be a tiny bit slower than before, but not to
any noticeable extent even on an m68k processor.
NOTE:
I have not tested all SCUMM/HE games with these changes, but I did
test most of the ones I own to a reasonable extent to make sure that
everything seemed to be working correctly compared to before these
changes were made.)