Hi

for a long time i used the sprite collision bit to detect if there is collision.
If so, then (manually) the 2 sprites that collide are calculated.

All this time I thought the sprite collision detection worked, however,
I re-checked it, and it turned out that this collision bit was allways set.

Some help I could need.

I got my int. at $38, I use no Bios Calls.
I set statusregister 2 at line int, and a bit later I set status register 0.
Setting status register 0 is done like this:

ld a,0
out ($99),a
ld a,15+128
out ($99),a
in a,($99)
bit 5,a ;bit 5 of s#0 is the sprite collision detection bit
ld (Store_Sprite_Collision),a

However the content of this bit 5 turns out to be 0, always.
I know sprite collision detecion is also dependant on the colors of the sprites.
When writing the colors of the sprites to VRAM you may choose to set or reset sprite collision detecion.
I checked this, and the sprite colision detecion in the SpriteColorTable is ON.
What could be wrong here ?

Another question: Initially I had to set status register 0 at lineint, a bit after I set it to 2.
I read that its needed to keep the status register set at 0 allways,
for Bios usage or so ??
If I DONT set the status register back to 0, then nothing happens, no problems.
Do I NEED to set the status register allways back to 0 ?

Also Im using a routine called DoCopy,
this routine switches to s#2 to check if the VDP is busy,
if not it switches back to s#0 and then performs a number of copy commands.

Could i also NOT switch back to s#0 here ?

thankx

Check your mail. Norakomi

IMHO, the sprite collision bit is useless for gaming purposes and it's best to forget it even exists. Since it doesn't give you any info about the collision you will need to check what happened. You may as well save the few cycles for the check and run the full check every time. You need to account for the time needed to check the collision anyway, so it's not like skipping it will help you out.

Quote:

IMHO, the sprite collision bit is useless for gaming purposes and it's best to forget it even exists. Since it doesn't give you any info about the collision you will need to check what happened. You may as well save the few cycles for the check and run the full check every time. You need to account for the time needed to check the collision anyway, so it's not like skipping it will help you out.

Problem Fixed.
I downloaded the new Bluemsx, and the spritecollisiondetection works now!
Was a bug in older Bluemsx version (I knew, but I completely forgot about it, DOH !!)
Anyway,
Edwin,
since its possible to set the spritecollisiondetection per sprite(line), I do this:
I Only set spritecollisiondetection=ON for:
The Main ship & the enemies.
So, NO spritecollision for bullets etc.

whenever the spritecollisionbit gets set, this means that either you ran into an enemy,
OR an enemy ran into another enemy.
The enemies in each level dont touch each other so often.
roughly estimated I could say that in 5% of the time an enemy touches another enemy
So in 95% of the time there is no collision between enemies
Meaning, that ONLY in 5% off the gametime the spritecollisionbit will get set.
And ONLY when the spritecollisionbit is set, only then
will I do the compares neseccary to check if the player bumped into an enemy or an enemy into an enemy.

So in my case the spritecolldet.bit server me very well.

@norakomi:

I've found another small bug in bmsx 2.5 only in sc5-8

the first not correctly showed sprite plane number in s0 is always 11111b = 31 even if you align 9 sprites 0-8 on the same scanline.
Take in account that in sc1-4 this is working correclty.

norakomi: *always* check your stuff on real MSX!
Additionaly, you coudl also check on another emulator.

Quote:

@norakomi: I've found another small bug in bmsx 2.5 only in sc5-8 the first not correctly showed sprite plane number in s0 is always 11111b = 31 even if you align 9 sprites 0-8 on the same scanline. Take in account that in sc1-4 this is working correclty.

I dont understand quite what you're saying.
Could you explain me a bit more ?

Quote:

Quote: @norakomi: I've found another small bug in bmsx 2.5 only in sc5-8 the first not correctly showed sprite plane number in s0 is always 11111b = 31 even if you align 9 sprites 0-8 on the same scanline. Take in account that in sc1-4 this is working correclty. I dont understand quite what you're saying. Could you explain me a bit more ?

The vdp status reg 0 had this layout:

bit n. meaning
7 interrupt vblank requested.
6 too many sprites on a single scanline
5 coincidence flag
4,3,2,1,0 number of the first sprite not correctly displayed if bit 6 = 1.


in the real msx when bit 6 = 1, (too many sprites on a single scanline) bits 4-0 holds the plane number of the first not correctly displayed sprite. otherwise, when bit 6=0 they hold 11111b = 31


In bluemsx 2.5 there is a bug only in screen modes 5-8: the five least significant bits hold always 11111 even if, for example you align 9 sprites on the same scanline.

So assuming you are placing 9 sprites on the same scanline from number 0-8, the sprite 8 should not be displayed correctly. In this situation on the real machine when you read the status reg0 you get:


1 [1] 0 [01001]

the quare brackets values tell you: Too many sprites on scanline, the first not correctly displayed number is 01001b=9!
on bluemsx2.5 in screen modes 5-8 you get instead.

1 [1] 0 [11111]

that is obviusly wrong, because say:

"Too many sprites on scanline, the first not correctly displayed number is 11111b=31!"

About (re) setting the stat reg when exiting your INT routine. Indeed you don't have to reset to 0. This is done because most (BIOS) routines expect statreg to be 0. So these routines just read out the value without first setting stat reg to 0. If you don't use any of them (BIOS) routines, and your own code doesn't depend on it either, you can do what ya want. You might even consider leaving stat reg 2 the whole time (or atleast set it to be expected) if you want, keeps your code shorter and more efficient

Quote:

About (re) setting the stat reg when exiting your INT routine. Indeed you don't have to reset to 0. This is done because most (BIOS) routines expect statreg to be 0. So these routines just read out the value without first setting stat reg to 0. If you don't use any of them (BIOS) routines, and your own code doesn't depend on it either, you can do what ya want. You might even consider leaving stat reg 2 the whole time (or atleast set it to be expected) if you want, keeps your code shorter and more efficient

thats what I thought. When the player dies the INTs get RESET and the level gets re-initialized.
Then the INTs get set again, and the level starts again.
In this period after the INTs got reset and before they got set again I got some crashes,
because I didnt always set status register back to 0.
So you're absolutely right.
In my case I should have switched back to s#0 when resetting INTs

Oh,talking about bluemsx 2.5
Ive started using it since yesterday,
it actually runs smoother than the versions I used before ! Hooray !
However I cannot enter the debugger.
An windows-explorer error message is displayed.
The same happens when I press print-screen.
weird huh?

Quote:

Edwin, since its possible to set the spritecollisiondetection per sprite(line), I do this: I Only set spritecollisiondetection=ON for: The Main ship & the enemies. So, NO spritecollision for bullets etc. whenever the spritecollisionbit gets set, this means that either you ran into an enemy, OR an enemy ran into another enemy. The enemies in each level dont touch each other so often. roughly estimated I could say that in 5% of the time an enemy touches another enemy So in 95% of the time there is no collision between enemies Meaning, that ONLY in 5% off the gametime the spritecollisionbit will get set. And ONLY when the spritecollisionbit is set, only then will I do the compares neseccary to check if the player bumped into an enemy or an enemy into an enemy. So in my case the spritecolldet.bit server me very well.

I still don't see how it's helpful. Since collisions can happen at any time during the game, you must reserve time for that if you don't want to run the risk of stutters. If the time is reserved anyway, you may as well execute the code. What else are you going to do with cpu time that you can't count on being available.

Quote:

Oh,talking about bluemsx 2.5 Ive started using it since yesterday, it actually runs smoother than the versions I used before ! Hooray ! However I cannot enter the debugger. An windows-explorer error message is displayed. The same happens when I press print-screen. weird huh?

There's a bug in the S1985 device that causes emulator to crash when debugger is open (and maybe it can also happen when making a screenshot ?). It will be fixed in next version (2.6). I guess you are running a Japanese MSX2 with this device. If this is the case, you can in the meantime resolve the problem by going in the Machine editor, replacing "MSX S-1985" by "MSX" as board type and saving the modified machine under a new name.

i was using the "MSX"
so, it must be something else........

I still don't know which machine you are running in blueMSX ...

Or maybe are you speaking about the 'MSX' machine, in another words an European MSX1 ?

sorry I was a bit unclear.
I wasnt using the "MSX S-1985" machine,
i was using the "MSX 2" (top of the list) machine all the time.
What I did now, is replace BLUE.EXE with the older version I had.
Included the folder to enable the mixer.
It works, but not superb.