Java-Gaming.org Hi !
Featured games (83)
games approved by the League of Dukes
Games in Showcase (513)
Games in Android Showcase (121)
games submitted by our members
Games in WIP (577)
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
  ignore  |  Print  
  Mac VS. PC  (Read 3399 times)
0 Members and 1 Guest are viewing this topic.
Offline MacOLauncher

Junior Newbie





« Posted 2012-10-18 06:46:54 »

Okay I have a simple question that's been bugging me for a while. I'm new to java game development and I made a simple game on a PC. All it does is you control a little ship and move around shooting the alien ships.

When I compiled on PC it worked just as expected, but when I ran the jar file on my Mac, everything in the game was happening a lot faster!

One day when I make a full-blown real game, I would like it to be able to run the same on both Mac & PC. So my question is, is there any way to have it run the same? Maybe detect what OS its running on and change the code accordingly? Any help would be appreciated. Thanks Smiley

- Mac



EDIT:
So what I've learned from ya'll:

1.
Quote
The mac is giving a better performance then your windows.

2. I could either use Delta or Fixed Rate.

3. princec(Cas) makes
Quote
hundreds of thousands of dollars! xD

4.
Quote
Delta - complex (just try doing collision detection properly, go on), mercy of floating point, jerky movement. Absolutely horrible for 2D, in any form.
Fixed rate - easy, can use integers all over the place, glassy smooth movement, perfect for 2D.

5.
Quote
The basic idea is to link your game to real time, not computer execution speed.

Thanks very much for all your help Smiley
P.S. Any Code examples on how to actually do this would come in handy xD

- Mac
Offline Phased
« Reply #1 - Posted 2012-10-18 06:49:25 »

The mac is giving a better performance then your windows, you can fix this by using delta, which you will pass to your update methods, and it will use it to update the game at pretty much the same speed no matter how good your computer is.

edit:
Delta is a variable that changes every time, and will become bigger the slower the computer is going, this means when your doing your movement speed you will need to use a double, something like 0.25 or so as the movement speed, and when your adding to x it will be like

speed = 0.25

x += speed * delta
Offline princec

JGO Kernel


Medals: 409
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #2 - Posted 2012-10-18 08:45:01 »

Why does everyone insist on using delta for logic  Emo It's far far harder to get your head around than fixed-rate logic.

Cas Smiley

Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Online Riven
« League of Dukes »

JGO Overlord


Medals: 818
Projects: 4
Exp: 16 years


Hand over your head.


« Reply #3 - Posted 2012-10-18 08:53:18 »

Another disadvantage of delta for logic is that it results in non-deterministic code.

With a fixed rate, you'll be able to consistently reproduce state (or well: bugs) with every run of your code.

Hi, appreciate more people! Σ ♥ = ¾
Learn how to award medals... and work your way up the social rankings
Offline badlogicgames
« Reply #4 - Posted 2012-10-18 09:33:44 »

For fixed time steps you have to compensate by interpolating whatever "overhang" you have (e.g 14ms passed, your timestep is 10ms, what do you do with the other 4ms?). This can get rather involved. Delta time doesn't need that.

I prefer fixed time steps plus interpolation myself exactly for the fact that it makes games deterministic as Cas and Riven said.

http://www.badlogicgames.com - musings on Android and Java game development
Offline R.D.

Senior Duke


Medals: 2
Projects: 1


"For the last time, Hats ARE Awesome"


« Reply #5 - Posted 2012-10-18 09:49:42 »

I usally smooth out my deltas too by just calclulating the average delta. This gives constant deltas and thus deterministic results.
Offline Orangy Tang

JGO Kernel


Medals: 56
Projects: 11


Monkey for a head


« Reply #6 - Posted 2012-10-18 11:01:24 »

I usally smooth out my deltas too by just calclulating the average delta. This gives constant deltas and thus deterministic results.

Huh? The deltas are still going to differ between machines and runs, so you won't get deterministic results.

Unless you meant something else by averaging the delta?

[ TriangularPixels.com - Play Growth Spurt, Rescue Squad and Snowman Village ] [ Rebirth - game resource library ]
Offline princec

JGO Kernel


Medals: 409
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #7 - Posted 2012-10-18 12:05:01 »

I loves me a good delta vs fixed rate discussion! Here is my wisdom:

Delta - complex (just try doing collision detection properly, go on), mercy of floating point, jerky movement. Absolutely horrible for 2D, in any form.
Fixed rate - easy, can use integers all over the place, glassy smooth movement, perfect for 2D.

I make 2D games in Java, that make hundreds of thousands of dollars! But don't listen to me, because I don't want the competition.

Cas Smiley

Offline ReBirth
« Reply #8 - Posted 2012-10-18 12:11:34 »

..., because I don't want the competition.

Cas Smiley
That's why you didn't put up code as example Pointing

Offline princec

JGO Kernel


Medals: 409
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #9 - Posted 2012-10-18 12:14:44 »

A more careful look at my code will reveal numerous bugs and gotchas that will have you wasting loads of time trying to figure out what it's doing only to discover it's just broken Smiley My code is a deadly trap. I leave it here as a warning to others.

Cas Smiley

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

JGO Coder


Medals: 13
Projects: 1


Follower of Nurgle


« Reply #10 - Posted 2012-10-18 12:34:37 »

My code is a deadly trap. I leave it here as a warning to others.

Now I'm scared  persecutioncomplex

EDIT: Are you saying that instead of using delta-time I should just pin the frame-rate to a constant 60FPS and dont use delta-time at all?
Offline Cero
« Reply #11 - Posted 2012-10-18 13:12:40 »

Finally some people are talking sense.
Seriously most guys will PLEAD that you use delta timing... and its horrible
I sat there DAYS to get it to behave smoothly - it just wont happen - not matter how smooth you think it is, any spark in delta timing with jitter everything in a fast action game.
So on desktop I dont use delta anymore.

on mobile you kinda have to watch out because some devices will do 20-30 or 50 or 60 FPS/hertz Vsync

Offline ReBirth
« Reply #12 - Posted 2012-10-18 13:35:06 »

As for mobile I never do display sync persecutioncomplex (or libgdx has done that for us underhood?! Roll Eyes)

Offline princec

JGO Kernel


Medals: 409
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #13 - Posted 2012-10-18 13:38:02 »

Are you saying that instead of using delta-time I should just pin the frame-rate to a constant 60FPS and dont use delta-time at all?
Yes. Or whatever constant rate you prefer. 60 is a good number for desktops as 99% of all monitors out there nowadays will also be locked to 60Hz as well.

In a 2D game, the best and simplest advice I can give about varying frame rates is... just make sure that your game actually nearly always achieves a reliable 60FPS on the hardware it's targeted to run on. If it can't ... just let it run slower and tell people to upgrade, or write faster code / do less fancy effects.

Cas Smiley

Offline Gjallar

JGO Coder


Medals: 13
Projects: 1


Follower of Nurgle


« Reply #14 - Posted 2012-10-18 13:46:09 »

Now after looking for a way to cap the FPS in libGDX all I find is this (libGDX wiki):

1  
2  
3  
4  
5  
//Good advice right at start: You should never code anything dependent on the framerate! Instead it is a good idea to make it depend on the time e.g. one of these:

 System.currentTimeMillis();
 System.nanoTime();
 Gdx.graphics.getDeltaTime();


I guess there's no "setTargetFramerate();" ... I already miss Slick2D's simplicity  Sad
Offline delt0r

JGO Knight


Medals: 27
Exp: 18 years


Computers can do that?


« Reply #15 - Posted 2012-10-18 14:05:31 »

You can make it dependent on the *frame* not frame rate.

 I in fact have a graphics decoupled from the logic loops. But its fix rate logic. So a frame drop does not put you one frame behind. Since the logic loop requires very little cpu compared to the graphics loop. Keeping that ticking over at a fixed and constant rate is pretty easy. 

I have no special talents. I am only passionately curious.--Albert Einstein
Offline kappa
« League of Dukes »

JGO Kernel


Medals: 78
Projects: 15


★★★★★


« Reply #16 - Posted 2012-10-18 14:27:46 »

Now after looking for a way to cap the FPS in libGDX all I find is this (libGDX wiki):

1  
2  
3  
4  
5  
//Good advice right at start: You should never code anything dependent on the framerate! Instead it is a good idea to make it depend on the time e.g. one of these:

 System.currentTimeMillis();
 System.nanoTime();
 Gdx.graphics.getDeltaTime();


I guess there's no "setTargetFramerate();" ... I already miss Slick2D's simplicity  Sad
Also do have a look at LWJGL's Display.sync(int fps) method (needs to be called every frame). Not sure if LibGDX exposes this through its API.
Offline Roquen
« Reply #17 - Posted 2012-10-18 14:37:54 »

Yes, fixed logic/simulation rates is a really really wise route.  Rendering rates...do whatever you want.

I don't think this has been mentioned but with fixed rates you can do the easiest motion models and nothing gets hinky.  Variable rate requires very complex motion models and they'll always be hinky.
Offline Varkas
« Reply #18 - Posted 2012-10-18 14:57:36 »

So my question is, is there any way to have it run the same? Maybe detect what OS its running on and change the code accordingly? Any help would be appreciated. Thanks Smiley

To answer what you want to do:

The basic idea is to link your game to real time, not computer execution speed.

For more methods how to achieve this, read the thread again, and pick up the frequently occuring keywords Smiley

if (error) throw new Brick(); // Blog (german): http://gedankenweber.wordpress.com
Offline Gjallar

JGO Coder


Medals: 13
Projects: 1


Follower of Nurgle


« Reply #19 - Posted 2012-10-18 15:26:22 »

Added this to the render method:

1  
2  
3  
4  
5  
6  
7  
8  
9  
10  
11  
12  
13  
14  
15  
16  
17  
long lastLoopTime = TimeUtils.nanoTime();
   final int TARGET_FPS = 60;
   final long OPTIMAL_TIME = 1000000000 / TARGET_FPS;  

   @Override
   public void render() {        
      System.out.println(Gdx.graphics.getFramesPerSecond());

      long lastLoopTime = TimeUtils.nanoTime();

      try{
         Thread.sleep((lastLoopTime-TimeUtils.nanoTime() + OPTIMAL_TIME)/1000000);
      }
      catch(Exception e){
         e.printStackTrace();
      }
   }


and it runs at 60/61. Scrapped the deltatime and let the entities move for straight 3(int). I have to say the outcome is pretty similar to before, it runs very smooth but I still seem to get a tiny jitter every second Sad
Offline davedes
« Reply #20 - Posted 2012-10-18 16:15:09 »

Now after looking for a way to cap the FPS in libGDX all I find is this (libGDX wiki):

1  
2  
3  
4  
5  
//Good advice right at start: You should never code anything dependent on the framerate! Instead it is a good idea to make it depend on the time e.g. one of these:

 System.currentTimeMillis();
 System.nanoTime();
 Gdx.graphics.getDeltaTime();


I guess there's no "setTargetFramerate();" ... I already miss Slick2D's simplicity  Sad
Also do have a look at LWJGL's Display.sync(int fps) method (needs to be called every frame). Not sure if LibGDX exposes this through its API.
LibGDX's LWJGL (desktop) backend uses Display.sync, but only if the following condition is met:
1  
graphics.vsync && graphics.config.useCPUSynch


(Should be noted that it will use Display.sync by default, as both of those are initialized to true)

IMO Slick's usage was more reasonable: You set a target frame rate which will be used by Display.sync, and then you can independently enable/disable hardware vsync with setVSync(boolean).

Currently, LibGDX's unusual implementation could lead to bugs with Display.setVSyncEnabled never being reset.

Offline MacOLauncher

Junior Newbie





« Reply #21 - Posted 2012-10-18 17:01:31 »

Wow! Thanks for all the replies!  Grin Really appreciate it!!! The only problem is most of this stuff passes straight over my head! But I'll keep at it and find a solution!

So what I've learned from ya'll:

1.
Quote
The mac is giving a better performance then your windows.

2. I could either use Delta or Fixed Rate.

3. princec(Cas) makes
Quote
hundreds of thousands of dollars! xD

4.
Quote
Delta - complex (just try doing collision detection properly, go on), mercy of floating point, jerky movement. Absolutely horrible for 2D, in any form.
Fixed rate - easy, can use integers all over the place, glassy smooth movement, perfect for 2D.

5.
Quote
The basic idea is to link your game to real time, not computer execution speed.

Thanks very much for all your help Smiley
P.S. Any Code examples on how to actually do this would come in handy xD

- Mac
Offline Gjallar

JGO Coder


Medals: 13
Projects: 1


Follower of Nurgle


« Reply #22 - Posted 2012-10-18 18:40:04 »

Now that I changed the Target FPS to 100 it seems to be smooth.

Any ideas why it's smooth with 100 but not with 60 FPS? :/


Thanks very much for all your help Smiley
P.S. Any Code examples on how to actually do this would come in handy xD

If you are using libGDX, the sample I posted seems to work now (with 100FPS though).
Offline theagentd
« Reply #23 - Posted 2012-10-18 18:56:41 »

Why not to use delta:

<a href="http://www.youtube.com/v/sEVSVGbj3uE?version=3&amp;hl=en_US&amp;start=" target="_blank">http://www.youtube.com/v/sEVSVGbj3uE?version=3&amp;hl=en_US&amp;start=</a>

Myomyomyo.
Offline ra4king

JGO Kernel


Medals: 350
Projects: 3
Exp: 5 years


I'm the King!


« Reply #24 - Posted 2012-10-18 21:19:45 »

Well screw all you guys. I'm sticking with delta. I can wrap my head around it and it loves me very much <3

Offline princec

JGO Kernel


Medals: 409
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #25 - Posted 2012-10-18 21:28:40 »

Fine, we shall both sit atop our huge mounds of cash from making games, and throw projectiles at each other. Though due to latency and random timing errors your projectiles will somehow warp right through me, and mine will knock you off  Cool

Cas Smiley

Offline ra4king

JGO Kernel


Medals: 350
Projects: 3
Exp: 5 years


I'm the King!


« Reply #26 - Posted 2012-10-18 21:39:54 »

Fine, we shall both sit atop our huge mounds of cash from making games, and throw projectiles at each other. Though due to latency and random timing errors your projectiles will somehow warp right through me, and mine will knock you off  Cool

Cas Smiley
Nuh uh! Not if my super awesome coding skills make my code absolutely perfect with almost non-existent timing errors that are corrected eventually! Mwahahahahahaha *throws project at Cas*

Offline Cero
« Reply #27 - Posted 2012-10-18 22:43:54 »

Well screw all you guys. I'm sticking with delta. I can wrap my head around it and it loves me very much <3

Just wait until you actually distribute something and people right and left say "well jitters for me !"

Offline ReBirth
« Reply #28 - Posted 2012-10-19 02:33:55 »

I still hope either Nate or badlogicgame come and explain libgdx's.

Offline StumpyStrust
« Reply #29 - Posted 2012-10-19 05:16:21 »

hmmm... every where I went people said, "use delta as it keeps game steady," and "only the best game loops use delta fixed rate sucks B." So I started using delta (not bad, kinda cumbersome) and now its, "for the love of god do not use delta" Idk who to believe anymore.

Should I interpolate in the render? update? neither? I have to say that in meh game Neobat it is fixed rate and the collisions were shit as if anything moved even slightly to fast it would jump past an object.  I really want to stop working on my current game as it uses delta but I really don't want to use if it it will cause huge issues.

Pages: [1] 2
  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.

theagentd (16 views)
2014-10-25 15:46:29

Longarmx (52 views)
2014-10-17 03:59:02

Norakomi (45 views)
2014-10-16 15:22:06

Norakomi (34 views)
2014-10-16 15:20:20

lcass (39 views)
2014-10-15 16:18:58

TehJavaDev (68 views)
2014-10-14 00:39:48

TehJavaDev (68 views)
2014-10-14 00:35:47

TehJavaDev (60 views)
2014-10-14 00:32:37

BurntPizza (74 views)
2014-10-11 23:24:42

BurntPizza (45 views)
2014-10-11 23:10:45
Understanding relations between setOrigin, setScale and setPosition in libGdx
by mbabuskov
2014-10-09 22:35:00

Definite guide to supporting multiple device resolutions on Android (2014)
by mbabuskov
2014-10-02 22:36:02

List of Learning Resources
by Longor1996
2014-08-16 10:40:00

List of Learning Resources
by SilverTiger
2014-08-05 19:33:27

Resources for WIP games
by CogWheelz
2014-08-01 16:20:17

Resources for WIP games
by CogWheelz
2014-08-01 16:19:50

List of Learning Resources
by SilverTiger
2014-07-31 16:29:50

List of Learning Resources
by SilverTiger
2014-07-31 16:26:06
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!