Multisprite Sprite Positioning Woes

[Cybearg]

I initially asked this of bogax in a PM, but I'm really itching for an answer, so I guess I'll bug everyone with it:

 

I'm trying to get player 1 to chase down player 0, but there are a couple problems:

 

1. There are "safe points", such as in the lower-right corner of the screen, where player 1 nuzzles up close to player 0 but never actually reaches player 0. I assume this has something to do with the coordinate system, because I'm simply using:

 

if player1x > player0x then player1x = player1x - 1 else player1x = player1x + 1
if player1y > player0y then player1y = player1y - 1 else player1y = player1y + 1

 

... And yet there are places where the sprites will never touch each other. If it matters, player 0's sprite is 12 pixels high and player 1's sprite is 16 pixels high. Player 0's sprite is 8 pixels wide in some frames, but player 1 is only filling out the center 6 pixels, with a column of pixels empty for the highest and lowest bits.

 

Any idea what I can do to deal with this coordinate problem?

 

2. There are places, such as at the bottom of the screen, where player 0 remains visible but player 1 becomes invisible -- the sprite doesn't get rendered. I would assume this was simply coordinate-based, but I'm currently using soft collisions instead of hardware collisions and I (sometimes) still get soft collisions even when the sprite isn't showing, so it's possible it has something to do with the sprite's positioning. Any idea what's wrong there to make player 1 vanish while player 0 remains visible?

[+Gemintronic]

You're not going to like the answer.. because it's one of those negative nancy answers

 

I too have noticed the visible player0y and player1-5y seem to be off. If the past I've just allowed for it and carried on. I don't think batari will be updating the multi sprite kernel any time soon

[Omegamatrix]

Post a rom, and list file.

[Cybearg]

Just made this example.

 

No list file was generated.

 

rem batari Basic Program
rem created 7/19/2013 10:27:38 PM by Visual bB Version 1.0.0.566

set kernel multisprite

dim counter = a

pfheight = 7
gosub resetall

main

if (counter & 1) then goto skipmove

if joy0up then player0y = player0y + 1
if joy0down then player0y = player0y - 1
if joy0right then player0x = player0x + 1
if joy0left then player0x = player0x - 1

if player0x > player1x then player1x = player1x + 1 else player1x = player1x - 1
if player0y > player1y then player1y = player1y + 1 else player1y = player1y - 1

skipmove

if collision(player0,player1) then gosub resetp1

12hi
player0:
%11111111
%11111111
%11111111
%11111111
%11111111
%11111111
%11111111
%11111111
%11111111
%11111111
%11111111
%11111111
end

16hi
player1:
%11111111
%11111111
%11111111
%11111111
%11111111
%11111111
%11111111
%11111111
%11111111
%11111111
%11111111
%11111111
%11111111
%11111111
%11111111
%11111111
end

COLUP0 = $0E: _COLUP1 = $0E
drawscreen

goto main

resetall
player0x = (rand & 127) + 16
player0y = (rand & 63) + 8

resetp1
player1x = (rand & 127) + 16
player1y = (rand & 63) + 8

return thisbank

moveshow.bas

moveshow.bas.asm

moveshow.bas.bin

Edited July 20, 2013 by Cybearg

[Omegamatrix]

No list file, huh? Is that the same for everyone else with the Multisprite kernel? It is just a switch passed to DASM that creates the list file.

 

 

The biggest problem I see with your code is there are no wraparound conditions for moving off the screen. For example you should wraparound the left and right edges something like this:

 

 

if joy0up then player0y = player0y + 1
if joy0down then player0y = player0y - 1
if joy0right then player0x = player0x + 1
if joy0left then player0x = player0x - 1

if player0x = 160 then player0x = 0
if player0x = -1 then player0x = 159

 

 

You'll need to do some boundary conditions for the top and bottom as well. Then see if your sprites still disappear.

[bogax]

Here's a list file

I removed the parenthesis on line 13

of the .bas file other than that it's

the same.

 

moveshow.bas.lst

 

Like theloon said the positions are different

for the virtual sprites and player0 which is why

(I presume) they need different offsets when you're

doing soft collisions with the playfield.

 

Try just putting player0 and player1 on the playfield

and see how they line up maybe give them the same x

with offset y by 20 or so and/or the same y with

an x offset.

 

The collision code I posted a while back allows you

to show the x and y numbers in the score and switch

amongst sprites.

 

I think you'll just have to figure out how to allow

for the differences.

 

edit my collision code doesn't actually update the position

untill the sprite moves so if you switch sprites but don't

move, the position doesn't get updated to match the switch.

that was sloppy of me.

Edited July 20, 2013 by bogax

[Cybearg]

But what can be done with the way that the virtual sprite disappears when near the bottom/top of the screen?

 

EDIT: Yeah, wish I'd have thought of the obvious solution of just lining them up by having the virtual sprite's coords equal sprite 0's coords.

 

But there's still the bigger issue of the virtual sprite flickering at the bottom/top of the screen. Player 0 can move pretty much off the screen on the top/bottom while still remaining partially visible, as it should be, but the virtual sprite flickers and then vanishes when nearing the vertical borders. Can anything be done about this?

moveshow.bas.bin

Edited July 20, 2013 by Cybearg

[+Gemintronic]

I tried providing an explaination over chat but Cybreag may have missed it. The multi sprite kernel does strange things when it reaches the top and bottom borders. It's as if the playerxheights and playerxpos get messed up at the boundaries. Since it's unlikely batari will apply any new effort to the original multi sprite kernel my suggestion was to manually adjust the playerxheight when it reaches the borders. This is to make the sprite appear to cross the visible screen border without actually doing so (and thus side-stepping the issue.)

[SeaGtGruff]

Back a few years ago when I was helping someone write a game with the multisprite kernel, I ran into the same sort of problems. As I recall, my solution was to use different limits at the top and bottom of the screen for player0 and the various player1 sprites. As for the flickering, I wonder if it has anything to do with player1 being used in the score? The virtual copies of player1 have to separated by a couple of lines if you want to avoid flickering, so I presume they also can't get too close to the score without flickering.

[Omegamatrix]

Cybearg, I downloaded VBB, and I can't compile your .bas file from post 4. I get a syntax error, where I should get no syntax error. I tried compiling a different source (probably not multisprite) and it worked.

 

 

So at this point I think I have to swap some files. I'm using VisualbB_1.0_Build_554 from Jeff's topic, and bBWin7_64bit-2-26-2013. Can you send me your files? If that doesn't work I will then try the registry fix and different 2600bas yadda yadda.

 

 

Also, is there an unofficial be all, end all, version of BB? One that is backwards compatible with everything? Right now it BB seems to be a miss-mash of files in different threads.

[+Gemintronic]

Yeah, I think it's been long enough that a community "unofficial" standard release would be appropriate. Maybe after RevEngs 64k support is released?

[Cybearg]

I know I've expressed my utter frustration with the way that bB and vbB are split off into obscure little fixes and files here and there across multiple buried threads.

[+Gemintronic]

As long as the OP is willing to go slightly off topic I'll continue my blabbering.

 

At one the the Sega Genesis BASIC community put together a suite with:

 

* Latest compiler

* Latest IDE

* Every known example

* Offline documentation

* Generally recognized best tools

[Cybearg]

Woah-woah-woah...

 

The Genesis has a Homebrew community that programs in BASIC? And the NES homebrew community still goes on just assembly?

 

Sega does what Nintendorequiresyoutoknowassembly.

[+Gemintronic]

Well, this was some time ago. It's just sorta alive now. The point is that the suite idea was/is a good one

[Sprybug]

As long as the OP is willing to go slightly off topic I'll continue my blabbering.

 

At one the the Sega Genesis BASIC community put together a suite with:

 

* Latest compiler

* Latest IDE

* Every known example

* Offline documentation

* Generally recognized best tools

THERE'S A GENESIS BASIC COMPILER....*Smacks hand* NO CHRIS. You've already got too many projects on your plate.

[+Gemintronic]

THERE'S A GENESIS BASIC COMPILER....*Smacks hand* NO CHRIS. You've already got too many projects on your plate.

 

Just keep telling yourself It'd be less fun to make Sonic the Hedgehog on the Sega Genesis

[Omegamatrix]

I know I've expressed my utter frustration with the way that bB and vbB are split off into obscure little fixes and files here and there across multiple buried threads.

 

So, I still can't get you .bas file to compile. Can anyone else? Are you using some different multisprite files?

 

 

Edit: Just got it to work. I had to remove the parenthesis around (counter & 1). BB didn't like that.

[Cybearg]

I've had varied responses to parenthesis as well... It's inconsistent between versions.