Limit Refresh Rate? (Solved)

I don't think there is a way to limit the refresh rate afaik.

However, if you properly used dt everywhere you're supposed to it should not matter. If you're having situations where a high refresh rate is affecting your gameplay, low framerate on a low end device would presumably also result in problems.

Triggers should still work properly. Collisions for fast moving objects normally have more issues with lower framerates when more pixels are skipped, but that should not be an issue with stepping enabled.

Note that you don't want to use dt with behaviors. Behaviors (except physics) already use dt, so if you use dt expressions to control behaviors, you'll actually make them framerate dependent again.

Interesting. Good to know. I'm having the issue an enemy using the platform behavior. Moving right through an object that alters one instance variable(checking the direction), which then changes the direction, and whether the image is mirrored or not.

Works fine at 60hz. They move through them pretty often at 185hz. I have not tested it at lower refresh rates though.

EDIT: The game with the glitching enemy works fine at 120hz. Speeds seem fine, and everything works as it should. That collision just seems to wonk out at 185hz.

The other game I have just about ready for release, is a never ending vertical scrolling shmup for the Android Play Store. I could make a version for 120hz phones, if needed, just by halving the speeds. I have all the background layers, enemies, and collectibles move a set speed down the screen each tick. I sort of enjoy it more at 120hz, as it's more challenging. I'll make a comment in the games description, and see what players want.

Either way, thanks for responding to the thread oosyrag

It probably just means you're not using delta-time correctly. You can take the stock games in Construct like Kiwi Story and run them in unlimited framerate mode, and they work exactly the same. Here Kiwi Story can run at 2500FPS+ and it's pretty much indistinguishable from 60 FPS.

Thanks again for sharing your knowledge. I was reading articles about Delta Time Last night. Now I'm reading through the one you linked to here on the Scirra site right at this moment. I'm going to work with both of those two games today. I'll see about implementing Delta Time correctly, and see what the end result is.

I figured if an object is using platform behavior it should take dt into consideration, and move at the same speed independent of a displays refresh rate(like the article says). Everything moves at the same speeds, except for that collision glitch. That enemy glitching through a collision object, is just using simulate move left/right, etc, with a simple switch direction block. Then at 185hz, I can watch it quickly flip direction twice, and move through the object.

I'll double check, and make sure all my image points are proper as well. All movement speeds are the same to my eye anyway. Just that pesky collision with a boundary object to flip direction. It's not critical to have it work at 185hz. But, now I am just curious to figure it out.

Does it happen if you don't mirror the sprite?

I'm watching it run right now, with the "Set Mirror" blocks disabled, and it seems to be working fine at 185hz. I played with it a couple times, setting it back and forth. Once I mirror the sprite, is when it moves through the boundary object it collides with. Origin Point is completely centered, and bounding box has completely flat lines, and sides(I've had issues with those things in the past, and learned from my mistakes back then).

Apologies for the double post. I may have that enemy collision glitch at 185hz worked out. I noticed the Origin Point was not a whole number. Would that for some reason cause an issue? Still reading through the article on DT.

All I did was widen the collision box by one pixel(double checked on every frame, as "Apply to All Animations" missed it on a collision point or two by a smidge(off by .03-.2 pixels), so I could set the Origin Point centered within the collision box using a whole number, now "60", rather than "59.5".

I set the blocks in the Event Sheet for mirroring on the boundary object as enabled. And now the enemy is reversing direction, and flipping the sprite as intended. I'm going to get some fuel to my brain, and finish up this Delta Time article. Thanks for all of the assistance, everyone!

Everyday, I learn something new. I love to learn, so it's all fun to me haha.

EDIT: Or perhaps it was one of the collision points being barely off by a fraction of a pixel, and I didn't realize it, until I manually checked each one. Either way, it's working now. Been sitting here, reading, and watching this guy bounce back and forth for a while now.

Common practice for platformers is to use a rectangular invisible helper sprite as your base object for collision purposes, and pin the visible texture/sprite to it. This helps to minimize many potential collision issues.

Great to know oosyrag. Thanks for sharing your knowledge :). That makes sense now that I sit and think about it. This is a game I made a few months back, and was just trying to grab video footage of it for something, when I noticed the glitch.

Just like you said at the end. My current projects I use a square base sprite, with another sprite objects with all the animations pinned to that base sprite for that player/enemy/whatever. So all my current projects, it hasn't been an issue. Definitely good design practice!

I'm learning a ton. Love this community. Thanks again everyone, for taking the time to explain this to me. I really appreciate it.

EDIT: The Vertical Scrolling SHMUP was an even easier fix. I had everything that moves down the screen under an "Every Tick". I just had to change that to "Every 0.016 seconds" to simulate the same speed at any refresh rate. Now I can just tweak the seconds value, to adjust the speed to where it won't be too easy or too difficult.