Replies: 2 comments
-
All memory reads are formatted as addresses appropriate for the system. On machines with <64KB of memory, the addresses are only 4 characters ( The serializer uses the same function to write an address to the serialized string as is used to format the address for the editor. One could argue that AddAddress offsets should not be formatted as addresses as they are offsets, but the first item in an AddAddress chain is going to be an address, so it's not something that can just be assumed for AddAddress. A better argument would be that no formatting is needed at all as the serialized string is not meant for human consumption. While it would be possible to generically remove all padding zeroes, I'm hesitant to do so for the same reason I argue against raising the limit. I realize that the 64KB restriction for a single achievement's logic is sometimes not enough, but that works out to roughly 4500 conditions that have to be evaluated every frame even when achievements are for some part of the game that the player is no where near. Anything that I do that makes it possible to have more conditions means that more conditions will have to be evaluated every frame and thus more time spent processing achievements. At some point, that's going to start to slow down the emulator. At 60fps, each frame has to be completed in less than 16ms. That includes all the time spent doing the emulation, rendering the frame, and processing achievements. I'm not sure what your logic is doing, but most achievement sets have several achievements with similar logic for doing the same thing in different maps or with different target scores. If you really need 8000 conditions (or whatever threshold you actually reached to cause you to work around the implementation), and you multiply that across 5 or 6 achievements, that's 40000+ conditions that are going to be evaluated every frame. You also most likely have the same logic twice in your achievement - once for current value and once for the delta. I envision having helper variables to manage complex logic like AddAddress or AddSource chains. Then the runtime could evaluate the singular variable once per frame and any achievements dependent on it would be able to look at its current or delta value without having to duplicate the logic in each achievement and for each delta. This would reduce both the size of the individual achievements and the per-frame overhead. Unfortunately, it's one of those things that's dependent on some server work and just hasn't been feasible yet. |
Beta Was this translation helpful? Give feedback.
-
Thank you very much for the detailed explanation! Unfortunately, there was no way for me to make the achievements any simpler. It's just the way the game handles the data in memory and I have to work with what I have. Helper variables seem like an extremely valuable addition to the site, and I look forward to the day when that is feasible. |
Beta Was this translation helpful? Give feedback.
-
I was having issues getting an achievement within the character limit that involved stepping through a linked list, where navigating through the list mostly involves steps of +0xc to reach the next pointer. The toolkit seems to pad zeroes to every address, so that they are 8 characters total. See the image below for what I mean:
Removing these padded zeroes reduced the achievement character count in half. See below for an example of the result:
It works now, but if I ever edit the achievement, it will add the zeroes again.
Would it be an option to have the toolkit not pad zeroes in this way?
Thank you for your consideration.
Beta Was this translation helpful? Give feedback.
All reactions