How Many Using Pure Basic

[Pfaber11]

Yes I think that's it for me as far as models from photos go . The results were useless . Read an article on line and this guy reviewed it and his results were rubbish as well . Oh well at least I've tried it . Back to blender . I guess that's why good models command a good price .

[Hotshot]

Hey Hotshot what is your opinion of purebasic . For me personally I quite like it . And Ron you have to convert the entity into an entity body to check for a collision after this check you have to turn it back into an ordinary entity with freentity and so on .

I like purebasic due that you can produce small file size but what I don't like is unnecessary of using start drawing and stop drawing commands as if you not careful with these commands as could crash the program.

[Derron]

Well guys I did learn something today and that is don't check for a collision every frame instead do it every 5 frames or 10 frames and that really speeds things up . Thanks for the tip.

Who told you that? Hope nobody here did. Skipping collision checks will result in missed collisions. Famous example is the "bullet vs thin wall". This example would expose one problem:
frame 1: bullet is at grid 0,10 and wall is on 3,10
frame 2: bullet is at grid 1,10 and wall is on 3,10
frame 3: bullet is at grid 2,10 and wall is on 3,10
frame 4: bullet is at grid 3,10 and wall is on 3,10
frame 5: bullet is at grid 4,10 and wall is on 3,10

You check frame 1, frame 6, frame 11 ...
Bullet hits the wall in frame 3 - which you skipped.


The real "bullet versus thin wall" is not about missing the wall because you skip frames - but because the bullet moves more than the width of the wall per physics frame. So in one check it is before and in the next it is right after the wall. So the idea is to check also "mini steps" of the units movement. so if bullet moved from "0,10" to "5,10" between two physic frames, the physics simulate the mini steps (1,10 / 2,10 / 3,10 / 4,10) to check for collisions too.


So I would say no to doing collision checks only every Nth physics frame (also assuming you properly split physics from rendering).
to increase performance of collision checks: only check what is in range - or give entities an area/locationID which describes a bigger area of your map. If areas differ or are not neighbours then they wont collide - no need for boundingbox or hull collision checks.



bye
Ron

[Pfaber11]

Yes I see your point Ron can't remember who mentioned not checking for a collision every frame . I think it may have it's uses but not for every situation. As you say bullets and thin walls .

[Pfaber11]

Yes Hotshot it can be a pain but I think the benefits outweigh the negatives . It does all I want and it's fast. Having to initiate everything I suppose that's a bit of a pain too but it only takes a minute so no real hardship.

[MikeHart]

@Pfaber1: i am deeply sorry that i jumped at you.

[Pfaber11]

That's ok Mike no harm done . Have a nice day.

[iWasAdam]

not checking for a collision every frame

mmm, error prone as Derron said.
But... If you are having issues with collision and speed (e.g. collide x2 is ok but collide x20 feels slow), it probably points to something amis with the collision routine.
The only way to get around this would be to code your own collision.

in something like a 2d (3d maze is really 2d) maze you should be able to do a couple of hundred collision checks per frame without affecting speed. See above code for simple circle collision.
box/rect collision is the simplist to do. But again the best policy is to only check those things that are closer to you.

Again you will need to learn a bit more code

[Pfaber11]

My mazes really are 3D mazes .  They are made out of height maps . A bit unconventional but they work. Not as good as your stuff though but easy to make .

[iWasAdam]

You might think that they are 3D, but that is how they are displayed, internally and logically they are pure 2d. The moment you get a grasp of that, the simpler all you problems will become ;0

[Pfaber11]

Yes I know it's just an allusion but it's pretty damn convincing.

[iWasAdam]

Please bear with me on this. I have a very easy question for you:

when you load in your initial bitmap and convert it to a 3d height map (3dmap). Do you use the bitmap to decide the collision or the 3dmap?

[Derron]

I assume he uses the 3d model and simply checks if something collides with the object or not ... which is cpu costly, kind of stupid but might somehow work (albeit with issues).


If you want to draw your maps then "just" define a grid width, lay a grid over the image (scale one of them) ... and for each grid you identify what is drawn there (make it black and white - and check if it could represent straight line or corners (by checking splitting the grid in subgrids, and checking if there are vertical _and_ horizontal areas -> corner, or just one of them). That way a hand drawn map could be used to generate simple 2d labyrinth maps.


bye
Ron

[Pfaber11]

I do a check for what's in front or behind my object and camera so it stops and doesn't go through the wall. Something like if height map height at cameraz +10 > 50 cameraz = cameraz - 1. That's not exactly right but you get the idea.
No Adam I don't I just check what's in front and instead of going over the height map I just stop and can't go forward. Very simple really . 

[iWasAdam]

hmm. I am at a loss to how to help you go further:
1. You realize that your code is not brilliant (see many lines of code verses a few lines of code)
2. you realize that the collide methods are not correct (it is better to skip collision instead of per frame, etc - if many objects need collision the whole thing slows to a crawl)
3. you refuse to widen your method of thinking (E.G. my code works - therefore it is brilliant)
3. you also acknowledge that people here are trying to help
4. but you continue to ignore any help or suggestions
I wish you all the best