Optimizing the usage of character-related data
Moderator: Moderators
Re: Optimizing the usage of character-related data
I assume there's no way to prevent the cc65 compiler from using the X register in C code, right?
My game "City Trouble":
Gameplay video: https://youtu.be/Eee0yurkIW4
Download (ROM, manual, artworks): http://www.denny-r-walter.de/city.html
Gameplay video: https://youtu.be/Eee0yurkIW4
Download (ROM, manual, artworks): http://www.denny-r-walter.de/city.html
-
- Posts: 1565
- Joined: Tue Feb 07, 2017 2:03 am
Re: Optimizing the usage of character-related data
CC65 is basically 16bit so it uses AX for everything.
Re: Optimizing the usage of character-related data
That's unfortunate.
I guess I have to try to reduce the variables then.
Unless there's some other trickery to copy variables in a faster way.
For example, if I store the variables of the 10 opponents into 10 arrays, and one array is my local buffer array where the data gets copied to, is there a way to bulk-copy an array into another array that's faster than individual LDAs and STAs?
I guess I have to try to reduce the variables then.
Unless there's some other trickery to copy variables in a faster way.
For example, if I store the variables of the 10 opponents into 10 arrays, and one array is my local buffer array where the data gets copied to, is there a way to bulk-copy an array into another array that's faster than individual LDAs and STAs?
My game "City Trouble":
Gameplay video: https://youtu.be/Eee0yurkIW4
Download (ROM, manual, artworks): http://www.denny-r-walter.de/city.html
Gameplay video: https://youtu.be/Eee0yurkIW4
Download (ROM, manual, artworks): http://www.denny-r-walter.de/city.html
Re: Optimizing the usage of character-related data
Not on NES. SNES would have that.
Re: Optimizing the usage of character-related data
You can fit FacingDirection, HorizontalDirection, VerticalDirection, HorizontalDirectionBeforeThrownAway, and VerticalDirectionBeforeThrownAway all in a single byte. I'm assuming you're doing stuff like "if (HorizontalDirection) {..}", then a hit like "if (HorizontalDirection & MASKhoriDirection) {..}" should be an extra 2 cycles for the immediate AND instruction. I mean if the C code isn't that optimal, you appear to already know how to code in some fashion of ASM.. so you could implement this yourself. You don't specifically need N and V flags for optimization.DRW wrote: ↑Thu Jun 30, 2022 3:43 pmUnfortunately no. The direction variables are up, down, left, right, none. Untouchable status is also a counter value for mercy invincibility. Only PatternIsAdditional is an actual boolean value.Oziphantom wrote: ↑Thu Jun 30, 2022 2:28 amFacingDirection, UntouchableStatus, HorizontalDirection, VerticalDirection, PatternIsAdditional, HorizontalDirectionBeforeThrownAway, VerticalDirectionBeforeThrownAway, LastHorizontalFacingDirection
these all seem to be bool flags, so 1 bit.
Like you said, do you really need all 35 bytes? I see that you have a few different state machines there.. I would streamline that if you don't have state machines that can/do run in parallel, then don't bother grabbing other state machine related indexes/support values. How many "objects" are you parsing through in a single frame? 4, 5,.. 10? Is this data structure only for "enemies" or do you re-use it for "items" as well? Do you have an active/de-active area mechanism in this game?
Honestly though, no one asked the question.. do you actually need to optimize your code? Is this something you're doing pre-emptively in order to avoid some future potential issue.. or is this an issue right now?? If it's an issue right now, what performance profile have your run on your game? Since this appears to be a complicated area to untangle and optimize (i.e. a heavier lift for refactoring), what other simpler support functions have you benchmarked that could provide some low hanging fruit for optimization? (Replace some of the simple functions with ASM code).
Re: Optimizing the usage of character-related data
Using VBCC is fine, provided that you know for certain that one of the following is the case:Oziphantom wrote: ↑Fri Jul 01, 2022 9:39 am ok coding in c... cc65? to which best bet is just use a better C compiler, port to Kick-C for best performance but harder to code in. Or VBCC,however LLVM-MOS is probably not ready for the prime time yet.
- you are targeting MEGA65 hardware (not NES),
- you are targeting AmigaOS on 68K, or
- you plan to never distribute for a fee any copies of the compiled code. This provision is incompatible with distribution on cartridge, incompatible with paid downloads bundled with an emulator on Steam or modern consoles, and incompatible with the submission policy of NESdev Compo.
In February 2021, I received a quote from the author that a license for commercial use of vbcc targeting the NES might cost on the order of 100 USD.
(Source: vbc's post in topic "VBCC Optimizing C-compiler now supports NES")
The commercial NES games Haunted: Halloween '85, Haunted: Halloween '86, and (forthcoming) Full Quiet use array access and keep the current actor's index in the X register most of the time.
These games are also commercial because they have appeared in an Action 53 volume:
- Thwaite keeps the index of the current crosshair, missile, explosion, or smoke particle being operated on in X.
- RHDE: Furniture Fight keeps the index of the current player, unit, or missile in X.
Re: Optimizing the usage of character-related data
Optimize characters, and dynamically generate characters using mirroring algorithm like game genie?
To save 8KB CROM? It's better to write one screen of data to cram in advance by using unrom
To save 8KB CROM? It's better to write one screen of data to cram in advance by using unrom
-
- Posts: 1565
- Joined: Tue Feb 07, 2017 2:03 am
Re: Optimizing the usage of character-related data
they are using character to reference actor or unit in the game, a story character not a letter to be displayed on the screen.