Array screen positioning looks to have issues for me

Previous topic - Next topic

MrPlow

Hi,

I have a past working project - created maps and positioned items using array values to determine they were beside each other etc.

Now the project is showing the items with gaps and other issues...

Were there any changes to variables etc.?
Also a clue, I used a lot of INTEGER() command - could that have issues?

Thanks

Example of how i am using integer...

Code (glbasic) Select
startwater_top% = INTEGER(1+(INTEGER(RND(2)+3) * 16))
startwater_left% = 1+(INTEGER(RND(4)+1) * 16)
startwater_right% = ((resx/2)+1) + (INTEGER(RND(20))*16)


TYPE
Code (glbasic) Select
ccx = INTEGER(cs.ca_x)
Comp:
Speccy-48k, Speccy-128k, Amigas, PCs

MrPlow

Also, what seems to be the issue...

BOXCOLL might be firing on 16 x 16 surrounding items - maybe there was an older BOXCOLL bug that was resolved?
But the codebase was working when last run a few years ago...

Now the collision detection is off? I'll try play around to see what happens...

BOXCOLL(vk1.vx,vk1.vy,16,16,vk1.vx + 16,vk1.vy - 16,16,16)<>1

I could have also implemented badly in old version and a recent fix could have made my current code act-up?
Comp:
Speccy-48k, Speccy-128k, Amigas, PCs

MrPlow

Right so...
Although some GLB aspect must have changed with the accuracy of BOXCOLL

I have solved my issue by using a modified BOXCOLL to allow for accuracy of hitbox to have a buffer per test when assuming equal tiles in grid format...maybe boxcoll had this before and it was reomoved? I'm not sure...anyway this solved my current issue :D

Code (glbasic) Select
FUNCTION boxcollm:qx1%,qy1%,qs1%,qs2%,qx2%,qy2%,qs3%,qs4%

IF BOXCOLL( qx1+2,qy1+2,qs1-4,qs2-4,qx2+2,qy2+2,qs3-4,qs4-4)
RETURN 1
ENDIF

ENDFUNCTION
Comp:
Speccy-48k, Speccy-128k, Amigas, PCs

bigsofty

I had problems with the INTEGER command iirc. It was producing weird rounding errors. I never liked how it rounded down from 0.9 to 0 either.

BTW, as long as you store a (floating point)number in an integer variable it will implicitly be cast to an integer so no need for direct casting.

I don't use GLBs RND function (I use my own) but doesn't that produce integers? If so then I don't think you need to use INTEGER at all in your code.
Cheers,

Ian.

"It is practically impossible to teach good programming style to students that have had prior exposure to BASIC.  As potential programmers, they are mentally mutilated beyond hope of regeneration."
(E. W. Dijkstra)

MrPlow

Quote from: bigsofty on 2023-Apr-07
I had problems with the INTEGER command iirc. It was producing weird rounding errors. I never liked how it rounded down from 0.9 to 0 either.

BTW, as long as you store a (floating point)number in an integer variable it will implicitly be cast to an integer so no need for direct casting.

I don't use GLBs RND function (I use my own) but doesn't that produce integers? If so then I don't think you need to use INTEGER at all in your code.

Thanks - I'll check that out...
Comp:
Speccy-48k, Speccy-128k, Amigas, PCs

spacefractal

#5
not a bug, so wont been fixed.

This is just how floats work as floats is imprecise.

When you using floats, then 4/2 can been 1.9999998 and not 2. Since INTEGER allways round down, then you face this issue as its would been round down to 1 and not 2.

To fix this issue, you could try to add 0.0001 or 0.5001 to the value, before using INTEGER or something like that.

like

startwater_right% = ((resx/2)+1.0001) + (INTEGER(RND(20))*16)

Yes floats can been very annoying, but this is what it is.
Genius.Greedy Mouse - Karma Miwa - Spot Race - CatchOut - PowerUp Elevation - The beagle Jam - Cave Heroes 2023 - https://spacefractal.itch.io/