I don't really know the Physics Behaviour that well, but from what You are saying, it sounds like moving up a slope is no problem for You? Just adjusting the angle of the Player Sprite itself (the rotation)?

You can easily do this by comparing the LastX and LastY (private variables, that You assign the .X and .Y position to, at the end of the Event Sheet) position with the current .X and .Y position, by entering the values into the angle expression (a system expression).

It will then give You the angle the Player is moving in; You then just set the Player Sprite Angle to this.

Unless I am missing something, why don't You just use a 'focus' variable?

Set it to 1, if You want focus, and to 0 if You don't.

Then only allow the buttons to work, if something was pressed AND focus = 1.

(event 70)

+ Hero: On collision between Hero and BibleDrop

-> System: Add 1 to global variable 'BookCount'

-> BibleDrop: Destroy

(event 71)

+ System: Is global variable 'BookCount' Equal to 66

-> System: Add 2000 to global variable 'Score'

-> System: Set global variable 'BookCount' to 0

-> Hero: Set animation frame to 2

(event 72)

+ Hero: Animation frame Equal to 2

(event 73)

+ System: Every 5000 milliseconds

-> Hero: Set animation frame to 1

Okay, according to my logic what should happen with this is:

When 'BookCount' is 66 the animation frame will be changed to 2. (note animation frame is not another animation, but the second frame of the current animation)

Then in Event 73, Every 5 seconds, we set animation frame to 1. (note again, not the animation, but the frame of the current animation)

What we should see with this code, is the animation "frame" changing to the second frame one time, once 'BookCount' is 66, and then never change back to frame 1.

Because Event 73 is only run every time if in the same frame/tick: "Hero Collides with BibleDrop AND BookCount = 66 AND Hero Animation Frame = 2. However in the next tick, the Event check already can't get down to Event 73, because Hero must still be colliding with Bible Drop and BookCount must be equal to 66.

From my understanding, You should better use the Every X ms as a main Event, combined with a constantly true condition (or at least true for longer than the 'Every X ms' You entered), like a variable.

7Souls way is a good suggestion.

Is (Event 73) a Sub-Event of (Event 72), or one of the Main Events?

If it's a Main Event, then that's Your problem.

INI writes to disk, and you should never constantly write to disk like that! It's far too slow to be practical. You should only save to INI once, like at the end of the layout, or when the user clicks save. Hash table is all done in memory so there's no slowdown from going to disk at all.

Thank You, Ashley. <img src="smileys/smiley1.gif" border="0" align="middle" /> Gives me some clues as to what to research next, the difference in disk memory and RAM, and how exactly they work.

Could someone explain to me why writing to an INI file every step (adding string) slows down the application significantly, while doing the same thing with a hash table causes almost no change in Framerate?

The string added every step is basically just the number of the .X position of a sprite and a comma.

The Framerate doesn't drop instantly either (testing in Unlimited FPS mode), but after a while. So I thought it might have something to do with the INI file getting too large? And that every consecutive time it needs to search longer for the end-position to to add the next string to.

Thank You in advance.

From what I can see, the problem is that You don't specify which instances private variable to use for the event. So it will just use the 'spiketime' variable of the the first created spikes Sprite.

All You need to do is add the System Condition 'For Each Object' on top of both events. This will pick each instance and its own variables.

I love You. <img src="smileys/smiley1.gif" border="0" align="middle" />

Yeah, I was reading about loop index earlier today, but didn't really think about this.

I've been trying to find a way to access the order information of objects. Naturally, in which order they have been created, and have them carry their information in each instance. As in, this is the first instance, that has been created of this object, this one the second, the third, etc. ... .

The only ways I could think of are too complicated, when I feel like there is surely an easy way.

I would do it with a global variable, and that is what I don't like, to have something external like that. Since, if different Objects get plentysome, I'd end up with loads of global variables just for ordering the instances of each Object.

I would basically do something like this:

We have:

+ globalvar('IDCounter') = 0

+ SpriteObject

+ SpriteObjectVar('IndexID') = 0

We do:

+ For Each SpriteObject (Ordered by SpriteObject.UID - Ascending)

-> Add +1 to global('IDCounter')

-> SpriteObject.SetValue('IndexID') = global('IDCounter')

Thank You in advance.

That's funny, lol. I was just searching about a very similar question, hash tables vs arrays. I didn't find that much yet, just checking the Help Section for some recent things, and I see a topic about almost exactly my question.

it automatically AA's the graphic to look like its making sub pixel movement if you have linear filtering (the default sampling mode) set. this can look ugly sometimes though. you can change the sampling mode (which causes tearing instead of subpixel blurring).

rounding the position when you want it to be non blurry (example when your character isnt moving) will fix the blurred look.

Construct uses Linear Sampling, but are You sure for everything? Because moving the sprite with 0.1 every step doesn't move the sprite at all, until the next whole number. In the info box it sais the sampling is just used for rotations and scaling.

I've been wondering how Sprites are moved, if the given value for example is .X += 5.5 X. With decimal numbers. Since the smallest possible value of the screen basically is 1px, how are images moved when they have decimal numbers?

Are the numbers just automatically rounded? Or nearby pixels illuminated weaker so it appears halfway on it? I don't know, how is it handled?

EDIT: I also noticed an odd behaviour in Debug Mode. For a moment I thought, the sprite is just moved, if the position has updated to a new whole number. I came to this conclusion by moving the sprite += 0.5px on X every step a button is down, while running with 2FPS. I pressed the button at different intervals.

But when I was moving it by 0.1px every step, sometimes it was updating the screen and moving the sprite by 1px, when the current X position was 10.8 and sometimes at 10.6 (10 being a placeholder for any whole number here).

And then sometimes it wouldn't move at all, if X was a whole number and the screen was updated the next time.

Related to this I would actually like to know how exactly using a fixed framerate affects the reading of the events? - First I thought, the internal processing speed of the events is not affected, and it will just keep reading the event list top to bottom as fast as it can and render the image, and then just wait for the given fixed framerate interval time to pass, until it updates the screen.

Now I feel like it actually also reads the event list with a slower speed, because sometimes it doesn't recognize the button input, if I press it at different times until the next reading (which I assume is signaled by the blink that is visible in the debugger window). And it seems to recognize the button press, if I press it shortly before the next tick, and not recognize it, if I press it directly with the next tick starting (the blink happening).

If it was reading the events as fast as possible, I would assume it to recognize the button press at the beginning of the tick, not at the end.

However if it was actually processing the events slower, I am confused about how it would handle the rendering of the image into the backbuffer.