Pearls of Wisdom

General Discussions
#1

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 :’(, but with your help…

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

[b]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.

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

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

#2

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.

#3

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 :frowning: My game engine is based on Thread.sleep() and it’s working fine.

#4

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

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

  3. 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.

#5

I’m in great spirits already, thanks! :smiley: Interesting points bleb.

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

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!

#6

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() !

#7

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

#8

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.:

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.

  1. avoid swing if possible (but use it if you need thank kind of gui) … sorry for this huge generalisation, but I hate swing :slight_smile:

  2. 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

  3. avoid commenting trivial stuff, like set/get methodes, it’s clear what they do

  4. 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.

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

  6. 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

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

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:

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.

#10

  1. Over simplified bad advice is worse than no advice at all. Apply to the above as you see fit :slight_smile:

  2. 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

#11

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

#12

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.

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.

  1. run old tests again stuff you think you haven’t touched… yeah.

  2. 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.

  3. turn on warnings, they can always be ignored but you can’t take them inaccount if there not there.

#13

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” :smiley: … 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.

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.

reserved? :smiley:

#14

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

#15

disagreeing violently to anything is usually a bad sign.

#16

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.

#17

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:

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 :)) 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

#18

Having no plan is a plan in itself ;D

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

#19

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…”

#20

[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
[/quote]
I can’t agree enough with that.