Collision stuttering in 8.6
JonTiStudios
Member Posts: 66
In my game (Snow Trax) currently on the App store (made with 8.5) the collision system works great. The sled travels along a series of invisible actors behind the graphics.
However, with the new 8.6 version the sled seems to have some trouble when colliding with the ground. It very sluggish, and often stops in place for a fraction of a second before catching up. It's less noticeable on the 3GS phone, but on the 3G is very noticeable. Although it looks almost like a frame-rate problem the game is still getting the same FPS it was before.
I have an update nearly ready to go out just before GS 8.6 came out. I'd really like to update my app this weekend. Is it possible to get this compiled using 8.5 somehow?
Thanks,
-Jon
However, with the new 8.6 version the sled seems to have some trouble when colliding with the ground. It very sluggish, and often stops in place for a fraction of a second before catching up. It's less noticeable on the 3GS phone, but on the 3G is very noticeable. Although it looks almost like a frame-rate problem the game is still getting the same FPS it was before.
I have an update nearly ready to go out just before GS 8.6 came out. I'd really like to update my app this weekend. Is it possible to get this compiled using 8.5 somehow?
Thanks,
-Jon
Comments
Hope you get it solved.
Edit: I stand corrected, my colliding is back to its old self.
Send and Receive Data using your own Server Tutorial! | Vote for A Long Way Home on Steam Greenlight! | Ten Years Left
@mulcahy - Yeah, I'm using GS viewer 8.6 - thanks for checking though.
Is it possible to get a game file back from the GS team compiled in an older version? If I uninstall 8.6 and install 8.5, what happens when I upload the file? Which version will it get compiled in?
@RH - What happened between your first post (where you said that it seemed flawless) and your edit (where you wrote that it's back to its old self)? Did you change anything?
----------
I found that collision detection has improved for me and my actors seem to move faster under 8.6.
I was having a problem where, if two actors follow each other over the same target, the collision of the second actor with the target wouldn't register in the GS Viewer (while it would on my computer). I assumed that it was caused by the reduced computing power of the iPhone compared with the computer.
When I installed 8.6, collision detection improved and is reliable about 95% of the time. And, I think I know how to optimize to get the other 5%...
I'm interested to know what experiences other people have had with collision detection under 8.6. Is it better, worse, the same? Did anybody notice any difference?
What I was trying was never very stable, sometimes it worked and sometimes it didn't. It seems to work more often now and I just got lucky the first 10 or so times i tried it
I ended up changing my game so that I get the same result.
Overall I'd say that collision detection is better in 8.6 but it isn't 100%
For me, I find that collision detection improves when I:
- slow down my actors,
- simplify and reduce the number of rules, and
- use actors (which uses fewer rules to identify them) instead of instances of actors.
Of course, this makes sense: the less you make the iPhone/computer work, the better it performs. (When I focus on one job, I work much better than when I'm multitasking ten things.)
It's always a delicate balance between what you want to do, and what you can do.
Im working to fix this right now, Ill post here as soon as / if I solve it!
Good luck sortin it m8!!
Marc
Last resort, I deleted the graphics actor from the scene, and tried spawning my graphics actor from my controller actor, constrained the graphics actor x and y positions to the controller position, and my game is now smooth as silk. Good times. hehe. Hope this may help you Jon!!
Marc
I too have had flickering graphics issues. For some reason it seems to happen on stuff that's on the scene before some change (update maybe?) happens. If I have that effect I will just re-place my actor on scene and it usually fixes it.
My issue isn't graphics, is the physics engine. My physics are very clunky now, and seems to have hangups when traveling along the collision boxes.
I'm going to check to see if I still have the 8.5 installer file for GS when I get home today. Hopefully I can install that and get a build of my game from 8.5 that's working which I can submit to Apple.
If I don't have the 8.5 installer I will be back on here to ask if anyone else still has it. I need to get my update submitted before the weekend.
On the not colliding ground section - I had the same issue! It was one of my biggest challenges early on. I finally solved it with a silly work-around as I could not figure out a better way of doing it. I will explain how I did it below:
__________________
Staying "On the ground" when driving over overlapping actors
I had an invisible actor constrained to the sled to tell me that the tracks were on the ground. The actor was located on the track area extending a bit below. That actor had a rule that when it overlapped with the ground actors (rectangles and circles) to mark "OnGround" as TRUE and an otherwise to toggle it back to FALSE.
Now the problem I had was that when you drove into overlapping ground actors (say a flat one, and onto one that is angled to represent a hill). The invisible actor overlaps with the first ground actor and OnGround is marked "TRUE". You start to drive and it now overlaps with ground actor 2. The code tells it to change OnGround to "TRUE" - which it does, but is already TRUE. However, as the actor stops overlapping the first ground actor the Otherwise rule kicks in and OnGround is marked "FALSE".
Now you're sitting on the 2nd ground actor but the game thinks your not on the ground.
I tried many different ways of trying to solve this, and what I finally came up with that worked consistently was this:
Solution (or one at least)
I created 2 sets of ground actors. A rectangle and a circle that were tagged as "Ground1" and another set tagged as "Ground2". I then created "OnGround1" and "OnGround2" rules.
Then I set my actor (the one on the tracks area) to mark OnGround1 as TRUE when overlapping with actors tagged "Ground1", and an otherwise of FALSE. I repeated this theory with OnGround2 and overlapping with the "Ground2" actors.
Finally I had a rule that said when EITHER (change rule from "ALL" to "ANY") OnGround1 or OnGround2 was TRUE to mark my original "OnGround" rule as TRUE with an Otherwise rule to mark it FALSE.
Now when I placed my ground actors I alternated Ground1 actor, Ground2 actor, Ground1 actor, Ground2 actor, etc.. This made my level creation a bit slow going, but it worked.
Now when your actor hits an overlapping ground actor it does not try to change the attribute current marked TRUE, but rather it changes a different one. Thanks to the rule that checks for at LEAST one of the OnGround# to be TRUE you should consistently be marked as OnGround until you are really in the air, in which both OnGround# will be FALSE and the Otherwise rule will kick in making your global "OnGround" rule FALSE.
__________________
I hope that wasn't too confusing. Let me know if it did not make sense and I'll try to explain it differently.
since my sled lurches a lot when driving I have to think it has something to do with it checking both ground actors. The lurching could be corresponding to when it collides with the different Ground groups. Although you said you are having the same issue, and It sounds like you're not using this method. GS version 8.5 did not have any of these issues however and it was smooth as butter for the initial release.
My current game doesn't need to detect when it's off the ground but my new ones do and I'll definately try what u did for those games once this stuttering issue gets fixed. Thanks again for the help. My email is ericdg123@yahoo.com if u want to talk about ideas on games or getting around the issues of working with game salad. Also if u have time I'll give u a code for my game. It may give you some ideas for urs but it's nowhere near the level of yours. Great job on the game. I'll leave u a 5 star review shortly.
Great job on your game, how is it doing for you?
Im my version of Photoshop (CS2), it doesn't give you that option (just png), so I don't know what other free/shareware prog would do that for you, if you've a similar aging version of PS.
:-)
---------------------------------------------------------------
Spiral Gyro Apps
""You are in a maze of twisty passages, all alike." - Zork temp domain http://spidergriffin.wix.com/alphaghostapps
I just have to images I'm using as a test and they are each 1000 x 500. Saving them as png 24 results in a file size of 800k and using png 8 or gif they go down to 185k which is still way too big considering I will need at least 15 of these images per level. Snow trax has to be doing something different. He has 20 levels and they levels are quite long but his entire game is 4.7mb which is awesome.
Also, back to the topic, collision stuttering. It is just killing my games. I can't update my game I have up now and my future games I'm testing are running terrible with the same problem.
I know game salad is great and none of this would of been possible without them, but I just don't think they are concerned with this problem because it apparently doesnt affect many users. Worked great in .85, but in .86 it went to hell, and stayed in hell for .87. I sure hope .88 addresses this issue. The slower the device and the slower the framerate, the more pronounced it is, rendering all my games on the 3g unplayable and barely playable and not at all acceptable on the 3gs.
I've only ever used 0.8.7, so was unaware of prev. (and present) problems; wish I could be more help with your framerate problem but I wouldn't know what else to suggest; except perhaps if you're using a lot of animation, that could slow things down.
Anyhow, hope you get it sorted. let's all hope that 0.8.8 addresses the problem, as you say.
""You are in a maze of twisty passages, all alike." - Zork temp domain http://spidergriffin.wix.com/alphaghostapps
As far as collision, yeah my drag helped me a tiny bit but it's still noticeable. I couldn't wait for them to fix it so I went ahead and updated even though I'm really not pleased with the way it works.
I thought at first it might have been my method of marking on/off ground - perhaps something when my zone actor overlaps and marks my boolean accordingly, however I removed that and it still occurred. It's actually something with the physics and the colliding that's causing it. It's very very frustrating.
As far as graphics go, all my images were saved as PNG with alpha. I'm guessing that you are drawing the entire level and chopping it up into parts? If that's the case that would explain your large file sizes.
My levels are actually many smaller images compiled in the scene. I had 6 "sizes" of ground graphics which were designed to be able to tile (look seamless when overlapped). Then each jump/obstacle is it's own graphic as well. My levels consist of a bunch of ground actors, and a bunch of obstacle actors, then a TON of invisible actors for collision.
By re-using the same graphics multiple times the system (theoretically) should only have to load it once into memory - or at least that's how games usually work. I tried making the entire level as 1 image and chopping it down to a few parts but that used a much larger amount of system mem.
Since I did it that way I was able to use about 20 obstacles and mix them in all the levels to get variety.
If you are trying the few massive images method, that may be your memory problem. If you're doing it the same way I am though I'm not sure what the problem is, sorry.
Have you had any problems with the graphics that you snapped together showing white lines where they meet? I noticed this once but haven't looked into it yet.
Also did u do all your own art? I can make the ground look good but I'll have to pay a graphic artist to make my character and object graphics. I think I'll talk to that guy on that topic here on gs forums.
Have you done pretty good on sales? I think your game is great looking and fun. Thanks again for the help.
Sales are pretty slow now a days. They did pretty well when it was released then slowly tapered down.