09-29-2025, 07:53 PM
(09-29-2025, 07:42 PM)SMcNeill Wrote: @bplus you need to update these routines for the newest versions of QB64PE.
Code: (Select All)
Function BoxCollision% (b1x, b1y, b1w, b1h, b2x, b2y, b2w, b2h)
' x, y represent the box left most x and top most y
' w, h represent the box width and height which is the usual way sprites / tiles / images are described
' such that boxbottom = by + bh
' and boxright = bx + bw
If (b1y + b1h < b2y) Or (b1y > b2y + b2h) Or (b1x > b2x + b2w) Or (b1x + b1w < b2x) Then
BoxCollision% = 0
Else
BoxCollision% = -1
End If
End Function\
Change all those OR statements to _ORELSE statements. A collision routine like this is one place where ORELSE could prove to make a heckuva change in performance.
OR is a mathematical process. It involves doing math on bits and the above will take 3 different math processes to arrive at an answer.
_ORELSE does a binary TRUE/FALSE compare -- **WITH** break logic installed built in it.
IF a = b OR a = c OR a = d THEN .... This will solve it as (a = b) then do the (a = c) then do the (a = d). Then it'll OR the first two values. Then OR the result of that and the last value to get a final result. Multiple processes here.
IF a = b _ORELSE a = c _ORELSE a = d THEN.... This will solve (a=b). If the result is 0, it's done. No need to do anything more.
This statement:
IF a = b _ORELSE a = c _ORELSE a = d THEN
Would translate closer to this code:
IF a = b THEN
IF a = c THEN
IF a = d THEN
The first time it fails to produce a positive result, it's done. No need to do the other parts.
See where that might make quite an improvement for a collision routine, which is being called X number of times per loop?
I dont think I actually use that SUB, I like the one that provides the info of where the intersect point, line or box exists exactly.
But thankyou for explaining the advantage of the new _OrElse, that is handy to know and even to be reminded of for this old dog.
724 855 599 923 575 468 400 206 147 564 878 823 652 556 bxor cross forever

