Author Topic: 3DMaze glitch  (Read 3325 times)

Offline shinydarkrai94

  • Mc. Print
  • *
  • Posts: 3
    • View Profile
3DMaze glitch
« on: 2010-Oct-08 »
   Hello, I am new to the forums and GLBasic, but it looks great so far :). Since I am new, I apologize if I am not supposed to post glitches with sample programs, but I thought you may want to know anyway.
   I was just testing out the 3DMaze sample program that comes with GLBasic and I managed to go through the wall. It was on the west wall of the maze and I was moving against the wall. After I went through, I could not get back into the maze. I have included a picture to demonstrate this.

Offline shinydarkrai94

  • Mc. Print
  • *
  • Posts: 3
    • View Profile
Re: 3DMaze glitch
« Reply #1 on: 2010-Oct-08 »

MrTAToad

  • Guest
Re: 3DMaze glitch
« Reply #2 on: 2010-Oct-08 »
Your FPS is over 200, whilst mine in around 70, so its possible that the program was moving faster than the radius of the collision check.
« Last Edit: 2010-Oct-08 by MrTAToad »

Offline shinydarkrai94

  • Mc. Print
  • *
  • Posts: 3
    • View Profile
Re: 3DMaze glitch
« Reply #3 on: 2010-Oct-08 »
Ah, nvm them :P.

Offline Kuron

  • Mr. Polyvector
  • ***
  • Posts: 238
    • View Profile
Re: 3DMaze glitch
« Reply #4 on: 2010-Oct-09 »
Your FPS is over 200, whilst mine in around 70, so its possible that the program was moving faster than the radius of the collision check.
Collision should work properly regardless of the FPS ;)

MrTAToad

  • Guest
Re: 3DMaze glitch
« Reply #5 on: 2010-Oct-09 »
Dont forget it just uses a given radius - move too far and you wont get a collision.

In order to sort it you would need a ray collision system to detect anything between where you current are and where you will be.

But as its only a demo program, I dont think its worth implementing.

Another way of solving it would be to limit the movement size.
« Last Edit: 2010-Oct-09 by MrTAToad »

Offline matchy

  • Prof. Inline
  • *****
  • Posts: 1545
    • View Profile
Re: 3DMaze glitch
« Reply #6 on: 2010-Oct-09 »
I found when passing collision points that modifying the the step dtime mutliplier has effects of certain devices and it'd documented.  :rtfm:
Code: (glbasic) [Select]
.
.
.
dtime = GETTIMER()
// limit on slow machines / begrenzen f. langsame Rechner
dtime = MIN(dtime, 16)
.
.
.
ply_x=ply_x+my*COS(ply_dir)*sz*dtime/1000
ply_y=ply_y+my*SIN(ply_dir)*sz*dtime/1000
.
.
.


Offline Kuron

  • Mr. Polyvector
  • ***
  • Posts: 238
    • View Profile
Re: 3DMaze glitch
« Reply #7 on: 2010-Oct-09 »
But as its only a demo program, I dont think its worth implementing.
Unfortunately, as this thread shows, an improperly coded example or demo can give a beginner (or somebody evaluating GLB before purchasing it) a bad impression and even a potential lost sale (in the case of the latter).

MrTAToad

  • Guest
Re: 3DMaze glitch
« Reply #8 on: 2010-Oct-09 »
I would hope these postings would explain why things happen, and hopefully would spur someone one to write a collision system that is fool-proof...