Java-Gaming.org    
Featured games (79)
games approved by the League of Dukes
Games in Showcase (475)
Games in Android Showcase (106)
games submitted by our members
Games in WIP (530)
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  
  Reasons why Java is not a good language for game development  (Read 24169 times)
0 Members and 1 Guest are viewing this topic.
Offline Orangy Tang

JGO Kernel


Medals: 56
Projects: 11


Monkey for a head


« Reply #90 - Posted 2008-11-16 02:41:39 »

My game needs physics and that means integrating values over an elapsed time period.
For 2d using fixed time steps generally produces much better results (because as you've found variable steps can stutter and look bad). In fact even for 3d games fixed time steps have a whole bunch of advantages (determinism mainly). Depending on your game you may want to do fixed rate logic and rendering or fixed rate logic with variable rate rendering.

You've made a lot of fundamental mistakes over the course of this thread and have blamed the vm and java for your own mistakes. I suggest you do some proper background research and come back when you've got a better grasp of the basics.

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

Senior Newbie





« Reply #91 - Posted 2008-11-16 03:31:49 »

I know how to write a game loop with a fixed time step, a variable time step and move objects in discrete increments and I know the benefits of these aproaches. I also know how to compensate for variable time step physics simulations by decoupling the physics update from the framerate and using an alpha blending approach to cope with any remainder problems. In short I know how the mathematics for game loops work. Cool Your comments are simply unfair.

Anyway, it still stutters regardless of whether you use a fixed, or variable time step. The C code doesn't, which is strange because the JVM writers have access to the exact same C libraries that I do. If you write games in pure Java they stutter. I'm sorry but I think I'm correct, Java is not a good language for games development. Or more accurately, the JVM is not a good platform upon which to build a game.

If you use a native lib to do your graphics, input and sound then you might as well continue writing the game in C. At least in C you can synchronize the main loop properly. I think it is Java's shortcomings in the timing and synchronization arena that you are attempting to vainly support (it is obviously inadequate) and that you're just making excuses for Java's stuttery, laggy games performance by pointing the finger at my coding errors which were Java specific and based upon lack of experience in Java. It isn't fair to dismiss me as having made basic fundamental errors simply because I am new to Java. Let's face it, the code that I posted was pretty simple stuff and it was a fair translation of how you implement a simple game loop. Works in C, doesn't work in Java. Hmm... why not? That was the basis from which I approached the problem.

Why is it that Java games require a native library to handle the graphics & input in a satisfactory manner? Is it because pure Java simply sucks from a games development point of view? I think so. And it is obvious that others do too otherwise they wouldn't need the native libs.


--Mario
Offline Addictman

Senior Member


Medals: 3
Projects: 1


Java games rock!


« Reply #92 - Posted 2008-11-16 07:56:55 »


Here is my simplified loop (specific stuff taken out). At least I get decent accuracy and little stuttering using it. It doesnt differenciate logic and graphics, but that was a conscious choice on my part.

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  
27  
28  
29  
30  
31  
32  
33  
public void run()
    {
      long startTime = System.nanoTime();
      int frameCount = 0;
      cycleTime = 0.0;

     // additional init stuff
     
      while(isRunning)
      {
        // Update and render
       if(drawable != null)
           drawable.display();
        // Increase frame count
       frameCount++;

          // Loop until our time is spent
       while( ((cycleTime = System.nanoTime()-startTime) / aimedFPSFrame) < frameCount)
         {
            Thread.yield();
         }
         
                 
         // convert to ms for loop values
        cycleTime = cycleTime / 1000000.0;
         
         // reset counters
        startTime = System.nanoTime();
         frameCount = 0;
      }
     
     // clean up
   }


So if some basic stuff stutters using this, then I dont know what to say Smiley "It works here" (TM)
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline mgianota

Senior Newbie





« Reply #93 - Posted 2008-11-16 08:34:14 »

Hmm... You can't do a Thread.yield() in your delay section as it will peg the CPU. It is better just to put the thread to sleep for the length of the delay time. Additionally, the AWT thread is running at a higher priority than your game thread so you don't need code that gives it a chance to run. As far as I am aware, the only time you need to use yield is when you have a thread running at maximum priority and you need to give lower priority threads a chance to run.

I really want to get this stutter problem sorted out but I'm beginning to think that it is impossible.

--Mario
Offline Addictman

Senior Member


Medals: 3
Projects: 1


Java games rock!


« Reply #94 - Posted 2008-11-16 09:05:27 »

Did you try it? Wink I've had my share of Thread.Sleep loops, trust me. And it will only yield when you want it to, too. (And it won't hog the cpu. Why dont you try it before you say these things Smiley

Anyway, it was a suggestion to you. I use it, it doesnt stutter, it doesnt hog the cpu, and it works well for me. If it doesnt work for you, then I dont think Java alone is to blame.

Edit: Ok, explanation. You will of course "hog" the cpu if you aim your fps low enough (to stabilize the loop cycle) and waste most of the cycles, but that's basically the "fallback" mechanism. And as I use the EDT for I/O, I dont mind. Normally you'd be using most of  these cycles though. Thread.Sleep is in my opinion waaay to unpredictable, and I find it very difficult to stabilize the loop with it alone (You can program your way around it by computing averages, but it seems like such a waste)
Offline chrizo

Junior Newbie





« Reply #95 - Posted 2008-11-16 09:23:32 »

Greetings mgianota. I'm learning java and lwjgl as well. I'm still a novice really so i dunno if I am thinking correctly.  Undecided

I was just lurking around I thought we have a similar problem but it seems in your box program, there is something odd in your implementation of fixed time step.

If I interpret the first part of the article about Fix timestep correctly. You just let the render loop run and remember the elapsed time it took to make the loop. The accumulator in the render loop accumulates how many dt updates is possible within the time frame of the render loop. If the render took a long time, the update loop will run until the accumulater is less than the dt, if the render loop took a short amount of time, the update loop will wait till the next render loops if its time for another update.

Here is a portion of code in your render loop that i found odd:

               // Delay for a period of time equal to 1/60th of a
                // second minus the elapsed time
                elapsedTime = System.nanoTime() - time;               <----- also your elapsed time didnt account for the while loop below
                delayTime = frameRate - (double)elapsedTime;
                time = System.nanoTime();
                while( System.nanoTime() - time <= delayTime)
                    Thread.yield();



your NOT suppose to control how long the render takes by stalling it based on specifying an exact time since Thread.sleep() and Timers have a slight inaccuracy anyway.

I suppose this way, If you want to limit the fps, you can add a Thread.sleep(var) in the renderloop since it wouldn't matter if its accurate or not since elapsed time & accumulator will pick up on this.

Btw, guys, is this minor inaccuracy of thread.sleep() & timers the case in all Programming Langages? Whats the cause of this? CPU? Implimentation? OS?

Offline mgianota

Senior Newbie





« Reply #96 - Posted 2008-11-16 09:41:05 »

That code is broken through too much hacking. Below is the code I'm currently using. It is based upon feedback from Mr_Light and it is better than my original version but it still stutters. BTW it is not true that Thread.sleep() is innacurate. The method has a resolution of 1 millisecond and it seems to sleep for exactly that length of time.

If you're interested in this problem, here's the current test code:
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  
27  
28  
29  
30  
31  
32  
33  
34  
35  
36  
37  
38  
39  
40  
41  
42  
43  
44  
45  
46  
47  
48  
49  
50  
51  
52  
53  
54  
55  
56  
57  
58  
59  
60  
61  
62  
63  
64  
65  
66  
67  
68  
69  
70  
71  
72  
73  
74  
75  
76  
77  
78  
79  
80  
81  
82  
83  
84  
85  
86  
87  
88  
89  
90  
91  
92  
93  
94  
95  
96  
97  
98  
99  
100  
101  
102  
103  
104  
105  
106  
107  
108  
109  
110  
111  
112  
113  
114  
115  
116  
117  
118  
119  
120  
121  
122  
123  
124  
125  
126  
127  
128  
129  
130  
131  
132  
133  
134  
135  
136  
137  
138  
139  
140  
141  
142  
143  
144  
145  
146  
147  
148  
149  
150  
151  
152  
153  
154  
155  
156  
157  
158  
159  
160  
161  
162  
163  
164  
165  
166  
167  
168  
169  
170  
171  
172  
173  
174  
175  
176  
177  
178  
179  
180  
181  
package gameloop;

import java.awt.Color;
import java.awt.Frame;
import java.awt.Graphics;
import java.awt.GraphicsConfiguration;
import java.awt.GraphicsDevice;
import java.awt.GraphicsEnvironment;
import java.awt.Toolkit;
import java.awt.event.KeyEvent;
import java.awt.event.KeyListener;
import java.awt.geom.Rectangle2D;
import java.awt.image.BufferStrategy;

/**
 * A basic game loop.
 *
 * @author Mario
 */

public class GameLoop implements KeyListener {
    /*
     * The display window
     */

    Frame mainFrame;
   
    /*
     * Saves the time in nanos at which the last frame was drawn
     */

    long lastFrameDrawn;
   
    /*
     * The frame rate cap. Set to 60 fps here as a default.
     */

    long fpsLimit = 60;
   
    /*
     * Stores the frames per second.
     */

    long fps;
   
    /*
     * Saves the last time we looked at the clock.
     */

    long lastTime;
   
    /*
     * Saves a count of the number of frames drawn per 1 sec interval.
     */

    long frameCounter;
   
    /*
     * Saves the elapsed time in nanos.
     */

    long elapsedTime;
   
    /*
     * A rectangle to use as a basic game object to move
     * around on screen.
     */

    Rectangle2D rect;
   
    /**
     * Create a new GameLoop that will use the specified GraphicsDevice.
     *
     * @param device
     */

    public GameLoop(GraphicsDevice device) {
        try {
            // Setup the frame
           GraphicsConfiguration gc = device.getDefaultConfiguration();
           
            mainFrame = new Frame(gc);
            mainFrame.setUndecorated(true);
            mainFrame.setIgnoreRepaint(true);
            mainFrame.setVisible(true);
            mainFrame.setSize(640, 480);
            mainFrame.setLocationRelativeTo(null);
            mainFrame.createBufferStrategy(2);
            mainFrame.addKeyListener(this);
            // Uncomment this code if you want to see the game loop run full
           // screen. Running in full screen will enable the buffer strategy's
           // vertical retrace lock which should result in smoother animation.
           //device.setDisplayMode(new DisplayMode(640,480,8,DisplayMode.REFRESH_RATE_UNKNOWN));
           //device.setFullScreenWindow(mainFrame);
           
            // Cache the buffer strategy and create a rectangle to move
           BufferStrategy bufferStrategy = mainFrame.getBufferStrategy();
            rect = new Rectangle2D.Float(0,100,64,64);
           
            // Main loop
           
            while(true) {
                long time = System.nanoTime();
                elapsedTime = System.nanoTime() - time;
               
                updateWorld(elapsedTime);
               
                // Draw
               Graphics g = bufferStrategy.getDrawGraphics();
                drawScreen(g);
                g.dispose();
               
                // Flip the buffer
               if( ! bufferStrategy.contentsLost() )
                    bufferStrategy.show();
               
                // Synchronise with the display hardware. Note that on
               // Windows Vista this method may cause your screen to flash.
               // If that bothers you, just comment it out.
               Toolkit.getDefaultToolkit().sync();
               
                yield();
                calculateFramesPerSecond();
            }
        } catch (Exception e) {
            e.printStackTrace();
        } finally {
            device.setFullScreenWindow(null);
        }
       
    }
    private void updateWorld(long elapsedTime) {
       
        //double xMov = 0.001 * elapsedTime;
       double xMov = 2.0;
        rect.setRect(rect.getX() + xMov, 100, 64, 64);
       
        if( rect.getX() > mainFrame.getWidth() )
            rect.setRect(-rect.getWidth(), 100, 64, 64);
       
    }
   
    private void drawScreen(Graphics g) {
        g.setColor(Color.BLACK);
        g.fillRect(0, 0, mainFrame.getWidth(), mainFrame.getHeight());
        g.setColor(Color.WHITE);
        g.drawString("FPS: "+ fps, 0, 17);
       
        g.setColor(Color.RED);
        g.fillRect((int)rect.getX(), (int)rect.getY(), (int)rect.getWidth(), (int)rect.getHeight());
    }

    protected void yield() throws InterruptedException {
      long delayTime = 1000000000L/fpsLimit  - (System.nanoTime() - lastFrameDrawn);
      if(delayTime > 0) Thread.sleep(delayTime/1000000);
      lastFrameDrawn = System.nanoTime();
   }
   
    private void calculateFramesPerSecond() {
        long time = System.nanoTime();
        if( time - lastTime >= 1000000000L ) {
            fps = frameCounter;
            lastTime = time;
            frameCounter = 0;
        }
        frameCounter++;
    }
    public void keyPressed(KeyEvent e) {
        if( e.getKeyCode() == KeyEvent.VK_ESCAPE ) {
            System.exit(0);
        }
    }
    public void keyReleased(KeyEvent e) {
       
    }
    public void keyTyped(KeyEvent e) {
       
    }

    public static void main(String[] args) {
        try {
            GraphicsEnvironment env = GraphicsEnvironment.
                getLocalGraphicsEnvironment();
            GraphicsDevice device = env.getDefaultScreenDevice();
            new GameLoop(device);
        } catch (Exception e) {
            e.printStackTrace();
        }
    }

}


--Mario
Offline Mr_Light

Senior Member




shiny.


« Reply #97 - Posted 2008-11-16 12:09:59 »

My my I can't sleep in can I?  Tongue

FYI - putting yield() in a tight loop like that uses 100% CPU on the Mac. If no other threads are doing anything, it's like a no-op.

EDIT: oops sorry, I think I was looking at the wrong code. Looks like there's a couple different game loops in there.

Euh yeah I also included the old code (Main.java), Game.java & co is the newer code.

For the only-minorly-curious (by which I mean lazy, or - if you're feeling kind! - busy Smiley ) among us that don't have the inclination to diff the jar source (assuming it's included) and the posted code (I'm not even entirely sure which version we're talking about here, there have been several game loops posted), what was the main problem with the original code?  Just a memory leak, improper usage of something Java specific, or a logic problem?

Latest version he posted, but I worked of one of his earlier ones.
His fps limiter was off I think, it automaticly went away by pulling the code apart. And using sleep(); to actually un-schedule the thread. Adding sync() - Which as indicated before makes a huge difference.

...
Well that relates to why I stopped after 30 mins or so, I didn't want to create another library while there are probably tons of better ones already out there.

@Mr_Light: It still stutters on my machine --I didn't run your code for long enough to see the stuttering effect the first time. It is as if something is throttling the execution thread, slowing it down and then speeding it up.

The *reason* you don't see stuttering as bad with your example is that you are not updating the game objects inline with elapsed time, you just tick them forward a fixed increment at a time. That's why your example looks smoother even though the game objects are actually moving at a variable rate. My game needs physics and that means integrating values over an elapsed time period.

I need to think about this issue some more. Something in the JVM or in the OS is throttling the execution thread.

--Mario
Does the fps drop below 60? cause then all bets are off. - For single player gaming - well I'm against hard coding minimal specs, I've played red alert on a 386 and we had fun. For networked gaming it shouldn't matter - to stay with red alert  the game will go out of sync, so a minimum is enforced automatically.

Now you can trottle the game speed (even in network games, see supreme commander) based upon the available power. But game play shouldn't be affected - so it will only work for some games. That and it needs to swift gracefully - small delta's - else again it will effect gameplay.

To have anything reliable you just need a minimal fixed steps of your game logic being executed. For single player you might think well if I update logic and not draw it what's the use. For multi-player it's a bit different cause syncing take importance over a frame drop.

As for Laptops Pc's and speed stepping / amd equvialent you have to counter that you need to facilitate that a bit I can make some comments on that but most likely someone else on this forum can elaborate on this better.

If you are above 60 frames everything should move at a fixed rate. - though the code should probably be refined to ensure this. Distribution of executing with a set small enough bock of time shouldn't matter as it is not perceivable by human senses - and we are making games for humans right? With blocks of time made out of those small blocks with fixed executions we can guaranty linearity and fixture.  Btw yield is probably even less predictable then sleep as sleep allows the scheduler to make a strategy for waking it up the closest possible by the scheduler to the specified time. If you'd want more precise you'd have to go beyond the sceduler(provided the sceduler is well written). - not something I advice, as inherently you will still have the same problem.

I am somewhat out of my comfort zone here, so do fact check if (large piles of) money is involved.   persecutioncomplex - but then again you should probably do that with any information received from a public forum on the internet  Cheesy

It's harder to read code than to write it. - it's even harder to write readable code.

The gospel of brother Riven: "The guarantee that all bugs are in *your* code is worth gold." Amen brother a-m-e-n.
Offline princec

JGO Kernel


Medals: 339
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #98 - Posted 2008-11-16 14:10:28 »

I'm not sure what's so wrong with using a library to achieve what you need to...? I mean it's second nature to C programmers to use libraries right? And saying that if you use a native library you might as well just go C all the way is just crazy talk. The whole of Java is built with native libraries that interact with the OS! The LWJGL is just one that adds some extensions that make proper game development possible and easy. On their own, the Java standard libraries are not quite good enough.

Cas Smiley

Offline VeaR

Junior Member





« Reply #99 - Posted 2008-11-16 14:18:26 »

There are some ideas i didn't see discussed much. What would it take to make the Java platform better for making games?

First of all, i don't think any of this would make it into the Sun JVM. The Java platform development direction is largely influenced by enterprise developers. Enterprise web applications are where Java rules, and where the money in Java is, not in games developed in Java. This means that all the decisions which RFE-s to implement is driven by needs of enterprise web applications, and not games.

The Sun JVM is open-source (OpenJDK), so in theory it would be possible to make a branch version of it, which is more focused on needs of games. The distribution of such a JVM is problematic, because it needs to be distributed with the games itself, so applets and JWS is ruled out, but at least there would be a better Java platform for desktop installable games.

What could this custom open JVM do better/differently than the Sun JVM?

1. A different native interface. The JNI has problems. It calls functions in dynamically linked library, with passing environment, object reference, and all access is going trough that. What it lacks very much is possibility to inline functions. The JIT compiles Java code to native code, but JNI function calls are going back to JVM and then to JNI. Why not have something as a "Java Driver Interface"? This interface would extend the JVM from the bottom, just like drivers are extending an operating system. These would be special function libraries, that can be called and functions even inlined (if designated so) by the JIT into the machine code compiled Java code. So for example, glDrawElements would be a call to OpenGL function library, with C call convention and if requested inlined into JIT compiled Java code. The binary format of these drivers would be proprietary, suited for tight integration into the JVM.

2. Manual control over object allocation. In my application i have different allocation scenarios. Some objects are allocated for the whole run time of the game, some are for the currently loaded level (geometry, textures), some are used for the duration of rendering one frame, and some are used for a single call (for example collision detection, stack allocation would fit for these). So the heap could be divided into segments based on allocation scenarios, and all the objects in a segment could be wiped out with a single call to a pointer reset when they are not needed any more. This requires more work from the programmer, than the automatic garbage collector. But every one who tried optimizing by using object pools and reusing objects, had to write code for that anyway.

3. More aggressive, and manual control over the optimization process. If the JIT is in doubt to eliminate an array bound check by itself, why not let the programmer hint it at his own responsibility (with a pragma for example)? Security is not guaranteed, but those who work with OpenGL have JVM crashes regularly anyway, which need to be eliminated by proper testing, and not by the JVM by default being safe but less performant.

4. Structs for Java. OpenMP for Java. Now!

The regular answer for ideas like these is: "use C++". The C++ has its own problems, which in my eye are just as worrying as the suitability of Java for games.
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline whome

Junior Member




Carte Noir Java


« Reply #100 - Posted 2008-11-16 14:20:10 »

That code is broken through too much hacking. Below is the code I'm currently using. It is based upon feedback from Mr_Light...
WinXP/Java6

I had to flip two fullscreen rows to make fullscreen-mode run, setFullscreenWindow must be called before setDisplayMode method. Then I added commandlines to make testing easier.
c:\test> java -cp test.jar GameLoop "fullscreen=true"

I have LCD 60fps screen and was able to see a tearing on both modes. FPS counter actually reported 60-63 frames on both windowed and fullscreen modes. It's strange to have tearing even this simple and low-cpu intensive animation.

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  
27  
28  
29  
30  
31  
32  
33  
34  
35  
36  
37  
38  
39  
40  
41  
42  
43  
44  
45  
46  
47  
48  
49  
50  
51  
52  
53  
54  
55  
56  
57  
58  
59  
60  
61  
62  
63  
64  
65  
66  
67  
68  
69  
70  
71  
72  
73  
74  
75  
76  
77  
78  
79  
80  
81  
82  
83  
84  
85  
86  
87  
88  
89  
90  
91  
92  
93  
94  
95  
96  
97  
98  
99  
100  
101  
102  
103  
104  
105  
106  
107  
108  
109  
110  
111  
112  
113  
114  
115  
116  
117  
118  
119  
120  
121  
122  
123  
124  
125  
126  
127  
128  
129  
130  
131  
132  
133  
134  
135  
136  
137  
138  
139  
140  
141  
142  
143  
144  
145  
146  
147  
148  
149  
150  
151  
152  
153  
154  
155  
156  
157  
158  
159  
160  
161  
162  
163  
164  
165  
166  
167  
168  
169  
170  
171  
172  
173  
174  
175  
176  
177  
178  
179  
180  
181  
182  
183  
184  
185  
186  
187  
188  
189  
190  
191  
192  
193  
194  
195  
196  
197  
198  
199  
200  
201  
202  
203  
204  
205  
206  
207  
208  
209  
210  
211  
212  
213  
214  
215  
package gameloop;

import java.util.*;

import java.awt.Color;
import java.awt.Frame;
import java.awt.Graphics;
import java.awt.GraphicsConfiguration;
import java.awt.GraphicsDevice;
import java.awt.GraphicsEnvironment;
import java.awt.Toolkit;
import java.awt.event.KeyEvent;
import java.awt.event.KeyListener;
import java.awt.geom.Rectangle2D;
import java.awt.image.BufferStrategy;

import java.awt.DisplayMode; // for full-screen mode

/**
 * A basic game loop.
 *
 * @author Mario
 */

public class GameLoop implements KeyListener {
    /*
     * The display window
     */

    Frame mainFrame;
   
    /*
     * Saves the time in nanos at which the last frame was drawn
     */

    long lastFrameDrawn;
   
    /*
     * The frame rate cap. Set to 60 fps here as a default.
     */

    long fpsLimit = 60;
   
    /*
     * Stores the frames per second.
     */

    long fps;
   
    /*
     * Saves the last time we looked at the clock.
     */

    long lastTime;
   
    /*
     * Saves a count of the number of frames drawn per 1 sec interval.
     */

    long frameCounter;
   
    /*
     * Saves the elapsed time in nanos.
     */

    long elapsedTime;
   
    /*
     * A rectangle to use as a basic game object to move
     * around on screen.
     */

    Rectangle2D rect;
   
    /**
     * Create a new GameLoop that will use the specified GraphicsDevice.
     *
     * @param device
     */

    public GameLoop(Map<String,String> args, GraphicsDevice device) {
        try {
            // Setup the frame
           GraphicsConfiguration gc = device.getDefaultConfiguration();
           
            mainFrame = new Frame(gc);
            mainFrame.setUndecorated(true);
            mainFrame.setIgnoreRepaint(true);
            mainFrame.setVisible(true);
            mainFrame.setSize(640, 480);
            mainFrame.setLocationRelativeTo(null);
            mainFrame.createBufferStrategy(2);
            mainFrame.addKeyListener(this);

            // Uncomment this code if you want to see the game loop run full
           // screen. Running in full screen will enable the buffer strategy's
           // vertical retrace lock which should result in smoother animation.
           if ("true".equalsIgnoreCase(args.get("fullscreen"))) {
              device.setFullScreenWindow(mainFrame);
              device.setDisplayMode(new DisplayMode(640, 480, 8, DisplayMode.REFRESH_RATE_UNKNOWN));
            }
         
            // Cache the buffer strategy and create a rectangle to move
           BufferStrategy bufferStrategy = mainFrame.getBufferStrategy();
            rect = new Rectangle2D.Float(0,100,64,64);
           
            // Main loop
           
            while(true) {
                long time = System.nanoTime();
                elapsedTime = System.nanoTime() - time;
               
                updateWorld(elapsedTime);
               
                // Draw
               Graphics g = bufferStrategy.getDrawGraphics();
                drawScreen(g);
                g.dispose();
               
                // Flip the buffer
               if( ! bufferStrategy.contentsLost() )
                    bufferStrategy.show();
               
                // Synchronise with the display hardware. Note that on
               // Windows Vista this method may cause your screen to flash.
               // If that bothers you, just comment it out.
               Toolkit.getDefaultToolkit().sync();
               
                yield();
                calculateFramesPerSecond();
            }
        } catch (Exception e) {
            e.printStackTrace();
        } finally {
            device.setFullScreenWindow(null);
        }
       
    }
    private void updateWorld(long elapsedTime) {
       
        //double xMov = 0.001 * elapsedTime;
       double xMov = 2.0;
        rect.setRect(rect.getX() + xMov, 100, 64, 64);
       
        if( rect.getX() > mainFrame.getWidth() )
            rect.setRect(-rect.getWidth(), 100, 64, 64);
       
    }
   
    private void drawScreen(Graphics g) {
        g.setColor(Color.BLACK);
        g.fillRect(0, 0, mainFrame.getWidth(), mainFrame.getHeight());
        g.setColor(Color.WHITE);
        g.drawString("FPS: "+ fps, 0, 17);
       
        g.setColor(Color.RED);
        g.fillRect((int)rect.getX(), (int)rect.getY(), (int)rect.getWidth(), (int)rect.getHeight());
    }

    protected void yield() throws InterruptedException {
      long delayTime = 1000000000L/fpsLimit  - (System.nanoTime() - lastFrameDrawn);
      if(delayTime > 0) Thread.sleep(delayTime/1000000);
      lastFrameDrawn = System.nanoTime();
   }
   
    private void calculateFramesPerSecond() {
        long time = System.nanoTime();
        if( time - lastTime >= 1000000000L ) {
            fps = frameCounter;
            lastTime = time;
            frameCounter = 0;
        }
        frameCounter++;
    }
    public void keyPressed(KeyEvent e) {
        if( e.getKeyCode() == KeyEvent.VK_ESCAPE ) {
            System.exit(0);
        }
    }
    public void keyReleased(KeyEvent e) {
       
    }
    public void keyTyped(KeyEvent e) {
       
    }

    public static void main(String[] args) {
        try {
       Map<String,String> mapArgs = parseArguments(args);

            GraphicsEnvironment env = GraphicsEnvironment.getLocalGraphicsEnvironment();
            GraphicsDevice device = env.getDefaultScreenDevice();
            new GameLoop(mapArgs, device);
        } catch (Exception e) {
            e.printStackTrace();
        }
    }


   /**
    * Parse commandline arguments, each parameter is a name-value pair.
    * Example: java.exe MyApp "key1=value1" "key2=value2"
    */

   private static Map<String,String> parseArguments(String[] args) {
      Map<String,String> mapArgs = new HashMap<String,String>();

      for(int idx=0; idx < args.length; idx++) {
         String val = args[idx];
         int delimIdx = val.indexOf('=');
         if (delimIdx < 0) {
            mapArgs.put(val, null);
         } else if (delimIdx == 0) {
            mapArgs.put("", val.substring(1));
         } else {
            mapArgs.put(
               val.substring(0, delimIdx).trim(),
               val.substring(delimIdx+1)
            );
         }
      }
     
      return mapArgs;
   }

}


(me still looking for a good mainloop for windowed mode gfx apps)
Offline princec

JGO Kernel


Medals: 339
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #101 - Posted 2008-11-16 15:49:23 »

1. A different native interface. The JNI has problems.
There is such an interface already in development on java.net somewhere (I forget its name). However you must understand that half of the calls we make to native code have to be adapted for Java use anyway - specifically the use of Buffers and arrays - so this simply wouldn't work for many function calls. Of the remaining function calls, almost all are essentially trivial state changes, the overhead of which is lost in noise. The only real benefits we could really glean are if we had a mechanism to allow us to interface to native libraries that required a lot less tedious boilerplate code for these trivial functions.

Quote
2. Manual control over object allocation.
I agree that having different heaps would be handy, and each heap could be given a different garbage collection strategy depending on its usage. Stack allocation would be handy from escape analysis too, to simply avoid the whole bother of heap allocation in the first place.

One particular scenario I have is that I'd like to manage references to GL objects (textures, shaders, FBOs, etc) in a separate heap - the GC is typically only forcibly triggered when some arbitrary out-of-memory condition occurs in the main heap; however the memory taken up by GL objects is exists in a video card and would ideally be shadowed by some phantom heap that tracked the size of these objects and triggered separate collections independent of the main heap in order to destroy things no longer referenced.

Quote
3. More aggressive, and manual control over the optimization process.
This is one thing I don't really agree with; it'd be better if the JIT simply got better and better. But having said that, in a closed environment (ie. locally installed) it should be possible to run the JVM with a -Dnoboundscheck parameter which would bring almost all Java speed bottlenecks vs. C on to an equal footing. A bit like turning off asserts.

Quote
4. Structs for Java. OpenMP for Java. Now!
How long have we waited? And I bet they do it wrong.

Cas Smiley

Offline oNyx

JGO Coder


Medals: 1


pixels! :x


« Reply #102 - Posted 2008-11-16 16:32:39 »

[...] LWJGL provides a proper timer that works pretty flawlessly on any hardware [...]

TGT is actually broken on some 15-20 year old motherboards. Fortunately that's completely irrelevant. Wink

[...] It's strange to have tearing even this simple and low-cpu intensive animation. [...]

Huh? The complexity of the animation doesn't change anything. If vsync is disabled there will be tearing. Yes, it's really that simple.

弾幕 ☆ @mahonnaiseblog
Offline Mr_Light

Senior Member




shiny.


« Reply #103 - Posted 2008-11-16 16:44:11 »

It's strange to have tearing even this simple and low-cpu intensive animation.

Without vsync you'll always have some tearing no matter how you programm it or in what ever language. -> oi oNyx beat me to it.

It's harder to read code than to write it. - it's even harder to write readable code.

The gospel of brother Riven: "The guarantee that all bugs are in *your* code is worth gold." Amen brother a-m-e-n.
Offline erikd

JGO Ninja


Medals: 16
Projects: 4
Exp: 14 years


Maximumisness


« Reply #104 - Posted 2008-11-16 16:46:45 »

Since when was 9998757ns ever equal to 10ms? Okay, it is close to 10ms but it is not exact.

Since the day we realized that there is no such thing as *exactly* 10ms in real life, so you always have to define a certain precision. I think I learned that in my 1st physics class.
Like I said, Thread.sleep has a precision of 1ms. So with that precision, 99987757 nanoseconds *is* 10 milliseconds. So your test does not really demonstrate any failure of Thread.sleep

In any case, small imprecisions like this are not going to cause jerky movement anyway.

Offline VeaR

Junior Member





« Reply #105 - Posted 2008-11-16 17:17:49 »

The only real benefits we could really glean are if we had a mechanism to allow us to interface to native libraries that required a lot less tedious boilerplate code for these trivial functions.
Trivial functions would benefit even more from inlining (inserting the machine code between JIT compiled code), those are the functions that are potentially called a lot of times, so in case of inlining the JNI call overhead wouldn't add up.

Quote
But having said that, in a closed environment (ie. locally installed) it should be possible to run the JVM with a -Dnoboundscheck parameter which would bring almost all Java speed bottlenecks vs. C on to an equal footing. A bit like turning off asserts.
I think a "@NoBoundsChecks" infront of the method where the programmer is sure no problem can arise would be the best.

Offline Mr_Light

Senior Member




shiny.


« Reply #106 - Posted 2008-11-16 17:20:29 »

http://maxine.dev.java.net - I need more spare time Smiley

Quote
VM code can be inlined into app code and optimized together
Quote
Optional runtime code features can be turned on and off
by dynamic re-compilation
 • no overhead while off

I think a "@NoBoundsChecks" infront of the method where the programmer is sure no problem can arise would be the best.
nooooooo, and all those methods are going to do what? throw security exceptions? or just create huge security problems?  Shocked

It's harder to read code than to write it. - it's even harder to write readable code.

The gospel of brother Riven: "The guarantee that all bugs are in *your* code is worth gold." Amen brother a-m-e-n.
Offline bienator

Senior Member




OutOfCoffeeException


« Reply #107 - Posted 2008-11-16 18:22:33 »

the most interesting part of this project is this:
Quote
....to develop a research Virtual Machine that is written in the Java(TM) Programming Language
aka, what was first, egg or chicken?   Wink

Offline VeaR

Junior Member





« Reply #108 - Posted 2008-11-16 18:56:41 »

nooooooo, and all those methods are going to do what? throw security exceptions? or just create huge security problems?  Shocked

That reaction sums it up, how people react to the idea of a game-friendly JVM.
Offline jamongames

Senior Newbie





« Reply #109 - Posted 2008-11-16 19:35:17 »

the most interesting part of this project is this:aka, what was first, egg or chicken?   Wink

haha, you are right... java virtual machine should be programmed in C or C++? because  you need one JVM for windows, one for Linux, one for solaris... etc

i develop a massive multiplayer chess game.

http://www.chessk.com

enjoy!
Offline Mr_Light

Senior Member




shiny.


« Reply #110 - Posted 2008-11-16 20:57:33 »

That reaction sums it up, how people react to the idea of a game-friendly JVM.

I'm afraid that has little to do with game friendliness,  I have nothing against a jvm flag. I also have little against memory mapped objects. But what your suggesting, in light of all the other efforts in the jvm,  would just make everything a half baked, poor, engineering job.

Quote
a -Dnoboundscheck parameter which would bring almost all Java speed bottlenecks vs. C on to an equal footing. A bit like turning off asserts.
More a bit like disabling bytecode verification, but who cares.

It's harder to read code than to write it. - it's even harder to write readable code.

The gospel of brother Riven: "The guarantee that all bugs are in *your* code is worth gold." Amen brother a-m-e-n.
Offline jezek2
« Reply #111 - Posted 2008-11-16 21:23:29 »

But having said that, in a closed environment (ie. locally installed) it should be possible to run the JVM with a -Dnoboundscheck parameter which would bring almost all Java speed bottlenecks vs. C on to an equal footing. A bit like turning off asserts.

I don't agree, forced bounds checking are one of core Java features that warrants you don't get corrupted memory/state and you're informed about the error very precisely. And no, I don't believe in debug builds for testing, you get bugs all the time in production, and it can be triggered even after some time of usage.
Offline Mr_Light

Senior Member




shiny.


« Reply #112 - Posted 2008-11-16 21:32:59 »

But aren't there type of applications[size=1pt](games?)[/size] that aren't so much focused on stability as much as user experience?

It's harder to read code than to write it. - it's even harder to write readable code.

The gospel of brother Riven: "The guarantee that all bugs are in *your* code is worth gold." Amen brother a-m-e-n.
Offline VeaR

Junior Member





« Reply #113 - Posted 2008-11-16 21:51:28 »

I'm afraid that has little to do with game friendliness,  I have nothing against a jvm flag. I also have little against memory mapped objects. But what your suggesting, in light of all the other efforts in the jvm,  would just make everything a half baked, poor, engineering job.
I'm suggesting it in addition to the JVM flag. I'f you have code that you think is worth to risk, and think that it does not pose a security risk to omit bounds checking, then you would mark it as such. Old libraries unaware of the pragma, would still run with bounds checking with JVM flag enabled or disabled. During development and testing the JVM flag should be disabled, so exceptions come to light. If you think this is half-baked, then think about that C++ does not have bounds checking at all if the programmer explicitly does not write it, yet it is widely accepted for games (and other kind of) applications. Enterprise applications concerned in safety above all can just disregard both the flag and the pragma, make the IDE/compiler throw a warning if it encounters the pragma, tie its use to security manager, don't allow dynamic loading of classes with the pragma or force it to still run with bounds checking, or just don't use the custom JVM in the first place.

Offline VeaR

Junior Member





« Reply #114 - Posted 2008-11-16 22:10:36 »

I don't agree, forced bounds checking are one of core Java features that warrants you don't get corrupted memory/state and you're informed about the error very precisely. And no, I don't believe in debug builds for testing, you get bugs all the time in production, and it can be triggered even after some time of usage.

It is easily possible to write OpenGL code that breaks the JVM (the graphics driver to be precise, but no Java stacktrace, just a JVM crash), but we are still managing to make working applications. Everything should be done with proper consideration, so don't add the pragma if you are not sure. And don't rely on exceptions too much, they are faster than in C++, but are still costly.
Offline Mr_Light

Senior Member




shiny.


« Reply #115 - Posted 2008-11-16 22:21:50 »

Sorry I though you meant best as in replacement:
I think a "@NoBoundsChecks" infront of the method where the programmer is sure no problem can arise would be the best.
But yeah in unison, complimenting each other, sounds pretty sweet.

It's harder to read code than to write it. - it's even harder to write readable code.

The gospel of brother Riven: "The guarantee that all bugs are in *your* code is worth gold." Amen brother a-m-e-n.
Offline jezek2
« Reply #116 - Posted 2008-11-16 22:45:04 »

It is easily possible to write OpenGL code that breaks the JVM (the graphics driver to be precise, but no Java stacktrace, just a JVM crash), but we are still managing to make working applications. Everything should be done with proper consideration, so don't add the pragma if you are not sure. And don't rely on exceptions too much, they are faster than in C++, but are still costly.

Yes, with native code it's normal to have crashing programs. Unfortunatelly we have to use OpenGL for 3D acceleration, so some native code interaction is needed. But it can be pretty well isolated in small area of code (wrapped calls to OpenGL routines) and checked (for example LWJGL tracks OpenGL state and does bounds checks for direct buffers to prevent corruption). Also OpenGL is good API secure-wise because it doesn't work with pointers but handles. After all JRE does the exact same thing with native OS calls (wrapped and checked).

Speed of exception generation is irrelevant, because it's generated when there is problem. And there is no visible (probably not any) penalty for try/catch blocks.

But aren't there type of applications[size=1pt](games?)[/size] that aren't so much focused on stability as much as user experience?

Good user experience requires stability.
Offline cylab

JGO Ninja


Medals: 38



« Reply #117 - Posted 2008-11-16 23:04:12 »

I can't see any disadvantage of having a flag for disabling bounds checking, as long as it is a runtime and not a compiletime flag. Make some security restrictions on setting this flag (valid certificate) and forbid it's usage for applets, so you basically have this ability for locally installed applications (that users trust anyhow). Provide two icons for your game ("unchecked" and "checked"), so your support can advice the user to start the "checked" one after a crash and you have the best of both worlds...

Mathias - I Know What [you] Did Last Summer!
Offline jezek2
« Reply #118 - Posted 2008-11-16 23:15:58 »

I can't see any disadvantage of having a flag for disabling bounds checking, as long as it is a runtime and not a compiletime flag. Make some security restrictions on setting this flag (valid certificate) and forbid it's usage for applets, so you basically have this ability for locally installed applications (that users trust anyhow). Provide two icons for your game ("unchecked" and "checked"), so your support can advice the user to start the "checked" one after a crash and you have the best of both worlds...

This would create grand effect of crippling Java as many (standalone) apps will disable it and value of Java platform will decrease rapidly. Try look to things at big picture... Luckily this won't happen, Sun won't allow this. You're perfectly OK to modify OpenJDK code if you wish, but it won't be Java.

I don't know what's wrong, either you like Java strengths and use Java for them or use native languages instead.
Offline brackeen

Junior Member





« Reply #119 - Posted 2008-11-16 23:41:58 »

HotSpot already has range-check elimination:
http://www.forthgo.com/blog/range-check-elimination-optimization/
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.

ctomni231 (39 views)
2014-07-18 06:55:21

Zero Volt (36 views)
2014-07-17 23:47:54

danieldean (29 views)
2014-07-17 23:41:23

MustardPeter (32 views)
2014-07-16 23:30:00

Cero (47 views)
2014-07-16 00:42:17

Riven (48 views)
2014-07-14 18:02:53

OpenGLShaders (38 views)
2014-07-14 16:23:47

Riven (37 views)
2014-07-14 11:51:35

quew8 (33 views)
2014-07-13 13:57:52

SHC (70 views)
2014-07-12 17:50:04
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

HotSpot Options
by Roquen
2014-05-06 15:03:10

Escape Analysis
by Roquen
2014-04-29 22:16:43

Experimental Toys
by Roquen
2014-04-28 13:24:22
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!