How Many Using Pure Basic

[Pfaber11]

you know I do agree with you and I now Know a better way to check for collisions . I have to be honest and the code I was using to check for a collision between 2 objects was about 35 lines of code and it was given to me from someone on TGC forum . What can I say it works . But I needed to check for 5 orb collisions and 5 food collisions hence 10 checks per level per frame . so that's 350 lines of collision checking for each level and there were 12 levels . Hence 350 lines per level times 12 . Hmm will not be doing that again all I can do is put it down to experience . There you go it was all down to TGC forum. Found a much faster and better way to do this in PureBasic  using way less code and I understand how it all works . I still think the game was fun to play though and nobody would ever know anyway. Have a  nice evening .

[Pfaber11]

This is the way I'm checking for collisions in purebasic and it works well basically if the entitys collide the screen turns red .

Code: [Select]

CreateEntityBody(2,1)
 CreateEntityBody(4,1)
 result = EntityCollide(2,4)
 d=1
If result > 0
 
  d=d+1
EndIf

  If d <=1
    CameraBackColor(0,#Blue)
  EndIf
 
  If d >=2
    CameraBackColor(0,#Red)
    d=0
  EndIf

FreeEntityBody(2)
FreeEntityBody(4)

Don't think there is anything wrong with this code but you might . I guess we all have our own style .
 
edit Looking at this code now I see I could shorten it significantly but there you go .

I see I made a mistake should read

Code: [Select]

createentitybody(1,#PB_entity_staticbody)
However the above still works.

[Hotshot]

I used Purebasic sometimes

[Derron]

> using way less code and I understand how it all works


So what does

Code: [Select]

CreateEntityBody(2,1)
 CreateEntityBody(4,1)
 result = EntityCollide(2,4)
do in detail?


Do not tell us you understand what it does if you didn't. If you did understand what it does, you would never have done that 35*12 collision thing.
Creating collision layers is better than nothing - but with hundreds or thousands of objects you sooner or later need other ways to approach this. So better understand the basics of collision detection - and what the above code is really doing as this helps to understand its limitations and possibilities.


bye
Ron

[iWasAdam]

taking you 'working' code above:

Code: [Select]

CreateEntityBody(2,1)
CreateEntityBody(4,1)

if EntityCollide(2,4) > 0
   CameraBackColor(0,#Blue)
else
   CameraBackColor(0,#Red)
EndIf

FreeEntityBody(2)
FreeEntityBody(4)

Now I don't know the ins and outs of what EntityCollide does, but I do know that all the crap with 'd' and 'result' is not needed and is just adding 'cruft' and potential errors to your code.

I would possibly go further and suggest you only need to set up the entitybody's once (when they are created) and delete them when you have finished with them. not create and delete every frame. But again I don't know exactly how purebasic is dealing with them?
that would take your 'it's superb, my code is the best in the world, don't you wish you could do it like me' 20 lines of code and make it very simple 5 line! But hey - what do I know? I'm not the best programmer in the world - like you are...


It sort of seems you have very little grasp on some very basic fundamentals:
if else end
data/arrays

Anyone here would be happy to help you through any of these things - they are core basics. But banging on about how good one language is from another when you can't even use the basic building blocks is sort of irrelevant.

[Pfaber11]

Hmm well you create the entity body from the entity check for a collision then free the entity so it can be used as a normal entity again . Probably not what you were looking for but it works fine .

[Pfaber11]

yes  Adam that is a better way to do it I did realise this after I had put it up but there you go . Thanks for the input.

[Pfaber11]

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 freeentity and so on .

[Pfaber11]

But yes that code I put up for collision detection was very strange . But one thing and that's at least I didn't just copy someone  else's code . And it does work . Maybe my brain is packing up which would be a shame but there you go knock on wood I'll be fine . You should see the code I put up for AGK2 collision detection it's mind blowing . In fact I'm going to find it and show you .
Going to find it now.

[Derron]

I did not ask for the reasons of the command usage - but more what they actually do. You told you know your code now. So what is the collision function actually doing, why does it need the entity bodies to get processed by that other functions - such stuff is what you "at least basically" need to know. Why? Because only then you can estimate how "costly" these functions are.

Sometimes the provided functionality is not good enough for a specific use case - too generic, doing too much. Sometimes you do not need complex hull collision checks if a bounding box collision check is already good to go (this is stuff the above used functions surely contain - but were you aware?).

It is similar to know if you can skip checks of collision between certain objects (either as you do not have a physics reaction like "repel" or because you are not interested in "enemy hitting enemy" or similar stuff).


As Adam suggested: learning the basics helps to read code, to write code. Learning tricks helps to speed up your code. Learning methods/approaches helps to shorten your code or to make it more efficient.
You plough through progamming languages and as soon as you do not advance in their ... or reach a "non-solveable problem" you move on. So far no problem - but you should avoid blaming these languages for stuff which obviously is not happening for others. So if your "game" (or prototype) is not smooth for you - but other programmes done in that language with the same framework are running smooth ... then you should always ask yourself twice if it is the language (maybe a bug?) or your code.


With game programming in general - and "hobby/indie games" in special: it is not just about bringing the game to the market. It is also about learning, about improving, about trying stuff out. Every dirt trick you do to achieve a fast "playable state" might repel smashing right into your coding face once you need to modify that piece of code. Especially more generic stuff like "collisions" - which you might need all over your game - should be done properly and not with tons of spaghetti code. There you _really_ benefit from "write once, use multiple times". Just assume you had to write a manual "image loading" ... and you copied + adjusted it for every image you load. It is tedious - and once you find a bug you need to adjust it everywhere...


On the other side - to not just "rant": It is good that you try out stuff, that you do not "force" yourself to feel comfort in a language which does not comfort you (and your current state of skills / knowledge). Maybe do not try to create a big game first ... create little "one screen" games. Later extend with Start screens, highscores, ... just to learn the "aspects" of the games. Learn to reuse stuff - it makes you learn what you are doing wrong in certain parts of the code (you recognize it is not easy to "copy paste" but requires a lot of adoption? ... something to improve on!).


bye
Ron

[RemiD]

I needed to check for 5 orb collisions and 5 food collisions hence 10 checks per level per frame . so that's 350 lines of collision checking for each level and there were 12 levels . Hence 350 lines per level times 12 .

what you apparently need to learn is to store your entities in list(s) and use for{} loops to do checks between entities. less code to do the same thing.

you can also add a field (variable) for each entity, named "kind", which is given an integer (corresponding to a constant with a destrictive name) to further refine, your for{} loops and only do the checks between specific group of entities

in blitzbasic this would be :

Code: [Select]

;list with dim arrays :
global entitiescount%
dim entitykind%(100) ;integer constant (cplayer or corb or cfood)
dim entitymesh(100) ;reference
dim entitylife#(100) ;float

;list with custom type :
type entity
 field kind% ;integer constant (cplayer or corb or cfood)
 field mesh ;reference
 field life# ;float
end type


[Pfaber11]

Thanks for all the advice I am taking it onboard. Gonna be a while before I get proficient at this although I have come on in leaps and bounds in the last 2 years . My next project will be a lot better thought out . As promised here is the AGK code for detecting collisions that was given to me from someone on TGC forum . The first couple of line and last few lines are mine and the stuff inbetween is alien.

Code: [Select]

objID=2
objID2=8
function checkCollision4(objID as integer,objID2 as integer)
     
local width# as float
local height# as float
local depth# as float
local x# as float
local y# as float
local z# as float
local start_x# as float
local start_y# as float
local start_z# as float
local end_x# as float
local end_y# as float
local end_z# as float
local object_Hit as integer
 
//this checks for colliion between an object with any other object and returns its id
width#=(GetObjectMeshSizeMaxX(objID,1)-GetObjectMeshSizeMinX(objID,1))/2
height#=(GetObjectMeshSizeMaxX(objID,1)-GetObjectMeshSizeMinX(objID,1))
depth#=(GetObjectMeshSizeMaxX(objID,1)-GetObjectMeshSizeMinX(objID,1))/2
 
x#=getObjectWorldX(objID)
y#=GetObjectWorldY(objID)
z#=getObjectWorldZ(objID)
 
 
// calculate the start of the ray cast
start_x# = x#-width#
start_y# = y#+height#
start_z# = z#-depth#
// calculate the end of the ray cast
end_x# = x#+width#   
end_y# = y#-height#
end_z# = z#+depth#
 
// determine which object has been hit
object_Hit = ObjectRayCast(objID2,start_x#,start_y#,start_z#,end_x#,end_y#,end_z#)
endfunction object_Hit

if checkcollision4(2,8)=1
deleteobject(8)
resettimer()
playsound(1)
key4=1
key=key+1
endif

You guys probably understand it . I don't although I know how to use it .

[Pfaber11]

I just counted the lines of code for that collision test and it's  even more than I thought. Anyway just looked at it and I understand some of it . But could not and did not write It myself.

[Pfaber11]

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. Gonna use if else and endif more appropriately too. And that d thing was just spaghetti as you say . Thanks again for all the useful tips . I'm definitely not the best programmer on here I'm probably below par but I still enjoy it and strive to better myself .
  Twelve months ago I hadn't even heard of a height map or texture or mesh so I've come  a long way in a year. I've still got my first program I wrote in AGK2 and that was so crap. I did sort of think it was due to AGK2 at the time but I was wrong my programming skills were terrible ( still are maybe ) but I have improved . Ready to give up on making models from photos the quality is just not there . I'll either have to buy my models or do my best to make them decent . They will be on the simple side though . Anyway enjoy your evening . over and out.

[iWasAdam]

Modelling from photos is nasty. My thought there would be to try some very low poly stuff. 3D is not the simplist thing to get your head into...