Java-Gaming.org    
Featured games (79)
games approved by the League of Dukes
Games in Showcase (477)
Games in Android Showcase (107)
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  
  Reasons why Java is not a good language for game development  (Read 24285 times)
0 Members and 1 Guest are viewing this topic.
Offline Eli Delventhal

JGO Kernel


Medals: 42
Projects: 11
Exp: 10 years


Game Engineer


« Reply #30 - Posted 2008-11-12 22:54:01 »

I like Java. Yay!

Try using C# (a very similar language) and you'll be happier with Java. As JIT languages go it's the best.

See my work:
OTC Software
Online gouessej
« Reply #31 - Posted 2008-11-12 23:27:46 »

I like Java. Yay!

Try using C# (a very similar language) and you'll be happier with Java. As JIT languages go it's the best.
Grin I agree. Using Mono is not completely legal because Microsoft can prosecute you for patents violation. C# is not really cross-platform, it is a bad dirty clone that has some drawbacks of C/C++ and some drawbacks of Java (without all its advantages)  Shocked

Offline Mr_Light

Senior Member




shiny.


« Reply #32 - Posted 2008-11-13 00:02:06 »

Quote
Most programming languages are turing-complete, so the power of closures do not arise from their ability to compute things that cannot otherwise be computed. Rather their expressive power arises from being able to abstract over things that you simply could not abstract over before. In the case of closures, it is the ability to define APIs that abstract over an arbitrary statement or expression. Writing such APIs simply isn't possible in Java today.
All that vouchers for is control abstraction, not closures per se. and everything seems to be geared towards that. What it seems to boil down to is that ppl want the ability control abstractions. No one has researched or focused on discovering possible other methods of including those without closures, they rather copy what is out there. Which is very un-java like. I'm not against stealing good idea's, I am against doing stuff wilst not thinking for ourselfs. The closures advocates have not given the right answers. Also syntax examples as shown out there just don't work half of them aren't java like other half is focused on one line code blocks and fail hopelessly with multi line etc. that and other stuff - which is rather something for an other (new) topic.

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.
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline cylab

JGO Ninja


Medals: 38



« Reply #33 - Posted 2008-11-13 00:03:22 »

(...) it is a bad dirty clone that has some drawbacks of C/C++ and some drawbacks of Java (without all its advantages)  Shocked

That's wishful thinking!

C# as a language is actually very capable and does not fall short of Java in any relevant aspect. I prefer Java, but discrediting C# does not help anything.

Mathias - I Know What [you] Did Last Summer!
Offline mgianota

Senior Newbie





« Reply #34 - Posted 2008-11-13 00:04:41 »

... at least add a thread.yield or you will produce a cpu lock (if your blitting has been delayed for example it will be locked..), (there are severals java source code available and able to produce a stable frame rate).

Yes, you're right. I added the Thread.yield() call into the main loop.

Quote
IMHO : even  from an algorithm point of view the method you have used is innacurate as the error are cumulative over time => with your method at 60fps after 100 s you can have produced a number of frame very different than 6000 (60*100)

The method I'm using is the only one I know for producing a reasonably acceptable frame rate. Do you have any code to share that can increase the accuracy? For example, do I need code that will measure the frame rate while the game is running and increase the frame rate to compensate for cumulative errors over time?

--Mario
Offline Orangy Tang

JGO Kernel


Medals: 56
Projects: 11


Monkey for a head


« Reply #35 - Posted 2008-11-13 01:17:13 »

There's also some tearing in evidence which is not supposed to happen as BufferStrategy purportedly checks the vertical retrace before drawing.

BufferStrategy will only vsync if it's in fullscreen exclusive mode. IIRC it's impossible (even for a native app) to do proper vsync'd rendering in a window.

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

JGO Coder


Medals: 1
Projects: 1


END OF LINE.


« Reply #36 - Posted 2008-11-13 01:32:23 »

Whilst the collection of points against using Java for games writing is admittedly a little weak, I think that the code above that uses just Java's standard APIs clearly shows that it is not worthwhile attempting games in Java without recourse to a native library. Just my two cents worth: if you want to write games in Java then make sure you use a native library such as LWJGL, or JOGL to handle the painting and screen updates.

Well, sorry if this is abrupt, but that is what we have been advocating all along.  Java is fantastic as a language for so many reasons but without native libraries, it would not be possible to achieve parity with other native languages.  And I see absolutely no problem with that whatsoever.  In fact, check out one of my recent blog posts:  http://blogs.sun.com/ChrisM/entry/wayback_machine_games_at_sun

Back in 2001-2002 we were attempting to build the equivalent of DirectX for Java.  These were all going to be native libraries to get closer to the metal.  And, again, there is nothing wrong with that.  Better to have to support development of specific APIs than worry about cross platform porting of an entire application code base. I mean, before C became performant enough, developers used to code entire rendering pipelines in assembly.  C++, developers used bindings for C APIs.  In fact, you still see certain graphics platforms that access hardware directly and bypass APIs all together.

Offline Matzon

JGO Knight


Medals: 19
Projects: 1


I'm gonna wring your pants!


« Reply #37 - Posted 2008-11-13 09:03:53 »

there is a reason why we stop using QPC (which nanotime is based on, on windows) in LWJGL Wink - its crap.

Offline princec

JGO Kernel


Medals: 343
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #38 - Posted 2008-11-13 09:09:45 »

On a related note, it certainly would help matters if someone did that DirectX binding for LWJGL...

Cas Smiley

Offline kevglass

JGO Kernel


Medals: 120
Projects: 23
Exp: 18 years


Coder, Trainee Pixel Artist, Game Reviewer


« Reply #39 - Posted 2008-11-13 09:28:57 »

I guess someone needs to *want* it enough for that to happen.

Going back to the original comments on the thread, there seem to be just a few gripes:

- Applets are crap (different reasons from different people, but still crap)
- JRE is too big (fixed by Java Kernel?)
- Need to use native libraries to get consistant performance (is this really an issue or a matter of taste?, fixed by including JOGL et all as a module of the Java Kernel?)

The other bits and pieces seem to be a matter of taste or isn't a directly related games thing.

Kev

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

JGO Kernel


Medals: 343
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #40 - Posted 2008-11-13 11:06:56 »

I want it that much but no longer have the time to altruistically devote to helping others Sad I could easily increase my sales a hefty amount if I got a DX version of my sprite engine working.

- Applets I would say are crap now but in about 2-3 years, provided update 10 fixes the problems and Apple get it released pronto, it should have sorted this issue. I have to say I have noticed since Flash 10 got released all my browsers crash or freeze at 100% CPU nowadays so Adobe looks to have screwed it up. Er, yay!

- JRE size: well, should be fixed by kernel thing yes?

- Native libraries: problematic because of security dialog, also because they're OpenGL only and we really need a DX binding for people writing proper middleware

- NO CONSOLE SUPPORT. AT ALL.

Cas Smiley

Offline Mr_Light

Senior Member




shiny.


« Reply #41 - Posted 2008-11-13 13:24:18 »

I have to say I have noticed since Flash 10 got released all my browsers crash or freeze at 100% CPU nowadays so Adobe looks to have screwed it up. Er, yay!
Also under the populair ubuntu distro flash seems to die randomly after a while, producing just a grey rectangle.

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: 343
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #42 - Posted 2008-11-13 13:37:32 »

No one cares about Linux desktops Smiley

TBH I wonder why Sun don't shift all those Linux desktop Java engineers on to the Apple side and make a proper Sun Mac OS JVM.

Cas Smiley

Offline Mr_Light

Senior Member




shiny.


« Reply #43 - Posted 2008-11-13 13:56:26 »

No one cares about Linux desktops Smiley

Oem's ship more and more linux boxes, think eee laptops for example. While in the corporate space things remain the same, I see stuff picking up in the home/consumer space. Among students, youngsters  and mom's that only do e-mail and some browsing I see it picking up. though I don't foresee an actual market within a year. After that it depends on if matter keep moving towards that direction. At this time there is some momentum.

I care about linux desktops but that isn't really gaming related.  Kiss

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 Orangy Tang

JGO Kernel


Medals: 56
Projects: 11


Monkey for a head


« Reply #44 - Posted 2008-11-13 14:09:16 »

TBH I wonder why Sun don't shift all those Linux desktop Java engineers on to the Apple side and make a proper Sun Mac OS JVM.

Cas Smiley

They're probably all beardy linux hippies who would leave as soon as Sun tried that.  Wink

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

Senior Member


Projects: 1
Exp: 15 years


Used to be bleb


« Reply #45 - Posted 2008-11-13 15:29:10 »

Preemptive to gouessej:

It's ok, they're just joking. 
Offline brackeen

Junior Member





« Reply #46 - Posted 2008-11-13 18:44:55 »

Okay, my two cents :
- Timing. Neither sleep() or nanoTime() work well, mainly because of hardware/OS issues. (already mentioned)
- Java Sound. This is the buggiest library I have ever used, ever.

I don't think JRE size matters anymore. Most folks have Java 6 at this point. The kernel helps, plus it's got auto-update and patch-in-place. Even without the kernel, 15MB isn't as big a deal today as it was 10 years ago.

That said, I wouldn't recommend to anyone to make game Applets from scratch. Use an existing library or framework that has dealt with stuff like timing problems.

Offline Eli Delventhal

JGO Kernel


Medals: 42
Projects: 11
Exp: 10 years


Game Engineer


« Reply #47 - Posted 2008-11-13 18:48:19 »

He says as his signature links to PulpCore...  Tongue

See my work:
OTC Software
Offline mgianota

Senior Newbie





« Reply #48 - Posted 2008-11-13 20:02:03 »

So in summary, is it fair to say that Java is bad choice for game development if you do not include native libs?

I think the answer to the question is fairly obvious really. I don't mind using native libraries from within Java, but using them increases the likelihod that my game will fail to start up on another machine. For example, neither LWJGL nor JOGL will work on this Windows Vista laptop that I'm using despite the fact that it is a reasonably well specc'd machine. LWJGL complains about an unsupported pixel format (video card trouble) and JOGL regularly crashes the JRE, though software emulation works just fine but is far too slow for games work. I can't play Puppy Games' games because they won't start up on my machine. The failure to start problem is just *eating* away at your profits Cas. A DirectX version in C++ would have run just fine. A shame really 'cos I really like playing shoot-em up games --they help me to concentrate.

As for writing games in pure Java, I've given up! There are timing problems and screen update problems that I just don't get if I use C and a really simple hardware layer interface library like SDL. Additionally, there is something deeply suspicious about the inner-workings of System.nanotime() and the lag and stutter in the main game loop is causing me so many headaches. Again, as Kev suggested, it is probably a hardware problem but I no longer care about Java's hardware interface problems. My lack of care in this respect is prompted in part by the suspiciously low coupling of Java  to hardware.

Anyway, back to the point. If I can't do something really, really basic like time the appearance of game objects and move them *smoothly* around on screen (even at low frame rates on really bad hardware) then I don't really want to know what else Java can do. Hell, even Blitz Basic and Dark Basic will give me a smooth, consistent main loop on a crappy 500Mhz Pentium, why won't Java? Christ, even Flash will give me a steady frame rate and Flash is the suckiest of the suckiest arse-over-tit, extra-ecma-anal game programming environments. On this machine, I only get a stable frame rate for my test code in Java if I drop the frame rate to ten frames per seconds, which is unusable except for the simplest of puzzle games.

It is not enough to say, well there's something wrong with the way you're doing your screen updates in the test code (as Dzzd said) and you need code to stabalize the frame rate. That's just a load of bollocks Dzzd. There's nothing wrong with the code: time the game objects update & drawing operations and then sleep for a period of time to sync the loop at sixty frames per second, or whatever frame rate you can get away with. It doesn't get much simpler than that. Coding a game loop is trivial, yet Java just doesn't seem to be able to handle the timing and synchronisation requirements and produces inexplicable stutters and lags in the main loop. Let's face it, stutter and lag are just anathema to a games writer. Its the kind of thing that furrows your brow when you're falling off to sleep and it is annoying because the problem subtracts thinking time from designing and implementing the game play and game mechanic. Incidentally, when I ported the test code across to C and SDL, I got a rock steady frame rate. As expected, with none of the stupid bollocky timing artifacts that Java seems to throw in to the mix.

The other thing that is bothering me, which cas has touched upon, is that there is no console support in Java. If I write a game for the PC and it does reasonably well then the obvious thing to do would be to use the profits generated from the PC version to purchase a console development kit and port the game across. If I've already written the game in C then porting becomes trivial, if it is written in Java with native lib dependencies then porting is not so easy and straight-forward. In fact, it is probably near enough a complete rewrite.

IMO Java fails as a choice for game writing at the most basic level: the game's update/render loop. This is unpardonable for a runtime that wants to make it in the game writing arena. If the timing in your game is off then the players will notice and stop playing the game and they certainly won't buy a game that stutters and lags. I'm a little annoyed not to mention peeved at the amount of time (wasted in my opinion) I have spent writing and debugging code on a platform that just doesn't perform well enough and no amount of tinkering will coax the JRE, or the graphics libraries or the timer or whatever the Hell the problem is with Java's jerky screen updates into giving me a stable main loop on top of which I can build a playable game.

I'll continue to hang around the forum to see if things improve, but TBH I think that Java's games writing problems are fundamental and located within the JRE and the native interface code. Aargh, all those bloody layers just to get at the hardware! I'm sorry, but I think you are completely wrong to spend your time writing games in Java. C/C++ is a much better choice. Using Java for games writing just brings to mind a modern curse: may your games stutter and lag for all eternity.

I'll stick around the forum to view the games showcase releases (I do like seeing those) and just generally monitor the Java performance related posts but as for using Java to write a commercial game, I think I'd rather eat a pooh sandwhich and wash it down with an extra large cup of vommit. Grin Heh, not that I'm in the habit of consuming such eye wateringly disgusting repasts. My experiences with Java game programming have given me a bloody twitch. Right, where the Hell's my C compiler? Sanity extends an elegant, manicured finger and beckons with a sultry call "this way young Jedi, this way...".

Jesus, you know what? I'm actually beginning to believe that I'll need a theraputic course in advanced cognitive neronal repair after my experiences with that JRE and class library. I feel that my experience of writing games in Java has just caused the window of opportunity to slam down on my fingernails, throwing me breathless to the floor. And there I lied, helpless, as I watched the Sun Necrosystems vultures descend from the sky to pick at my loathsome bones...

--Mario

Online Riven
« League of Dukes »

JGO Overlord


Medals: 746
Projects: 4
Exp: 16 years


Hand over your head.


« Reply #49 - Posted 2008-11-13 20:14:18 »

So... let me get this straight. If you would have gotten the animation part smooth, it'd be all fine?

I mean... if you can play PulpCore games (for instance) without hickups (can you?), then that means there is a solution.

It is certainly very bad that it doesn't work out of the box for you, but if a quick copy/paste from PulpCore fixes it, it will be well worth staying with Java IMHO, due to the superiour API, IDEs and other tools.

Hi, appreciate more people! Σ ♥ = ¾
Learn how to award medals... and work your way up the social rankings
Offline kevglass

JGO Kernel


Medals: 120
Projects: 23
Exp: 18 years


Coder, Trainee Pixel Artist, Game Reviewer


« Reply #50 - Posted 2008-11-13 20:41:21 »

Quote
My experiences with Java game programming have given me a bloody twitch.

OOI, what exactly have you been doing with Java to give you such a bad impression? Even the most closed minded of Java haters can normally see the benefits even if in many cases they seem out weighed by the problems.

Kev

Offline mgianota

Senior Newbie





« Reply #51 - Posted 2008-11-13 20:48:37 »

@Riven: Yeah, you've hit the nail on the head. My only raison d'etre for using Java is the gorgeous IDEs and other build tools (like Ant) that are available. Plus the Javadoc popup thing in the editor makes coding to libraries a breeze. But, if I can't get a stable frame rate because the platform timer sucks then no way am I going to use Java.

BTW Pulpcore is excellent David, but the applets are jerky. It is such a shame 'cos Pulpcore has got a beautiful timing and animation framework. I wrote a quick 2D shooter using Pulpcore and it was just dead easy to do, but I stopped writing when I noticed the jerky screen updates becase I thought that nobody will play a game for more than ten seconds if it is lagging and jerking around on screen. In fact, I think players will actually start to *hate* you for publishing a jerky game. Jerky games are my number one biggest turn off.

I have no idea whether the problem is due to the Java system's timer, or the graphics libraries. I just know that I can't use it to write games 'cos the stutter & lag offends my sensibilities as a programmer first and as an avid games player second.

--Mario
Offline mgianota

Senior Newbie





« Reply #52 - Posted 2008-11-13 21:01:47 »

@Kev: I'm not a Java hater. It is impossible to hate a language which is obviously so beautifully engineered. At heart I'm a C programmer and I use Java because I think it has a great class library, blindingly good tools and a knockout windowing kit all built-in to one package. Also, server-side Java goes like sh*t off a shovel. The speed of Java isn't an issue for me, it is the reliability of the programming APIs. I don't know about you, but for me timing bugs are a source of major headaches and Java's timing (I'm basing this upon what David Brackeen and Dzzd has said) isn't up to the job for games writing.

I would like to be able to write games in Java because it gives me one-click deployment off a web page but I'm forced back into C simply because Java has got the fundamentals wrong. In gaming, timing is everything.

--Mario
Offline DzzD
« Reply #53 - Posted 2008-11-13 21:04:08 »

Quote
It is not enough to say, well there's something wrong with the way you're doing your screen updates in the test code (as Dzzd said) and you need code to stabalize the frame rate. That's just a load of bollocks Dzzd. There's nothing wrong with the code: time the game objects update & drawing operations and then sleep for a period of time to sync the loop at sixty frames per second, or whatever frame rate you can get away with. It doesn't get much simpler than that. Coding a game loop is trivial, yet Java just doesn't seem to be

yup, this is trivial... that's the problem

I dont look very close to your code but I saw a cupple of things that make me think some things was wrong :
- the " while...; " that lock cpu and that should never exist even in C/C++ or even Basic ...
- there is too much call to system.nanotime , something is wrong : lot of call to a timer are unecessary, usually only one call is enough
- I think IMHO, that even if it is not completly crappy, computing the delay to wait the way you do it, is a wrong way and you have to found why yourself Luke "May the Force be with you"

on another hand I agree with the fact that farcry3 will not use Java... arf too bad..., but you can produce severals other kind of games using Java, but Java requiere to think Java... trying to program Java while thinking C/C++ can make you become crazy.. hum..or vice versa

EDIT: how can you see all that jirky I have an old computer an pulpcore works great ?

Offline mgianota

Senior Newbie





« Reply #54 - Posted 2008-11-13 21:36:53 »

@Dzzd: Okay, there's a strong possibility that I have hardware that Java just doesn't like very much. But, the problem is that I can write a rock-solid game using C & SDL and the timing will be 100% accurate. This code works just great on my machine so I don't think my hardware can be all that bad, I'm more inclined to think that the problem lies with Java not me. True, I should not have locked up the CPU in the while loop but I fixed that and it made no difference.

I'm just totally bemused by the way the Java code behaves, it seems to have a mind of its own and that makes me feel nervous and unsafe when I'm writing code on top of code that makes things move around unpredictably over time. All I can think about is that if the Java code is doing this to me then chances are it is going to do the same to a lot of other people too. What it boils down to is that if I use C I get no timing problems, but if I use Java I get timing problems.

--Mario
Offline princec

JGO Kernel


Medals: 343
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #55 - Posted 2008-11-13 21:40:59 »

@mgianota

I got the render loop thing licked years ago. LWJGL provides a proper timer that works pretty flawlessly on any hardware (it's the same one Windows Media Player uses, the Windows Multimedia timer) and half of the time I get vsync anyway. In fact pretty much LWJGL is the only way to go if you want to write games in Java Cheesy That's why it exists.

You could try updating your video drivers to try out my games - that's usually the only problem with Vista* - the OEM drivers are often broken. But having said that I'd really love someone to get cracking on the DirectX wrapper for LWJGL then at least we'd be able to use it.

Cas Smiley

* or you might have just been unlucky and tried to grab 'em the other day when I broke them and had to upload them about 4 times.

Offline princec

JGO Kernel


Medals: 343
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #56 - Posted 2008-11-13 21:43:43 »

FYI this is the game loop I've been using for the last 5 years or so: (it's of the fixed-at-60hz-variety, no time deltas or anything clever)
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  
   /**
    * Run the game.
    */

   private void run() {
      while (!finished) {
         // Always call Window.update(), all the time
        Display.update();
         if (Display.isCloseRequested()) {
            // Check for O/S close requests
           exit();
         } else if (Display.isActive() || alwaysRun) {
            // The window is in the foreground, so we should play the game
           try {
               Resources.manage();
            } catch (Exception e) {
               e.printStackTrace(System.err);
            }
            tick();
            render();
            Display.sync(getFrameRate());
         } else {
            // The window is not in the foreground, so we can allow other stuff to run and
           // infrequently update
           try {
               Thread.sleep(100);
            } catch (InterruptedException e) {
            }
            try {
               Resources.manage();
            } catch (Exception e) {
               e.printStackTrace(System.err);
            }
            if (Display.isVisible() || Display.isDirty()) {
               // Only bother rendering if the window is visible or dirty
              render();
            }
            Display.sync(getFrameRate());
         }
      }
   }


Cas Smiley

Offline Mr_Light

Senior Member




shiny.


« Reply #57 - Posted 2008-11-13 21:47:19 »

Unpredictable as Hell, what a headache! Does anyone get a run of the code above with zero failures?

--Mario
yes, also with 1000 iterations...  Huh

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 #58 - Posted 2008-11-13 21:57:28 »

mgianota, I think you're just victim of some bad combination of PC components, OS version, driver versions, etc. Your observations are really unusual and not normal for most of people. I understand your anger... but please calm down a little and try some constructive approach. As I mentioned, PC are assembled from many different components, and there are many versions of OSs and drivers, etc. so it sometimes happens that things go very wrong. And this is general, nothing Java specific. It's also normal that it affect specific programs such as JRE. For example, many users blamed KDE4 for slowness, when in fact some version of nVidia drivers caused that... it's not easy to distinguish the root of problem. Or some users have problem with specific antivirus programs making some apps totally unusable... and the app and it's author is unrightly blamed... and so on.

So... we should analyze what is wrong step by step and fix that. LWJGL and others projects are open source and welcome bug reports of such bad behaviour, like wrong pixel formats. Try to gather more information, stack traces, what apps works and what not, etc. and cooperate with LWJGL folks. BTW, in typical LWJGL applications there is most of calls done just by LWJGL to native layer without any JRE interfering. GC is not generally problem, I've found it's very rarely the problem, GC can do very good actually. Most of time GC is unrightly blamed first, most likely the problem is somewhere else. Also remember that nanoTime is bad on Windows platform, because QPC timer is really that bad (and native programs have different sort of workarounds for it). Try using LWJGL's Timer it should be better I think.

EDIT: better wording about GC
Offline Mr_Light

Senior Member




shiny.


« Reply #59 - Posted 2008-11-13 23:00:41 »

Weirdly enough running his draw-a-block-and-move it is jerky here too.

If I implement a old school simplistic self coded double buffered approach, it's smooth. (image still jerks a bit, what double buffing was suppose to fix.) Then again under linux I have quite some paint issues progress bars don't draw too well either out of the box.

Back in de day when 1.4 was new and crisp I remember writing horrible code - I mean freaky horrible - and we still had smooth crisp images bouncing on our screen making up a fancy game menu in an applet. (Which seemed to work everywhere)

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.
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 (7 views)
2014-07-30 21:08:39

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

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

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

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

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

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

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

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

Riven (29 views)
2014-07-23 20:56:16
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!