If your class is immutable then you could parameterise it using a generic type along these lines:



However this will quickly break down if you need your class to do anything vaguely useful such as addition (e.g. try using a += operator in that class!)

Check out the Point2D classes in the java.awt.geom package which does something similar.

This is OK for small projects but quickly breaks down as your complexity grows. If you group classes simply by their type the chances are that most of the classes in that package will be unrelated but are dependant on code in other simlarly grouped packages.  This leads to unneccessary coupling, i.e. you will have cross-package dependencies which could be avoided, making the structure of your code more difficult to follow.

Instead, group classes by purpose.  For example, I have an animation package that defines an animation interface, some useful base classes and helpers and a controller that actually runs animations.  However the actual animation implementation classes live in the packages where they are used: I have an animator for particle systems, it lives in the particle system package, not in the animation package.  Ditto audio player, rotation animator, etc.

So the implementation classes live in the areas that they belong in and are not grouped by type.  This reduces dependencies (one of your requirements) and keeps related code together, making it easier to comprehend.


Sounds like you've already gone some way down this path by seperating your generic library code into a different project.

As an example: for my 3D terrain work I have the following projects:
- generic library code: higher-level collections, random utilities, etc.  Could be used in just about project.
- general 3D code: shaders, VBOs, texture management, matrices, lighting, etc.  Can be used in any 3D project.
- terrain engine: terrain loader and management, skybox, weather, day/night cycle, terrain following, etc.  Specific higher-level stuff for terrain-based 3D projects.
- various terrain demos:  i.e. the actual applications using the engine.

Each is dependant on the one(s) above it.


I find a high-level UML package structure diagram and class diagrams for the more complex packages is sufficient documentation, even if it's just a back-of-a-fag-packet diagram.  Attempting to document every class and method is going to be a huge task and is generally pointless: the diagrams will become out-of-date over time as your design evolves, they eventually end up being write-only documents and confuse more than they help.  Therefore I would suggest simple and quick diagrams that you can easily amend or replace (note this is pretty much the approach in the real IT world!)

If you have some fairly complex algorithms it might also be worth outlining the approach as flowcharts or UML activity/interaction diagrams.

Also, don't overlook JavaDoc: it's structured and can be used to explain how a class (or set of related classes) should be used from the perspective of a third-party developer (even if that's you).  If you use an IDE like Eclipse than it will pop up the JavaDoc if you hover over a class/method/member which is a nice side-benefit.

Finally do you write unit-tests for your code?  If not check it out.  One side-benefit of unit-tests that is often overlooked is that they are essentially documentation for your code.


One other thought springs to mind: try to keep the complexity of individual classes and packages low so that it's easier to understand how they should be used.

There's a few ways to achieve this:

- Use encapsulation:  i.e. avoid making every class, method and member public - if it doesn't need to be exposed then hide it.  This makes the 'API' of your code neater and easier to understand.

- Reduce mutability: An immutable object is almost always easier to understand and use.  If you need a mutable version, consider two implementations and only expose the immutable one.

- Avoid deep class hierarchies: Inheritance has it's place but it quickly becomes complex and brittle the deeper the hierarchy is.  Check out some of the SWING UI classes for an example of how not to use inheritance, some of them have over 100 public methods!

- Consider extracting complex code into helper classes or methods: it will be easier to comprehend and maintain if the code is broken down into manageable chunks.

You don't mention what technologies and frameworks you are using, but not too worry the approach is generally the same.

Basically you are talking about game state, i.e. whether the character is jumping or not in your scenario.

Presumably you have some sort of callback handler that starts the jump when you press the button, and possible some sort of listener that knows when the jump animation has completed?  You'll need to check whether you're already jumping, plus you need some means of letting it know when the jump has ended, i.e. something along these lines (in pseudo code):



The jumping boolean is the game state.

The above is very crude but hopefully you get the idea.

I'm quite an aggressive re-factorer, if (for example) I find I've been unconciously using cut-and-paste code code that needs condensing into some common base-class or helper.  The only thing I would caution against is re-factoring as procrastination, i.e. fiddling with the code rather than actually implementing something

For optimisation:  I try and aim for the 'cleanest' code that implements what I want and then profile to see what is bottle-necking (if anything), even if that's crude timer blocks around a section of code.  I'm definitely in the camp of avoiding prior optimisation, again it's easy to get bogged down in the details of trying to write some super-efficient section of code which doesn't actually need optimisation in the first place (and you end up making is complex and messy and thus bug-prone).

I guess it can be considered just a matter of semantics, but I have actually separated my code-base into two sub-projects, called - you guessed it - library and engine.

As you suggest, the 'library' consists of the common building blocks that could be used in any application, such as: VBOs, texture loading, input handling, networking, model loaders, shader management, etc.  (building on top of LWJGL in this case)

Whereas the 'engine' is slightly more application-specific and builds upon the library to provide stuff such as (for example, if we're building a fantasy MMO) terrain/level management, day/night cycle, weather, etc.  If you were building for a slightly different genre (say space games) then you may well create a different engine adapted to that genre, but would still re-use the same library (VBOs are VBOs whether its an MMO or space game).

In turn one could then take an 'engine' to create (to follow the example) a fantasy MMO game using the facilities it provides with little or no further coding, just design and config.  In fact this is way that most games companies work, not many actually develop their own engines, they tend to buy or lease off-the-shelf products that are optimised for the type of game they are aiming for and then configure/design the game using editors and other tools.

Some 'engines' are so powerful and comprehensive that they could be used for just about any application or genre, e.g. Unity, Unreal 3, etc.

However ultimately it's your baby so you can call 'it' what you want

- stride

As the previous posters have suggested this is a difficult question to answer without knowing what 'direction' you want to take.

Can I suggest you choose an application or game as a target to aim for (however ambitious it might seem!) and then I'm sure people will be able to offer some suggestions.

e.g. do you want to create a first-person dungeon shooter, an MMO-style world, a space game, a free-form minecraft-esque world editor, etc etc.

Hope this helps.

- stride

When you say generic do you mean Java generic?  i.e. You'd want the same code but for integer, float, double, etc. as required?


If the intervals are not the same size then I think the answer is no, the approach of iterating through the intervals seems the simplest (and the most efficient).

If you implement the filter method as you suggested (to return 1, 2, 3, etc) then 'scale' is redundant.

I thought the OP was asking for the results to be in the range 0/100/200.  You could use your approach (without the +1 at the end) and multiply the result by 100, the results would be the same I think.

Also, encapsulate the code into a class and pre-calculate the 'fixed' stuff as class members, i.e. work out the range, step and scale values once in the constructor to avoid having to calculate them on every call of the filter() method.

If your 'slices' are all the same size (steps of 100 in your example) then you could use simple integer maths to do a sort of stepped linear interpolation, something along these lines:



where 'slices' would be 3.

Note that the brackets and casts are important for this to work.

If your steps/slices are *not* the same size then you'll have to use some sort of table approach.

Thanks for the responses guys, lots of good suggestions and pointers, exactly what I was hoping for.

Cheers 

- stride

And just for illustration here's a screenshot of a single chunk terrain.

I now have a working terrain application which currently consists of a single terrain mesh and I'm thinking through the design for extending this to a continuous terrain engine.

The structure of each terrain 'chunk' is as follows:
- 512 x 512 grid of vertices stored in an interleaved VBO.
- Each vertex consists of a 3-float vertex position (X-Z grid, height in Y direction), 3-float normal and 2-float texture coordinate.
- Index buffer specifying the terrain grid as a single triangle-strip with degenerate triangles on the end of each row.
- Single VAO covering the terrain segment.
- Vertex and fragment shaders for rendering, fog and lighting.
- One-or-more textures used in the fragment shader to render sand, grass, rock, snow, etc. depending on height or slope.

The application loads and creates terrain chunks on the fly on a background thread and adds them to the scene as needed depending on where the camera is in the 'world'.

Now this works fine for the relatively trivial case of a single chunk of terrain, but will clearly not scale up to a terrain extending to the 'horizon' consisting of (perhaps) around a couple of hundred chunks.  The first naive implementation simply uses multiple instances of these chunks, but even with a handful it's clear that rendering performance will be poor.

So I need to start optimising the design and would appreciate any thoughts or ideas from anyone that have tried similar projects before I dive in.

Some obvious optimisations spring to mind:

- Collapse the terrain vertex data into 'compound' VBOs (or maybe even just one VBO).  This would reduce the number of VBO/VAO state changes, at the cost of additional complexity.  But might it also reduce rendering performance?

- Consider using 'smaller' data types for the position, normal, texture coordinates, rather than the default 4-byte float - is this viable?  logical?

- Use smaller terrain chunk sizes?  512 x 512 equates to around 8Mb of data per chunk which I suspect is quite a lot?

- Share the index buffer across all terrain chunks.

- Create lower LOD terrain chunks for more distant terrain (in addition to rendering LOD) and replace these with higher LODs as required (and discard higher LOD chunks as they become redundant).

- Investigate geometry and tesselation shaders as a possible means of generating the X-Z and texture coordinates using the vertex index?

However the biggest bottle-neck seems to me to be the amount of redundant data, namely the X-Z grid positions and texture coordinates.  These are the same for every terrain chunk.  DirectX supports (AFAIK) the idea of vertex streams, i.e. a mesh can be comprised of multiple VBOs, in this case we would have one for the static data that is the same for every chunk, and individual VBOs for the height-data.  Does OpenGL have the same mechanism, because I can't find it if it does?

Any opinions, thoughts, suggestions, etc. on the above is appreciated in advance  

- stride

Thanks for the feedback guys, lots of food for thought there.



Very true, don't get me wrong I'm a developer at heart and love the challenge and creativity of programming, I was showing my cynical side when I said that I had no desire to learn a new programming language

For reference http://www.tiobe.com/index.php/content/paperinfo/tpci/index.html is handy to keep tabs on language popularity (from a potential job perspective).

I'm actually quite enthused about this objective now, if anyone's interested I'm thinking of giving Ruby or Ruby on Rails a go:

* it's an OO language, so it will be interesting to compare and contrast with Java as I port my 3D software.

* as a couple of posters mentioned it's often used in the back-end (we actually do use it in my organisation, just not in any of the areas I've been involved in as yet).

- stride

OK so this isn't a Java / OpenGL question but bear with me...

I'm a Java enterprise developer by trade.  Following my last review I've been given a personal development objective to expand my programming skills beyond Java - specifically Ruby and/or Scala.  Now frankly I've little interest in learning other languages having invested more years than I care to remember in Java and associated technologies, also the marketplace for Ruby or Scala skills is negligible compare to Java or (for example) C#, so why bother!?

But it occurs to me that I could learn another language by porting the Java / LWJGL code-base I've built up over the years, thus satifying the personal objective and doing something that I would be interested in.  I believe there are OpenGL bindings for both the languages - correct?

So I'm interested in the experiences of the JGO community:  Do any of you use these languages as an alternative to Java?  Anyone offer any recommendations, pitfalls to avoid, suggestions, other thoughts, etc?

Thanks in advance for any thoughts.

- stride

If the file is on your class-path (which it seems to be) then an alternative could be this:

I've highlighted the offending lines, assuming I correctly identified the problem (I didn't try to compile/run the code).

public class Screen extends JPanel implements Runnable {
   public static Thread thread = new Thread();
  
  public static Ball ball;     <-- this is the class member that never gets created
  
   public Screen(){
      thread.start();
   }


This method doesn't seem to get called anywhere, so 'ball' is null.  
     public void define(){
      ball = new Ball(0, 0, 50, 50);
   }
 
   public void paintComponent(Graphics g){
      
      
      g.setColor(new Color(0,0,0));
      g.fillRect(0, 0, Frame.size.width, Frame.size.height);
      
      g.setColor(new Color(0,50,0));
     ball.draw(g); <-- which causes the null pointer exception (NPE) here (I think)
      
   }
  
   @Override
   public void run() {
      while(true){
         repaint();
        
        
         try {
            Thread.sleep(1);
         } catch (InterruptedException e) {
            // TODO Auto-generated catch block
            e.printStackTrace();
         }
      }
   }
}

What are you using to develop the code?  Do you have a debugger so you can step through, that's the best way of tracking down bugs?

Hope this helps.

- stride

EDIT: Why can't I make stuff bold within a code block ffs

The Ball class member in your Screen class is never created which causes the NPE I think.  You have a define() method to create it but it never gets called as far as I can tell.

EDIT: Although I would have then expected the error to report line 29 in that case, if cas in the previous post is correct it would be line 27, odd

I think you're making a mistake in considering unit-test code to be 'extra work' and 'little value', this is often the response I get from new or junior engineers (not meant to be a slur btw!) who have yet to have the epipheny moment.  Personally I now feel nervious (and dirty ) if I have code that doesn't have comprehensive test coverage.

There are some obvious positives to unit-testing:

- It's a lot easier to fix any bugs or design flaws when the code is fresh in your memory, rather than finding them days or even years later.

- Sections of code are often inter-related (especially highly coupled code like deep inheritance hierarchies), you make a change here and might inadvertently knacker something in an unrelated section over there, how are you going to ensure all your code still works after making changes without a test suite?

But there are some more subtle benefits as well:

- If you develop the unit-tests and code in parallel you are effectively exercising your design as you code, i.e. you become a sort of 'user', and can therefore spot and resolve any design flaws sooner rather than later.  I've often found myself thinking "this sucks" and completely redesigning a class or package.

- Unit-tests are also essentially documentation for how to use your code, again handy if you come back to re-use a chunk of code and need a refresher on how it works.

Of course if you're a hobbyist then you can do what you like but I'd advice you to give the above some consideration.  Try it, you might just like it.

Any pattern or language construct can be an anti-pattern when used badly or in the wrong circumstances.  Singletons are often used for the wrong reasons or implemented incorrectly, but they do have their place, a good example is to access the 'global' sound system when using OpenAL.


Burn him!

I assume you're implementing some sort of loot table.  I've previously used something along the lines of the following:



The LinkedHashMap orders the entries by insertion order.  The code is pretty crude (just boshed it out from memory), you'd probably want to add some checks to ensure that the percentiles total 100.

You mention efficiency - did you mean speed or storage space or both?  Personally I wouldn't worry in either case, I assume this would not be a performance-critical part of your code (correct me if I make the wrong assumption) so just design whatever is the easiest to maintain.

Also is there any reason why you were using item IDs instead of the items themselves (I used Object in the above)?


The insertion order technique means you don't need to worry about ranges of the same value.

An alternative is to just use a simple Map and insert multiple entries to emulate percentile ranges.
e.g. in your example you would add items 1 and 3 once, but item 2 three times, and just used a random value in the range 0 to size-of-table (5) to select one out.

Hope this helps.

Really depends on what each square in your level map represents.  For example, if it's just (say) the colour of that tile then you could easily represent that as a simple in-memory 2D array for a a few 10s of Mb.  If however you're talking about height-map data, references to textures, objects within the world, etc. then that approach will obviously break down very quickly.


All games that have large maps use pagination.

The 'world' is segmented into tiles (or chunks of the map) and only those in view reside in memory.  As the character avatar or camera or whatever moves around the map, chunks are loaded into memory and added to the view, chunks that are no longer needed are discarded (usually on a background thread with suitable caching).  What data is in each tile and the granularity of the tiles is really down to the individual application / game.

I've used this approach to represent very large 3D world maps with each tile containing the actual terrain height-map with additional information such as cosmetic objects (trees models, rocks, etc), lighting, ambient colours, AI spawn/routing data, yada yada.

Couple of suggestions you may want to consider:

1. Encapsulate the code that extracts the text from between the XML tags into a helper method:
- you can then write a unit-test to make sure that chunk works
- the code that's doing the actual parsing will then be a lot cleaner (and therefore less buggy / easier to maintain)
- and you won't be cut-and-pasting and hard-coding the end index when you add further functionality, further reducing chances of cock-ups

2. Avoid duplicating the indexOf() call - OK the performance of doing it twice is probably hardly game-breaking but it's good practice.

3. Is there a reason you're not just throwing exceptions for the cases where the file is not valid (no <version> tag)?  You'll have to check elsewhere that the vertex/fragment shader is potentially empty which (presumably) is a pretty fatal scenario, so you might as well handle that explicitly with an exception.

-stride

You cannot create an array of a generic type, it's an inherent limitation (or perhaps restriction is a better term) of the compiler.  If you do a google search for "array of arraylist" you'll see lots of people with the same question.

There are a couple of nasty workarounds:
- use Array.newInstance() and cast the result
- use ArrayList<ArrayList<Thing>>( size );

But you should probably consider a redesign that doesn't require you to 'mix' an array of lists.

You'd need to use the File(URI) constructor:



Probably easier to get an input-stream though:

Not sure exactly what your requirement is - are you saying you want to check that the 4 buttons in array2 are members of array1?

If so something along these lines:



If your array1 is already sorted you could use:

Sorry if I came across as challenging, I was actually attempting to be constructive lol.


Running the test you posted (and a couple of others to compare add() and clear() ) to compare an ArrayList using Iterator.remove() against ReadWriteCollection shows no difference on the three machines/JVMs I tried it on, execution times were roughly the same irrespective of the size of the data, number of iterations, random or specific data, etc.  In fact ArrayList was slightly faster overall.

OK hardly a scientific analysis but what I was trying (unsuccessfully) to point out is I couldn't see how the ReadWriteCollection implementation solved the performance problem - see below.

Of course the main point of the ReadWriteCollection was the advantage of being able to concurrently add and remove whilst iterating rather than performance per se.


Resizing was a poor choice of word, I was referring to array-copies: using the simple ArrayList as an example, most remove() operations will result in the right-hand part of the underlying array being copied one step to the left (unless one happens to remove the last element).  An analysis tool such as JProbe highlights the array copy as the highest-cost part of the test.  So the remove() operation is linear in both implementations, but the actual bottle-neck is the same.  That was what I was trying to point out.


Again poor terminology, forget queues, what I meant was linked lists (which by definition are not backed by an array) do not have the array-copy issue.

One question: ReadWriteCollection isn't in fact a Java Collection (realised that when I tried to write a parameterized test!) - any reason for that?

Unless I'm missing the point you can remove entries from any collection while iterating using standard iterators:

final Iterator<T> itr = list.iterator();
while( itr.hasNext() ) {
    final T t = itr.next();
    final boolean dead = ....
    if( dead ) {
        itr.remove();
    }
}

Obviously not as concise as the for-each syntactic sugar but simple nevertheless.

Removing entries from any array-based collection (e.g. ArrayList) is going to perform poorly whatever removal strategy you use (due to the array resizing under the hood) unless the collection is a queue or linked list.

To be honest I'd be very surprised if they were actually changing the colours in the texture itself, it's more likely that the effect is implemented in the shader, possibly using alpha maps or something like that to combine the texture and the coloured pulses you mention.  Mind you I've never played Minecraft so I could be completely wrong.

If you *did* want to modify a texture then glTexSubImage() can be used to modify all or part of an uploaded texture, but as you say if you were doing that every frame I expect it wouldn't work too well.

I did the same thing and had the same artifacts that you're seeing, it's quite hard to chop up an image by hand.


Here's some cut-and-paste pseudo-code code from texture loader class used by my skybox builder (using LWJGL):




Dunno, anyone else have any advice on how to separate the 6 texture images?