Java-Gaming.org    
Featured games (79)
games approved by the League of Dukes
Games in Showcase (477)
Games in Android Showcase (109)
games submitted by our members
Games in WIP (536)
games currently in development
News: Read the Java Gaming Resources, or peek at the official Java tutorials
 
    Home     Help   Search   Login   Register   
Pages: 1 [2] 3 4 5
  ignore  |  Print  
  Solving Stuttering With Fixed Timesteps, Once and For All  (Read 22288 times)
0 Members and 1 Guest are viewing this topic.
Offline Cero
« Reply #30 - Posted 2011-10-29 23:09:27 »

One more thing: almost nobody cares about running smoothly when running in a window. It's not how people play real games. Web toys, etc. - that's what people play in windows, with accordingly lower expectations.

Yeah I mentioned that - I thinks its true.
Although back then, I played like Fallout 3 windowed and World of Warcraft and stuff - to see MSN or whatever

Offline princec

JGO Kernel


Medals: 343
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #31 - Posted 2011-10-29 23:37:02 »

Any luck with that Sync class removing stutter?

Cas Smiley

Offline Cero
« Reply #32 - Posted 2011-10-29 23:57:41 »

Feels the same as Display.sync + Vsync, i do get 1 frame of stutter or something every 5 seconds or so

also, if I don't set Vsync to true, this Sync class doesnt stop it , and it goes to 600 FPS

Since Vsync in fact does not work on every machine - this is bad

Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline Saucer

Junior Member


Medals: 1



« Reply #33 - Posted 2011-10-29 23:59:14 »

but I heard it only works in fullscreen mode; is that true? In any case turning on VSync in windowed doesn't seem to improve the stuttering much (if at all).

Don't know the technicality, but like Cas said, Display.Display.setVSyncEnabled() really syncs very good.
It is definitely very noticeable and different even in window mode.

Well, it's not noticeable for me... Did you see anything faulty with the Slick2D example I posted, then?

Offline princec

JGO Kernel


Medals: 343
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #34 - Posted 2011-10-30 00:03:20 »

Feels the same as Display.sync + Vsync, i do get 1 frame of stutter or something every 5 seconds or so

also, if I don't set Vsync to true, this Sync class doesnt stop it , and it goes to 600 FPS

Since Vsync in fact does not work on every machine - this is bad
Whoops sorry I left a line out of it. I edited the code - have another go. Did you try with removing the Thread.yield() too?

Cas Smiley

Offline Saucer

Junior Member


Medals: 1



« Reply #35 - Posted 2011-10-30 00:09:33 »

Tried Cero's LWJGL example with and without princec's Sync class; still stuttered. Note, however, that that example uses variable timesteps; I still haven't tried a fixed timestep with interpolation.

Offline theagentd
« Reply #36 - Posted 2011-10-30 00:18:19 »

If you've got DWC turned off and running in a window, and vsync's on, the only thing left you can do is accurately sync to the hi-res timer. Unfortunately LWJGL's Display.sync() method somehow manages to do this wrongly if you need it to be dead accurate. Try this:
1  
2  
3  
4  
5  
6  
7  
8  
9  
10  
11  
12  
13  
14  
15  
16  
17  
18  
19  
20  
21  
22  
23  
24  
25  
26  
   public class Sync {
   
      private long timeThen;
     
      public Sync() {
         timeThen = Sys.getTime() & 0x7FFFFFFFFFFFFFFFL;
      }

      public void sync(int frameRate) {
         long timeNow = Sys.getTime() & 0x7FFFFFFFFFFFFFFFL;
         if (timeNow < timeThen) {
            // Account for clock wrapping
           timeThen = timeNow;
         }
         long timeNext = (timeThen + Sys.getTimerResolution() / frameRate) & 0x7FFFFFFFFFFFFFFFL;
         if (timeNext < timeNow) {
            // Just forget about it this frame, clock's wrapped
           return;
         }
         do {
            Thread.yield();
            timeNow = Sys.getTime() & 0x7FFFFFFFFFFFFFFFL;
         } while (timeNow < timeNext);
         timeThen = timeNext;
      }
   }

Remove the Thread.yield() for ultra-precise timing.

Cas Smiley
It will round the sleep time every frame, so it will sync to 63 FPS too. Same problem as the LWJGL Display.sync().

The stuttering that you see is due to two frames being submitted before a screen refresh can take place, meaning that one frame is lost. By having 63 FPS, you're dropping about every 20th frame. Result: visible but not "measurable" stuttering.

Why does this happen at 60FPS? Already explained that above, but here we go again. You have literally no control at all over when a frame is actually completed due to the command buffer, so there is no way to prevent the core cause of this problem. The command queue can potentially cause frames to be completed at irregular intervals, effectively affecting the chance a frame has to actually make it to the monitor before being overwritten by next one.

So even if you submit your commands perfectly synced to the screen refresh rate (exactly 60 commands per second) there is no guarantee that this will sync up with the screen refresh rate after going through the command buffer, the actual rendering process and then over to the screen. There are many things that can affect how long it takes for a frame to pass through all these stages.

 - The driver thread is obviously sleeping while you're filling the command buffer. It's affected by the same timing problems as our own Java threads.
 - Even if the driver is woken up at the exact same time, there might be other programs running that are using your CPU, causing commands to be delayed.
 - Even your graphics card is a shared medium. Everything that's drawn on your screen goes through your graphics card, so why expect it to process the commands of your program immediately? We're talking pretty heavy context switches, delays in sending the data to the graphics card, delays in rendering the data due to other load, e.t.c.

Now to the funniest part: Why do people expect their monitors to have billion dollar atomic watches built in to their monitors? It's not that your monitor has a more precise clock than your computer. Rather, on the contrary I'd expect a cheap monitor to have a pretty inaccurate clock, possible running too fast or too slow, or even having heavy jitter. To ensure that no frames are lost, you obviously shouldn't synchronize to the same values as your monitor tries to synchronize to. You should synchronize to the monitor itself, and and all the syncing flaws it comes with. I'd guess that a monitor might update at between 59.5 and 60.5 FPS, giving you a lost or duplicated frame every other second.

Why are you guys so sensitive to this? I mean, your TVs have refresh rates of 60FPS, but movies are stored in 23.976 FPS. How can your screen handle that. IT CAN'T. It simply shows the same frame for either 2 or 3 updates, to achieve somewhat smooth movement. I bet you didn't even know that, and have never been bothered by it.

Things that won't solve this kind of stuttering:
 - Better sleep precision than what we have right now.
 - Newer more advanced game loops and delta handling than those in the game loop thread.
 - Syncing everything perfectly to 60 Hertz.

If you try any of these, you're syncing on the wrong side of the graphics card.

There is no way of completely getting rid of this stuttering. It is simply put an inherent flaw of computers running more than one process and one thread, your graphics card having a command buffer, your graphics card being used by more than one thread at a time and your monitor being imperfect, plus lots of other things.

VSync helps though. Your computer tries to supply a single frame for each screen update. However, you can still "miss a train" and get a duplicated frame. The time it takes for a frame to go from rendering commands to being displayed on your monitor is so susceptible to factors beyond your control that you're sometimes bound to lose a frame or two no matter how good you sync your game loop.

Obviously I can see the stuttering in the bouncing box demo posted by Cero. The reason that it is so easy to see is because you're moving the box one pixel per update, making it easy to see when one pixel is skipped. In a game, how many things move at a constant 60 pixels/second speed? For your information, running this with a green box on a red background will produce glaringly obvious artifacts on some very expensive monitors due to how they work. They simply assume that nothing you draw on it is going to be moving at 1 pixel per update constantly with the colors red and green.

Another better solution is to just render at an as high FPS as possible. If you're rendering at 120 FPS and a two frames are overwritten instead of just 1, it will only be a half as big difference compared to if you were rendering at 60 FPS and dropped a frame. It's much less visible, try it with any somewhat decent sync code (Display.sync(), the Sync class posted above, e.t.c). The higher your FPS, the less visible your stutter is. If you want to get rid of tearing too (which gets worse with higher FPS), use triple buffering. Remember that VSync and triple buffering can be forced in your drivers, and it should kick in for OpenGL accelerated Java2D too.

So drop it. You can't fix this completely. I'm so sick of people whining about a pixel here and there. It's not like your game will get bad reviews for this kind of stuttering. Commercial games have the exact same problem. This is not in any way related to Java or your choice of operating system. It's quite simply the way it is.

In response to all the recent responses. Please stop. It's sad to watch.

Myomyomyo.
Offline princec

JGO Kernel


Medals: 343
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #37 - Posted 2011-10-30 00:19:10 »

Do not use interpolation. The only way you will get apparently smooth motion is a precisely fixed logic rate tied to a precisely fixed frame update rate.

If you get stuttering with vsync turned on, then the problem is not your code, nor LWJGL, but Windows.

Cas Smiley

Offline Cero
« Reply #38 - Posted 2011-10-30 00:20:24 »

Tried Cero's LWJGL example with and without princec's Sync class; still stuttered. Note, however, that that example uses variable timesteps; I still haven't tried a fixed timestep with interpolation.

Yea thats not really the issue right here. My game uses fixed timesteps aswell - hasn't really to do with the rendering - its only to compensate the logic if the game lags

Did you try with removing the Thread.yield() too?

Yeah, didn't seem to make any difference - I mean with Vsync enabled I have to scroll around for a number of seconds anyway to get one stutter, but I got one with this line removed too

Although - without Vsync, it is kinda bad. Stuttering a little every second

Offline princec

JGO Kernel


Medals: 343
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #39 - Posted 2011-10-30 00:25:17 »

@theagentd - not everyone uses LWJGL for games. The whole reason it came about in fact in the dim distant past is that I wrote a library to do television graphics output which needed graphics at a rock steady 60Hz. This I achieved; however, I rely on actual vsynced fullscreen displays, which is the only cast iron way to do it right. Also it turns out a surprising number of objects in 2D games run at very precise unchanging velocities and they look jarring to people used to the slick smooth professional feel of console graphics and anyone brought up on home computers in the 80s.

Sadly you're right about the Sync class I posted, it will creep out of sync due to rounding, which is what LWJGL attempts to fix in its Display.sync() but fails. I don't use this loop myself Smiley I instead use a method that counts time over a big number of frames, resetting every now and again. But again, this is only a backup, to ensure that the game doesn't race if vsync fails.

Cas Smiley

Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline theagentd
« Reply #40 - Posted 2011-10-30 00:26:09 »

Do not use interpolation. The only way you will get apparently smooth motion is a precisely fixed logic rate tied to a precisely fixed frame update rate.

If you get stuttering with vsync turned on, then the problem is not your code, nor LWJGL, but Windows.

Cas Smiley
...
I would definitely use interpolation for rendering things in my game that will use fixed 50FPS updating to allow frame rates over 50 FPS. If you do it right, there is no problem at all with interpolation. BUT IT WON'T SOLVE THE REAL PROBLEM FOR F*CKS SAKE.

And yes, if you get stuttering with VSync on AND you're measuring exactly 60 FPS per second, then yes, it's something you cannot affect. If you're getting less than 60 FPS for a game that runs at >80 FPS with VSync off, then it's your own fault for having some frames take drastically longer time to render than other frames.

Myomyomyo.
Offline theagentd
« Reply #41 - Posted 2011-10-30 00:28:38 »

@theagentd - not everyone uses LWJGL for games. The whole reason it came about in fact in the dim distant past is that I wrote a library to do television graphics output which needed graphics at a rock steady 60Hz. This I achieved; however, I rely on actual vsynced fullscreen displays, which is the only cast iron way to do it right. Also it turns out a surprising number of objects in 2D games run at very precise unchanging velocities and they look jarring to people used to the slick smooth professional feel of console graphics and anyone brought up on home computers in the 80s.

Sadly you're right about the Sync class I posted, it will creep out of sync due to rounding, which is what LWJGL attempts to fix in its Display.sync() but fails. I don't use this loop myself Smiley I instead use a method that counts time over a big number of frames, resetting every now and again. But again, this is only a backup, to ensure that the game doesn't race if vsync fails.

Cas Smiley
I'm not talking LWJGL. I'm talking about anything that goes through your graphics card.

Myomyomyo.
Offline princec

JGO Kernel


Medals: 343
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #42 - Posted 2011-10-30 00:36:33 »

Interpolation does not produce apparently smooth movement. The brain already predicts where something is going to be when it's supposed to be there, and when it doesn't appear there precisely on time, no amount of interpolation fixes it. So my advice is not to use interpolation positions but instead to get everything done at an unfailingly fixed rate and hope for the best.

Unless you're in fullscreen mode, you can't rely on vsync. But when you can rely on vsync, you're waiting on the correct side of the graphics card. You will get absolutely perfect 60hz displays with not a stutter in sight. That is what vsync is for. All that confusing stuff about command buffers and so on - no-one really needs to know! All devs need to know is: go fullscreen, turn vsync on, and that's the best you can do.

Cas Smiley

Offline ra4king

JGO Kernel


Medals: 342
Projects: 2
Exp: 5 years


I'm the King!


« Reply #43 - Posted 2011-10-30 00:39:06 »

Although most here are talking about syncing with LWJGL, the OP should be mainly concerned with Java2D until he gains enough experience.

@OP Does this game stutter for you? Is there any screen tearing?
Pressing 'X' will alternate between 60FPS and max FPS. I use a busy while loop that calls Thread.yield until the sleeping period is over. At both FPS's, I don't see any screen tearing on either good computers or slow computers.

Offline princec

JGO Kernel


Medals: 343
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #44 - Posted 2011-10-30 00:39:37 »

btw - it irritates me greatly that movie framerates don't match monitor framerates Smiley But then, coz I've been working in broadcast video engineering for quite a while, little things like this really grate and stand out for me. I can't even watch DVDs or normal TV without the MPEG artefacts irritating the hell out of me!

Cas Smiley

Offline princec

JGO Kernel


Medals: 343
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #45 - Posted 2011-10-30 00:41:05 »

Although most here are talking about syncing with LWJGL, the OP should be mainly concerned with Java2D until he gains enough experience.

@OP Does this game stutter for you? Is there any screen tearing?
Pressing 'X' will alternate between 60FPS and max FPS. I use a busy while loop that calls Thread.yield until the sleeping period is over. At both FPS's, I don't see any screen tearing on either good computers or slow computers.
Uh, I think you have sort of become confused by what causes tearing and what causes stuttering. On Vista or 7 you can't even get tearing in a windowed display as the compositor is already vsynced. The speed of a computer also has no relevance to tearing.

Cas Smiley

Offline ra4king

JGO Kernel


Medals: 342
Projects: 2
Exp: 5 years


I'm the King!


« Reply #46 - Posted 2011-10-30 00:42:20 »

Ah I meant computers having a single core and integrated graphics (like my school's computers Grin)
And I did not know that bit about the compositor already being vsynced in Windows 7, interesting!

Online Riven
« League of Dukes »

JGO Overlord


Medals: 757
Projects: 4
Exp: 16 years


Hand over your head.


« Reply #47 - Posted 2011-10-30 00:48:49 »

In response to all the recent responses. Please stop. It's sad to watch.
Thank you for your informative posts, but please drop the condescending attitude. When dealing with human beings, it doesn't matter whether you're right, it matters that you have the skills to convey your point of view.

Hi, appreciate more people! Σ ♥ = ¾
Learn how to award medals... and work your way up the social rankings
Offline theagentd
« Reply #48 - Posted 2011-10-30 00:53:17 »

Interpolation does not produce apparently smooth movement. The brain already predicts where something is going to be when it's supposed to be there, and when it doesn't appear there precisely on time, no amount of interpolation fixes it. So my advice is not to use interpolation positions but instead to get everything done at an unfailingly fixed rate and hope for the best.

Unless you're in fullscreen mode, you can't rely on vsync. But when you can rely on vsync, you're waiting on the correct side of the graphics card. You will get absolutely perfect 60hz displays with not a stutter in sight. That is what vsync is for. All that confusing stuff about command buffers and so on - no-one really needs to know! All devs need to know is: go fullscreen, turn vsync on, and that's the best you can do.

Cas Smiley
I don't really agree with you about interpolation, but lets drop it before it gets out of hand. And no, the primary reason for VSync to exist is to prevent tearing, which it does to 100%. With VSync, you will still get occasional stuttering if you get 65-70 FPS without VSync. Even though the game should be able to always produce 60 FPS, with just a margin of 5 FPS you're pretty sensitive to external factors, which may cause you to miss some trains. Jesus, I'm gonna be called Trainman soon.
Although most here are talking about syncing with LWJGL, the OP should be mainly concerned with Java2D until he gains enough experience.

@OP Does this game stutter for you? Is there any screen tearing?
Pressing 'X' will alternate between 60FPS and max FPS. I use a busy while loop that calls Thread.yield until the sleeping period is over. At both FPS's, I don't see any screen tearing on either good computers or slow computers.
Sorry if I'm jumping in here, but I can't see any stuttering at all here due to the irregular movement. What I can see however is rounding errors. You jump higher when you have 1.5k FPS.

btw - it irritates me greatly that movie framerates don't match monitor framerates Smiley But then, coz I've been working in broadcast video engineering for quite a while, little things like this really grate and stand out for me. I can't even watch DVDs or normal TV without the MPEG artefacts irritating the hell out of me!

Cas Smiley
24 FPS videos irritate me too, because have way too low frame rate. I can't see any stuttering between these frames though. You do realize that the stuttering is about a lot more subtle compared to what you get in the bouncing box demo, right? If you can see that stuttering, I feel sorry for you.

EDIT:
In response to all the recent responses. Please stop. It's sad to watch.
Thank you for your informative posts, but please drop the condescending attitude. When dealing with human beings, it doesn't matter whether you're right, it matters that you have the skills to convey your point of view.
I tried to convey it, both with long explanations and with shorter statements. Sorry for that last post though, I'm getting tired (as in sleepy).

Myomyomyo.
Offline Saucer

Junior Member


Medals: 1



« Reply #49 - Posted 2011-10-30 01:10:32 »

Why are you guys so sensitive to this? I mean, your TVs have refresh rates of 60FPS, but movies are stored in 23.976 FPS. How can your screen handle that. IT CAN'T. It simply shows the same frame for either 2 or 3 updates, to achieve somewhat smooth movement. I bet you didn't even know that, and have never been bothered by it.

Things that won't solve this kind of stuttering:
 - Better sleep precision than what we have right now.
 - Newer more advanced game loops and delta handling than those in the game loop thread.
 - Syncing everything perfectly to 60 Hertz.

If you try any of these, you're syncing on the wrong side of the graphics card.

There is no way of completely getting rid of this stuttering. It is simply put an inherent flaw of computers running more than one process and one thread, your graphics card having a command buffer, your graphics card being used by more than one thread at a time and your monitor being imperfect, plus lots of other things.

For all I know, this may be the case; but, if so, and it really does only matter on the hardware, then there's still the ever-present question: Why are Game Maker games fine?

Although most here are talking about syncing with LWJGL, the OP should be mainly concerned with Java2D until he gains enough experience.

@OP Does this game stutter for you? Is there any screen tearing?
Pressing 'X' will alternate between 60FPS and max FPS. I use a busy while loop that calls Thread.yield until the sleeping period is over. At both FPS's, I don't see any screen tearing on either good computers or slow computers.

I can't currently test this right now, but if I remember correctly I didn't see any stuttering. However, it was a little difficult to be sure if there was or wasn't any stuttering/tearing. This is because (again, if I remember correctly) the gameplay is pretty fast, it's all vertical movement, and the movement isn't at constant speed, and all of those factors make it harder to see if there is or isn't stuttering.

EDIT: ra4king, perhaps you could make one of those sprites-moving-side-to-side examples with your method? Also, could you perhaps post your game loop and rendering code?

Offline Mads

JGO Ninja


Medals: 26
Projects: 3
Exp: 6 years


One for all!


« Reply #50 - Posted 2011-10-30 01:13:30 »

@Cero - do you get stutter with any of our games?

Cas Smiley

I own all of them, and I did not.

Offline theagentd
« Reply #51 - Posted 2011-10-30 01:18:31 »

Why are you guys so sensitive to this? I mean, your TVs have refresh rates of 60FPS, but movies are stored in 23.976 FPS. How can your screen handle that. IT CAN'T. It simply shows the same frame for either 2 or 3 updates, to achieve somewhat smooth movement. I bet you didn't even know that, and have never been bothered by it.

Things that won't solve this kind of stuttering:
 - Better sleep precision than what we have right now.
 - Newer more advanced game loops and delta handling than those in the game loop thread.
 - Syncing everything perfectly to 60 Hertz.

If you try any of these, you're syncing on the wrong side of the graphics card.

There is no way of completely getting rid of this stuttering. It is simply put an inherent flaw of computers running more than one process and one thread, your graphics card having a command buffer, your graphics card being used by more than one thread at a time and your monitor being imperfect, plus lots of other things.

For all I know, this may be the case; but, if so, and it really does only matter on the hardware, then there's still the ever-present question: Why are Game Maker games fine?

Although most here are talking about syncing with LWJGL, the OP should be mainly concerned with Java2D until he gains enough experience.

@OP Does this game stutter for you? Is there any screen tearing?
Pressing 'X' will alternate between 60FPS and max FPS. I use a busy while loop that calls Thread.yield until the sleeping period is over. At both FPS's, I don't see any screen tearing on either good computers or slow computers.

I can't currently test this right now, but if I remember correctly I didn't see any stuttering. However, it was a little difficult to be sure if there was or wasn't any stuttering/tearing. This is because (again, if I remember correctly) the gameplay is pretty fast, it's all vertical movement, and the movement isn't at constant speed, and all of those factors make it harder to see if there is or isn't stuttering.

EDIT: ra4king, perhaps you could make one of those sprites-moving-side-to-side examples with your method? Also, could you perhaps post your game loop and rendering code?
Care to drop a link or create a program that is exactly the same to this one but made in Game Maker?

Myomyomyo.
Offline Saucer

Junior Member


Medals: 1



« Reply #52 - Posted 2011-10-30 01:54:03 »

Care to drop a link or create a program that is exactly the same to this one but made in Game Maker?

Like this?

http://www.box.net/shared/6crbm32djhs3627lt93k

Note that I don't know exactly how Game Maker works internally, but it seems like it employs a fixed timestep.

This example actually DOES stutter on my laptop... ha ha. But I had already observed a little bit of that going on; I have yet to test it on our desktop, on which the differences seem to be most apparent between GM and Java. Specifically, on my desktop GM seems to run more smoothly than on my laptop, and Java seems to run less smoothly. I'll try to report on that later.

Offline jonjava
« Reply #53 - Posted 2011-10-30 02:08:28 »

Quote
timeThen = Sys.getTime() & 0x7FFFFFFFFFFFFFFFL;

Swifly off-topic, what the hell is this? What does that '&' do? I know that 0x**** is hexadecimal, or at least afaik. But wth is that &? And how does it work? o.O

Why are you guys so sensitive to this? I mean, your TVs have refresh rates of 60FPS, but movies are stored in 23.976 FPS. How can your screen handle that. IT CAN'T. It simply shows the same frame for either 2 or 3 updates, to achieve somewhat smooth movement. I bet you didn't even know that, and have never been bothered by it.

Risking sounding like an idiot, does this mean that if you settle for and intentionally update your game every 50 seconds, ie less than your screen refresh rate (which is usually 60hz), you would get smooth frame transitions like in films? And if not, why not? Short dummy explanation please:)

[size=8pt]Also interesting note, Peter Jackson is filming his new movie in double the fps ie 48fps. The day when movies will run in higher fps, rather than increased pixels, is coming!:)[/size]

Another point @theagentd, I never experienced stuttering in my Super mario games on my SNES - why shouldn't Java be capable of doing the same? Is there a reason it doesn't, or did my SNES games actually DO stutter and I've simply not noticed it?

Offline jonjava
« Reply #54 - Posted 2011-10-30 02:16:47 »

@OP Does this game stutter for you? Is there any screen tearing?
Pressing 'X' will alternate between 60FPS and max FPS. I use a busy while loop that calls Thread.yield until the sleeping period is over. At both FPS's, I don't see any screen tearing on either good computers or slow computers.

On my laptop I get greatly visible stuttering. When I press X however, it's really smooth.

Offline Cero
« Reply #55 - Posted 2011-10-30 02:20:48 »

Another point @theagentd, I never experienced stuttering in my Super mario games on my SNES - why shouldn't Java be capable of doing the same? Is there a reason it doesn't, or did my SNES games actually DO stutter and I've simply not noticed it?

Basically: PC Game Programming and Console Programming are very different things. When programming for a console you know the exact hardware and it will be the same hardware every time - this allows you to write very low level code that works perfectly with this hardware - but not at all with other hardware.

Which is why I would rather program console games ;D

John Carmack said this even about Rage, that it was easier to get Rage running at 60 fps on the consoles than it was on the PC, because of the way ID Tech 5 and especially Mega texture uses the memory, and that pc drivers for memory and video card are written so that they work with many different things - which doesnt allow, what he always calls "aggressive high performance operations" - because of too much driver overhead

Offline Saucer

Junior Member


Medals: 1



« Reply #56 - Posted 2011-10-30 02:38:13 »

Care to drop a link or create a program that is exactly the same to this one but made in Game Maker?

Like this?

http://www.box.net/shared/6crbm32djhs3627lt93k

Note that I don't know exactly how Game Maker works internally, but it seems like it employs a fixed timestep.

This example actually DOES stutter on my laptop... ha ha. But I had already observed a little bit of that going on; I have yet to test it on our desktop, on which the differences seem to be most apparent between GM and Java. Specifically, on my desktop GM seems to run more smoothly than on my laptop, and Java seems to run less smoothly. I'll try to report on that later.

So I tested this on my desktop and there is some stuttering, but I *think* it happens less often than with Java. When it does happen in the Game Maker example, it seems to be a slightly different sort of stuttering; it's more... "minuscule"? And the stuttering in Java is more "jarring." Also, it seems that my Java programs have a harder time maintaining an (reported) FPS of 60 (that is, on my desktop; on my laptop 60 FPS is usually maintained, I think).

Has anyone else tested the GM example?

Another point @theagentd, I never experienced stuttering in my Super mario games on my SNES - why shouldn't Java be capable of doing the same? Is there a reason it doesn't, or did my SNES games actually DO stutter and I've simply not noticed it?

Basically: PC Game Programming and Console Programming are very different things. When programming for a console you know the exact hardware and it will be the same hardware every time - this allows you to write very low level code that works perfectly with this hardware - but not at all with other hardware.

Which is why I would rather program console games Grin

John Carmack said this even about Rage, that it was easier to get Rage running at 60 fps on the consoles than it was on the PC, because of the way ID Tech 5 and especially Mega texture uses the memory, and that pc drivers for memory and video card are written so that they work with many different things - which doesnt allow, what he always calls "aggressive high performance operations" - because of too much driver overhead

By the way, I'm totally going for an SNES/GBA sort of feel with the stuff I want to make. I can understand that the programming would be different between consoles and PC, though. I wonder if Nintendo will ever support indie games.

Offline jonjava
« Reply #57 - Posted 2011-10-30 02:40:56 »

Like this?

http://www.box.net/shared/6crbm32djhs3627lt93k

Note that I don't know exactly how Game Maker works internally, but it seems like it employs a fixed timestep.

I exp lots of stutter of the slow moving characters, I think this is because of rounding errors and could easily be fixed by enabling interpolation in GM. (In Game Options inside GM)

The high speed ones, ( like the one at the bottom ) is really smooth. However, I do believe, by careful examination, that it experienced stuttering as well. But very little compared to the two Java versions you posted (on the TIG forum). Using double buffering on your Java programs, however, reduced the stuttering phenomenally ( as you would expect ) and I would argue that the GM game and your Java examples with Double buffering produce the same quality of stuttering.

This was all tested on my laptop (notebook really).

Also I'm certain GM uses fixed timesteps. At least GM7 and anything prior did. Therefore GM8 probably does too.

Offline Saucer

Junior Member


Medals: 1



« Reply #58 - Posted 2011-10-30 02:43:17 »

Like this?

http://www.box.net/shared/6crbm32djhs3627lt93k

Note that I don't know exactly how Game Maker works internally, but it seems like it employs a fixed timestep.

I exp lots of stutter of the slow moving characters, I think this is because of rounding errors and could easily be fixed by enabling interpolation in GM. (In Game Options inside GM)

The high speed ones, ( like the one at the bottom ) is really smooth. However, I do believe, by careful examination, that it experienced stuttering as well. But very little compared to the two Java versions you posted (on the TIG forum). Using double buffering on your Java programs, however, reduced the stuttering phenomenally ( as you would expect ) and I would argue that the GM game and your Java examples with Double buffering produce the same quality of stuttering.

This was all tested on my laptop (notebook really).

Also I'm certain GM uses fixed timesteps. At least GM7 and anything prior did. Therefore GM8 probably does too.

Thank you for your feedback. You say "using double buffering"... Isn't that something that the programmer uses? Like, with the BufferStrategy class? Game Maker and my Java programs all should be implementing double buffering whether the player likes it or not...

Offline jonjava
« Reply #59 - Posted 2011-10-30 02:49:59 »

Thank you for your feedback. You say "using double buffering"... Isn't that something that the programmer uses? Like, with the BufferStrategy class? Game Maker and my Java programs all should be implementing double buffering whether the player likes it or not...

That's true. However, in the two examples you posted on the TIG forum you let the user choose, before the application launches, if he wants to use Double buffering or not...  right? o.O


Pages: 1 [2] 3 4 5
  ignore  |  Print  
 
 
You cannot reply to this message, because it is very, very old.

 

Add your game by posting it in the WIP section,
or publish it in Showcase.

The first screenshot will be displayed as a thumbnail.

CogWheelz (18 views)
2014-07-30 21:08:39

Riven (26 views)
2014-07-29 18:09:19

Riven (15 views)
2014-07-29 18:08:52

Dwinin (13 views)
2014-07-29 10:59:34

E.R. Fleming (34 views)
2014-07-29 03:07:13

E.R. Fleming (12 views)
2014-07-29 03:06:25

pw (43 views)
2014-07-24 01:59:36

Riven (44 views)
2014-07-23 21:16:32

Riven (30 views)
2014-07-23 21:07:15

Riven (31 views)
2014-07-23 20:56:16
List of Learning Resources
by SilverTiger
2014-07-31 18:29:50

List of Learning Resources
by SilverTiger
2014-07-31 18:26:06

List of Learning Resources
by SilverTiger
2014-07-31 13:54:12

HotSpot Options
by dleskov
2014-07-08 03:59:08

Java and Game Development Tutorials
by SwordsMiner
2014-06-14 00:58:24

Java and Game Development Tutorials
by SwordsMiner
2014-06-14 00:47:22

How do I start Java Game Development?
by ra4king
2014-05-17 11:13:37

HotSpot Options
by Roquen
2014-05-15 09:59:54
java-gaming.org is not responsible for the content posted by its members, including references to external websites, and other references that may or may not have a relation with our primarily gaming and game production oriented community. inquiries and complaints can be sent via email to the info‑account of the company managing the website of java‑gaming.org
Powered by MySQL Powered by PHP Powered by SMF 1.1.18 | SMF © 2013, Simple Machines | Managed by Enhanced Four Valid XHTML 1.0! Valid CSS!