• Content count

  • Joined

  • Last visited

Community Reputation

108 Neutral

About DevineCaesar

  • Rank
  1.   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.     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.
  2. 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.
  3. 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 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.
  4. 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 got me thinking, even though Java more or less "does it for you" when it comes to memory management surely there is an inherent understanding that using primitives instead of objects where appropriate would be better? or is that a false assumption on my part?   For simple things like keeping track of a player's numerical attributes number of lives, health, experience, etc I would have thought using primitive types instead of Object types would have made more sense.   There are other programming languages that don't have primitive types at all, but to my knowledge they aren't as popular for games as C/C++ and Java etc wihich do have primitives.  So the question is quite simply, are primitive types necessary for Game Programming?  Would there be any knock on effects of removing them from a language?
  5. Apologies in advance but I did not know where else to put this. Does anyone know of any repositories or sites which provide existing XML DTDs for download? Not necessarily related to Games Someone asked if they could download a DTD for an existing file type that uses XML. They were not looking for any file type in particular, they are building an application that is essentially a Calendar and they wanted to know what existing XML based file types existed and if their DTD were downloadable. This original question is not relevant anymore what we now just want to know, as the title of the post says, is there an XML DTD repository or collection that anyone knows of?
  6. Render order for 2D isometric map

    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. [code]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[/code] 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.
  7. I have developed a 2D Game Engine that currently represents the scene as a series of Tile Objects, each tile has an associated texture. At present there is a texture Palette, this is a collection that stores a single copy of each texture, each Tile then has a texture index which indicates which texture from the palette should be drawn. Now, at present to render the tile the following steps are taken: The texture index is got from the Tile, The Texture is then got from the palette using the index Texture is then drawn. I have been wondering if, this is the best set up. The above setup has loose coupling and high cohesion and allows me to change how textures are stored in the engine quite easily, only the palette and the rendering engine need updating the game logic classes are unaffected, a Tile does not need to know how the texture is stored it just needs to provide the information needed to draw the correct texture. What I was thinking of is that this process is long winded and has many execution steps, and instead I was thinking of making the Tile objects extend my texture class, so that the tiles themselves could simply be passed to the rendering engine and drawn. A single copy of each texture would still exist in the palette as before but instead of holding a texture index each tile would instead directly reference the texture in the palette. This setup offers tighter coupling though and less cohesion and would mean if I wanted to change the way in which the texture data is stored, I would have to change all the classes as noted before, as well as the Tile class. So I am left with the decision, possibly increase efficiency by reducing the execution steps, but increasing coupling and making the code harder to change or keep the current system. It is worth noting that the current system has not brought forward any problems with speed or frame rate, but I have not tested the engine on lower spec machines. Also the main reason for the current system was to try and keep the game logic and the rendering engine separate as much as possible. What is everyones' advice or opinion on this matter? Stick with what I have or change it around?