brainwavecreations's Forum Posts

  • Hey Hey. Are you running version r276, the latest stable release?

    There is an example called "Foggy Outbreak". Just search "foggy" on the start page and it will come right up. You might find checking out the Event Sheet in the example helpful.

    It basically "Requests pointer lock", if the mouse does not have "pointer lock" yet, and that Action is within an "On any click" Event using the Mouse Object.

    As far as, placing a sprite/object at the center of the screen within the 3D Game. Take a look at the "GunOverlay" group within the Event Sheet in that example to get a general idea on where to begin with that aspect.

    The built in examples of Construct are extremely helpful. You can learn a lot just by deconstructing the Event Sheets within them, and figuring out how different game mechanics have been created in the examples provided.

  • Thank you so much for all of your help and insight oosyrag, and thanks again for your knowledge Ashley, and calminthenight!

    I had tested the enemy.y+(7*dt*60) the other day, but it had broken everything. The problem was... I was missing the parenthesis around the "x*dt*60". I just tested it real quick at multiple refresh rates, and it works perfectly now.

    I really appreciate the deeper insight into "Every X Seconds" as well. I'm making a mental note of everything in this thread, for all my current and future projects. So I can design them properly for any refresh rate.

    With all of that I think this issue is now solved. I'll work on redoing my Event Sheet to take dt into account asap. For now, I'm off to get some rest.

    Thanks again everyone. All the help, and deeper knowledge is much appreciated :)

  • Thanks for your response, as always oosyrag. I really appreciate the support. I'm more concerned about people playing a commercial game on various mobile devices, and it not playing the same on every device. I'm still a bit confused on how accomplish incorporating delta time in all my Events, and Actions. This is what my Every Tick Group currently looks like: https://i.ibb.co/Fqt0XrW/everytick.png

    What I just tested, was changing it up to something like Set position to Enemy1.X, Enemy1.Y+900*dt for that first enemy, and it feels right about the speed I'd like it to be at. Does that seem like a proper way to go about it?

    EDIT & SIDE NOTE: So the "Every X seconds" condition is not ideal for times below 1 second, but should be okay to utilize for Events that run every 1 or more seconds? If not, I'm going to have to rethink this entire Event Sheet.

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

    I would advise against doing that - very small times in 'Every X seconds' can still actually be framerate-dependent, as noted in the manual. For example if the game dips to 30 FPS on a slower machine, "Every 0.016 seconds" will actually be running every 0.033 seconds, and hence the game slows down in a framerate-dependent way. Also at higher framerates like 120 FPS, you'll have a janky appearance from moving things at a lower framerate than the game is actually rendering at.

    The correct solution is, as before, to use dt. There is probably some movement happening in "Every tick" that isn't using dt and ought to be using it.

    Thanks for the heads up. I've been sick, and fighting something the past few days(all signs of Covid, but can't get a test anywhere...). Was laid up on the couch yesterday, just seeing your post tonight.

    Is there any simple way to check "dt" for an entire event? Or is it done in each action within the event? Everything I did the other day to move the objects based on delta time broke everything.

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

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

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

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

  • Thanks for all the suggestions, calminthenight, and Ashley. I'm going to take a look into this today. I'll test out the bullet behavior, and see how that works for the SHMUP.

    I'll read through the tutorial linked to as well. The strange thing is, Ashley. Everything seems reliable at 60hz, and 120hz. Once I step up into 185hz, is when things start getting wonky. I have not tested all the frame rates in between, but it might be an interesting test to see how things respond. That game with the enemy glitching through a collision at 185hz is a platformer, and is using entirely built in behaviors.

    Yesterday I tested setting the framerate mode to unlimited, and it yielded the same results with my display running at 185hz.

  • Try Construct 3

    Develop games in your browser. Powerful, performant & highly capable.

    Try Now Construct 3 users don't see these ads

  • 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

  • Would multiplying everything by Delta Time do the trick?

  • Is there anyway to limit the refresh rate within a Construct 3 Game? I was just making a video of a game I made a couple months back, and events in the game were bugging out. After a while of tweaking different things within the game, I realized it must be something else causing the issues.

    The only other thing I could think of, was that a few weeks ago I upped the refresh rate on both of my displays to their full 185hz potential in the Windows Display Settings. They had been set to 60hz previously. So I went back in there, and changed them back to 60hz. Now everything is running fine within the game.

    With the displays set to 185hz, the player & enemy movements all felt exactly the same. But the enemies were glitching through invisible objects(tried widening these to no luck), that reverse their movement and image direction. I figure with the higher refresh rate, the event must be running multiple times, and allowing the enemies through the object. I tried running the event under "Trigger Once While True", and still glitches out with the displays at 185hz.

    I'm getting ready to submit a mobile game to the Play Store, and while testing the game on my Galaxy s21, I noticed everything is running much faster. Due to the phone's display running at a 120hz refresh rate.

    So. Is there anyway to cap the refresh rate of a project to 60hz? I've looked through the Project Settings, and the Construct 3 documentation. But, I'm failing to find anything that would allow this. Any help is appreciated.

    Thank You :)

  • > The easiest method would be to create an image point below the Oil Rig sprite in the Sprite Editor. Then spawn the text on that image point.

    Thank you! This is what I was looking for.

    Haha, sure thing. Happy to help :)

  • The easiest method would be to create an image point below the Oil Rig sprite in the Sprite Editor. Then spawn the text on that image point.

  • > The steps outlined above, are if you want the health bar to float above or overlapping the player sprite(Depending on the image point of the sprite). If you simply want it on the top "GUI" layer, and stationary in one position. It should work, the way your first post mentioned.

    I don't want the health bar to stick on top corner of the interface, I just want it to stick on top of a player when the player is moving to any place

    Alrighty. So the steps that KryptoPixel laid out would be perfect for this instance. You can adjust the image point on the health bar, or make another image point on the player character to pin it to. Then make adjustments to that point's orientation in the sprite editor, to position it in relation to your player, where you would like it to be :)