+Gemintronic Posted July 30, 2012 Share Posted July 30, 2012 (edited) 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 Quote Link to comment Share on other sites More sharing options...
+Gemintronic Posted July 31, 2012 Author Share Posted July 31, 2012 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? Quote Link to comment Share on other sites More sharing options...
RevEng Posted July 31, 2012 Share Posted July 31, 2012 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. Quote Link to comment Share on other sites More sharing options...
SeaGtGruff Posted August 2, 2012 Share Posted August 2, 2012 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. 1 Quote Link to comment Share on other sites More sharing options...
+Gemintronic Posted August 2, 2012 Author Share Posted August 2, 2012 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 Quote Link to comment Share on other sites More sharing options...
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.