[Jase]

CommandanteStreakTH, on 16 December 2014 - 06:49 AM, said:

Jase, on 16 December 2014 - 06:39 AM, said:

How stable is the framerate?

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.

[Candescence]

Jase, on 16 December 2014 - 06:25 AM, said:

Mr Lange, on 16 December 2014 - 05:48 AM, said:

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.

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.

CommandanteStreakTH, on 16 December 2014 - 06:34 AM, said:

(The funny thing is that I was playing "Around the World" as I was recording this... how appropriate)

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.

This post has been edited by Candescence: 16 December 2014 - 06:57 AM

[CommandanteStreakTH]

Jase, on 16 December 2014 - 06:53 AM, said:

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.

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?)

Candescence, on 16 December 2014 - 06:55 AM, said:

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.

Did that, Sonic is still wobbling a bit, but the physics are still going very smoothly.

This post has been edited by CommandanteStreakTH: 16 December 2014 - 07:27 AM

[Jase]

Candescence, on 16 December 2014 - 06:55 AM, said:

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 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..

CommandanteStreakTH, on 16 December 2014 - 07:09 AM, said:

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?)

Ohhh right, you're using the debugger. Heh. That thing destroys framerate, I only use it when absolutely needed. But cool, I see. :P

This post has been edited by Jase: 16 December 2014 - 07:58 AM

[CommandanteStreakTH]

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.

This post has been edited by CommandanteStreakTH: 16 December 2014 - 08:40 AM

[winterhell]

Jase, on 16 December 2014 - 06:25 AM, said:

If you had 100000 objects scattered around a massive level

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.

[Jase]

winterhell, on 16 December 2014 - 12:24 PM, said:

<br/>

Jase, on 16 December 2014 - 06:25 AM, said:

If you had 100000 objects scattered around a massive level

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

This post has been edited by Jase: 16 December 2014 - 04:23 PM

[Techokami]

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

[Mr Lange]

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.

This post has been edited by Mr Lange: 16 December 2014 - 06:58 PM

[Jase]

Mr Lange, on 16 December 2014 - 06:55 PM, said:

Recently discovered C2 doesn't has neither the family nor 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

[Candescence]

Mr Lange, on 16 December 2014 - 06:55 PM, said:

Recently discovered C2 doesn't have the family nor 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.

Uh... What? Yes it does. Families are still a thing, and much improved from Classic, and attributes have been merged with behaviours, if partly because they were effectively redundant, if I recall.

[Mr Lange]

I looked this up. No wonder, families are only available in the full version. I'm still using the demo.
Attributes are not redundant with behaviors. They worked similar to families, but the difference is, they allowed objects of different types to be grouped, attributes are read only in that you can't apply code to them, only run checks. Also, objects in families all have to share the same private variables. Objects grouped by attributes are independent.
You cannot read from objects that share behaviors, they're not grouped as a readable object.
So, having families and no attributes is better than nothing, but attributes were still an important feature.

This post has been edited by Mr Lange: 16 December 2014 - 10:14 PM

[Candescence]

Pretty much everything you said can pretty much be done with families, with the only exception being grouping objects of different types, but that's really not much more work.

Mr Lange, on 16 December 2014 - 10:12 PM, said:

Also, objects in families all have to share the same private variables. Objects grouped by attributes are independent.

Not true. Families have their own set of private variables, but individual objects within a family can have their own independent variables and behaviours. You can just have a family with no variables or behaviours, and let all the objects in that family have their own variables and behaviours without any problems.

Quote

You cannot read from objects that share behaviors, they're not grouped as a readable object.

You can just make a family (or families for however many object types you need to check) with that common behaviour to achieve the same effect.

[Mr Lange]

Oh, so two different objects in a family can have different private variables now? That's good.
And what if I wanted a sprite and tiled background to be part of a group, so I can check both of them for collision? That's what attributes allowed. So, unless they made it possible to put different types of objects in the same family now, that's still kind of a hole.

This post has been edited by Mr Lange: 16 December 2014 - 11:17 PM

[Candescence]

Mr Lange, on 16 December 2014 - 11:11 PM, said:

Oh, so two different objects in a family can have different private variables now? That's good.
And what if I wanted a sprite and tiled background to be part of a group, so I can check both of them for collision? That's what attributes allowed. So, unless they made it possible to put different types of objects in the same family now, that's still kind of a hole.

Well, you can just have multiple versions of the same family for different object types and check all of them at once in multiple conditions. A bit more work, but it does the same thing.