HuC overloaded graphics bank?

[DarkKobold]

I think I've overwhelmed HuC's use of graphics banks.

#incspr(VacuumEyeL,"spr/vacuum_eyes.pcx", 0,0,2,7);   
#incspr(VacuumEyeR,"spr/vacuum_eyes.pcx", 32,0,2,7);

- Result, ROM compiles and plays fine.

#incspr(VacuumEyeL,"spr/vacuum_eyes.pcx", 0,0,2,8);   
#incspr(VacuumEyeR,"spr/vacuum_eyes.pcx", 32,0,2,8);

Result:

pass 1
#[1]   main.s
13326  1A:A001                    .dw $0
       Bank overflow, offset > $1FFF!


#incspr(VacuumEyeL,"spr/vacuum_eyes.pcx", 0,0,2,10);   
#incspr(VacuumEyeR,"spr/vacuum_eyes.pcx", 32,0,2,10);

Result - ROM compiles, but won't run, at all.

I've tried the normal moving around the include lines, but no matter where I put them, I get the same result. Have I hit HuC's limit for graphics? Can I force banks in HuC?

[Arkhan]

What does your image look like, anyways?

Is this all you are loading?  You should be OK to do what you are doing.  I've loaded things like 0,0,12,8, which is going to load way more than what you are trying to load that isn't working.

and, IIRC, the incspr preprocessor is smart enough to do the banking for you.

I could be wrong about that.

[Gredler]

What does your image look like, anyways?

Here is an version of it, this is not the final image or color optimization, and was a screen grab I took while working on it so not scale either. Dimensions are 96x192. I think Nodt got him past the hurdle via a chat room assistance - thanks nodt!

[Arkhan]

That's interesting.  I load a 192x128 image as sprites by doing 0,0,12,8 and don't have any issues.   

What ended up solving the issue?

[Gredler]

The eyes swap out with. 64x32 so they can animate so maybe the image subdivision was the issue?

There are various other sprites on the same horizontal line; the cat character and the obsticals for him to avoid.

I'm interested to hear this discussion as I try to inch closer to understanding what the heck you code wizards are doing on that back end.

[DarkKobold]

Rover had me split the line, so it turned

#incspr(VacuumEyeL,"spr/vacuum_eyes.pcx", 0,0,2,10);   
#incspr(VacuumEyeR,"spr/vacuum_eyes.pcx", 32,0,2,10);

into

#incspr(VacuumEyeL,"spr/vacuum_eyes.pcx", 0,0,2,6);   
#incspr(VacuumEyeR,"spr/vacuum_eyes.pcx", 32,0,2,6);
#incspr(VacuumEyeL2,"spr/vacuum_eyes.pcx", 0,96,2,4);   
#incspr(VacuumEyeR2,"spr/vacuum_eyes.pcx", 32,96,2,4);

No clue why that worked. If it were just a banking issue, you'd think it would fix it by moving those lines around.

[Arkhan]

Yeah, I am at a bit of a loss for why that worked since it seems like the initial code should work.

IIRC, each 2x4 sprite is 1K, so you can put 8 of those in a bank. (8 32x64 sprites, or, a f*ckload of 16x16 sprites).

2*10 is definitely loading less than 12*8 is.    I wonder if the offset stuff isn't right, or if there's some other weird issue.

I always load from 0,0,X,Y.   Pretty sure the entire Atlantean sprite sheet of player/bullets/enemies is also bigger than what you tried to load unsuccessfully.   

Weird.

[Necromancer]

The problem is that the sprite he's trying to load sucks.

Ba-dum-tss!

[Gredler]

The problem is that the sprite he's trying to load sucks.

Ba-dum-tss!

[Bonknuts]

Bank overflow means just that; it crossed a bank boundary. This is a PCEAS thing and not necessarily a HuC error. But still, why HuC didn't evalute it and automatically move it to the next bank.. is weird (unless the whole thing, as a single include, is larger than 8k by itself).

 I modified PCEAS to allow crossing bank boundaries without problems. But I don't know how that would affect HuC for really large files (and it's included with it on two fork HUC git repositories).

[Arkhan]

Bank overflow means just that; it crossed a bank boundary. This is a PCEAS thing and not necessarily a HuC error. But still, why HuC didn't evalute it and automatically move it to the next bank.. is weird (unless the whole thing, as a single include, is larger than 8k by itself).

 I modified PCEAS to allow crossing bank boundaries without problems. But I don't know how that would affect HuC for really large files (and it's included with it on two fork HUC git repositories).

It sounds like it might be a bug.     Blocks are blocks, regardless of whats in them.   2x8 blocks (16 blocks) shouldn't be more than a bank.

I wonder if there's a bug in HuC when using the macro and X/Y offsetting.

[Bonknuts]

I wonder if there's a bug in HuC when using the macro and X/Y offsetting.

 I think you're right. I was thinking of code, not data. Data shouldn't have a problem crossing bank boundaries (only code has this problem on PCEAS).

[DarkKobold]

The problem is that the sprite he's trying to load sucks.

Ba-dum-tss!

I'm ashamed to say, it took a moment to get that.

Bank overflow means just that; it crossed a bank boundary. This is a PCEAS thing and not necessarily a HuC error. But still, why HuC didn't evalute it and automatically move it to the next bank.. is weird (unless the whole thing, as a single include, is larger than 8k by itself).

 I modified PCEAS to allow crossing bank boundaries without problems. But I don't know how that would affect HuC for really large files (and it's included with it on two fork HUC git repositories).

It sounds like it might be a bug.     Blocks are blocks, regardless of whats in them.   2x8 blocks (16 blocks) shouldn't be more than a bank.

I wonder if there's a bug in HuC when using the macro and X/Y offsetting.

Which bank something ends up in, is based on where the "include" comes in the code, right? It seems strange that moving the include lines around, didn't fix the issue. Unless the compiler magically alphabetizes the includes, and Vacuum comes last... It made no sense.

[Bonknuts]

Look at the S file that it outputs. And the SYM file (if it's built). That'll give you the insight of where things are being put; what bank, address, etc.

[Arkhan]

Which bank something ends up in, is based on where the "include" comes in the code, right? It seems strange that moving the include lines around, didn't fix the issue. Unless the compiler magically alphabetizes the includes, and Vacuum comes last... It made no sense.

The includes all happen sequentially, and the compiler generates the banking for you ( you could do this manually instead).

So, it not working seems to mostly just be a bug.

Try this:

Cut the sprite image into separate pictures and do the same loading but with all 0,0 based offsets.  Don't use the 32 offset.   See if that works.
 
My guess is there is something wrong with the HuC macro.