game speed.

[ARTgames]

Jake, do you have such a system in your game? Or does your game run nativity at 60 fps? just wondering.

[Jake]

Jake, do you have such a system in your game? Or does your game run nativity at 60 fps? just wondering.

It runs at 30 fps, but I'm looking into frame rate compensation techniques.

[Aqua]

The only good thing about 60 fps is that the collision checking is more accurate. Bad things are that GM games with more than 1 object tend to lag at 60fps for many PCs, and you have to go back and edit EVERYTHING to go twice as slow so that the balance is restored. Things don't necessarily need to be updated more... just less often quicker. But I've done this before, with a much smaller game, and changing all the variables to be scaled up 2x is a PAIN.
~Aqua

[ARTgames]

The only good thing about 60 fps is that the collision checking is more accurate.
~Aqua

Those two things are irrelevant to each other. A normal collision checking accuracy is independent from frame rate.

Bad things are that GM games with more than 1 object tend to lag at 60fps for many PCs,

To what proof or study have done to back this up? I would like to see it. I and other gm games with my standard hardware work just fine.

Things don't necessarily need to be updated more... just less often quicker. But I've done this before, with a much smaller game, and changing all the variables to be scaled up 2x is a PAIN.

What?

@Jake
Cool! I would like to see what you can do looking at your past work.

[Aqua]

The only good thing about 60 fps is that the collision checking is more accurate.
~Aqua

Those two things are irrelevant to each other. A normal collision checking accuracy is independent from frame rate.

They are relevant. In a 30fps game, to have something move 2 inches in 1 second with 72DPI, you have to go 4.8 pixels per step. If your object is a 1x1 pixel, it will skip over 3-5 other pixels in each step. However, in a 60 fps game, if you keep the rate at 2 inches in 1 second, you're only going at 2.4 pixels per step; and in the same situation you're skipping half the amount of pixels, thus increasing the accuracy of collision checking.

Bad things are that GM games with more than 1 object tend to lag at 60fps for many PCs,

To what proof or study have done to back this up? I would like to see it. I and other gm games with my standard hardware work just fine.

Unfortunately I lost that game, but it was my version of Spore to keep me busy until the real one was released. However, I posted it on a community, and many people had issues when I changed the fps from 30 to 60. I will try to find the link in that community, and will edit with my findings.

Edit: The two people who played the update both had lag. http://www.xspore.com/community/spore-games/3339-gm-spore-actual-spore-game-2.html
~Aqua

[Meiun]

The only good thing about 60 fps is that the collision checking is more accurate.
~Aqua

Those two things are irrelevant to each other. A normal collision checking accuracy is independent from frame rate.

They are relevant. In a 30fps game, to have something move 2 inches in 1 second with 72DPI, you have to go 4.8 pixels per step. If your object is a 1x1 pixel, it will skip over 3-5 other pixels in each step. However, in a 60 fps game, if you keep the rate at 2 inches in 1 second, you're only going at 2.4 pixels per step; and in the same situation you're skipping half the amount of pixels, thus increasing the accuracy of collision checking.

That really isn't neccesarily true. It is based entirely on how you code your collision and movement engine. A system can easily be programmed to avoid this issue if desired.

[Aqua]

Well yeah, but I prefer not to. The way I'm thinking of is checking collision_line() between x,y and xprevious, yprevious. But this doesn't allow for precise collision checking with the actual sprite. What were you thinking of?

Offtopic- I saw your public picture for your profile on Facebook- I hope that's outdated ;)
~Aqua

[ARTgames]

The only good thing about 60 fps is that the collision checking is more accurate.
~Aqua

Those two things are irrelevant to each other. A normal collision checking accuracy is independent from frame rate.

They are relevant. In a 30fps game, to have something move 2 inches in 1 second with 72DPI, you have to go 4.8 pixels per step. If your object is a 1x1 pixel, it will skip over 3-5 other pixels in each step. However, in a 60 fps game, if you keep the rate at 2 inches in 1 second, you're only going at 2.4 pixels per step; and in the same situation you're skipping half the amount of pixels, thus increasing the accuracy of collision checking.

Why are you doing that? >_< You know all you need to do is check the amount its going to move. Your going to move five pixels to the left from your object check 5 pixels to the left. Don't check one pixel/spot/etc ever step/frame/loop/etc. I could make you something to show but i feel you might understand now. Don't make it harder for your self.

Edit: The two people who played the update both had lag. http://www.xspore.com/community/spore-games/3339-gm-spore-actual-spore-game-2.html
~Aqua

That is not sufficient. That was only a sample of 2 people with unknown hardware. And we don't even know if the problem was fps related.

@Meiun
Thank you.

[Meiun]

Offtopic- I saw your public picture for your profile on Facebook- I hope that's outdated ;)
~Aqua

A bit. Never been a big facebook user. But regardless, screw you. Last thing I need is a bunch of !@#$ing teenagers critiquing my facebook, honestly.

[Jake]

The only good thing about 60 fps is that the collision checking is more accurate. Bad things are that GM games with more than 1 object tend to lag at 60fps for many PCs, and you have to go back and edit EVERYTHING to go twice as slow so that the balance is restored. Things don't necessarily need to be updated more... just less often quicker. But I've done this before, with a much smaller game, and changing all the variables to be scaled up 2x is a PAIN.
~Aqua

Sorry, but you're way off the mark. Running a game at 60 fps has more upsides to it than "collision checking is more accurate". Whether or not you think the upsides outweigh the downsides is whats important. Also, your complaints about changing game code to accommodate the higher frame rate are only valid if the game was originally programmed with 30 fps in mind. The argument could go either way depending on what the developer originally coded the frame rate around. "30 fps suckz cuz you have to speed up da objects" is the same argument as yours but it takes the opposite stance. If you're replying in regards to Stick Online, then you might want to make that more apparent.

I also wanted to point out that having your collision checking rely on the exact frame rate of the game shows bad programming methods. Doing so does not account for frame rate dips, and generally shows a lack of effort in the game design.

[Meiun]

I also wanted to point out that having your collision checking rely on the exact frame rate of the game shows bad programming methods. Doing so does not account for frame rate dips, and generally shows a lack of effort in the game design.

I second that.

Well yeah, but I prefer not to. The way I'm thinking of is checking collision_line() between x,y and xprevious, yprevious.

Well, my current collision system is coded 100% from scratch, using no built in GM functions or even "collision events," so yeah.

[Mr Pwnage]

Well yeah, but I prefer not to. The way I'm thinking of is checking collision_line() between x,y and xprevious, yprevious.

Well, my current collision system is coded 100% from scratch, using no built in GM functions or even "collision events," so yeah.

Good thing too...because I can say from experience that GM collisions are absolutely horrible. I was making one game, and had to tweak with the gravity: Pretty much, when the object hit the ground after falling it was supposed to stay there and become a platform, but it actually only did that 80% of the time and the other 20% it deleted itself. Lowering the gravity fixed this (well didn't fix, but made it happen a lot less)...just an example of how buggy GM collisions are. Inconsistencies in a code which SHOULD be providing a consistent result.

[Meiun]

Well yeah, but I prefer not to. The way I'm thinking of is checking collision_line() between x,y and xprevious, yprevious.

Well, my current collision system is coded 100% from scratch, using no built in GM functions or even "collision events," so yeah.

Good thing too...because I can say from experience that GM collisions are absolutely horrible. I was making one game, and had to tweak with the gravity: Pretty much, when the object hit the ground after falling it was supposed to stay there and become a platform, but it actually only did that 80% of the time and the other 20% it deleted itself. Lowering the gravity fixed this...just an example of how buggy GM collisions are.

Well thats almost always just because the person isn't very good with GM (no offense). Also, were you using "drag and drop" vs actual coding? (even then same thing applies to some extent). The current stick online has a sortof mix of my own coding with built in GM functions (functions, not D&D) but still obviously works fine. Long story short, it's usually the coder not the code ;] The built in collision stuff may not be perfect for every scenario or work exactly how some people like best, but it definitly does "work".

Anyways, I think we are starting to shift a bit off topic here.

[Jake]

Although Game Maker has somewhat limiting built-in functions, I've never known them to be buggy. Perhaps increasing the gravity too much caused the object to bypass the platform entirely? Make sure your collision checking code accounts for the speed of the moving object. I would need to see the code to tell you exactly what's happening though.

Woops, sorry for getting so off-topic.

[Mr Pwnage]

Well it wasn't with D&D...and it was years ago when I made it, so I don't know that I could resurrect a code for you. Either way, I can't assure you my programming skills were all that great at the time, but I can say that GM collisions are very limiting, sometimes buggy, and have enough flaws that I prefer to use DLLs for coding collisions. Just my preference though.