Player 2-9 Collision?

[Master_Programmer]

Ummm...when ever i try to use collision(player2, player5), it gives me an error.

 

is collision for players 2 through 9 working?

 

 

or does it have something to do with the fact i Remmed out the line "set kernel_options collision(playfield,player1)"

 

 

P.S:

I remmed it out, because VbB 565 was giving me an error, saying that was an invalid option.

[jbs30000]

1. Yes, don't RIM out set kernel_options collision(playfield,player1). That's what allows virtual collision detection.

 

2. While playing around I found that virtual collisions don't seem to work quiet right. For example, about a month ago or so I posted how while testing collisions between sprites 0 and 2 sometimes it would register as a collision between sprites 0 and 2 and other times between 0 and 1.

 

Actually, any collision between sprites 0 and 1-9 register as a collision between sprites 0 and 1. So what I had to do for my DPC+ Mario game I'm working on, is detect a collision between sprites 0 and 1 and then check the locations of sprite 0 and sprites 1-9 to see which sprite that sprite 0 collided with.

 

I haven't checked to see if collisions between sprites 1 - 9 have any glitches though. So maybe what I wrote won't apply.

 

Oh, and I don't know if you're aware, and this may not affect your game, but currently there is no pfread or pfscroll.

[Master_Programmer]

1. Yes, don't RIM out set kernel_options collision(playfield,player1). That's what allows virtual collision detection.

 

2. While playing around I found that virtual collisions don't seem to work quiet right. For example, about a month ago or so I posted how while testing collisions between sprites 0 and 2 sometimes it would register as a collision between sprites 0 and 2 and other times between 0 and 1.

 

Actually, any collision between sprites 0 and 1-9 register as a collision between sprites 0 and 1. So what I had to do for my DPC+ Mario game I'm working on, is detect a collision between sprites 0 and 1 and then check the locations of sprite 0 and sprites 1-9 to see which sprite that sprite 0 collided with.

 

I haven't checked to see if collisions between sprites 1 - 9 have any glitches though. So maybe what I wrote won't apply.

 

Oh, and I don't know if you're aware, and this may not affect your game, but currently there is no pfread or pfscroll.

 

I can't un-rem the kernel option, or it'll give me an error.

 

and I don't need pfread, or pfscroll....but a pfpixel would make things easier in my project...is that still available?

 

if not, then dungeons will be annoying to make. DX

[Master_Programmer]

Here, when i remove the rem, the compiler itself, not just Visual bB, gives me this error:

 

" set kernel_options: Options unknown or invalid "

 

this is the exact line causing the problem:

 

" set kernel_options collision(playfield,player1)"

[jbs30000]

To answer your first question, yes, there is a pfpixel.

 

As for the code not working, in this post ScumSoft posted a template to use for making DPC+ programs.

; *****************************************************
; * BANK 1
; *****************************************************
bank 1
temp1 = temp1

set tv ntsc
set kernel DPC+
set smartbranching on
set optimization inlinerand
set kernel_options collision(playfield,player1)

rem DEFINE VARS HERE

goto MAIN bank2

; *****************************************************
; * BANK 2
; *****************************************************
bank 2
temp1 = temp1

MAIN
 rem INSERT GAMEPLAY LOGIC
 goto MAIN

; *****************************************************
; * BANK 3
; *****************************************************
bank 3
temp1 = temp1

; *****************************************************
; * BANK 4
; *****************************************************
bank 4
temp1 = temp1

; *****************************************************
; * BANK 5
; *****************************************************
bank 5
temp1 = temp1

; *****************************************************
; * BANK 6
; *****************************************************
bank 6
rem temp1 = temp1 not required here as this bank is for graphics only
rem However I have placed my TitleScreen here with no apparent consequences

Also note that in bank one you you only have a little over 100 bytes (I forget and I'm having a hard time searching for the exact amount) so that bank should just or mostly be used for creating variables, defs, and so on.

Also, except for using bank 6 for the title screen, you really can't use banks 6 - 8 for anything.

[Master_Programmer]

To answer your first question, yes, there is a pfpixel.

 

As for the code not working, in this post ScumSoft posted a template to use for making DPC+ programs.

; *****************************************************
; * BANK 1
; *****************************************************
bank 1
temp1 = temp1

set tv ntsc
set kernel DPC+
set smartbranching on
set optimization inlinerand
set kernel_options collision(playfield,player1)

rem DEFINE VARS HERE

goto MAIN bank2

; *****************************************************
; * BANK 2
; *****************************************************
bank 2
temp1 = temp1

MAIN
 rem INSERT GAMEPLAY LOGIC
 goto MAIN

; *****************************************************
; * BANK 3
; *****************************************************
bank 3
temp1 = temp1

; *****************************************************
; * BANK 4
; *****************************************************
bank 4
temp1 = temp1

; *****************************************************
; * BANK 5
; *****************************************************
bank 5
temp1 = temp1

; *****************************************************
; * BANK 6
; *****************************************************
bank 6
rem temp1 = temp1 not required here as this bank is for graphics only
rem However I have placed my TitleScreen here with no apparent consequences

Also note that in bank one you you only have a little over 100 bytes (I forget and I'm having a hard time searching for the exact amount) so that bank should just or mostly be used for creating variables, defs, and so on.

Also, except for using bank 6 for the title screen, you really can't use banks 6 - 8 for anything.

 

Buddy, the Visual bB version i have, uses that EXACT template, but i keep getting the error about the kernel options.

[Master_Programmer]

Okay, here is all the tools i'm using:

 

Visual bB 565, with the soundlib

Batari Basic 1.1 rev B, I DID NOT INSTALL A PREVIOUS VERSION BEFORE THIS ONE.

 

I got Revision(version) B of batari basic 1.1, and never got the first version.

 

is there ANY chance that could mean i'm missing files?

[jbs30000]

Could be. Somewhere on this board there's a version 1.1d. It's too much of a pain for me to search, but you can try using my files if you like. In fact, if I remember correctly I think I got a copy of them from jwierer.

DPC.zip

[Master_Programmer]

Could be. Somewhere on this board there's a version 1.1d. It's too much of a pain for me to search, but you can try using my files if you like. In fact, if I remember correctly I think I got a copy of them from jwierer.

DPC.zip

 

it messed it up even more.

 

"DASM V2.20.07, Macro Assembler ©1988-2003

free ram: 9

DPC free RAM=

bytes of ROM space left in bank 1

bytes of ROM space left in bank 2

bytes of ROM space left in bank 3

bytes of ROM space left in bank 4

bytes of ROM space left in bank 5

bytes of ROM space left in bank 6

bytes of ROM space left in graphics bank

free ram: 9

DPC free RAM= 603

--> repo 1ab2

Compilation completed at 12/12/2011 4:24:02 PM

view output file:///C:/Documents and Settings/10guy/My Documents/Zelda Gaiden/bin

Post compilation files deleted"

 

 

 

(EDIT)

 

Wait!!!

no, it worked this time!!!

 

i'm checking to test collision, but it didn't give me the garbled screen of death!!!

Edited December 12, 2011 by Master_Programmer

[Master_Programmer]

Good news, and Bad news.

 

 

Good news, is things seem to be working, and i'll be testing collision detection for virtual sprites, tomorrow.

 

Now, for the Bad news.

 

It won't tell me how much memory is free for each bank anymore....so.....yeah.

 

that'll cause troubles....but nothing i can't handle.

[jbs30000]

OK, here is something strange I've found, and I don't know why. Sometimes you'll see free memory, sometimes you won't. It seems to depend on the size of your program. Try adding something to the first bank, like a=a. Sometimes adding code makes the output show free memory again.

[Master_Programmer]

OK, here is something strange I've found, and I don't know why. Sometimes you'll see free memory, sometimes you won't. It seems to depend on the size of your program. Try adding something to the first bank, like a=a. Sometimes adding code makes the output show free memory again.

 

One last thing....I;ve noticed, Player2ponterhi and lo don't work.

 

neither to ANY of the virtual sprite pointers.

 

they crash the game, right as it boots up, but they DO compile....

[jbs30000]

You'll need to ask someone like Batari, SeaGtGruff, or RevEng about that.

[Master_Programmer]

You'll need to ask someone like Batari, SeaGtGruff, or RevEng about that.

 

Kay...i'll wait to see if they find this topic, and care to post.

[jbs30000]

I suppose it's possible.

[RevEng]

Weird that it compiles, but the only player pointer variables that exist in the bB DPC+ kernel are player0pointerlo/hi.

 

Try compiling a minimal program with a player2: definition, and look at the assembly output. You'll see what I mean.

[Master_Programmer]

Weird that it compiles, but the only player pointer variables that exist in the bB DPC+ kernel are player0pointerlo/hi.

 

Try compiling a minimal program with a player2: definition, and look at the assembly output. You'll see what I mean.

 

odd....then i wonder....how can i make two virtual sprites use the same sprite, without two different definitions?

 

this zelda game is gonna be complex, so I need to use every last optimization I can think of....for ram, rom, and cpu cycles.

 

i'm planning on TRYING to make this real hardware compatible.

[jbs30000]

In some post I think I saw Batari say he'd try to implement setting multiple sprites to the same shape with something like:

players1-3:

%00111100

%01000010

...and so on

end

 

But I guess he's pretty busy as I've haven't seen any updates in about a month or so.

[jjsonique]

Yeah, in the next version of bB thread he said it's incomplete, but you can try it:

 

"The ability to assign multiple players to a single set of sprite data is another feature I neglected to mention. It is incomplete at the moment but so far, to assign the same data to players 1-4, use player1-4: for the declaration.

 

It apparently only assigns player#height for the first player. Also, it does not yet work for assigning the same colors to multiple players (I will use player1-4color: for that). Since this is a feature you guys probably want, I'll look into getting it going properly."

Edited December 14, 2011 by jjsonique

[Mubo]

im also having the same issue with 2-9 collision... i cant actually even put in the collision code for player2, it wont compile if i do .... but even without it, when i shoot player 2 it's registering as if i had shot player one

 

master_programmer, have you had any luck with 2-9 detection?

 

btw, my current install is the bB beta b with the addidion of the dpc folder from this thread... was the only way i could get it to work ( thanks guys!).

 

-mubo

[Master_Programmer]

yes, but I don't remember how I got it working.

[iesposta]

In some post I think I saw Batari say he'd try to implement setting multiple sprites to the same shape with something like:

players1-3:

%00111100

%01000010

...and so on

end

 

But I guess he's pretty busy as I've haven't seen any updates in about a month or so.

This works in the "d" version.

However, you have to assign colors for each player separately.

They can share the same bit data, but not the same color data.

Let me know if that's not clear.

 

Also what's with the disappearing free ram.

I have to compile after each change to make sure I haven't lost ram remaining. (Add a variable... Gone... Move it to another bank... Ok...)

Also some things I have compiled that work on Stella don't work from Harmony. The play field jitters on real hardware ( not score jitter) and the nice blue line at the bottom of the screen is gone.

[+stephena]

I have to compile after each change to make sure I haven't lost ram remaining. (Add a variable... Gone... Move it to another bank... Ok...)

Also some things I have compiled that work on Stella don't work from Harmony. The play field jitters on real hardware ( not score jitter) and the nice blue line at the bottom of the screen is gone.

 

If possible, please forward any ROMs that exhibit different behaviour in Stella vs. Harmony, with a brief description of how they differ.

[jbs30000]

im also having the same issue with 2-9 collision... i cant actually even put in the collision code for player2, it wont compile if i do .... but even without it, when i shoot player 2 it's registering as if i had shot player one

 

master_programmer, have you had any luck with 2-9 detection?

When I played around I finally had to just check the X and Y locations of each sprite to determine a collision. Unless there was an update, and I haven't seen any posts saying there was, then detecting collisions with sprites 2 - 9 isn't completed yet.

In some post I think I saw Batari say he'd try to implement setting multiple sprites to the same shape with something like:

players1-3:

%00111100

%01000010

...and so on

end

 

But I guess he's pretty busy as I've haven't seen any updates in about a month or so.

This works in the "d" version.

However, you have to assign colors for each player separately.

They can share the same bit data, but not the same color data.

Let me know if that's not clear.

Of course it's clear.