Losing my mind...

[unhuman]

I probably should sleep it off, but... I've got 2 sprites, in call magnify(3) mode. That, theoretically means that each sprite is 16 pixels high, right? Well, I have sprite #28 at row 1 and sprite #2 at row 17. I checked and rechecked with a call position... The #28 is stationary and the #2 moves horizontally. Call Coinc(ALL, A) is noticing a collision between these 2. I just don't get it.

 

Now, everyone tell me how stoopid I am.

[sometimes99er]

Are you using the real hardware or an emulator ?

 

I seem to remember that sprites with the color transparent can make collisions too.

 

I guess XB terminates the sprites in use with a hardware end indication. So if youre using sprite #1 and #2, none of the other sprites come into play. If youre using just sprite #28, then all of the other sprites are in use, though they will be set off screen (below the bottom). I guess this in itself should not course any collision problems. But the real hardware and emulators might handle this differently.

 

Try a simple scenario with only sprite #1 and #2 to start with.

 

Edited April 14, 2010 by sometimes99er

[unhuman]

Yeah, I'll create a sample. It was late and I was toast, but definitely 1 & 17 - which shouldn't be.

 

Are you using the real hardware or an emulator ?

 

I seem to remember that sprites with the color transparent can make collisions too.

 

I guess XB terminates the sprites in use with the a hardware end indication. So if you're using sprite #1 and #2, none of the other sprites come into play. If you're using just sprite #28, then all of the other sprites are in use, though they will be set off screen (below the bottom). I guess this in itself should not course any collision problems. But the real hardware and emulators might handle this differently.

 

Try you simple scenario with only sprite #1 and #2 to start with.

 

[Tursi]

The real question is, "Where are the other sprites?"

 

CALL COINC(ALL) means ALL sprites, not just the ones visible on the screen. XB can actually throw a collision for sprites located off the bottom of the screen, where they all sit till they are in use (as Sometimes99er alluded to). (edit: that statement was full of it )

 

Just to verify, try bringing up the other sprites and placing them at notably non-touching locations, or like he suggests, try 1 and 2.

 

I believe I tested that real hardware sees collisions off the bottom of the screen... but that was years ago and is worth testing again, since I don't remember coding that in Classic99

Edited April 16, 2010 by Tursi

[unhuman]

I'm pretty sure it's not that... If I moved sprite #1 to location 256 (so it's 1 pixel up higher), it doesn't collide. I'll hopefully have time to do my sample tonight. Swamped with real work tho.

 

The real question is, "Where are the other sprites?"

 

CALL COINC(ALL) means ALL sprites, not just the ones visible on the screen. XB can actually throw a collision for sprites located off the bottom of the screen, where they all sit till they are in use (as Sometimes99er alluded to).

 

Just to verify, try bringing up the other sprites and placing them at notably non-touching locations, or like he suggests, try 1 and 2.

 

I believe I tested that real hardware sees collisions off the bottom of the screen... but that was years ago and is worth testing again, since I don't remember coding that in Classic99

[unhuman]

1 CALL CLEAR::CALL MAGNIFY(3)::CALL CHAR(96,"FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF")

2 CALL SPRITE(#28,96,2,1,128)

3 CALL SPRITE(#1, 96,2,17,11,0,7)

4 CALL COINC(ALL,A)::IF A <>0 THEN CALL SOUND(100,110,0)

5 GOTO 4

 

If you switch 1 & 17 to 2 & 18, no noise!!!! I'm not CrAzY

 

Also happens in Call Magnify(1) when 1 & 9 but not 2 & 10

 

And, the sprite #s are irrelevant. They can be any #.

 

This is all on Classic 99. Tried it on MESS and it's fine. Haven't tried it on real hardware. Guess I found a doozie

Edited April 15, 2010 by unhuman

[Tursi]

Confirmed. (And validated on real hardware).

 

Well. This is strange. Will look at it a bit more after work, I'm late.

Edited April 15, 2010 by Tursi

[Tursi]

Have found and fixed the bug, will publish a new version later (with the focus keyboard fix too).... it would specifically affect fade-in from the top including the very top row, row 1, and cause the sprite to be drawn one row lower than it should have been. Thanks for the clear example of the problem!

[sometimes99er]

The real question is, "Where are the other sprites?"

I like this intro. Very cool.

 

[Tursi]

hehe... though it was a mistaken question, brought on by lack of sleep and memories of a much older bug I once ran into.

 

I've fixed this bug and uploaded a fixed Classic99. The keyboard issue from another thread I'd already fixed the way I expected, and couldn't reproduce, so no change there...

 

The sprite position bug affects any sprite row 1 (XB) and higher (though I still need to test that sprites fade out on the top on a real console.. I can't right now as my cartridge port is otherwise occupied )

 

http://harmlesslion.com/software/classic99 - v340b

[unhuman]

Thanks for the super-fast fix!