Even if you used a pointy collision polygon, it's never going to be pixel-perfect, and if you could use an infinite amount of points and shaped the polygon around the terrain perfectly, then you win, you get your nice pixel-perfect collision, but say goodbye to your framerate . If I'm not mistaken, it's better to have 2 4-pointed sprites to test each of them, than 1 8 pointed sprite or something. Then again, I could be wrong, I guess I should test and benchmark this stuff.
Either way, with any sort of optimal collision detection method (and the "invisible box" method can result in some more unique shapes than what is limited by a square tileset), the physics still work as they should, though I would suggest vertical surfaces have more friction, because right now it acts weird. Uh... Candescence, what are some of the problems you're seeing so far?
I guess that's something I've never been able to test. I would have thought the sheer amount of multipointed objects would be worse than hundreds of 4-pointed objects. But yeah your right, it is tedious Lets say you have a sprite called "FloorCollision", and in an event you decide to put: +Is Sensor overlapping FloorCollision Then this event will take advantage of Collision cels. If you was to have another condition in this same event so it looks like: +FloorCollision.X > 50 +Is sensor overlapping FloorCollision Now the event will not use collision cels. This is because it picked from all existing FloorCollisions that have their X position > 50 , then with that list of picked FloorCollisions, it then tests them for collision with the sensor. It's a downside and it is annoying lol.
If you ask me though, it reminds me a lot of playing around with the editors in Spore when you want to make a curve but all you have are squares (and if you have played with Spore editors before, this method is the best for you). It's great for complex and unorthodox shapes, but I've yet to check out the performance consequences of having those many objects. Probably another workaround for that is to have single pieces for long platforms instead of the segments that have been provided. (Also, using this method, you could just overlay a dummy image of the level and make a collision skeleton that's set to invisible, instead of having to piece the level together with a tileset, great!) Currently I made this massive "hook"-type ramp using that method, and Sonic is running around it without a snag. If you'd like to see the results, just ask and I might post a gif
Lol yeah, I know what you mean. I guess it's all about illusion, the player thinks it's a smooth curve but in reality it's loads of squares and lines stuck together, but to the player it seems smooth, which is who we are trying to cater towards anyway, right? The single pieces for long platforms thing is similar to what I'm doing in my own engine! gif plz
Ah wow... this could be a problem with some things, but then again if the check is specific, it doesn't really need the collision cell optimization, does it? For example, if I were checking for the value of an object's variable and only one object has that value, then as long as that condition is above the collision condition, it's already eliminated every object but that one for the collision check, right?
Yes that's correct. If you had 100000 objects scattered around a massive level, then I'd probably order the events so that it does the collision check first, since in that situation, it would cost more to check 100000 objects' variables, than to use the collision cells optimisation which essentially lowers the picked object list to however many objects are within the cell (so maybe 100 collision checks depending on how clustered the objects are positioned). If I'm not mistaken, the way collision cells work internally, it splits objects into different picked lists so it doesn't have to keep iterating through all of them to see if it's close enough or whatnot. It's an awesome feature but very situational, and I find myself doing a handful of variable checking then collision, rather than collision then variable checking.
Hooray! I finally feel useful in a programming community! (The funny thing is that I was playing "Around the World" as I was recording this... how appropriate)
Well, when I recorded it, I was running a couple programs which would've marred the results of a performance test, so I closed them and did it again, and it was hovering around 30-40 FPS. Worst I got was about 29 FPS, and that was at ground level where most objects are focused in.
Ohh damn I see. What is your CPU and GPU specs? Also what browser do you use to run the game? I highly recommend Node-Webkit or Google Chrome, they are insanely more stable with Construct 2 games than other browsers.
It is dependent on what you actually want to do, but generally, I don't really see much point in not having the collision check be first unless other picking conditions narrow things down much quicker, and I can't conceive of a reason why you wouldn't want to use it for collisions with terrain. It's just a matter of ordering the conditions, and I don't see how that'll be a problem most of the time. I suggest adding more sprites under the terrain to 'thicken' it somewhat so the lower sensors are covered, it seems like the thin sprites are making the rotations unstable even on flat ground.
My processor is a stock Intel Core @2.90GHz My graphics card is an AMD Radeon HD 6670 Without the debugger it was cruising at a steady 60 FPS throughout the whole loop, but not beyond (well, how would you even escape that hook?) Did that, Sonic is still wobbling a bit, but the physics are still going very smoothly.
I think you are right, I'm being biased with the way I'm thinking as my own project doesn't have massive levels so my approach is different. With having medium-size levels, it's probably not worth taking advantage of collision cells especially if a bunch of terrain collision is bundled together. Another important factor with Collision Cells is the Window Size. The window size is also the size of the collision cells, so if you stick with that really small resolution that genesis games have (320x240 or something?) then it should be very fast I think. EDIT: I don't even understand my own logic right now haha. I need to rethink this a lot more, I could have sworn there was a reason I wasn't putting terrain collisions top-level. Hmmm.. Ohhh right, you're using the debugger. Heh. That thing destroys framerate, I only use it when absolutely needed. But cool, I see. :P
Hey, uh, just as a reminder, since I'm a trial member, I might not have enough posts to continue this thread until I'm promoted, but at least I'm very pleased I breathed life back into this engine.
If the collision algorithm was written in C++ or C# it wouldn't be a problem to test Sonic against 100 000 polygons realtime even on a single core.
Yeah but Construct 2 exports in javascript lol. javascript is weird, it has issues with keeping accurate time or something. I'd totally move over to C++ if I had the time to learn it. EDIT: Just done some quick tests, spawning lots of squares in random positions between 0 and 10000, and then testing collisions constantly if I hold down a key (So if there's 100 squares and I hold down the key, it's doing 100 collision checks per tick). The collisions are against a separate different sprite. [FPS fluctuates but most often hit these numbers, and bare in mind this isn't reliable data and I had other software using my CPU at the same time. Also the objects are spawned randomly so cells may contain less squares to test against but heyho.] Spawning 10,000 No collision testing : 400fps Collision testing WITH cells : 380fps Collision testing WITHOUT cells : 350fps Spawning 10,000 No collision testing : 280fps Collision testing WITH cells : 270fps Collision testing WITHOUT cells : 210fps Spawning 100,000 No collision testing : 85fps Collision testing WITH cells : 80fps Collision testing WITHOUT cells : 25fps awesum
That's quite impressive! I was going to suggest using arrays to simulate collisions like in the Genesis games, but it looks like you guys have it figured out
Recently discovered C2 doesn't have the family nor the attribute system that CC had, which makes it nearly useless. How could they go this far and try to make a commercial version of Construct, then neglect these critically important features? Back to CC it is then.
Families exist in C2. You can assign Variables and other stuff to the family which then automatically get given to every object in the family. I think that the free version of C2 will not let you use families though. Not sure what the Attribute system is :P
