Sorry your browser is not supported!

You are using an outdated browser that does not support modern web technologies, in order to use this site please update to a new browser.

Browsers supported include Chrome, FireFox, Safari, Opera, Internet Explorer 10+ or Microsoft Edge.

Dark GDK / Is Sparky's best method fo collisions so far?

Author
Message
asdronin
16
Years of Service
User Offline
Joined: 10th Apr 2008
Location:
Posted: 25th Jun 2015 23:25
Link
Hi all,
Im considering about adding collisions to my current project, and while I was about to make it simple and based on maths, I thought about coming here and see if maybe new methods have been used or created, after searching and browsing some threads I notice that most of people is still using Sparky's dll, I remember Kensupen method use to work too, but I think it could eat many resources as it casts about 10 rays per object and frame. So is Sparky's still the best method? also can this be working for many entities without causing slowdowns? I have seen some examples running fine but Im considering about having many entities at the same time on screen. Well, thanks a lot beforehand for any advice =)

PS Im not using GDK 2.0 just in case something new was added there
Back to top
Profile PM
The Tall Man
11
Years of Service
User Offline
Joined: 16th Nov 2013
Location: Earth
Posted: 26th Jun 2015 09:46
Link
I've never encountered slowdowns with Sparky's except when I tried using complex collision (there was no need for complex either).

Judging what we see is the greatest blinder and self-limiter in the universe.

What we perceive is never reality. It is only a story we tell ourselves based on our current perspective, which has far more to do with our beliefs about ourselves than with anything else.
Back to top
Profile PM
s_i
15
Years of Service
User Offline
Joined: 23rd May 2009
Location: Russia
Posted: 26th Jun 2015 17:23
Link
Sparky for 3D games, Box2D for 2D games.
Back to top
Profile PM
asdronin
16
Years of Service
User Offline
Joined: 10th Apr 2008
Location:
Posted: 27th Jun 2015 00:59
Link
Thanks The Tall Man, I see what you mean, then I wonder if to avoid such complex collisions you use a hidden simplified version of the map or something like that?.

Thanks you s_i, I'm currently aiming at 3D collisions, sorry I didnt mention it, but its good to know Box2D is working here too, I had no idea about this, will be handy in the future =).
Back to top
Profile PM
The Tall Man
11
Years of Service
User Offline
Joined: 16th Nov 2013
Location: Earth
Posted: 27th Jun 2015 09:05
Link
Just set the collision to a simple method, like box collision or something. Sparky's creates its own copy of the map for collision purposes. In a simple method like box, it reduces all objects to boxes that enclose the objects, for example.

Judging what we see is the greatest blinder and self-limiter in the universe.

What we perceive is never reality. It is only a story we tell ourselves based on our current perspective, which has far more to do with our beliefs about ourselves than with anything else.
Back to top
Profile PM
asdronin
16
Years of Service
User Offline
Joined: 10th Apr 2008
Location:
Posted: 27th Jun 2015 10:01
Link
Ah I see, thats cool, then one doesnt have to make it in lowpoly, is Sparky's lib that makes it for us. But if I understood it right, this is just in case the map is very highly polygonized, I mean in regular average levels it would be ok the other way checking sphere with all map polygons I suppose, right?.
Back to top
Profile PM
The Tall Man
11
Years of Service
User Offline
Joined: 16th Nov 2013
Location: Earth
Posted: 27th Jun 2015 13:09
Link
Well sphere is another simple method. I'd think it'd be simpler than box actually. As I recall (without it in front of me), there are 3 modes. The first being the simplest/fastest. The last being that it basically copies the map w/ all its polies (by far, the slowest). But in terms of internal implementation, I wouldn't think there'd be much difference in performance between box and sphere. Really the best way is to just try different modes and see for yourself.

Judging what we see is the greatest blinder and self-limiter in the universe.

What we perceive is never reality. It is only a story we tell ourselves based on our current perspective, which has far more to do with our beliefs about ourselves than with anything else.
Back to top
Profile PM
asdronin
16
Years of Service
User Offline
Joined: 10th Apr 2008
Location:
Posted: 28th Jun 2015 09:36
Link
I see, I will be trying that, I know this depends on the type of map and all that, for instance I have in mind filling my current map with things common in streets like parked cars and other stuff, but I assume that checking against all polygons present in a car for example is a waste of resources as the lib would be checking the lower and even the inner polygons at some point, thats why I think I will do as you said and try, what I want to avoid is converting the whole car into a box with the lib method as I want to be able to step over it so thats why I was thinking about making a simplified version of that map featuring only polygons I want to be collided like car becomes a simplified version of it with no under and inner pollies and so on, just in case I decide to take such route, will I be wasting lot of resources? I think its worth trying to avoid so many extra checks, right?.
Back to top
Profile PM
The Tall Man
11
Years of Service
User Offline
Joined: 16th Nov 2013
Location: Earth
Posted: 29th Jun 2015 01:55 Edited at: 29th Jun 2015 01:55
Link
In that case, you may want to check out PhysX instead of Sparky's (sorry, I just thought of it from your description). I've never used it, but I ran the vehicle demo on my old computer and was very impressed with it. Here's the thread:

Dark GDK / Physics plug-in powered by PhysX
http://forum.thegamecreators.com/?m=forum_view&t=163701&b=22

Judging what we see is the greatest blinder and self-limiter in the universe.

What we perceive is never reality. It is only a story we tell ourselves based on our current perspective, which has far more to do with our beliefs about ourselves than with anything else.
Back to top
Profile PM
asdronin
16
Years of Service
User Offline
Joined: 10th Apr 2008
Location:
Posted: 29th Jun 2015 10:11
Link
Thanks for mentioning about PhysX, looks interesting too, but in my case I'm not moving vehicles, sorry its my bad English fault, what I meant is my current level is going to be a street with parked cars, but these are merely obstacles to jump over them or get covered behind, these are not functional vehicles in the end. I think given this situation I would be fine with Sparky's, right? as said considering the ammount of polygons not wanted for collisions then maybe having a duplicated simplified level hidden wouldn't be a bad idea, or am I wrong?
Back to top
Profile PM
The Tall Man
11
Years of Service
User Offline
Joined: 16th Nov 2013
Location: Earth
Posted: 29th Jun 2015 11:04
Link
Yes, I understood what you were saying about static cars. I know PhysX can do dynamic cars, but I thought it might be worth checking out for static ones, too. As I said, I've never used it though. Sounds like you're sticking with Sparky's. Okay.....

Just reviewing the Sparkys documentation... Before you redo your objects with only outer-bounding polys, you may want to try out SC_setupComplexObject() first. If that doesn't work to your satisfaction, then I guess doing those lower-poly copies would be good. But you mentioned inner polys in your cars? If you're using them as static objects, why would they have inner polys to begin with? ...unless you're using more dynamic models for static use?

With Sparky's, you can also tell it to draw the collision poly lines while rendering, so you can clearly see the model copies it created for collision.

Judging what we see is the greatest blinder and self-limiter in the universe.

What we perceive is never reality. It is only a story we tell ourselves based on our current perspective, which has far more to do with our beliefs about ourselves than with anything else.
Back to top
Profile PM
asdronin
16
Years of Service
User Offline
Joined: 10th Apr 2008
Location:
Posted: 29th Jun 2015 20:57
Link
Ah I see, yes I will check PhysX if Sparky's gives me any performance issue or if I find things that I'm unable to do in the end using it (which seems not likely in my case)

SC_setupComplexObject sounds quite cool, thanks for mentioning about it =), dont know why I was only using the regular setup for object and even if I have read the documentation, which is not long, I never thought that function could be so handy. I think you saved me a lot of work, thanks again .

In relation to cars inner polygons, well this part is not made yet, but my plan is to portray dystopic future, if you know Bubblegum Crisis then you will have an idea, its big influence in what I'm pursuing. I mean cars and other vehicles half destroyed can be found in some streets, slum or wasteland, so for these I will need inner polygons, but I don't want the player to enter these cars or do anything in there, at the most it would be needed to stay close to that area to automatically grab an item laying inside, but of course for that I dont need inner polys to collide with player.

And I just tried the SC_DrawObjectBounds, well I'm using test object for now, but at some points it draws lines in the middle of the air, I think its related to the nodes that are mentioned in the documentation but somehow it draws more lines than these that are used for collision, is this the usual behaviour?
Back to top
Profile PM
The Tall Man
11
Years of Service
User Offline
Joined: 16th Nov 2013
Location: Earth
Posted: 30th Jun 2015 00:17
Link
Ah, I see what you're doing with the cars now, yes..

The idea of the lines is to be able to discern the polys it's using. I suppose you can experiment with different numbers of faces in the Complex Setup command. It could also be that you're scaling an object and Sparky's hasn't updated its version of the object to reflect the new scale. You have to tell Sparky's to allow object scaling, and scale the object in DarkGDK before setting it up (I think). It's also possible that a line in mid-air that you're seeing is from a different object, perhaps a bigger one or a nearby one. If not and if you can't get rid of it, you can just see how it interacts with the player. An extra poly here or there isn't the end of the world (no pun in intended for you game there )

Judging what we see is the greatest blinder and self-limiter in the universe.

What we perceive is never reality. It is only a story we tell ourselves based on our current perspective, which has far more to do with our beliefs about ourselves than with anything else.
Back to top
Profile PM
asdronin
16
Years of Service
User Offline
Joined: 10th Apr 2008
Location:
Posted: 30th Jun 2015 06:39
Link
Ah yes thats what I thought about the lines Sparky's lib is drawing, but if you see in this image I'm attaching there are many floating lines not used for collisions, I can go through all of these (without going through wall I mean), the test level is merely floor with a wall, just I have many polygons in each as its for test and I wanted to measure distances, collisions and all that. Well this is not a fact that worries me a lot at this point, probably as you said when final level is ready I can try it with different numbers when setupping the complex object, and if everything fails I can still make the lowpolyfied version of it, won't be the end of the world you are right .

Also thanks for telling me about the scaling issue when using Sparky's, I didnt know that, so far I'm only using test objects as I want to build a kind of solid framework where everything works (collisions, input, interfaces etc) then start adding the final media, so Im sure you saved me a headache about the scaling in the future =).

Attachments

Login to view attachments
Back to top
Profile PM
The Tall Man
11
Years of Service
User Offline
Joined: 16th Nov 2013
Location: Earth
Posted: 30th Jun 2015 10:30 Edited at: 30th Jun 2015 10:32
Link
You're welcome

wow, those are some nasty lines there. It seems like I encountered that once as well. I'm not sure why Sparky's does that. If I remember correctly, it was when I was either trying the regular setup with (all) polygons mode, or the complex setup with lots of faces. Performance was slow also. Btw, showing the lines does slow performance as well. Of course ideally, the lines ought to hug (outline) the objects.

Yes the Sparky's scaling issue has caused many a headache. But once you're aware of it, it's simple enough to resolve

Btw, here's another tip. Sparky's has a grouping feature where you can group objects together. It works great. I have one group to handle regular collision (walls, floors, etc), and other group to handle interactions and manipulations (doors, switches, objects that make sounds or trigger events, etc). For objects that require both those functions, I put them in a third group (apparently you can't put an object in more than one group; attempting to do so moves the object out of the first group and into the second group).

Judging what we see is the greatest blinder and self-limiter in the universe.

What we perceive is never reality. It is only a story we tell ourselves based on our current perspective, which has far more to do with our beliefs about ourselves than with anything else.
Back to top
Profile PM
asdronin
16
Years of Service
User Offline
Joined: 10th Apr 2008
Location:
Posted: 30th Jun 2015 20:22
Link
Ah yes, I thought the excess of lines could be due to bad setup, but Im using 2 as recommended in documentation for complex object, also tried other low values, there is slight variation in lines, but still they are present in the mid/air and doesnt affect collisions.

Thanks for the tip about the groups, sounds really useful , I was just thinking about adding all elements to group 1 (enemies, level etc) of course it sounds like a bad idea now. I was thinking about using distance formula for most of these features like switches or to trigger any event, I assume Sparky's is more efficient than this, right? well of course for doors and other stuff that have to block our way I think is definetly best option as only moving an object or playing its animation like open door... I assume Sparky's support changes in geometry due the animation, or at least I hope so.
Back to top
Profile PM
The Tall Man
11
Years of Service
User Offline
Joined: 16th Nov 2013
Location: Earth
Posted: 1st Jul 2015 03:33 Edited at: 1st Jul 2015 03:36
Link
Sparky's has done well for me for triggering events. What I do is have a pair of invisible walls (planes) that the player walks through, walls that span the entire path (such as the width of a hallway). I used 2 invisible walls instead of 1 to track the player's direction. Otherwise only 1 would be needed. Of course it works well for events driven by collision with regular, visible objects, too.

I think Using the distance formula would be less efficient yes, because you'd have to check the player's position against multiple objects. It would also give you an effectively spherical collision zone. If you do use the distance formula though, you can leave off the final square-root, to save some processing time.

I'm not really sure how Sparky's deals with animated geometry. I've never used it for that actually. But I do know that whenever you move an object, you have to set it up again in Sparky's, so the collision map will get the update. My guess is it would be the same for animation. If updating Sparky's for every frame of the animation ends up performing too slowly (assuming it's necessary), then in the case of a door opening or closing, for example, you could wait until the door is fully open or fully closed before making the update to Sparky's. Or you you could set to the last frame of the animation, update sparky's, then return to the first animation frame, all in the same game-play frame (so it's invisible to the player), then play the animation normally.

Judging what we see is the greatest blinder and self-limiter in the universe.

What we perceive is never reality. It is only a story we tell ourselves based on our current perspective, which has far more to do with our beliefs about ourselves than with anything else.
Back to top
Profile PM
asdronin
16
Years of Service
User Offline
Joined: 10th Apr 2008
Location:
Posted: 1st Jul 2015 08:11 Edited at: 1st Jul 2015 08:23
Link
I think that way you used the invisible walls for triggering events is quite clever and sounds really usefull way to check for player direction too, I guess that could be used to load/unload parts of the level (although I really want to avoid doing such thing).

I see what you explained quite right, the distance formula would be less effective in this case, I have been using that forever but just because I never used Sparky's, think that when I get familiar enough with it I would be able to do as you suggested, using different groups for triggering events etc.

By the way, I see we can check collisions against one particular group or just all groups, then in the case of using different group for sliding collisions and events, you have to call for collision check twice, right? I mean it can happen that we are touching ground and touching an event triggerer, plus we don't want to slide against invisble objects... well thats my asumption based on my little knowledge of the Sparky's lib.

Your idea about handling the door animation sounds really interesting, thanks for that too, I haven't yet checked if Sparky's can handle animations just updating the object in each frame.

I have been thinking just in case it doesnt work, maybe I could use invisible object in door place, lets say door cant be open without key card then invisble object is there to block us and animation for visible door doesnt play, if key card is obtained and player is there then invisble object has collisions disabled (I think thats like deleting that from the Sparky's group) and play the animation on the visible door... I know I would be using twice the number of polygons needed, but its not much and I have though about using duplicate for characters too like I want to collide with enemy but be able to stay close enough for hand to hand combat, so without a thinner invisible box placed in same place of enemy and pasing it to Sparky's instead of real enemy mesh, I cant get close enough.


Edit: Just to clarify, this being a thing that I have observed in my few tests is the issue I desribed about enemies (sorry for bad quality Mspainting xD), blue is our enemy, well the red area is more or less what Sparky's would allow me to get close if I configure to sphere, if its like box well the same just squared, but as I said player wont be close enough to stablish hand to hand combat, then I thought I could use a thinner box (green) used with Sparky's instead of enemy mesh and this way it should work, well Im using primitive models now but I have seen this issue and its the workaround I thought.

Attachments

Login to view attachments
Back to top
Profile PM
The Tall Man
11
Years of Service
User Offline
Joined: 16th Nov 2013
Location: Earth
Posted: 1st Jul 2015 09:54 Edited at: 1st Jul 2015 10:19
Link
Sounds like your idea about the door is better than mine. I've never done characters w/ hand-to-hand combat, but your idea of two objects for a player, one for movement, the other for combat sounds like a good one.

Yes, I believe for multiple groups, you'd have to check each one during each frame, so multiple checks. Sparky's is fast enough that it's never been a problem for me. In my experience, Sparky's is several times faster than the visual renderer, actually (although my rendering hardware is primitive (no pun intended! )).

As for having to load other map sections during gameplay, yeah that's nasty. It seems that most (or all) professional games do that, and yet it's absolutely unnecessary since most games use the same object types over and over, regardless of which "level" you're playing. What you can do for maximum performance is to show only the objects that are within the player's field of view, and hide all the rest. Also, you can have a library of objects and reposition and reorientate the same objects for different major sections of you map, to save memory. It would be much quicker (real-time) than loading/unloading. And if you needed to, you could spread it out over a few frames.

This would require a good bit of programming though (you'd basically have to create your own mapping engine), and you'd have to build your maps, object by object, rather than loading .x or .dbo levels. But you'd be able to create HUGE maps that would blow the "professional" games away in performance (and detail, if desired). Perhaps that's beyond the scope of your project though. But if you wanted to attempt it, I created a thread a while back in which I gave an overview of how I did it (although it was crude, but effective). I didn't have the library idea for repositioning and reorienting models to different major map sections back then. It just covered showing only the objects visible while hiding the rest. It gave a MAJOR performance boost.

http://forum.thegamecreators.com/?m=forum_view&t=209149&b=22

Judging what we see is the greatest blinder and self-limiter in the universe.

What we perceive is never reality. It is only a story we tell ourselves based on our current perspective, which has far more to do with our beliefs about ourselves than with anything else.
Back to top
Profile PM
asdronin
16
Years of Service
User Offline
Joined: 10th Apr 2008
Location:
Posted: 1st Jul 2015 19:48
Link
I'm glad you see the idea for doors and hand to hand combat should work =), I was not sure about all these as I'm really new to Sparky's but seeing how fast and accuratelly it works (Im not counting the excess in lines drawn), I see it can achieve very nice effects such as the event triggering you mentioned and so on.

In relation to groups then its good, I will be checking against each group when needed for events and other stuff. Im not using a powerful machine either, thats why somehow I always look at these facts before proceeding, well maybe the final player will have better hardware, but... how can I create any game without properly testing it at full speed? xD

About your idea to increase the performance... Wow!! its awesome, I mean really, I could have never thought about this, congratulations on creating this method =), sounds quite clever and effective, I havent implemented that yet as Im unsure about how maps will be built in the end. I mean one of the possible team members (currently I work on this on my own), he said he has made some maps (BSP->converted to one single X file) and could be joining but is busy too so can't totally count on him, other people may or may not join maybe after asking here or on other boards, and I can make maps too of course (if all faisl and nobody joins xD), but my method for that would be a lot less effective as I would probably be creating one single big file or even worst 2 copies of that, one for textures and the other for shadows (I mean like what Giles exports), so under that scenario probably I cant apply your idea for performance boost, although I will keep it in mind for sure in case I manage to implement it in the game.

Also about the scope of this project, well to tell you the truth, my idea about this game is to be sold, Im not dreaming about this, I mean if everything goes fine this could be sold at low prize I guess through some site or even my own site, well that would be a bad idea as nobody visits me xD, but overall my idea is that.
Back to top
Profile PM
The Tall Man
11
Years of Service
User Offline
Joined: 16th Nov 2013
Location: Earth
Posted: 2nd Jul 2015 10:31
Link
When I mentioned the scope of your project, I meant big enough (or not) to create your own mapping engine there.

Anyway, good luck!

Judging what we see is the greatest blinder and self-limiter in the universe.

What we perceive is never reality. It is only a story we tell ourselves based on our current perspective, which has far more to do with our beliefs about ourselves than with anything else.
Back to top
Profile PM
asdronin
16
Years of Service
User Offline
Joined: 10th Apr 2008
Location:
Posted: 3rd Jul 2015 06:47
Link
Yes I see, well I still dont know wether I will be creating a mapping engine only for this, or any other specific tool, or maybe if I manage to isolate basic common elements for many different games it wouldnt be a bad idea to build a mapping engine that could be used with such framework in many games, still unsure, only few days working over this game so there is time to settle things, and one of my biggest troubles was colissions (I was thinking I should code collisions with maths, its crazy I know xD) which now work great with Sparky's, also event triggering and things to block or allow us through like doors, bridges etc, all these are now either working or I know how to make them with what you told me, thanks a lot for your big help and advice =)

Also good luck with your games too, I hope I see future games from you soon .
Back to top
Profile PM
The Tall Man
11
Years of Service
User Offline
Joined: 16th Nov 2013
Location: Earth
Posted: 3rd Jul 2015 09:19
Link
Great! I'm glad it's working well for you You're welcome!

... and thanks

Judging what we see is the greatest blinder and self-limiter in the universe.

What we perceive is never reality. It is only a story we tell ourselves based on our current perspective, which has far more to do with our beliefs about ourselves than with anything else.
Back to top
Profile PM
Back to top

Login to post a reply

Server time is: 2024-11-18 19:34:44
Your offset time is: 2024-11-18 19:34:44