How to read sprite #0 collision detection in huc ??

[touko]

Hi all , the question is in title !! 

I 'am selecting the control register :

Code: [Select]

poke(0x0000,0x05);

I'am putting 0xfd in :

Code: [Select]

poke(0x0002,0xfd);

Now if i'am reading the content of $0000

Code: [Select]

put_hex(peekw(0x0000),4,4,9);
Result is always 4000, collision within sprite #0 and other sprites is not effective ..

Thanks for help ..

[Tom]

 Unless you have a really good reason to use sprite #0 hit detection, I would highly recommend not to use it. That aside, don't poll/read port $0000 directly during active display. You can cause the system to miss a VDC interrupt (vblank or hblank). There's a variable for status register of the VDC that you should check/read from. This is updated on every VDC interrupt. Though... HuC might erase the sprite collision flag if another interrupt happens after it, but before you have a chance to read from it. I'll have to look to see what HuC is doing for interrupt code (or you could check in mednafen debugger too).

[touko]

ok, thanks tom ..

I'am understanding why i can't read it  .. 
My first reason to use hardware collision is for tests first, and to use it in the future to test collisions between player ship and aliens/bullets sprites.

For debug i'am not familiar with mednafen's debugger  :oops:

Thanks.

[Arkhan]

huc most likely jacks the interupts up and out from under you.

as for mednafen debugger: alt-d to enter debug mode

http://mednafen.sourceforge.net/documentation/debugger.html

and click that to know how to use it!


i wouldn't even worry about sprite 0 collision detection.  Its a neat thought, but you can set up and track bounding boxes and be just as well off as sprite 0 collision detection.

[touko]

Thanks arkhan  ..

Without sprite #0 collision, you must test all the time if all sprites, or all possible sprites collide with your ship, and some cpu time are lost .

Why not starting to check player ship collision, when a sprite #0 collision interuption was occured

[Arkhan]

I guess I could see that being more beneficial if enemies cant collide, but you can do some tricks with non sprite 0 collision checks that dont kill the CPU much at all.

I at most check 22 sprites all against each other.  It bogs down at some point sometimes, but thats checking EVERY sprite against EVERY sprite.....

you could do something like, check the two sprites and if one isnt the player, just return.  Dont do any stuff.  That way when you loop thru to say an enemy vs an enemy, it just returns.

i hope that even makes sense.  IM awful at explaining things.

[nodtveidt]

It also makes a difference if you're using arrays to hold the data. That will cut into CPU time a LOT. I think it was Tom that discovered that array access is like...138 cycles or so each. It's really expensive in any event. There are other ways to do it that are less expensive...

[touko]

I guess I could see that being more beneficial if enemies cant collide, but you can do some tricks with non sprite 0 collision checks that dont kill the CPU much at all.

I at most check 22 sprites all against each other.  It bogs down at some point sometimes, but thats checking EVERY sprite against EVERY sprite.....

you could do something like, check the two sprites and if one isnt the player, just return.  Dont do any stuff.  That way when you loop thru to say an enemy vs an enemy, it just returns.

i hope that even makes sense.  IM awful at explaining things.

yes, but for testing if all enemy colide with player sprite,you must test all x/y coordinate and boundary boxes(or other technique) for all possible sprites, every time ..

For galaxian, software collisions detection is relatively simple ,because enemies are in lines posotioned , but for a shmup for exemple, this is not optimal.

And like tom have said, arrays acces is very slow on HUC.

[nodtveidt]

For a shmup, the #0 collision could be useful if your ship is sprite #0. That would eliminate a lot of other checks. I wonder how many games, if any, do this?

[Tom]

yes, but for testing if all enemy colide with player sprite,you must test all x/y coordinate and boucing boxes(or other technique) for all possible sprites, every time ..

For galaxian software collision detection is relatively simple ,because ennemy are in lines , but for a shmup for exemple, this is not optimal.

And like tom have said, arrays acces is very slow on HUC.

 The problem with sprite #0 collision; 1) you don't know what other sprite(s) collided with the this sprite so you still have to check which sprite collided, 2) it gives pixel perfect collision; so if you use it as you ship, you're going to piss people off. Collision detection like that is super-super rare and mostly makes gameplay frustrating and/or impossible.

 Boundary boxes are the way to go. You only need a handful of compares per object-to-object check. In ASM, that's pretty light work. Object to map is a little more taxing, depending what kind of collision shapes you use on the map.

 Yeah, array (pointer) access in HuC is broken for static mapped ram access. Far access is still overly slow for no real apparent reason, but that's nothing to do with static mapped ram. There might be away to speed it a some, but it would require a function call for every access.

[touko]

1) you don't know what other sprite(s) collided with the this sprite so you still have to check which sprite collided

Yes but the difference in this case is the check should be only when sprite #0 collison was occur, you go to check which sprite(s) collide with sprite #0 and no all the time ..

2) it gives pixel perfect collision; so if you use it as you ship, you're going to piss people off. Collision detection like that is super-super rare and mostly makes gameplay frustrating and/or impossible.

You can complete that with boundary boxes .

[Arkhan]

Yeah, array (pointer) access in HuC is broken for static mapped ram access. Far access is still overly slow for no real apparent reason, but that's nothing to do with static mapped ram. There might be away to speed it a some, but it would require a function call for every access.

function overhead sure wont be speeding it up a great deal, rofl.

most things in HuC are slow.  Even things that shouldn't be.

slow arrays + no structs = ._.


everything speed wise has to be done in asm.  There is no way to do it in huc.


well, no easy/straightforward/non-headache way.

[Tom]

1) you don't know what other sprite(s) collided with the this sprite so you still have to check which sprite collided

Yes but the difference in this case is the check should be only when sprite #0 collison was occur, you go to check which sprite(s) collide with sprite #0 and no all the time ..

 In a general game engine you do. Because you'll have sprites that aren't interactive, that might appear over sprite #0. Like smoke, explosion, you're character's weapons, dead enemy animation, etc. And on the PCE, sprites are often used in complex background clipping for other sprites - to pop out pieces of the background over the sprites.

2) it gives pixel perfect collision; so if you use it as you ship, you're going to piss people off. Collision detection like that is super-super rare and mostly makes gameplay frustrating and/or impossible.

You can complete that with boundary boxes .

 Them it becomes nothing more than a switch in that current frame to do collision detection or not. But the situation/case is still variable in occurrences. You can't optimize for it because of the random type nature of that. I mean, how can you take advantage of that? Not to mention all the false positives you're going to get that'll keep that occurrence rate higher. For any game logic frame, you should optimize for the worst case scenario anyway - otherwise you're going to get uneven expected resource in a frame resulting in either slow down, missing frames, or whatever.

 Trust me, if there was a real world application for sprite #0 collision - games would be using it. We PCE long time coders would be using it. I know of no games that use it for the specific reasons I stated. PCE isn't the only system with this. Megadrive has this too and isn't used for the same reasons.

 The real application of it is for pixel accurate collision, which is cpu intensive. But like I said, not knowing which sprite it collides with makes it useless - unless all you have on screen is two sprites. Then you'll know which sprite collided with it

function overhead sure wont be speeding it up a great deal, rofl.

 Pragma Fastcall function in HuC is fast. You tell it how to pass arguments. Be it one of the three registers A/X/Y or ZP pseudo regs. You can also do argument overloading - a single function can take a variable number of arguments. You tell it the size of the arguments too; int or char. No internal C stack crap. I could setup a small pointer optimization block. Maybe 32 or so pointers. 16 near pointers and 16 far pointers. You call a function to load a pointer with the address. And special functions to read/write from those pointers. At min, it would definitely be 60% faster. You could even optimize for small arrays or split arrays like 16bit, 24bit, 32bit etc.

 I should really do this. And while I'm at it, do a faster left/right shift function

[Arkhan]

oh god dude dont get me started on right and left shift.

Here I thought I was being optimal.  I found out i was being craptimal.

gahhhhh




maybe PCC will absorb some of HuC and make a new C compiler soon.  Have to see if we even feel like actually doing it as opposed to games.  Writing compilers is totally not amusing.

Not with the intent to put HuC down or say its a POS.  Merely to say, were going to use it, and improve it!

[nodtveidt]

Writing compilers is boring...and I know this because I have one of my own.