Java-Gaming.org    
Featured games (91)
games approved by the League of Dukes
Games in Showcase (581)
games submitted by our members
Games in WIP (500)
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
  ignore  |  Print  
  Pearls of Wisdom  (Read 9843 times)
0 Members and 1 Guest are viewing this topic.
Offline CommanderKeith
« Posted 2006-10-23 19:19:47 »


I'm meant to be doing other stuff thats due very soon but I can't help myself but waste... i mean spend time here.  I'm doing an all-nighter at the moment & I'm in that bad patch at around 3:15 AM.  Please make this easier for me - there aren't enough new posts to read  Cry, but with your help...

add a little interesting / useful / tricky java tip.  Here's two I can think of:

1) Thread.sleep(int millis) is very inaccurate & usually sleeps for much longer than whatever you ask.  On windows it seems that the minimum sleep is 20ms.

2) System.currentTimeMillis() has between 35-50ms granularity on windows (but 1ms on linux & mac, apparently).  System.nanoTime() gives at least millisecond accuracy.


Also, refute any inaccuracies at will (but that went without saying   Smiley)

Offline Abuse

JGO Coder


Medals: 10


falling into the abyss of reality


« Reply #1 - Posted 2006-10-23 20:05:57 »


I'm meant to be doing other stuff thats due very soon but I can't help myself but waste... i mean spend time here.  I'm doing an all-nighter at the moment & I'm in that bad patch at around 3:15 AM.  Please make this easier for me - there aren't enough new posts to read  Cry, but with your help...

add a little interesting / useful / tricky java tip.  Here's two I can think of:

1) Thread.sleep(int millis) is very inaccurate & usually sleeps for much longer than whatever you ask.  On windows it seems that the minimum sleep is 20ms.

2) System.currentTimeMillis() has between 35-50ms granularity on windows (but 1ms on linux & mac, apparently).  System.nanoTime() gives at least millisecond accuracy.


Also, refute any inaccuracies at will (but that went without saying   Smiley)

Pearls of Inaccurate Widson!?

Under WindowsXP I get a mean average minimum sleep of ~2.1ms.
again, under WindowsXP the granuality of System.currentTimeMillis() is 15 or 16ms

What version of windows did you get your metrics from?!

I know the granuality of System.currentTimeMillis() on Win98 is ~55ms.

Make Elite IV:Dangerous happen! Pledge your backing at KICKSTARTER here! https://dl.dropbox.com/u/54785909/EliteIVsmaller.png
Offline Kova

Senior Member





« Reply #2 - Posted 2006-10-23 20:09:19 »

I can confirm that on Windows based on NT Thread.sleep() is accurate enough, the problems are on windows 98/ME/95 with resolution up to 50ms Sad My game engine is based on Thread.sleep() and it's working fine.
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline ryanm

Senior Member


Projects: 1


Used to be bleb


« Reply #3 - Posted 2006-10-23 20:13:14 »

3) Avoid synchronizing on a Swing component, as the tooltip system does the same, leading to deadlocks with very, very large stack traces  Undecided In fact, in general, avoid synchronizing on any object that is visible to other subsystems

4) PriorityQueue.remove() uses the comparator to decide object identity (Fixed in 1.6)

5) Set your IDE to nag you for missing JavaDoc for public interfaces. You'll write more javadoc, which is generally a good thing, and you'll find your public interfaces become much more succinct as you strive to avoid writing unnecessary documentation.
Offline CommanderKeith
« Reply #4 - Posted 2006-10-23 21:04:18 »

I'm in great spirits already, thanks!   Cheesy  Interesting points bleb.

Inaccurate Widson maybe, but I suppose it worked out for the better since you and Kova have refined my exaggeration  Tongue.

6 ) A BufferStrategy with 2+ buffers in full screen mode is currently the only thing that can give you vertical-retrace sync'ing in MS WIndows to prevent 'tearing'.

7 ) A thread doing someInt = 7; can pause half-way through, allowing another thread to re-assign or read the half-written field.  Only 'atomic' primitive variables which are booleans and shorts are done in one go & can't be half-done.  Object assignment is always by reference so it is atomic.  non-atomic primitive field access by more than one thread needs to be synchronized in a sync block or using the new concurrent API methods.

8 ) Technically, only repaint() and revalidate() should ever be called from outside Swing/AWT's Event Dispatch Thread, no other Swing methods are thread-safe.  (not even setText(), getText(), etc)

... keep them coming please!

Offline CommanderKeith
« Reply #5 - Posted 2006-10-23 21:42:28 »

Under WindowsXP I get a mean average minimum sleep of ~2.1ms.

I can confirm that on Windows based on NT Thread.sleep() is accurate enough, the problems are on windows 98/ME/95 with resolution up to 50ms Sad My game engine is based on Thread.sleep() and it's working fine.

By the way, testing Thread.sleep() is pointless since if you run lots of programs in the background then the OS may return the/a processor to you whenever it feels like it - so don't rely on Thread.sleep() !


Offline kevglass

JGO Kernel


Medals: 85
Projects: 25


Coder, Trainee Pixel Artist, Game Reviewer


« Reply #6 - Posted 2006-10-24 00:13:19 »

6 - check out PXSync for a way to use vsync in windows mode using Java 2D. I used it in mini adventure quite happily.

Kev

Offline Kova

Senior Member





« Reply #7 - Posted 2006-10-24 03:17:30 »

7 ) A thread doing someInt = 7; can pause half-way through, allowing another thread to re-assign or read the half-written field.  Only 'atomic' primitive variables which are booleans and shorts are done in one go & can't be half-done.  Object assignment is always by reference so it is atomic.  non-atomic primitive field access by more than one thread needs to be synchronized in a sync block or using the new concurrent API methods.

7 ) - On the other hand, I've got information that every operation on primitives except long and double are atomic. Quote from "Java Threads 2nd edition" published by O'Reilly in 1999.:

Quote from: Java Threads 2nd edition
The Java specification guarantees that setting any variable other than a double or a long is atomic, so in this example, it does not matter if multiple threads attempt to set the flag at the same moment.

BUT, due to how java uses memory (quick explanation: data may be cached) this does not guarantee that multiple threads will handle a variable properly since one of them may not notice that variable has been changed by another thread. So use VOLATILE on every primitive that is accessed by multiple threads.

------------------------------------------------------------------------------------------------------------------
9) avoid swing if possible (but use it if you need thank kind of gui) ... sorry for this huge generalisation, but I hate swing Smiley

10) if you work on a big project or/and with partners, try to comment every significant line in your code what it does, like ....
some_code;   // Kova: this does this and that

11) avoid commenting trivial stuff, like set/get methodes, it's clear what they do

12) before every project, make a perfect plan how you'll do it, plan every bit of it and even implemantation. If you're serious about your project don't just start and think you'll add things as needed or as they came to you. That way when you add new stuff you notice that it would be better if you coded stuff before different way and you must tweak all your previous code, and sometimes as you want to impelment new feature you notice that you completely replace an old one that you programmed for days, plus the code turns out to be not so OO and is not so refactorable.

13) if you are wokring with swing, be very patient, it take lots of time and code but thing works

14) as soon as you can, test what you have written, don't write multiple stuff all in once thinking you'll test it all when you're done with them
Offline CommanderKeith
« Reply #8 - Posted 2006-10-24 06:37:25 »

6 - check out PXSync for a way to use vsync in windows mode using Java 2D. I used it in mini adventure quite happily.

Thanks Kev, I've still got it bookmarked from when you mentioned it in the J2D forum.

7 ) - On the other hand, I've got information that every operation on primitives except long and double are atomic. Quote from "Java Threads 2nd edition" published by O'Reilly in 1999.:

Quote from: Java Threads 2nd edition
The Java specification guarantees that setting any variable other than a double or a long is atomic, so in this example, it does not matter if multiple threads attempt to set the flag at the same moment.

BUT, due to how java uses memory (quick explanation: data may be cached) this does not guarantee that multiple threads will handle a variable properly since one of them may not notice that variable has been changed by another thread. So use VOLATILE on every primitive that is accessed by multiple threads.

Oops, you're right, thanks Kova.  This leads to:

15 )  Don't take advice from Keith!

Yeah in my example (someInt = 7;) assignment is atomic, but not for the 64bit numbers like you said.  I was thinking of someInt += 7; or someInt++; which isn't atomic.  Roedy Green says stuff about this here:

http://www.velocityreviews.com/forums/t148575-how-does-java-make-assignments-atomic.html

By the way, don't you think you're points 12 & 14 conflict a little - 12 says have a set-out plan while 14 sounds like an 'agile' approach where you code as you go.  Don't you find yourself always moving the goal-posts on your project as you get nearer and nearer, abandoning the original plan?

16 )  The SWT (IBM/Eclipse's rival toolkit to AWT & Swing) doesn't have an event dispatch thread, which causes problems for Swing, but unfortunately it does everything using heavyweight components, ie native components that can't have their graphics easily over-ridden.  No Look and Feels in SWT, but its faster than Swing since its painted in native-code.


Offline kevglass

JGO Kernel


Medals: 85
Projects: 25


Coder, Trainee Pixel Artist, Game Reviewer


« Reply #9 - Posted 2006-10-24 07:22:34 »

17) Over simplified bad advice is worse than no advice at all. Apply to the above as you see fit Smiley

18) Or maybe better, take everything you read here with a pinch of "oh what a lovely day" salt.

9,10,11,12 are either opinion or *very* sunny day view. Hardly what I'd call pearls of wisdom.

Oh, what happened to 8 also?

Kev

Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline CommanderKeith
« Reply #10 - Posted 2006-10-24 08:31:55 »

The title was meant to be sarcastic.

Well, thanks for the input everyone, the points were great - its very useful to find out about problems the easy way like this.

Keith

Offline Mr_Light

Senior Member




shiny.


« Reply #11 - Posted 2006-10-24 09:18:41 »

10) if you work on a big project or/and with partners, try to comment every significant line in your code what it does, like ....
some_code;   // Kova: this does this and that
I generaly disagree comment methods, classes, packages and programs; not lines of code if you feel you need to comment lines then perhaps you should reevaluate your design. imo offcourse.
11) avoid commenting trivial stuff, like set/get methodes, it's clear what they do
is it? what happens if you pass null? the almost seemly perfectly named variable can be interperterd differendly. Also the unit's are deciving is padding in % px em? etc etc marking stuff as trival is dangerous. if comments bug you enable auto folding comments or upgrade to a better ide.

19) run old tests again stuff you think you haven't touched... yeah.

20) configuration files are subject to the same stuff as your code order it have a single point of definition if something overrides the other document it. and use overriding of configuration. Spring config is perhaps a good example I hear ppl bitch about 'those xml config files' if your injections on beans mostlyt look the same try evaluating if the use of inject upon abstract classes might be usefull.

21) turn on warnings, they can always be ignored but you can't take them inaccount if there not there.

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 Kova

Senior Member





« Reply #12 - Posted 2006-10-24 12:26:46 »

OK I may misunderstood what this topic is about, though we were talking about opinions and own experience, not absolute good advices applied to everyone, that should be clear from "I hate swing"  Cheesy .... So hell yeah, 9-14 take with consideration.

@Keith
no 12 and 14 don't conflict, 14 is about you testing something as soon as you complete it even if it's something small, it's not meant to advise how to develop. Like, you are coding movement of your player and you first make it go left and then test it right away. My advice is not to code whole thing first, go left, right, up, down, jump, shoot, switch weapons and so on, and then do testing afer you think you're done with all of that.

Also on 7) i said "On the other hand, I've got information that every operation on primitives except long and double are atomic", so operation is a bad choice of words, every assigment is atomic.

17) Over simplified bad advice is worse than no advice at all. Apply to the above as you see fit Smiley

Only for people that did not put any thought about it and just did what someone else told them... I like to think we don't have such people here on JGO.

Oh, what happened to 8 also?

reserved?  Cheesy
Offline blahblahblahh

JGO Coder


Medals: 1


http://t-machine.org


« Reply #13 - Posted 2006-10-24 13:36:07 »

7 ) A thread doing someInt = 7; can pause half-way through, allowing another thread to re-assign or read the half-written field.  Only 'atomic' primitive variables which are booleans and shorts are done in one go & can't be half-done.  Object assignment is always by reference so it is atomic.  non-atomic primitive field access by more than one thread needs to be synchronized in a sync block or using the new concurrent API methods.

7 ) - On the other hand, I've got information that every operation on primitives except long and double are atomic. Quote from "Java Threads 2nd edition" published by O'Reilly in 1999.:

Quote from: Java Threads 2nd edition
The Java specification guarantees that setting any variable other than a double or a long is atomic, so in this example, it does not matter if multiple threads attempt to set the flag at the same moment.

BUT, due to how java uses memory (quick explanation: data may be cached) this does not guarantee that multiple threads will handle a variable properly since one of them may not notice that variable has been changed by another thread. So use VOLATILE on every primitive that is accessed by multiple threads.

------------------------------------------------------------------------------------------------------------------
9) avoid swing if possible (but use it if you need thank kind of gui) ... sorry for this huge generalisation, but I hate swing Smiley

10) if you work on a big project or/and with partners, try to comment every significant line in your code what it does, like ....
some_code;   // Kova: this does this and that

11) avoid commenting trivial stuff, like set/get methodes, it's clear what they do

12) before every project, make a perfect plan how you'll do it, plan every bit of it and even implemantation. If you're serious about your project don't just start and think you'll add things as needed or as they came to you. That way when you add new stuff you notice that it would be better if you coded stuff before different way and you must tweak all your previous code, and sometimes as you want to impelment new feature you notice that you completely replace an old one that you programmed for days, plus the code turns out to be not so OO and is not so refactorable.

13) if you are wokring with swing, be very patient, it take lots of time and code but thing works

14) as soon as you can, test what you have written, don't write multiple stuff all in once thinking you'll test it all when you're done with them

9, 10, 11, I disagree with violently and believe are certainly not "pearls of wisdom".

malloc will be first against the wall when the revolution comes...
Offline g666

Junior Member





« Reply #14 - Posted 2006-10-24 14:22:41 »

disagreeing violently to anything is usually a bad sign.

desperately seeking sanity
Offline Breakfast

Senior Member




for great justice!


« Reply #15 - Posted 2006-10-24 15:26:52 »

I would quibble with the documentation suggestions, which could be replaced by "document anything which isn't obvious."

I would perhaps replace both with "No matter what language you are working in or platform you are developing make sure you have read Code Complete."  That will give you all the coding methodology advice you could possibly need.
Offline kevglass

JGO Kernel


Medals: 85
Projects: 25


Coder, Trainee Pixel Artist, Game Reviewer


« Reply #16 - Posted 2006-10-24 20:37:29 »

Quote
Only for people that did not put any thought about it and just did what someone else told them... I like to think we don't have such people here on JGO.

Unfortunately the world is full of people looking for absolute answers in development. Hence why pearls of wisdom would be really useful to saite them. As to whether we have them here on JGO, I think it's fairly obvious we do if you just look at a fair amount of the questions posed.

If anyone is interested in my *opinion* this one really irks me:

Quote
12) before every project, make a perfect plan how you'll do it, plan every bit of it and even implemantation. If you're serious about your project don't just start and think you'll add things as needed or as they came to you. That way when you add new stuff you notice that it would be better if you coded stuff before different way and you must tweak all your previous code, and sometimes as you want to impelment new feature you notice that you completely replace an old one that you programmed for days, plus the code turns out to be not so OO and is not so refactorable.

I think it's increadibly naive to believe that you can make a "perfect plan" - things change, ideas spawn from implementation (not so much in enterpise style stuff, but plenty in games). It's good to have a plan and a general shape to the software you're aiming at - but believing you have the perfect plan and trying to stick to it even when it's not working out is where time gets wasted during development. You mention refactoring but if you had the "perfect plan" you wouldn't need to do it - it'd already be perfect.

Given we agree this view is based on experience now, how many projects have you completed in this way without deviating from your perfect plan. I've worked on about 30 large scale projects commercially (not games of course Smiley) and 2 complete games projects in my spare time. I can't remember any of them sticking to plan or timescale "perfectly" - feature creep is scary but factoring in some contingency into the plan normally copes with the bulk of it.

Obviously just an opinion,

Kev "I hate absolutes" Glass

Offline darkprophet

Senior Member




Go Go Gadget Arms


« Reply #17 - Posted 2006-10-24 21:56:52 »

Having no plan is a plan in itself  Grin

* darkprophet tries to remember the last time he had a "plan"

Friends don't let friends make MMORPGs.

Blog | Volatile-Engine
Offline Breakfast

Senior Member




for great justice!


« Reply #18 - Posted 2006-10-25 01:38:38 »

My game-writing plan can be summed up by "What you're doing is ambitious enough in itself, don't get ambitious with extra stuff..."
Offline grazi

Senior Newbie




Life > Games > All


« Reply #19 - Posted 2006-10-25 01:47:08 »

Quote
Given we agree this view is based on experience now, how many projects have you completed in this way without deviating from your perfect plan. I've worked on about 30 large scale projects commercially (not games of course ) and 2 complete games projects in my spare time. I can't remember any of them sticking to plan or timescale "perfectly" - feature creep is scary but factoring in some contingency into the plan normally copes with the bulk of it

I can't agree enough with that.

Jeff Olson
Offline CommanderKeith
« Reply #20 - Posted 2006-10-25 12:40:07 »


22) This is for 2D games with a moving view (like a side-scoller or an RPG) that have a background painted using images and java2D primitives like lines & java.awt.Shapes.  When an AffineTransform is used to move the view, you may notice 'jiggle', where the images and shapes move relative to each other even though they're meant to be a static background.  The reason is that the images are painted on the nearest pixel, but the shapes can be painted across pixels.  To fix it, just set the AffineTransform's translate operation to an integer, not a decimal and then there shouldn't be any jiggle since both shapes and images will be painted to the nearest pixel.

Offline Breakfast

Senior Member




for great justice!


« Reply #21 - Posted 2006-10-25 15:01:45 »

23. Think in detail what you are going to build and make as much of a plan as possible before you start. Then look at all the available libraries and other resources that can give you a head start. Writing a game is such an epic task in itself that you're going to need all the help you can get if you're ever going to get it finished.
Offline Ask_Hjorth_Larsen

Junior Member




Java games rock!


« Reply #22 - Posted 2006-10-26 03:03:43 »

Cool avoid combinations of parentheses and numbers that result in smileys instead of other things.

EDIT: Also, always read the thread properly
Offline blahblahblahh

JGO Coder


Medals: 1


http://t-machine.org


« Reply #23 - Posted 2006-10-26 04:35:07 »

disagreeing violently to anything is usually a bad sign.

Sorry, what do YOU do in the Games Industry? Are you a full-time Lead? If not ... what are you talking about? I'm talking from the position of a professional who's been working in the games industry for almost a decade.

Of course, maybe I have no idea what I'm talking about. Unlikely, but I'm willing to entertain the idea...

malloc will be first against the wall when the revolution comes...
Offline pepijnve

Junior Member




Java games rock!


« Reply #24 - Posted 2006-10-26 10:08:51 »

24) Make sure you have a basic understanding of what the java memory model guarantees you before trying to reason about how threads interact.
25) Try to use high level concurrency primitives where possible. Sprinkling 'synchronized' around your code is deadlock prone.
Offline erikd

JGO Ninja


Medals: 15
Projects: 4
Exp: 14 years


Maximumisness


« Reply #25 - Posted 2006-10-26 19:07:24 »

I write every line of code with the thought that I'll have to refactor it later (so I try to only write code that's easily refactorable).
My reasoning is that I don't have a complete plan of the game that I'll end up creating as I tend to get inspired with features when things start to get playable and fun. Which is the point where I want to get asap, so I know if it'll be worth it at an early stage.

Dunno if this is worth being number 26, but there you go  Smiley

Offline kevglass

JGO Kernel


Medals: 85
Projects: 25


Coder, Trainee Pixel Artist, Game Reviewer


« Reply #26 - Posted 2006-10-26 20:56:09 »

Quote
Sorry, what do YOU do in the Games Industry? Are you a full-time Lead? If not ... what are you talking about? I'm talking from the position of a professional who's been working in the games industry for almost a decade.

Hey, come off it, he's definitely right - disagreeing violently can be bad for your health (see blood pressure). Are you allowed to tell us what you do for a living now? I'm sure quite a lot of folks would be interested and excited.

I came up with a new one:

27) Always change the diaper first, then the outfit - or run the risk of pee all over it. I know, I know, but I'm learning Smiley

Most everything thats been mentioned here is good software practice generally. Good stuff.

Kev

Offline blahblahblahh

JGO Coder


Medals: 1


http://t-machine.org


« Reply #27 - Posted 2006-10-27 12:18:47 »

Quote
Sorry, what do YOU do in the Games Industry? Are you a full-time Lead? If not ... what are you talking about? I'm talking from the position of a professional who's been working in the games industry for almost a decade.

Hey, come off it, he's definitely right - disagreeing violently can be bad for your health (see blood pressure). Are you allowed to tell us what you do for a living now? I'm sure quite a lot of folks would be interested and excited.

Sorry if I misunderstood g666's intention, but I took it to be that disagreeing violently was generally a sign of being wrong

I have seen people lose their jobs over doing stuff as stupid as the points I disagreed with. I consider it extremely poor to advise people to do that. Several people I know were actually *taught* to do it, and that's grossly unfair - I'd go to a lot of effort to try and prevent anyone else from being screwed that badly.

malloc will be first against the wall when the revolution comes...
Offline oNyx

JGO Coder


Medals: 1


pixels! :x


« Reply #28 - Posted 2006-10-27 13:29:51 »

Haha... making a perfect plan... yea right Grin

28) Prototype.

If you're doing something different, prototype it. Many things which sound fun in theory dont work in reality at all. Or they require lots of drastic changes and experimentation.

Fuzetsu for example wasnt planned at all. It "grew" into that direction and after dozens of iterations (yay for scripting) I had something which was fun.

弾幕 ☆ @mahonnaiseblog
Offline Breakfast

Senior Member




for great justice!


« Reply #29 - Posted 2006-10-27 15:29:54 »

I'm currently trying to prototype my turn-based combat mechanic in Flash. That way I will know what I want to build in Java before I start and hopefully have ironed out most of the "not fun" variants on it.

It's reminding me why I hate ActionScript so much...
Pages: [1] 2 3
  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.

xsi3rr4x (64 views)
2014-04-15 18:08:23

BurntPizza (62 views)
2014-04-15 03:46:01

UprightPath (75 views)
2014-04-14 17:39:50

UprightPath (58 views)
2014-04-14 17:35:47

Porlus (76 views)
2014-04-14 15:48:38

tom_mai78101 (101 views)
2014-04-10 04:04:31

BurntPizza (161 views)
2014-04-08 23:06:04

tom_mai78101 (256 views)
2014-04-05 13:34:39

trollwarrior1 (209 views)
2014-04-04 12:06:45

CJLetsGame (216 views)
2014-04-01 02:16:10
List of Learning Resources
by SHC
2014-04-18 03:17:39

List of Learning Resources
by Longarmx
2014-04-08 03:14:44

Good Examples
by matheus23
2014-04-05 13:51:37

Good Examples
by Grunnt
2014-04-03 15:48:46

Good Examples
by Grunnt
2014-04-03 15:48:37

Good Examples
by matheus23
2014-04-01 18:40:51

Good Examples
by matheus23
2014-04-01 18:40:34

Anonymous/Local/Inner class gotchas
by Roquen
2014-03-11 15:22:30
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!