can anyone help me with collision

[fsw]

This is a general problem in PB, and one that you won't have in 90% of all other programming languages - it comes from being forced to choose your handles manually.

Imagine if commands like CreateEntity, CreateLight and CreateWhatever would RETURN a handle, instead of requiring you to CHOOSE one - this is how it works in virtually every other programming language. Now you would simply do this:

hMyCamera = CreateCamera(...)
hMyEntity = CreateEntity(...)

now your camera handle and your entity handles could be 1 and 2, or 123 and 456 - it would no longer matter what numeric values your handles have, and this is the way it SHOULD be, because:

THE NUMBERS YOU CHOOSE HAVE NO MEANING.

That's right - making you choose your handles manually simply doesn't make any sense, because the numbers don't MEAN anything - they don't carry ANY information whatsoever.

Apart from that, having to choose your own handles creates major problems for developers trying to work together on larger projects....

PS: I apologize for this slightly off-topic reply, I didn't realize I would get this far off

I agree fully to what you said.

Fred said once he would create a #PB_Any constant to get some commands (like Gadgets, Memory etc.) to return the Number instead the OS-Handle, but he didn't say when this will happen.

At least for Gadgets there is a solution NOW!
Look at:
viewtopic.php?t=6969

This library is maybe not that important for game programmer, but the same technique could surely be used for all other objects, Memory, Files, Cameras etc.

[mp303]

I'm glad I'm not the only one who has observed this. I find that this is currently one of the few "stop blocks" for me - the things that keep me from starting anything bigger than a small shoot'em-up or some 3D experiments ... You simply can't develop anything much bigger than a breakout game at the moment, with these type of restrictions - the amount of self-discipline required to do so are inhumane

Until this is fixed, and until Ogre and ODE support are at least fairly complete (another two "stop blocks" for me), I don't think I will write anything "real" in PB ... the two things that I really want to start writing are: an email client - I gave up on this already while writing the first libraries (Base64 encoding/decoding) simply because I had to assign file-handles manually in every library - and a "virus" clone - e.g. something like the old "virus" game (Amiga) by Firebird; it's never been done since, at least not properly, and it's a crying shame, because it was such a damn good game ...

I hope PB will up to both tasks at some point, because it really is a language with a lot of potential

[LJ]

@Fred,

Looks awesome! You've got the right ideas. I like the Skybox command also. I remember years ago some programmers would say, "Shouldn't a skybox be left up to the programmer?" And so using another language, if you wanted to write a 3D shooter/FPS type game, well everybody had to write there own skybox code for outdoor scenes. With Purebasic, the skybox command just saved the programmer like me hours worth of coding and tweaking. Just by using the word Skybox in replace of dozens of lines worth of code. This is fantastic stuff. If you can do the same thing with a physics engine this would be awesome, something like Entity (1, -1,-5,-1, #PB_Jump) where -1,-5,-1 are relative movement locations (-5 in Y coordinate would be the distance the entity travels in the jump), and the optional flag of #PB_Jump uses the built in Purebasic/ODE physics engine library for a jump. If you can actually accomplish this, this would be awesome! Of course the built in physics in Purebasic would be optional. If someone wanted to do it manually, they would still have access to the moveentity commands and so they could do it manually.

I agree with you totally Fred and if you can make a physics movement as easily as the SKYBOX command is, that would be fantastic.

[mp303]

That sounds fairly crazy ... ODE is a generic physics engine, and the support for physics in PB should be generic as well - you can't generalize physics with commands like "jump", "roll" or "bounce" etc. ... just think of the number of commands you would need - the possibilities are endless. What should PB be optimized for? jump'n'run games? car games? flight simulators? all of the above? I think that's more work than Fred, or any programmer, can overcome.

PB should provide the physics - you should apply them yourself. Oversimplifying actual physic activities would be way too much work, and it just wouldn't be useful. I'm not even sure it would be possible, since "jump", for example, could mean lots of different things depending on the physical entities you apply it to ...

I wouldn't worry about it if I were you though, because as soon as the physics commands are there, you can be sure that, as with any previous PB commands, there will be plenty of users providing plenty of working examples for you to reuse

But I wouldn't think it fair to unload all this work on Fred

[Blade]

A good physics engine should just let the user to setup the right vectors (speed, gravity/acceleration) and a proper collision detection between the usual types: point, plane, bounding-box, complex object.

At this point almost any kind of game can be easily made...

So for jumping you simply define the gravity vector and the direction of the jump...

[mp303]

hear hear!

[Fred]

Blade: that's it.

[LJ]

That's exactly what I said except in fewer words. I very much look forward to this feature Fred.