Feature todo-list

I remember that getting position of collision was suggested back then, but Ashley said that it isn't that simple, as firstly, there can be many simultaneous overlapping pixels, and secondly, collisions are optimised that way that when first colliding pixel has occured, it conludes that sprites are colliding and stops further testing.

Suggestion about picking: Action "remove object from selected object list"; I had this event where there was two sprites created and after creating action, there was an action that set an angle for them. The first object's angle was 0 and the second's 180. But when the second object was created, the first object was still on SOL and setting the angle at 180 would set both object's angle at 180.

<img src="{SMILIES_PATH}/icon_sad.gif" alt=":(" title="Sad" />

Surely it could find the average position of the overlapping pixels? And only work with the "is overlapping" event which (I assume) keeps testing after first colliding pixel.

These picking problems definately need some addressing, I had a similar problem with collisions which ashley has kindly apparently fixed in the next build - though I can see it happening in other places too (such as this). I'm sure theres a way around that particular example, such as using a private variable and exploiting the fact that the newly created version will have the default value. Maybe there is a nicer way which doesnt use a value, I dunno.

Well, I used function object for workaround because it can be set to forget selected object list, but more control over picking would be definitely nice.

I think that overlapping stops at the first overlapping pixel too, but maybe Ashley can confirm this?

All collision testing in Construct is done by testing 64 pixels at a time in horizontal lines, and it stops on the first instance of touching pixels it finds. So it can't give the average point of collision - and it would be inaccurate up to 64 pixels on the X axis.

Suggestion about picking: Action "remove object from selected object list"; I had this event where there was two sprites created and after creating action, there was an action that set an angle for them. The first object's angle was 0 and the second's 180. But when the second object was created, the first object was still on SOL and setting the angle at 180 would set both object's angle at 180.

Can't you use subevents for this? Use two blank subevents (means the same as Always), and create an instance separately in each event, and set it to whichever angle you want.

All collision testing in Construct is done by testing 64 pixels at a time in horizontal lines, and it stops on the first instance of touching pixels it finds. So it can't give the average point of collision - and it would be inaccurate up to 64 pixels on the X axis.

ah alright <img src="{SMILIES_PATH}/icon_neutral.gif" alt=":|" title="Neutral" /> , well I guess you'd have thought of a way if there was one. Was just a thought, not very important for me anyway, would've just made things look slightly nicer - and other people are usually a hell of a lot more concerned about that sort of thing than I am <img src="{SMILIES_PATH}/icon_smile.gif" alt=":)" title="Smile" />

would a "get position of collision" be possible, ie you imagine sprites A and B are both huge

on collision between A and B -> create EXPLOSION at (collisionx, collisiony), at the moment I don't know how to do this and make it not look stupid (if A and B are huge, and if they're irregular (ie not a circle) I can't do it well at all)

You could possibly do it by setting up a series of image points around the edges of your sprites, then do a loop (# of image points times) that checks if a point has collided with an object, where the point is the x and y of the image point as defined by the loop index. To save from running the loop constantly, have it triggered by a regular sprite-on-sprite collision.

The more image points you make the more accurate it would be. Obviously it would be kind of a pain to set it up, but theoretically it's doable.

Well I think most issues where such a feature would be useful would benefit more from a case specific solution than a general solution as suggested -- though it's a very neat one!

Ah well, though. That sounds fair enough.

just a quick one, a sign function would be nice:

like sign(x)=x/abs(x) if x=!0, 0 if x=0

obviously you can do this anyway, but it would simplify a lot of my equations

I'd quite like the ability to pause the timer.

I brought this up before, but to bring it up where it should be, I'd like to be able to set the time override during run time. Also being able to retrieve a monitors refresh rate would be very nice.

^yeah I assumed that override timedelta would give 1/monitor refresh rate, so like 1/60 if your monitor is 60hz etc

^yeah I assumed that override timedelta would give 1/monitor refresh rate, so like 1/60 if your monitor is 60hz etc

Heh, if you want that put on V-sync and turn off the override...

I brought this up before, but to bring it up where it should be, I'd like to be able to set the time override during run time.

Set the timer FPS to 1, and timedelta will return whatever the time scale is.

Heh, if you want that put on V-sync and turn off the override...

I spose, but I meant it would always return that, if you do that, and it lags at all, and you get a drop in fps, timedelta will change. (tbh i dont even care im not gonna use the override anyway lol)

Yeah. Most math will probably be accurate enough on nice, whole time deltas. The issue again is the dip in frame rate, especially sudden, quick dips.

The general idea is with these features, I have control of when time delta changes, how it changes and how much it changes during slow down. I can set minimum FPSs, add options to adjust how frame loss is handled for the player and a number of other things. This makes overriding time delta a real nice and powerful advanced feature. It gets the job done right now, but I think those few changes would make it awesome. <img src="{SMILIES_PATH}/icon_smile.gif" alt=":)" title="Smile" />

one thing i did think though, surely instead of timedelta you can just have whatever constant you wanted?? - then you could change it whenever...

one thing i did think though, surely instead of timedelta you can just have whatever constant you wanted?? - then you could change it whenever...

Set the timer FPS to 1, and timedelta will return whatever the time scale is.