|
Post by D-Type on May 26, 2020 15:24:35 GMT -5
Starting with the simplest first, does anyone have any experience using Obj_Hit?
Before I knuckle down with my code and the VIDE debugger, can anyone give me some sample values for registers that are used by Obj_Hit that will result in a Hit and a No-Hit (i.e. Carry Flag set/unset?)
My current code always comes back with No-Hit and I just want to be sure my understanding of the input parameters is correct.
I did find one use of this routine in the VIDE code library, in vaboom.asm, but it's tricky for me to read and understand.
Any thoughts appreciated! (Or sample code!!)
Thanks!
Vaboom.asm code snippet:
move_diagonal: LDB NoMoreHitFlag BNE no_hit_chance LDB #$60 ;b=Ypos to check is man is hit CMPB ,x ;check if Ypos of the bomb is closer to BLT no_hit_chance ;upper line, if not, no chance for hit TFR x,u ;u = *ptr to bomb location PSHS x,d,u,y LDD ,u ;d = current bomb location SUBA #$0A SUBB #$0A TFR d,x ;X-> position of the bomb LDY ManYpos ; LDD #$1818 ;Dimentions Man... JSR Obj_Hit ;Check if there is a hit...re
|
|
|
Post by D-Type on May 26, 2020 18:10:47 GMT -5
It worked! Posting here soon gave me the Ah-ha! moment I coded a simple assembly version in VIDE and used the debugger to get some known working parameters to give me a Hit and No-Hit, then I applied these to the Forth BIOS API I'm writing and this proved that the problem I had was post-API call handling. (In this case it was a CLRB wiping out the C flag, which is what Obj_Hit uses to return Hit/No-Hit.) Some parameters to test Obj_Hit and get Hit returned are: $05 and $05 for x and y $1010 for object position $1515 for missile position If you use $1616 instead of $1515, you get a No-Hit. Forth BIOS API code: \ box_x box_y pos_obj_yx pos_missile_yx -- f ; f = hit CODE _Obj_Hit _Y___ # PSHU, D X TFR, ____D # PULS, D Y TFR, ____D # PULS, A B EXG, S ,++ ADDD, Obj_Hit JSR, 0 # LDD, 0 # ADCB, _Y___ # PULU, NEXT ;C
Forth test word: : oh \ -- ; Obj_Hit test $05 $05 $1010 $1515 \ -- box_x box_y pos_obj_yx pos_missile_yx \ 1515=hit _Obj_Hit \ -- f ; f = hit cr . \ Display result on a newline
$05 $05 $1010 $1616 \ 1616=no_hit _Obj_Hit cr . ;
VecForth v0.04 2020-03-26 based on 6809 CamelForth v1.1 2016-03-20 OK-0 OK-0 oh 1 0 OK-0
|
|
|
Post by Peer on May 27, 2020 5:58:30 GMT -5
|
|
|
Post by D-Type on May 27, 2020 6:16:13 GMT -5
Thanks for the link, Peer, now I've viewed that page on Malban's website, I recall I've seen it before, but it never came to my mind.
I guess Obj_Hit is quite a useful function if you don't have too many objects to deal with. I can imagine collision detection could get very expensive with lots of objects!
|
|
|
Post by Peer on May 27, 2020 11:00:38 GMT -5
Yes, you are right. Of course the complexity of the check itself is important, but for collision detection the crucial thing in general is the overall number of checks. With n objects and m bullets there would potenially be n times m checks to be performed which can be a cycle killer. It is usually much better to devise some clever algorithm or book-keeping infrastructure that determines some sort of minimal subset of checks which are necessary, and then effectively perform only those. Or do one half of the checks in each even cycle, and the other half in each odd cycle. Or ... or ... or ...
|
|
|
Post by playvectrex on Jun 2, 2020 17:00:36 GMT -5
We are running into the same situation with my son's tank game... and it seems like a clever approach for static items would be to sort the vector list into a linked list at the beginning of the level, organized by Y and/or X position, then use an iterative binary search tree vs. the player Y,X. Iterative vs. recursive due to limited stack available.
For moving objects, potentially Y,X and circular radius is a pretty fast method?
|
|