|
Post by DarkKobold on May 9, 2020 2:39:33 GMT
With huge thanks to turboxray, I was able to use the under-utilized "CONST_BANK" to store extra sprites. This freed up the ~6k that I wasn't able to use, while still leaving some extra space for more actual constants. To put this in perspective, I was able to move 46x 16x16 sprite tiles worth of graphics into this space. For Catastrophy, that's an entire enemy's worth of animation frames. Data goes quick in the 256kB limited size of an overlay, so every (literal) bit helps.
#asm .data .bank CONST_BANK #endasm
#incspr...
A few notes - you have to manage this on your own - if you write beyond it, it will overwrite the "USER PROGRAM" bank. I'm not even entirely sure what the User Program bank does. it's only 200 bytes long, but things break if you overwrite it. Meanwhile... don't do it.
Further, this has to be right after your #include "huc.h" so that it goes in the right place. HuC will just overwrite what it's already written. I've learned that the hard way.
|
|
|
Post by DarkKobold on Jul 20, 2020 1:42:14 GMT
So, I completely ran out of space in the final area. I needed more space to add another attack pattern to the final boss, but I only had 945 bytes left for code, and the final sprite bank was at ~7k used.
Time to crunch more.
First, I edited HuC to start the code of Bank 2 at $AE60 instead of $A600
.data .bank LIB2_BANK,"Base Library 2/Font" .org $6000 .include "font.inc" .code .bank LIB2_BANK .org $AE60 Then, since the default font is just a waste of space, I overwrote it. Note, when using this technique, you have to make sure that the $AE60 never changes - or you're using too much space!
#asm .data .bank LIB2_BANK,"Base Library 2/Font" .org $6000 #endasm
#incspr(GameOverL,"spr/GameOver.png",0,0,2,2); #incspr(GameOverR,"spr/GameOver.png",32,0,2,2); #incspr(BoomerangUpgrade, "spr/Items_Other_Palette.png",0,0,2,1); #incspr(AxeUpgrade, "spr/Items_Other_Palette.png",0,16,2,1); #incspr(spikemaskspr,"spr/spear_mask.png"); #incpal(boomerangpal,"spr/Items_Other_Palette.png");
Further, squirrel takes to till the end of a Bank, regardless of how much data it actually uses. Thus, I edited squirrel's output, and changed the start location. To figure out where the maximum value of .org was, I just kept increasing until it stopped compiling due to Overlay overflow. That indicated that the required data actually passed the size of the bank. I was also able to delete a lot of SFX that have been replaced by ADPCM.
#asm .data .bank $3 .org $8F00 _sngBank1: .include ".\squirrel\syd_cd.asm" .code
#endasm
Then, before I call squirrel, I add my graphics into that bank:
#asm .data .bank $3 .org $80C9 #endasm While I don't know if anyone else is ever going to be pushing HuC to the extent I do, this may save someone else in the future. For those who are curious, this is how the breakdown of space is used
No errors PC Engine Assembler (v 3.24-ff0c326-dirty, 2020-04-1
pass 1 pass 2 segment usage:
USED/FREE ZP $2000-$2015 [ 22] 22/ 234 BSS $2200-$2F1F [3360] 3360/4832
BANK 0 Base Library 1 7567/ 625 CODE $C000-$C024 [ 37] CODE $402F-$406E [ 64] CODE $4070-$412A [ 187] CODE $C130-$DD9E [7279] BANK 1 Base Library 2/Font 7739/ 453 DATA $6000-$6C9F [3232] CODE $AE60-$BFFA [4507] BANK 2 Constants 7821/ 371 DATA $4000-$5E8C [7821] BANK 3 User Program 8136/ 56 DATA $6000-$60C7 [ 200] DATA $80C9-$8EC8 [3584] DATA $8F00-$9FFF [4352] BANK 4 8192/ 0 DATA $8000-$9FFF [8192] BANK 5 8192/ 0 DATA $8000-$9FFF [8192] BANK 6 8192/ 0 DATA $8000-$9FFF [8192] BANK 7 8192/ 0 DATA $8000-$9FFF [8192] BANK 8 8192/ 0 DATA $8000-$9FFF [8192] BANK 9 8181/ 11 DATA $8000-$9FF4 [8181] BANK A 8184/ 8 CODE $A000-$BFF7 [8184] BANK B 8184/ 8 CODE $A000-$BFF7 [8184] BANK C 8189/ 3 CODE $A000-$BFFC [8189] BANK D 8189/ 3 CODE $A000-$BFFC [8189] BANK E 8168/ 24 CODE $A000-$BFE7 [8168] BANK F 8190/ 2 CODE $A000-$BFFD [8190] BANK 10 8191/ 1 CODE $A000-$BFFE [8191] BANK 11 8189/ 3 CODE $A000-$BFFC [8189] BANK 12 8191/ 1 CODE $A000-$BFFE [8191] BANK 13 8188/ 4 CODE $A000-$BFFB [8188] BANK 14 8190/ 2 CODE $A000-$BFFD [8190] BANK 15 8191/ 1 CODE $A000-$BFFE [8191] BANK 16 8169/ 23 CODE $A000-$BFE8 [8169] BANK 17 8171/ 21 CODE $A000-$BFEA [8171] BANK 18 8191/ 1 CODE $A000-$BFFE [8191] BANK 19 8190/ 2 CODE $A000-$BFFD [8190] BANK 1A 8174/ 18 CODE $A000-$BFED [8174] BANK 1B 8178/ 14 CODE $A000-$BFF1 [8178] BANK 1C 8191/ 1 CODE $A000-$BFFE [8191] BANK 1D 7238/ 954 CODE $A000-$BC45 [7238] BANK 1E 2106/6086 CODE $8000-$8839 [2106] ---- ---- 240K 8K
TOTAL SIZE = 248K The only space that we'll apparently never reclaim is the 6kB in the final bank. You'll see how much I am pushing this, if you compare this to a non-pushed compile of the first banks:
No errors PC Engine Assembler (v 3.24-ff0c326-dirty, 2020-04-
pass 1 pass 2 segment usage:
USED/FREE ZP $2000-$2015 [ 22] 22/ 234 BSS $2200-$2DBB [3004] 3004/5188
BANK 0 Base Library 1 7567/ 625 CODE $C000-$C024 [ 37] CODE $402F-$406E [ 64] CODE $4070-$412A [ 187] CODE $C130-$DD9E [7279] BANK 1 Base Library 2/Font 6043/2149 DATA $6000-$65FF [1536] CODE $A600-$B79A [4507] BANK 2 Constants 373/7819 DATA $4000-$4174 [ 373] BANK 3 User Program 8136/ 56 DATA $6000-$60C7 [ 200] DATA $8100-$9FFF [7936] Anyway, even if you don't code, maybe you'll find my trials and tribulations interesting.
|
|
nicole
Gun-headed
Posts: 50
Fave PCE Shooter: Magical Chase
Fave PCE Platformer: Legendary Axe II
Fave PCE RPG: Ys III
|
Post by nicole on Jul 22, 2020 1:01:52 GMT
Neat stuff! Definitely will need to keep some of these tricks in mind if I start to run low on space; haven't hit that yet (fingers crossed).
I'm curious, are you storing your graphics alongside your code in the same overlay? I have a separate data overlay for graphics at the moment and am wondering if there's a downside to that approach.
|
|
|
Post by DarkKobold on Jul 22, 2020 3:27:47 GMT
Neat stuff! Definitely will need to keep some of these tricks in mind if I start to run low on space; haven't hit that yet (fingers crossed). I'm curious, are you storing your graphics alongside your code in the same overlay? I have a separate data overlay for graphics at the moment and am wondering if there's a downside to that approach. It depends on how you are doing your graphics - if you're able to store all your animation and background tiles in the available VRAM, then you have a lot of space for code. However, you won't be able to load in new graphics fast. Even small loads will take abysmal amounts of time. It'd be important to burn the occasional CD to make sure that you aren't relying on emulator speeds of CD loads. Bizhawk makes things that take 30 seconds happen instantaneously.
|
|