Multi-Sprite and inline pfread not working

[+Gemintronic]

I include "inline pfread_msk.asm" in the very last bank. I do all of this in the beginning:

 include div_mul.asm

rem Kernel options
set smartbranching on
includesfile multisprite_bankswitch.inc
set kernel multisprite
set romsize 32k

rem Declare constants and definitions
const screenheight=80

 

I'm using the bB that reports this:

 

batari Basic Compiler date (1/31/2011 12:15:04 AM)

Current bB compiler version supports -O option. Peephole optimizer option enabled.

Current bB compiler version supports DPC+ Kernel. DPC+ options enabled.

 

My collision detection code looks like this:

Collision_Playfield
rem Divide then multiply the sprite x and y to get the playfield pixel coordinates
rem The visible playfield pixels seem to be 40 vertical and 32 horizontal.
rem Which seems to be twice as tall and 4 times as wide as a sprite pixel.
global_temp1 = (player_x/4)
global_temp2 = (player_y/2)
global_temp3 = (global_temp1*4)
global_temp4 = (global_temp2*2)
rem Show a missile just to make sure the coordinates are correct
missile1x = global_temp3
missile1y = global_temp4
rem Display a successful collision check in the score
if pfread(global_temp3, global_temp4) then score = 1 else score = 0
return

 

What pfread returns is totally different from the playfield pixel arrangement. What is going on here fellows?

SLost001.zip

Edited July 31, 2012 by theloon

[+Gemintronic]

I tried a more "1.0" version of the bB compiler so VisualbB reports this:

batari Basic Compiler date (12/6/2009 9:56:54 PM)

Current bB compiler version supports -O option. Peephole optimizer option enabled.

Current bB compiler version does not support DPC+ kernel. Those options will be disabled.

 

 

Same results.

 

I tried:

* Putting " inline pfread_msk.asm" in the first bank (the screen blanks in-game and appears to hang)

* Putting to main code in the last bank (bank along with the " inline pfread_msk.asm"

 

So, I'm not sure if I can blame either bB 1.0 or bB 1.1 on this. Has the inline pfread always been broke in the multi-sprite kernel? RevEng? Gateway? Have you guys used pfread in multi-sprite?

[+RevEng]

It may have always been broken. I haven't used pfread before with multi-sprite, but I just took a look at the code and it doesn't seem to make adjustments for a mirrored half-width playfield.

 

I'd recommend you post it to the bug thread, and maybe batari can comment if it's a bug or an intentionally missing feature. If its the latter, ideally the compiler would spit out an error when you tried to combine multisprite and the pf functions.

[SeaGtGruff]

It may have always been broken. I haven't used pfread before with multi-sprite, but I just took a look at the code and it doesn't seem to make adjustments for a mirrored half-width playfield.

I don't think the pfdraw commands (pfread, pfhline, pfvline, etc.) ever worked with the multi-sprite kernel, because the multi-sprite kernel originally used only ROM playfields, so the pfdraw routines were irrelevant, and I thought that if you compiled with the multi-sprite option then it didn't even include the pfdraw.asm "include" file.

 

But if you're using the Superchip option with the multi-sprite kernel then you should be able to use a RAM playfield, in which case the pfdraw routines would be relevant if they were rewritten to handle half-wide playfields-- with the understanding that anything drawn is for the left half and will be mirrored on the right half, and that anything read should also be for the left half. It's been a few years, but I think I wrote a custom version of pfdraw.asm that was specifically for the multi-sprite kernel. I'll look and see.

[+Gemintronic]

It may have always been broken. I haven't used pfread before with multi-sprite, but I just took a look at the code and it doesn't seem to make adjustments for a mirrored half-width playfield.

I don't think the pfdraw commands (pfread, pfhline, pfvline, etc.) ever worked with the multi-sprite kernel, because the multi-sprite kernel originally used only ROM playfields, so the pfdraw routines were irrelevant, and I thought that if you compiled with the multi-sprite option then it didn't even include the pfdraw.asm "include" file.

 

But if you're using the Superchip option with the multi-sprite kernel then you should be able to use a RAM playfield, in which case the pfdraw routines would be relevant if they were rewritten to handle half-wide playfields-- with the understanding that anything drawn is for the left half and will be mirrored on the right half, and that anything read should also be for the left half. It's been a few years, but I think I wrote a custom version of pfdraw.asm that was specifically for the multi-sprite kernel. I'll look and see.

 

I appreciate the help. I know the built-in pfread was irrelevent for multi-sprite. I read that the inline assembly module pfread_msk.asm at least let you use pfread.

 

When I enable use these settings:

include div_mul.asm

set smartbranching on

includesfile multisprite_bankswitch.inc

set kernel multisprite

set romsize 32kSC

 

It will compile only if I use "inline pfread_msk.asm" in the last bank. However if I try to use SuperChip variables it hangs.

 

UPDATE:

 

Okay, THIS code compiles and runs correctly AS IS:

http://atariage.com/...ad-not-working/

 

When I strip it down to Omegamatrixs code it still does the freaky burnt umber thing.

 

The real kicker is, simply TRYING to use superchip RAM the bB way fails. i.e. "w001 = 13"

 

I feel kinda dumb now. I was so sure that the biggest, baddest bB game I could make was 32kSC with multi-sprite. I never bothered to check if SuperChip variables work or not