Jump to content

  • Log In with Google      Sign In   
  • Create Account

Devine Caesar

Member Since 11 Jan 2011
Offline Last Active Mar 05 2013 04:35 PM

Posts I've Made

In Topic: Are primitive types necessary for Game Programming?

27 February 2013 - 02:32 PM

I was stumbling around the net and discovered that suggestions have been made for primitive types to be removed from future versions of the Java programming language. 


This is insanity in the Java community.

.Net (C#) has a best-of-both-worlds solution called "boxing".

If they made a change to Java they should implement a similar feature.


Removing primatives would wreck performance. You would have to allocate from the free-store for every field.

It would no longer be possible to create an actual array. You'd always get an array of handles.


Java already provides this feature it was introduced a while back it's called auto-boxing and unboxing which automatically wraps and unwraps int to Integer and vice versa whenever a primitive is passed when an Object is expected or when an Object is passed when a primitive is expected.


public static void main(String[] args)
int appleCount = 10;

System.out.println("You have " + appleCount + " apples");


Why would this syntax need to change? You could also have String number = 10.toString();. I'm sure that you realize there is already not a one to one mapping from syntax to code. The for ( String s : strings) is clearly one example of this. So the above example could be swizzled to "Integer.toString(10);" by the compiler.So I don't see why you'd have to change the syntax to support treating primitives as objects in the language but have them as primitives in the run time. Smalltalk does this.. they are called immediate directs.


As said in reply to Shannon, Java already provides this feature, removing primitive types makes this feature redundant so it would likely be removed along with the primitives.


I can't justify removing primitives from Java so I am not going to defend the idea, I posted this thread because I was looking for an explanation as to why this would be suggested and what ramifications there would be as a result.  I was curious to know if it seemed counter intuitive to anyone else so I asked if primitives were needed by programmers.  i personally use primitives where they make sense, i.e. where I don't need an Object but the suggestion that appears to be made is that people want Java to become a language where everything really is an Object.

In Topic: Are primitive types necessary for Game Programming?

26 February 2013 - 04:41 PM

I guess my main gripe with the idea of "Objects Everywhere" is that it will add complexity where it isn't needed.


If I have a player class with an int and an accessor method to get that int I would simply return that int and the value could be used.


With Objects everywhere since objects are passed by reference it wouldn't be possible to pass by value anymore - all primitives in java were passed by value - so now if you want to make sure the caller can't modify your member you'll have to create a copy and pass back the copy instead.


Same goes for calling methods, there'll be a lot more instances where the member will now have to be copied so that it can be passed to a method without worry that it might change the original.

In Topic: Are primitive types necessary for Game Programming?

26 February 2013 - 11:17 AM

To clarify, in terms of Java this will mean direct access to primitive types for the purpose of declaring variables will be removed.  Without direct access to these types every variable you declare will be an Object.  So int for example will no longer be available instead you will have to use the Integer class and create an Object.  The language will still have an internal concept of numbers and the ability to manipulate them obviously but in terms of writing code everything will have to be an Object.
Source: The Register: Java won't curl up and die like Cobol, insists Oracle

For the Java Development Kit (JDK) 10 or after, a fundamental change is being discussed: making the Java language Object Oriented. This might see the introduction of a unified type system that turns everything into objects and means no more primitives. The JDK is the developer kit that
is officially released by Oracle, based on the work of the Oracle- and IBM-led OpenJDK project

For example:

public static void main(String[] args)
     int appleCount = 10;

     System.out.println("You have " + appleCount + " apples");

This will no longer be possible, instead you will have to use Objects:

public static void main(String[] args)
     Integer appleCount = new Integer(10);

     System.out.println("You have " + appleCount.toString() + " apples");

I know this example is unrealistic it's just meant to illustrate the point.

In Topic: Render order for 2D isometric map

18 January 2011 - 10:01 PM

In a basic 2D Rendering Engine I find it best to use a Layer based approach.

I would have 4 layers.

Layer 0 - background this layer is drawn first.
Layer 1 - transitional
Layer 2 - transitional
Layer 3 - foreground this layer is drawn last.

All backgrounds and objects the Sprite should always be on top of should be in layer 0
The Sprite itself should initially be in layer 1 but can be moved to 2 and back depending on game events, you can use triggers for this. These layers should have their respective textures drawn first then their sprites.
All foregrounds and objects the Sprite must always be drawn underneath so they can cover or obscure the sprite should be in layer 3.

Consider a bridge, that you can both walk under or walk over. The bridge is raised up accessed by steps. And has a guide rail that should be drawn over the player.

All of the ground would be in layer 0
The sprite would be in layer 1. All textures in layer 1 are drawn before sprites.
The bridge is drawn in layer 2. Again all textures in layer 2 are drawn before sprites.
The rail is drawn in layer 3.

So the sprite could walk under the bridge in this scenario and the bridge path etc would be drawn over the sprite.

When the sprite collides with the tile at the top of the stairs it is moved to layer 2. Which tiles on the floor can be walked upon are changed you can do this by triggering a game event you probably have some mechanism like this planned so walls etc cannot be passed and doors can be locked etc that later open.
The sprite can then walk across the bridge, with the bridge being drawn beneath it. The rail is draw over the sprite. When leaving the bridge when the player collides with the tile at the bottom of the stairs trigger an event that changes the walkable floor map back.

Using the layer based approach even if you don't allow or need the sprite to move between layers you can still achieve the effects you want namely allowing the sprite to be in front of some textures and behind others.

We draw the screen from top to bottom; we draw layer 0 first, then the textures of layer 1 then the sprites of layer 1 then the textures of layer 2 then the sprites of layer 2 then layer 3.

You could implement the entire thing with 3 layers instead of 4 but then when crossing the bridge in the above scenarios instead of moving the sprite you would move the textures. It makes more sense to me to just move the one sprite though instead of moving the texture of each tile that the sprite would want to walk on.

As for implementing this system you can have two collections, one for layer 1 and one for layer 2 that contain sprites. This way when you render your layer you render all of the tiles first then render the sprites for that layer. The great thing about this approach is that you do not have to check at each tile, you just render the whole layer then all the sprites for that layer before rendering the next.

renderTexLayer( 0 ); // layer 0
renderTexLayer( 1 ); // layer 1
renderSpriteLayer( 1 );  // sprites for layer 1
renderTexLayer( 2 );  // layer 2
renderSpriteLayer( 2 );  // sprites for layer 2
renderTexLayer( 3 );  // layer 3

In your game events where a sprite moves between layers you just move the sprite from the collection for layer 1 to the collection for layer , your rendering order should take care of the rest.