Java-Gaming.org    
Featured games (81)
games approved by the League of Dukes
Games in Showcase (481)
Games in Android Showcase (110)
games submitted by our members
Games in WIP (548)
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  
  Data Structures  (Read 6112 times)
0 Members and 1 Guest are viewing this topic.
Offline JL235

JGO Coder


Medals: 10



« Reply #30 - Posted 2010-04-22 18:28:14 »

@Roquen Unless you're going crazy with this component system, I really don't think the number of pointers is going to make a big difference.
Seconded; performance is overrated. I personally put code maintainability and personal productivity above performance.

Offline Roquen
« Reply #31 - Posted 2010-04-23 08:56:33 »


My comment is not intended to say that such systems are either good or bad, but to simply point out the fact that it is an important design desision.  Increasing the memory footprint increases the number of cache & page missing that will occur.  Is this important? Maybe yes, maybe no.  It depends on a number of factors, such as access patterns and the number of active entities.

Seconded; performance is overrated. I personally put code maintainability and personal productivity above performance.

Performance is overrated, unless it's an issue. Wink  There are tons of possible systems, of which "faking" cross-cutting concerns in an OO language is simply one solution.  To toss out another, a simple data-driven model can handle the majority of the concerns addressed by cross-cuts..and it's simpler to write and maintain.  It is superior?  Well, like all game related questions...it depends.

When should I use a flavor of hash-table or a binary tree?  Which is "better"?  They have similar usages, but the best choice, well, depends.
Offline DzzD
« Reply #32 - Posted 2010-04-23 16:42:55 »

That's true, JL, but if you keep it simple then you can get the best of both worlds:

1  
2  
3  
4  
5  
public class Component
{
    private ArrayList<Component> components;
    private Component parent;
}


That's all you would do. So any component can have a parent (that it can access if it needs to), and/or it can have a lot of child components. So you can get a nice tree structure in there in terms of how things are formatted which can work very well with renderers, etc. if you make it work nicely enough (great for boned animations and the like).

I would say that IMO making cross component access will be requiered in a lot of case (as pointed above by Demonpants code), like if you got three components : sensor, visibility & position  in the system that manage visibility you will want to read the position and in the system that manage sensor you will also want to read position. In my case I have found interresting to have an entity class that is accessible from any of its components, this way a component know its entity and can give access to others components owned by this entity ( I told about its implementation here http://www.java-gaming.org/topics/efficient-caching-for-entity-system/22011/view.html), It is now implemented and working , it give excellent performance and it is very easy to use or build system.

EDIT : typos...

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

Senior Newbie





« Reply #33 - Posted 2010-04-23 18:47:41 »

Thanks for all the replies to my post. I'm still trying to soak it in. It definitely gives me another option than the traditional inheriting hierarchy to think about. Smiley

Programming since 2001 (Technically Tongue )
Uses: BlitzMax, Java, C++
Computers: W7 Desktop and a Triple Booting Netbook.
Offline Dreamcatchermatt

Junior Member





« Reply #34 - Posted 2010-05-01 01:37:17 »

Indeed, thanks for all the replies.

I'm playing with my code now. I'm having trouble getting cross-communication between components working.

I have the ArrayList<Component> + Parent setup as above.

What i want to do is get child A to get a property from child B. In this instance, I want my sprite drawing code to access the position of the entity from the physics component.

I'm doing this by saying

1  
(PhysicsComponent)(this.Parent().GetComponentType(PhysicsComponent.class)).GetPosition();


however, this causes a squiggly underline error on NetBeans, even though i think it should work.

Any ideas?
Offline Nate

JGO Kernel


Medals: 145
Projects: 4
Exp: 14 years


Esoteric Software


« Reply #35 - Posted 2010-05-01 10:18:59 »

It doesn't compile.

Offline JL235

JGO Coder


Medals: 10



« Reply #36 - Posted 2010-05-01 12:28:38 »

Just a hunch, but it might be casting the return of getPosition rather then getComponentType. Try:
1  
( (PhysicsComponent) (this.Parent().GetComponentType(PhysicsComponent.class)) ).GetPosition();


However it's also possible to remove the cast entirely using generics.
1  
2  
3  
4  
5  
6  
public <A> A getComponentType(Class<A> klass)
{
    Component component = components.get( klass );
   
    return (A) component;
}

Offline Dreamcatchermatt

Junior Member





« Reply #37 - Posted 2010-05-02 20:42:49 »

great, thanks JL323, that looks like a better way of doing this.

I personaly have never programed with generics in java before, and only used code that uses them from 3rd party and .NET librarys in C#

I'll hit the books and let you know how it goes.
Offline Eli Delventhal

JGO Kernel


Medals: 42
Projects: 11
Exp: 10 years


Game Engineer


« Reply #38 - Posted 2010-05-03 21:31:04 »

great, thanks JL323, that looks like a better way of doing this.

I personaly have never programed with generics in java before, and only used code that uses them from 3rd party and .NET librarys in C#

I'll hit the books and let you know how it goes.

FYI Java generics really aren't worth much else than saving you a bit of typing. Just ask Kev to go on a Java generics rant - he doesn't use them at all. So don't be in a hurry to learn them.

See my work:
OTC Software
Offline JL235

JGO Coder


Medals: 10



« Reply #39 - Posted 2010-05-03 23:04:13 »

FYI Java generics really aren't worth much else than saving you a bit of typing. Just ask Kev to go on a Java generics rant - he doesn't use them at all. So don't be in a hurry to learn them.
But they not only save lots of typing, make your code clearer and catch many potential run-time bugs at compile time (like potential class cast exceptions).

I fully agree they have limitations, and I'd like to see them go further, but IMHO there are no negatives in using generics. They are even backwards compatible with pre-generics JVMs.

Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline CommanderKeith
« Reply #40 - Posted 2010-05-03 23:28:27 »

I always get frustrated by generics when I try and build them into my own classes. They have bad limitations with arrays, and the <> tags become messy as soon as you start having nested generified types like lists of lists.

Offline Nate

JGO Kernel


Medals: 145
Projects: 4
Exp: 14 years


Esoteric Software


« Reply #41 - Posted 2010-05-04 03:23:37 »

and catch many potential run-time bugs at compile time (like potential class cast exceptions).

This was never such a big problem that required all the nasty warnings to be turned on by default. RHS generics on initialization bug the crap out of me.

Offline Eli Delventhal

JGO Kernel


Medals: 42
Projects: 11
Exp: 10 years


Game Engineer


« Reply #42 - Posted 2010-05-04 03:29:46 »

But they not only save lots of typing, make your code clearer and catch many potential run-time bugs at compile time (like potential class cast exceptions).

I fully agree they have limitations, and I'd like to see them go further, but IMHO there are no negatives in using generics. They are even backwards compatible with pre-generics JVMs.
No, it won't catch runtime errors - that's one of the main problems with Java generics. All type information is lost at runtime, so you might actually be getting runtime errors instead of compiler errors, and compiler errors are typically better, no? Not to forget that Java generics do a whole lot of type casting under the hood, so you might as well just make your own ArrayList implementation (this is what Kev always does) to avoid all potential problems and overhead.

More details:
http://www.facsim.org/node/77

I personally use generics usually, but that's because they typically save me programming time. The whole reason I posted the FYI was so that Dreamcatchermatt would know all the facts before spending the time learning generics.


See my work:
OTC Software
Offline JL235

JGO Coder


Medals: 10



« Reply #43 - Posted 2010-05-04 11:05:55 »

No, it won't catch runtime errors - that's one of the main problems with Java generics. All type information is lost at runtime, so you might actually be getting runtime errors instead of compiler errors, and compiler errors are typically better, no?
Yes generics are not available at runtime, but I still disagree that they can't prevent runtime errors.

The old example of using generics with a list shows this. This non-generics code will fail at runtime:
1  
2  
3  
List ls = new List();
ls.add( "a string" );
Integer i = (Integer) ls.get(0); // I'd expect a ClassCastException would be thrown here

We also don't know if ls should contain only Integers or Strings. The code does not express enough information for you to tell.

Where as if you add generics it will instead fail at compile time:
1  
2  
3  
List<Integer> ls = new List<Integer>();
ls.add( "a string" ); // I'd expect a compiler error here
Integer i = ls.get(0);

Maybe unlikely to happen that often with lists (how many people actually mix types in them?), but it does show moving a potential runtime error to compile time.

Offline jojoh

JGO Knight


Medals: 5
Projects: 7


games4j.com


« Reply #44 - Posted 2010-05-04 11:07:51 »

No, it won't catch runtime errors - that's one of the main problems with Java generics. All type information is lost at runtime, so you might actually be getting runtime errors instead of compiler errors, and compiler errors are typically better, no? Not to forget that Java generics do a whole lot of type casting under the hood, so you might as well just make your own ArrayList implementation (this is what Kev always does) to avoid all potential problems and overhead.
Good point about performance, since that isn't at all obvious from the beginning. I typically only avoid generics for performance critical things, since using generics is quicker to code for most situations. You might have to explain the "getting runtime errors instead of compiler errors". Looking at your code, changing:
1  
        doubleQueue.push (new Double (2.0));

to
1  
        doubleQueue.push (new Integer (2));

will create a compile time error when you use generics, but a runtime error in your other example when you didn't use generics. And that is probably what JL235 was talking about. I am sure he meant "catch" as in prevent, not "try - catch"). I don't see how generics could create a ClassCastException even though the the Lists loose the type after compile, since you can't create code with different types for the same List.


Offline Riven
« League of Dukes »

JGO Overlord


Medals: 781
Projects: 4
Exp: 16 years


Hand over your head.


« Reply #45 - Posted 2010-05-04 14:08:51 »

You might have to explain the "getting runtime errors instead of compiler errors".

For completeness sake... this results in a runtime exception Smiley

1  
2  
3  
4  
5  
6  
7  
8  
9  
10  
   static <T> T horrible(Object t)
   {
      return (T) t;
   }

   static
   {
      String s = horrible(Integer.valueOf(13)); // b00m!
     System.out.println(s);
   }

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 #46 - Posted 2010-05-04 14:27:38 »

Yeah, I mean you guys are right that they certainly prevent you from making most mistakes, but I would argue that the runtime exceptions that you will get from generics are much more difficult to track down because in order to make them happen you need to have some pretty complicated (or weird) code paths. They're not catch-all because they don't actually make an object that only allows one type, they just constrain it when you happen to be modifying that object in a scope that has generics defined for it. I have had several cases over the years where I am somehow modifying a Collection that has generics but without using generics. i.e. it gets modified like Collection<Object>. This has required some tricky code paths and passing of the Collection between lots of functions and other things, but it has indeed happened to me. The fact of the matter is, if you can somehow "trick" the compiler that you have a Collection<Object> even though you may have a Collection<Integer>, then you can put whatever you want in there with no problems, and expect it to be perfect because there are no compiler errors reported.

Anyway. Let me reiterate - I almost always use generics. I never make code critical-path enough to worry about the flaws of them.

See my work:
OTC Software
Offline Roquen
« Reply #47 - Posted 2010-05-04 14:44:15 »

@Riven:  Yeah, but 'horrible' should also emit an unchecked cast warning (or error depending on your settings).

Where this is silently accepted:

1  
2  
3  
4  
5  
6  
7  
8  
9  
10  
  static Object horrible(Object t)
  {
     return t;
  }

  static
  {
     String s = (String)horrible(Integer.valueOf(13)); // b00m!
    System.out.println(s);
  }
Offline Riven
« League of Dukes »

JGO Overlord


Medals: 781
Projects: 4
Exp: 16 years


Hand over your head.


« Reply #48 - Posted 2010-05-04 15:47:46 »

The fact of the matter is, if you can somehow "trick" the compiler that you have a Collection<Object> even though you may have a Collection<Integer>, then you can put whatever you want in there with no problems, and expect it to be perfect because there are no compiler errors reported.

To be ultra safe, you can use:
1  
List<Integer> list = Collections.checkedList(new ArrayList<Integer>(), Integer.class)

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

JGO Coder


Medals: 10



« Reply #49 - Posted 2010-05-04 17:10:16 »

Good point about performance, since that isn't at all obvious from the beginning. I typically only avoid generics for performance critical things, since using generics is quicker to code for most situations. You might have to explain the "getting runtime errors instead of compiler errors". Looking at your code, changing:
Using the standard java.util collections both with or without generics should always give the same performance.

At a guess I believe what you might actually have found an issue with is the overhead of auto-boxing primitive types. I'm pretty skeptical generics itself was causing any performance issues in your code, as all it adds are a few extra casts which you'd typically need to add to your non-generics code anyway. I've also rolled plenty of my own collections to get this small performance gain.

Offline Eli Delventhal

JGO Kernel


Medals: 42
Projects: 11
Exp: 10 years


Game Engineer


« Reply #50 - Posted 2010-05-04 18:09:36 »

What about this:

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  
//Server
private ArrayList<Comparable>gameStuff;

public void doServerStuff()
{
    try
    {
        ObjectOutputStream os = new ObjectOutputStream(clientAOutputStream);
        os.writeObject(gameStuff);
        os.close();
    }
    catch (Exception e)
    {
        e.printStackTrace();
    }
}


//Client
private ArrayList<Integer>gameStuff;

public void doServerStuff()
{
    try
    {
        ObjectInputStream is = new ObjectOutputStream(serverInputStream);
        gameStuff = (ArrayList <Integer>) is.readObject();
        is.close();
    }
    catch (Exception e)
    {
        e.printStackTrace();
    }
}


What's sent is an array list of Object, even though Comparable is passed as the template. So what comes in is also an ArrayList of Object, even though it gets cast (yes, you will get a compiler warning) to an ArrayList of Integer. The above would obviously be a silly mistake, but situations like these in complex projects are more what I'm talking about. It makes much more sense to just have like a ServerDataList object that has customer methods to only allow what you want and then send that around instead. Or just stick with ArrayList<Object> and know that it may not be safe (like you would always assume with ArrayList<Object>) so you can check each and every Object's type.

See my work:
OTC Software
Offline JL235

JGO Coder


Medals: 10



« Reply #51 - Posted 2010-05-04 18:55:30 »

You could also hide the generics using inheritance...
1  
2  
public class GameStuff extends ArrayList<Comparable>
{ }

and this could also be achieved through composition, or by creating your own object input/output streams which solved the type issues for you (i.e. they only took and returned a type of ArrayList<Comparable> allowing developers to avoid doing the cast themselves).

I do see what your saying, it is an example of generics failing to solve a type problem. But this issue will just as easily crop up in a system which didn't use generics.

Offline Nate

JGO Kernel


Medals: 145
Projects: 4
Exp: 14 years


Esoteric Software


« Reply #52 - Posted 2010-05-04 20:07:59 »

No, it won't catch runtime errors - that's one of the main problems with Java generics. All type information is lost at runtime, so you might actually be getting runtime errors instead of compiler errors
If you use generics and you have no compiler warnings then you can never get a ClassCastException. Ever. However, jumping through all the hoops and typing all the goddamn pointy brackets is not worth it to solve this "ClassCastException problem", which never really existed.

My approach is to turn off the warnings that are stupid, and to just use generics for syntatic sugar. Doing this you are no worse off ClassCastException-wise than pre-Java 1.5, but you have a little sugar. We all know Java could use some sugar.

Offline Dreamcatchermatt

Junior Member





« Reply #53 - Posted 2010-05-05 20:25:51 »

Wow, I seem to have poked a sleeping bear Cheesy

Thaks for all the different ideas and views though!

This sort of discussion helps me get a more rounded idea of what I'm dealing with, rather than just reading through books/tuts.

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.

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

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

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

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

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

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

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

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

Norakomi (37 views)
2014-08-06 19:49:38

BurntPizza (67 views)
2014-08-03 02:57:17
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!