Java-Gaming.org    
Featured games (81)
games approved by the League of Dukes
Games in Showcase (483)
Games in Android Showcase (110)
games submitted by our members
Games in WIP (550)
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]
  ignore  |  Print  
  Class and array  (Read 4688 times)
0 Members and 1 Guest are viewing this topic.
Offline Eli Delventhal

JGO Kernel


Medals: 42
Projects: 11
Exp: 10 years


Game Engineer


« Reply #30 - Posted 2011-01-25 20:31:13 »

Actually, this just becomes slow casting under the hood. Templates in Java are kind of crap. If you're worried about performance, better to make a subclass of ArrayList that accepts only a certain type of class. Then you can deal with the type casting yourself and make it maximally efficient.

But FYI, here is something like what I was referring to:

1  
2  
3  
4  
5  
6  
7  
8  
9  
10  
11  
12  
13  
14  
public class MonkeyArrayList extends ArrayList
{
    public Monkey get(int i)
    {
        return (Monkey) super.get(i);
    }

    public void add(Monkey m)
    {
        super.add(m);
    }

    //etc.
}


You honestly think this is faster?

I don't get it. Generics does exactly the same, except that is doesn't do the cast in the ArrayList, but at the callsite. What you do is moving the cast from the usual callsite into your own (newly created) callsite. For HotSpot it's exactly the same code, while your subclass even adds another level of indirection. I'm stumped.
Well you'll have half as many casts, because the setters don't also need a cast. Or maybe I'm wrong and generics don't do a cast at that point, but I thought they did.

But really in the end no I don't think this is worth worrying about if your reason for doing it is speed. I would argue that in some situations it has more clarity, and you avoid some of the other issues mentioned in that article (like you can have MonkeyArrayList.staticVar separate from ApeArrayList.staticVar, for example).

See my work:
OTC Software
Offline princec

JGO Kernel


Medals: 362
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #31 - Posted 2011-01-25 21:32:28 »

Aye Eli is a little misled on the application of generics. Generics don't make things faster or slower; but they do provide an extra level of compiler checkery which can make some code neater. Some code not so neat. Roll on project Coin which will sort it out.

Generics are like salt: use sparingly but effectively.

<edit> Also, casts in the JVM are much more cunning than you think.

Cas Smiley

Offline Eli Delventhal

JGO Kernel


Medals: 42
Projects: 11
Exp: 10 years


Game Engineer


« Reply #32 - Posted 2011-01-25 21:35:18 »

Aye Eli is a little misled on the application of generics. Generics don't make things faster or slower; but they do provide an extra level of compiler checkery which can make some code neater. Some code not so neat. Roll on project Coin which will sort it out.

Generics are like salt: use sparingly but effectively.

Cas Smiley
I've got to stop arguing points that I don't even really follow myself. Tongue

See my work:
OTC Software
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline princec

JGO Kernel


Medals: 362
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #33 - Posted 2011-01-25 21:38:44 »

I used to do that Smiley Now I just moan about Java being shit because I can't use it on the BASTARD IPHONE. Grrr. etc.

Cas Smiley

Offline Captain Awesome

Junior Member


Medals: 2


Hi


« Reply #34 - Posted 2011-01-25 21:46:06 »

I used to do that Smiley Now I just moan about Java being shit because I can't use it on the BASTARD IPHONE. Grrr. etc.

Cas Smiley

Moan on steve jobs instead for not supporting java lol.
Offline princec

JGO Kernel


Medals: 362
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #35 - Posted 2011-01-25 21:48:42 »

Jobsy doesn't actually mind Java at all. He's pretty good pals with Larry too. The problem was the legacy dealings Apple had with Sun. I have a feeling things might look a little rosier in the not too distant future.

Cas Smiley

Offline SimonH
« Reply #36 - Posted 2011-01-25 21:53:48 »

Just to satisfy my own curiosity I just did a quick test (1M add, get, remove) for generic and non-generic Vectors and found no appreciable time difference. Phew! I was hoping there wouldn't be!

People make games and games make people
Offline JL235

JGO Coder


Medals: 10



« Reply #37 - Posted 2011-01-26 00:47:22 »

Just dont bother! Stick to whats working for you and get something done before trying to optimize at this level. You wont get anywhere if you start this now. Trust me: "premature optimization is the root of all evil"
Okay, I will agree with this. Just stick with the Vector or whatever that you've got already.

But FYI, here is something like what I was referring to:

1  
2  
3  
4  
5  
6  
7  
8  
9  
10  
11  
12  
13  
14  
public class MonkeyArrayList extends ArrayList
{
    public Monkey get(int i)
    {
        return (Monkey) super.get(i);
    }

    public void add(Monkey m)
    {
        super.add(m);
    }

    //etc.
}

I'm surprised others failed to pick up on this. 'public void add(Object value)' still exists, so your method fails to be a full replacement to Generics. Your method is only ever called if you know a Monkey is passed in at compile time as otherwise it'll bypass it and call the old add. For example...
1  
2  
3  
4  
    MonkeyArrayList monkeys = new MonkeyArrayList();
    monkeys.add( "a string" );
    monkeys.add( 42 );
    monkeys.add( new Monkey() );

The above is perfectly valid and successfully executes.

To be fair you will get an exception when calling 'get' due to the cast. But consider this: if a non-Monkey is in the list then the error must have occurred at the point where the non-Monkey is added to the list (it shouldn't have been added). Because the type error only occures when calling 'get' (on performing the cast) then you have moved the error away from where it has occured. The error is now more misleading as you'd expect everything inside of 'monkeys' to already be a Monkey.

Secondly you will also get an error when using an iterator or when using a foreach loop (I believe foreach loops are just iterators + syntax sugar). This is because the iterator calls 'get', but this is implementation specific! I could build a 'SpecialList' which returns an iterator which does not call 'get'. If the 'MonkeyArrayList' extends my 'SpecialList' then there should not be a runtime error when using iterators or foreach loops.

Generics does not suffer from these issues. Finally yours offers no compile time validation. Generics does.

Offline Eli Delventhal

JGO Kernel


Medals: 42
Projects: 11
Exp: 10 years


Game Engineer


« Reply #38 - Posted 2011-01-26 01:33:05 »

Very good point, I wrote this quickly without thinking. To take a real-world situation, have a look at BodyList from Phys2D. It isn't an ArrayList, it has an ArrayList. I honestly momentarily debated that with myself before typing the example, obviously I made the wrong choice. You definitely wouldn't want to subclass ArrayList, that would make no sense.

1  
2  
3  
4  
5  
6  
7  
8  
9  
10  
11  
12  
13  
14  
15  
16  
17  
18  
19  
20  
21  
22  
23  
24  
25  
26  
27  
28  
29  
30  
31  
32  
33  
34  
35  
36  
37  
38  
39  
40  
41  
42  
43  
44  
45  
46  
47  
48  
49  
50  
51  
52  
53  
54  
55  
56  
57  
58  
59  
60  
61  
62  
63  
64  
65  
66  
67  
68  
69  
70  
71  
72  
73  
74  
75  
76  
77  
78  
79  
80  
81  
82  
83  
84  
85  
86  
87  
88  
89  
90  
91  
92  
93  
94  
95  
96  
97  
98  
99  
100  
101  
102  
103  
104  
105  
106  
107  
108  
109  
110  
111  
112  
113  
114  
115  
116  
117  
118  
119  
120  
121  
122  
123  
124  
125  
126  
127  
128  
129  
130  
131  
132  
133  
134  
135  
136  
137  
138  
139  
140  
141  
142  
143  
144  
145  
146  
147  
148  
149  
150  
151  
/*
 * Phys2D - a 2D physics engine based on the work of Erin Catto. The
 * original source remains:
 *
 * Copyright (c) 2006 Erin Catto http://www.gphysics.com
 *
 * This source is provided under the terms of the BSD License.
 *
 * Copyright (c) 2006, Phys2D
 * All rights reserved.
 *
 * Redistribution and use in source and binary forms, with or
 * without modification, are permitted provided that the following
 * conditions are met:
 *
 *  * Redistributions of source code must retain the above
 *    copyright notice, this list of conditions and the
 *    following disclaimer.
 *  * Redistributions in binary form must reproduce the above
 *    copyright notice, this list of conditions and the following
 *    disclaimer in the documentation and/or other materials provided
 *    with the distribution.
 *  * Neither the name of the Phys2D/New Dawn Software nor the names of
 *    its contributors may be used to endorse or promote products
 *    derived from this software without specific prior written permission.
 *
 * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND
 * CONTRIBUTORS "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES,
 * INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF
 * MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE
 * DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR CONTRIBUTORS
 * BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY,
 * OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO,
 * PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA,
 * OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY
 * THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR
 * TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT
 * OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY
 * OF SUCH DAMAGE.
 */

package net.phys2d.raw;

import java.util.ArrayList;

/**
 * A typed list of <code>Body</code>
 *
 * @author Kevin Glass
 */

public class BodyList implements java.io.Serializable
{
   /** The elements in the list */
   private ArrayList elements = new ArrayList();
   
   /**
    * Create an empty list
    */

   public BodyList() {
     
   }
   
   /**
    * Create a new list containing the elements specified
    *
    * @param list The list of elements to add to the new list
    */

   BodyList(BodyList list) {
      elements.addAll(list.elements);
   }
   
   /**
    * Add a body to the list
    *
    * @param body The body to add
    */

   public void add(Body body) {
      elements.add(body);
   }
   
   /**
    * Get the number of elements in the list
    *
    * @return The number of the element in the list
    */

   public int size() {
      return elements.size();
   }
   
   /**
    * Remove a body from the list
    *
    * @param body The body to remove from the list
    */

   public void remove(Body body) {
      elements.remove(body);
   }
   
   /**
    * Get a body at a specific index
    *
    * @param i The index of the body to retrieve
    * @return The body retrieved
    */

   public Body get(int i) {
      return (Body) elements.get(i);
   }
   
   /**
    * Clear all the elements out of the list
    */

   public void clear() {
      elements.clear();
   }
   
   /**
    * Check if this list contains the specified body
    *
    * @param body The body to look for
    * @return True if this list contains the specified body
    */

   public boolean contains(Body body) {
      return elements.contains(body);
   }
   
   /**
    * Get a list of bodies containing all of the bodies in this
    * list except those specified
    *
    * @param others The bodies that should be removed from the contents
    * @return The list of bodies excluding those specified
    */

   public BodyList getContentsExcluding(BodyList others) {
      BodyList list = new BodyList(this);
      list.elements.removeAll(others.elements);
     
      return list;
   }
   
   /**
    * @see java.lang.Object#toString()
    */

   public String toString() {
      String str = "[BodyList ";
      for (int i=0;i<elements.size();i++) {
         str += get(i)+",";
      }
      str += "]";
     
      return str;
   }
}

See my work:
OTC Software
Offline ReBirth
« Reply #39 - Posted 2011-01-26 03:18:53 »

Just dont bother! Stick to whats working for you and get something done before trying to optimize at this level. You wont get anywhere if you start this now. Trust me: "premature optimization is the root of all evil"
Thanks for the advice. Honestly I didn't bother this. My current small project is using ArrayList<Ball> (Ball is my own defined class) and it works well. I call get() every update() time so every Ball can draw themself and no lag.

I just want to know and take a glance about optimization for future need Smiley

Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline cylab

JGO Ninja


Medals: 43



« Reply #40 - Posted 2011-01-26 12:05:27 »

I just want to know and take a glance about optimization for future need Smiley

Fair enough, but you should take a different approach:

- benchmark your code - maybe it's just fast enough
- profile your code to find bottlenecks (Use one of Netbeans, Yourkit, Visual VM, JProfiler etc.)

Use the result of the Profiler to

- replace components that are slow for your use case with fast ones - usually every component has strengths and weaknesses
- reduce "exponential" complexities (like nested loops)
- find another algorithm to do things that are slow (google is your friend:))

Usually performance problems exist on a completely different level than such micro-optimizations

Mathias - I Know What [you] Did Last Summer!
Offline JL235

JGO Coder


Medals: 10



« Reply #41 - Posted 2011-01-26 14:50:26 »

Very good point, I wrote this quickly without thinking. To take a real-world situation, have a look at BodyList from Phys2D ...
Ah, through composure instead. Yeah, that works.

I actually used this method myself once in a library made. I also went further and wrapped an array instead of an ArrayList and then just resize it myself. There is a speed improvement, but the only real improvement you see if you also do this for primitive types.

However I added this to my own code a long time after writing it (not in the first case), I did need my library to run faster (you shouldn't optimize unless it's needed) and it's only seen internally. I'd maintain you should only ever optimize under those circumstances.

Considering that the original poster needed help on just how to use arrays; this kind of stuff is too advanced (and it's to early on in his code) to be suggesting.

Offline Eli Delventhal

JGO Kernel


Medals: 42
Projects: 11
Exp: 10 years


Game Engineer


« Reply #42 - Posted 2011-01-26 18:49:12 »

However I added this to my own code a long time after writing it (not in the first case), I did need my library to run faster (you shouldn't optimize unless it's needed) and it's only seen internally. I'd maintain you should only ever optimize under those circumstances.
I will agree with you. On JGO, I often get a little bit too academic about things. As I said above, I have never personally done this in any "actual" projects, because they are never my bottleneck.

See my work:
OTC Software
Offline Riven
« League of Dukes »

JGO Overlord


Medals: 781
Projects: 4
Exp: 16 years


Hand over your head.


« Reply #43 - Posted 2011-01-26 19:14:03 »

I will agree with you. On JGO, I often get a little bit too academic about things.
I usually associate academic with fully thought through

Ask Kev his opinion of generics and you'll get much more fire and brimstone than from me. Personally I'm going to stop arguing now, since it's already been done many times before.
This is just condescending and ill informed.

Hi, appreciate more people! Σ ♥ = ¾
Learn how to award medals... and work your way up the social rankings
Offline Eli Delventhal

JGO Kernel


Medals: 42
Projects: 11
Exp: 10 years


Game Engineer


« Reply #44 - Posted 2011-01-27 18:32:01 »

I will agree with you. On JGO, I often get a little bit too academic about things.
I usually associate academic with fully thought through

Ask Kev his opinion of generics and you'll get much more fire and brimstone than from me. Personally I'm going to stop arguing now, since it's already been done many times before.
This is just condescending and ill informed.
Hm... I was thinking academic more referring to talking over ideas and coming to a conclusion, but yes you're right in many cases I don't think an overly long time about what I'm saying. As for the condescension, it wasn't at all intended. And I don't think that was ill informed either. I just searched the forum for "generics" in posts by kevglass.

http://www.java-gaming.org/topics/type-compatibility-linkedlist/8132/msg/71311/view.html#msg71311
Quote
one of the benefits of not using generics, ick!
http://www.java-gaming.org/topics/please-vote-today/6441/msg/57663/view.html#msg57663
Quote
I don't like generics
http://www.java-gaming.org/topics/generics-good-or-bad/6164/msg/56424/view.html#msg56424
Quote
They're easy to misuse
http://www.java-gaming.org/topics/sun-s-crappy-generic-implementation/7180/msg/63294/view.html#msg63294
Quote
Just don't use generics. They're a move toward bad programming anyway

Now, I'm posting all this just to emphasize the impression I got from Kev, and not that I was trying to throw out wild opinions about what someone else thinks (which admittedly I am still doing to some extent). I will also be the first to point out that in many of the posts I quoted Kev's main point is not that generics themselves are bad, but that they allow programmers to do dumb things. So he doesn't like generics because of different reasons than I mentioned.

All that said, though, I am totally aware that I too often will evangelize a point I remember reading on this very forum, but I turn out to be mistaken. I get carried away with the interest of having a discussion. I will continue to try not to discuss something as an informed individual unless I do in fact know something about the subject from my own experiences. I will also point out that my skill as a software engineer has never lied in a deep knowledge of the compiler or the OS or anything like that as your knowledge is based in, Riven, but it is in making programs come together quickly and cleanly in an intelligent fashion. I usually only worry about the underlying mechanics of what I'm using if I need to know them. So, like I already said, I should probably stop giving advice about underlying mechanics and stick to giving advice about making games.

See my work:
OTC Software
Offline JL235

JGO Coder


Medals: 10



« Reply #45 - Posted 2011-01-27 19:23:44 »

I usually only worry about the underlying mechanics of what I'm using if I need to know them. So, like I already said, I should probably stop giving advice about underlying mechanics and stick to giving advice about making games.
I (obiously) disagreed with bits, but I didn't think there was nothing wrong with your suggestion. You certainly shouldn't feel like you shouldn't make suggestion in an area.

Offline Eli Delventhal

JGO Kernel


Medals: 42
Projects: 11
Exp: 10 years


Game Engineer


« Reply #46 - Posted 2011-01-27 20:50:08 »

I usually only worry about the underlying mechanics of what I'm using if I need to know them. So, like I already said, I should probably stop giving advice about underlying mechanics and stick to giving advice about making games.
I (obiously) disagreed with bits, but I didn't think there was nothing wrong with your suggestion. You certainly shouldn't feel like you shouldn't make suggestion in an area.
Cool. I've just gotten burned one too many times for suggesting/saying something that wasn't completely correct.

See my work:
OTC Software
Pages: 1 [2]
  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.

CopyableCougar4 (15 views)
2014-08-22 19:31:30

atombrot (28 views)
2014-08-19 09:29:53

Tekkerue (25 views)
2014-08-16 06:45:27

Tekkerue (23 views)
2014-08-16 06:22:17

Tekkerue (15 views)
2014-08-16 06:20:21

Tekkerue (22 views)
2014-08-16 06:12:11

Rayexar (61 views)
2014-08-11 02:49:23

BurntPizza (39 views)
2014-08-09 21:09:32

BurntPizza (31 views)
2014-08-08 02:01:56

Norakomi (38 views)
2014-08-06 19:49:38
List of Learning Resources
by Longor1996
2014-08-16 10:40:00

List of Learning Resources
by SilverTiger
2014-08-05 19:33:27

Resources for WIP games
by CogWheelz
2014-08-01 16:20:17

Resources for WIP games
by CogWheelz
2014-08-01 16:19:50

List of Learning Resources
by SilverTiger
2014-07-31 16:29:50

List of Learning Resources
by SilverTiger
2014-07-31 16:26:06

List of Learning Resources
by SilverTiger
2014-07-31 11:54:12

HotSpot Options
by dleskov
2014-07-08 01:59:08
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!