Java-Gaming.org    
Featured games (91)
games approved by the League of Dukes
Games in Showcase (581)
games submitted by our members
Games in WIP (500)
games currently in development
News: Read the Java Gaming Resources, or peek at the official Java tutorials
 
   Home   Help   Search   Login   Register   
  Show Posts
Pages: [1] 2 3 ... 6
1  Game Development / Shared Code / Re: Beware of Enum.values()! on: 2013-03-12 19:11:29
Since we're expanding on various oddities.. With J2SE Enum hashCode() returns the identity hash code on Android hashCode() returns the ordinal + hash code of the String name of the enum. Doh! If you try and mix a lot of Enum with other objects returning the identity hash code on Android collisions potentially occur. Also if you have two Enum classes with a duplicate name in the same position the hash codes collide. Doh!

On Android:
1  
2  
3  
4  
    @Override
    public final int hashCode() {
        return ordinal + (name == null ? 0 : name.hashCode());
    }
2  Discussions / General Discussions / Re: I Switched to IDEA! on: 2013-03-12 18:55:26
I've been using Idea for over 10 years, but v12 impressed me considerably. In my efforts with TyphonRT which is composed of 700 source code modules v12 with the compilation improvements takes 23 seconds on a circa '11 MBP w/ an SSD for a fresh build. Prior to v12 9 minutes; I was definitely getting worried! I'm liking v12 a lot and very glad about the community edition being available if I initially have to depend on others who want to work with the source directly using Idea if there are any potential Eclipse issues with large amounts of modules.
3  Discussions / Miscellaneous Topics / Re: Have you ever been Jumped/Beaten up? on: 2012-01-18 14:11:32
I've been lucky to not get jumped. I live near a shady area in SF / SOMA, so this is definitely always on my mind. If you look at the crime heat maps I'm real close to a big one. It's odd how a block or two away things are much worse and I walk through that area all the time to a local bar sometimes with my pool sticks. Luckily I'm tall and reasonably fit looking, but the biggest thing is just common sense and having decent awareness when in route. I'm doubly careful walking through said shady area late at night. But seriously any fight would freak me out as well the best course of action is usually to run away. If you can't run just give up whatever they want. My friends got jumped at knife point in Oakland and they quickly emptied their wallets and were lucky thankfully. I never got into fighting, duh clackity clackity, but always stayed clear due to being reasonably strong. With someone my size some decent damage can be done. I've really been meaning to start some martial art; quite likely Brazilian Jiu Jitsu as there is a highly regarded Gracie academy half a block from me. Not that BJJ would help in a street fight all too much with multiple assailants. I'm definitely interested in getting out of "coders head" and get moving around and learn how to control ones body with the appropriate force. Hah. I went to college in San Luis Obispo, CA and that is where Chuck Liddell is based and I was like 30 feet away on a big Mardi Gras party weekend when a fight broke out. Lets just say it didn't go well for the guy that tried to hit the Iceman and it was over quick. 
4  Game Development / Newbie & Debugging Questions / Re: Abstract classes and interfaces help on: 2011-12-20 09:07:44
I suppose I do this in my efforts for the core component architecture at least since it makes things clearer. You'd have to dig around some other posts to get all the background & "razmatazz".

componentManager.getAs(IActivityLifecycle.class) by naming convention alone makes it clear that one is dealing with an interface and not expecting code completion to any public member variables... I don't prepend shared / IE cross-platform J2SE / Android classes with "Shared" or J2SE. The actual cross-platform implementation or base class is "ActivityLifecycle" which may also be dual registered and accessed as componentManager.getAs(ActivityLifecycle.class) along with the interface. Likewise with the Android specific version: componentManager.getAs(AndroidActivityLifecycle.class). However for cross-platform usage things are composed using the interface and if direct access is necessaryfor any given component they are also stored under the actual implementation type.

In my case the naming convention helps shorten cross-platform implementation class names whether they are base classes or what not.

Technically devs using my efforts can do whatever they want for naming conventions, but I've found the prepend useful for interfaces and code readability in my core component architecture work. It's not for everyone nor a rule; use when handy essentially. Before my efforts went full on cross-platform I didn't standardize on prepending "I". I'd also argue it depends on the size of the project; less than 50-100 classes and small entity hierarchy then don't bother. While the core architecture is small w/ my efforts the larger network of components / libraries is growing beyond 1600 classes now with likely ~2k by the time I fully flush things all the way out feature wise; nice thing is it's highly modularized. Prepending "I" for interfaces just helps out at a certain scale, but to each their own.
5  Game Development / Newbie & Debugging Questions / Re: Abstract classes and interfaces help on: 2011-12-19 05:14:01
An interface essentially is a public contract. In Java it's also a top level type that is referenced by it's class. IE <interface name>.class

In your case with a base NPC class consider if there were private implementation details that could differ between a conceivable second base NPC class. This could be anything really. Creating an NPC interface ("INPC") that provides the public contract allows you to use either base NPC types interchangeably. An example of this is that say you create a collection ArrayList<INPC>. Now you can put either base types into this list and iterate over the common interface.

Interface based programming is important in larger architectures and app dev. In your case you may get away with things for a while depending on the scope of your efforts.

Interfaces are useful when private internal implementations differ, but the external public contract is the same between different implementations.
6  Discussions / General Discussions / Re: Still hardly any games, why entity systems suck, and why 4k is good on: 2011-11-25 20:12:31
I'm kind of surprised this isn't the common understanding and am at times kind of amazed at some of the discussion in this thread and forums in general. Not to be disparaging per se, but it's like CS 101 hasn't sunk in at all.
CS 101 shouldn't be covering software engineering. That's a completely separate discipline.

I was being a little rhetorical in that statement. It's fundamental knowledge essentially and is widely recognized as a best practice in the industry.

On whether software engineering is a separate discipline I at least do not treat it as such. The left hand must know what the right hand is doing otherwise if you just want to be a brick layer and be paid less be a programmer with little responsibility. You may eventually despise your work / job when non-software engineers / architects are calling the shots and this _will_ happen at some point if you don't demand to take control of this or keep it in mind in your career path. Besides when working as an indie one does both. There is no reason why one can't be a hands on architect especially on a small to mid sized team.

As far as teaching and degree wise I absolutely think it's a tragedy that things are being separated. After the CS 101/102/103 but before the typical data structures / algorithms course software architecture / engineering should be part of the curriculum. What are data structures other than patterns of organizing data. This is accomplished through a knowledge of the "paradigm" of implementation OO or otherwise. A course on design patterns before data structures seems appropriate in my opinion.  
7  Discussions / General Discussions / Re: Still hardly any games, why entity systems suck, and why 4k is good on: 2011-11-25 19:53:03
I fully understand the need to help people understand the usage of APIs by how you expose them.

No doubt.. One can't work that long in the industry and not grok that...  Grin

I just feel that most of the time it is a major pain in the arse deciding, when you aren't making a library for the use of others but instead writing end-code, or if you're the recipient of such a library, you simply can't use the code you have executing in your own damned program the way you want to have it executing if you don't have the source to hand.

I think there must be a better way.

Then don't criticize those looking towards entity systems and by general extension component architectures as wasting time or that they suck as the handful of us that are doing this are searching and some of us have found what we consider a better way. Searching and experimenting takes time and most definitely it takes an immense amount of time to convert a significant existing OO framework to a very granular component oriented one. I only did so after I saw the writing on the wall and pushed the older way to the limits. The inflexibility that you speak of above was obvious in my efforts with traditional Java / OOP mechanisms and I tried everything before going whole hog toward component architectures. Almost everything in my efforts now can be replaced or substituted fairly easily from external configuration files. A great deal of time was spent minimizing dependencies between components and related groupings so this is possible.

Beside the scenario above as you describe is just a poor API / framework that didn't do what it is intended to accomplish and I believe someone above commented on this sentiment in a reply above. I'm aware there may be times when a dev desires to mod a perfectly working API to do something slightly different as well, but usually that is an exceptional case as OOP in itself doesn't disable extension.

And that's how all new languages are born........

It can be, but I'm not ready to give up on Java yet. Though I certainly keep in mind how the CA can be leveraged from Scala and other JVM languages. In fact I certainly posit that it's a much better way to integrate Java w/ Scala or other JVM languages as opposed to extension of Java classes. I still need to experimentally validate this, but I put a lot of thought into it. A simple shift in perspective and coding practice is what I'm really trying to get at and while it works for me it may not work for everyone. The only downside so far is increased verbosity at the Java layer. There should be some ways with Scala for instance to reduce the verbosity in practice.

Now, I'm certainly not saying anyone has to follow me down the path I'm heading, but I do believe it will benefit any project small to large. It's not "f**king insane" as a poster above claimed. I have a large body of code that has only seen a benefit and things still chug along nicely in a reasonably complex 3D demo case. There will be early adopters and the typical bell curve of adoption. I most definitely have an up hill battle to fight, but it's an pedagogical one that can be overcome with good documentation, lots of clear tutorials, and perhaps a hit app or game + outside success stories. All that takes time...

To continue I would posit further that yet again this is a dirty mark on OOP and the is-a and explicit has-a relationship. It doesn't lend to flexible APIs / frameworks that can be easily extended or reconfigured and only truly works well for small to mid (at the most) sized projects in terms of maintenance unless there is someone full time working as a "cleaner / hands on architect" that can see the forest from the trees and has authority to refactor and uphold whatever standards that are set up. Code reviews are not enough in this regard as it's really an active full time position for a larger project with one or more folks involved day to day. Most small to mid sized projects with various devs involved benefit from a dedicated hands on architect.

Again a clarification, in my experience standard OOP as implemented in status quo Java projects doesn't work well as the central organizing mechanism, but is less of a deadly force in the leaves of any API / framework. Thus while my new efforts are component oriented they are partially still OO in the leaves which means some of the components / systems themselves. As a framework dev it's impossible to limit OOP in the leaves since OO is baked into Java. This is not necessarily the case for the entity system where it is recommended to minimize OO in the leaves, but for the runtime layer of my efforts it makes sense where there are component peers w/ a base cross-platform implementation + J2SE and Android peer extensions. Mind you the interface based programming aspect comes in because one stores the given platform implementation by the common interface / contract in the CA thus on any platform the dev just retrieves the particular platform implementation component by its common interface and bam easy cross-platform support w/ ease of adding more platform support on an as needed basis.

A simple shift of perspective to promoting the implicit has-a relationship as foundational and minimizing the explicit form and is-a relationship is not crazy. It's just a different approach. This is also fairly "CS 103" Cheesy material and shouldn't be strange language per se. It is a shift of perspective nonetheless though. It's true power is not realized until a significant amount of code is converted to this mechanism.

I know the "AbstractComponentManagerControl" thing may be hard to follow from a previous post as that is an implementation detail specific to my efforts, but I'll show it in psuedocode below (just a snippet mind you and not using best practices / IE never use foreach loop in near realtime bound code). It basically is an internally used component that can extend and change the behavior of the manager itself. It is what allows vetoing and encapsulation back that otherwise would be lost by the implicit has-a relationship. If you wanted to make a particular compound component final you'd first composite all the desired included components then add an ACMC that vetoes further set / unset actions.

This code is not the exciting part per se, but defines the bread and butter implicit has-a relationship. The exciting part is building a larger framework around a few essential new patterns that come from all of 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  
35  
36  
37  
38  
39  
40  
41  
42  
43  
44  
45  
46  
47  
48  
49  
50  
51  
52  
53  
54  
55  
56  
57  
58  
public class ComponentManager
{
   HashMap<Class<IComponent>, IComponent>  components
   HashMap<Class<IComponent>, Collection<IComponent>>  componentCollections

   public <C extends IComponent> C getAs(Class<C> componentType)
   {
      return components != null ? components.get(componentType) : null;
   }

   public <C extends IComponent> Collection<C> getCollection(Class<C> componentType)
   {
      return componentCollections != null ? componentCollections.get(componentType) : null;
   }

   // Sets a component adding it to this component manager
  public <C extends IComponent> boolean set(Class<C> componentType, C component)
   {
      Collection<AbstractComponentManagerControl> controlCollection = componentCollections.get(
       AbstractComponentManagerControl.class);
     
      if (controlCollection != null)
      {
         // Iterate through ACMCs to perform extra control actions or potentially veto set altogether if a control returns true.
        for (AbstractComponentManagerControl control : controlCollection)
         {
             if (control.set(this, componentType, component)
             {
                // control vetoed set action
               return false;
             }
         }
      }

      return components.put(componentType, component);
   }

   public <C extends IComponent> IComponent unset(Class<C> componentType)
   {
      Collection<AbstractComponentManagerControl> controlCollection = componentCollections.get(
       AbstractComponentManagerControl.class);
     
      if (controlCollection != null)
      {
         // Iterate through ACMCs to perform extra control actions or potentially veto unset altogether if a control returns true
        for (AbstractComponentManagerControl control : controlCollection)
         {
             if (control.unset(this, componentType)
             {
                // control vetoed unset action
               return null;
             }
         }
      }

      return components.remove(componentType);
   }
}
8  Discussions / General Discussions / Re: Still hardly any games, why entity systems suck, and why 4k is good on: 2011-11-25 05:01:30
It's about defining an API. *I* define what you access in my API. We have a contract. Anything I don't provide to you is none of your damned business and I am free to change without breaking you. There are plenty of scenarios where this makes sense. Everything *could* be public, but then I would have to assume any change I make will break all clients, and that is shit. If you want to access something that isn't exposed, you aren't using the API as intended and it is supposed to be a PITA. Blame the poorly designed API.

^ this; I'm kind of surprised this isn't the common understanding and am at times kind of amazed at some of the discussion in this thread and forums in general. Not to be disparaging per se, but it's like CS 101 hasn't sunk in at all. Interface based programming is one of the industries best practices and is core to API / framework creation in Java. It's central to my efforts with component architecture development and separating things modularly. I think interface based programming is likely the most important best practice that can be objectively discussed as such without a question of whom it might benefit.

Still going to try and post a bit of a response to various replies in this thread likely on Sat when I'm on a plane again.
9  Discussions / General Discussions / Re: Releasing a small library on: 2011-11-24 19:41:59
So Google Code is asking me for a license? Gah, so much bureaucracy! Which one means "Here's the code, do what you want with it, give me cred if you feel like it"?

MIT, BSD, Apache are of this nature.
10  Discussions / General Discussions / Re: Still hardly any games, why entity systems suck, and why 4k is good on: 2011-11-24 19:36:21
Yeah.. I'm not really into checked exceptions especially for any performance bound code, but handle unchecked exceptions intelligently from the clocking threads (potentially end the clocked runtime item silently, w/ a warning, log it, or if it is marked as a fatal error stop entirely) and via a default uncaught exception handler as to not crash the runtime, but provide some sort of reasonable response to the user, logging, or possible recovery if applicable. Any custom exceptions that are thrown in my efforts are all unchecked / runtime oriented.

As you say Sproingie if checked exceptions created a warning instead of an error if not handled I suppose there could also be an annotation that promoted it to an error state or could provide an IDE the ability to mark it visually instead of just a runtime JVM flag.
11  Game Development / Game Play & Game Design / Re: Executing Threads in a queue on: 2011-11-24 18:40:31
As others have commented on it, but not knowing more on your particular use case you likely don't need threads. As Sproingie mentioned you'll want to check out ExecutorService and the related APIs. You can build up your own API around it to control how things get run. I have a custom API built on it in my efforts that allows (of course in a component oriented fashion) to feed one thread pool in several different manners. Basic (one or more threads run immediately depending on available slots in the thread pool), Single (all threads submitted run single file), Pending (a runnable is submitted and will run as soon as a slot is open, if a new runnable is submitted it will wait in a pending state and run after any currently active runnable. If a new runnable is submitted while a pending one is waiting the pending one is replaced; good for long running GUI actions connected to something the user can press many times repeatedly. Such that the first and last button press will only potentially trigger execution). One can add a new custom scheduling mechanism too and have it share a thread pool.

I used a custom executor service when rewriting the download queue of the Amazon MP3 Android app that when the current download is paused it pushes the current download to the front of a custom BlockingQueue thus when the user resumes it pulls the previously downloading item and makes it active again. So you can certainly control the way runnables are scheduled and even service multiple ways of scheduling them from one thread pool. ExecutorService is also cross-platform between J2SE and Android. There really is no reason to use AsyncTask on Android when you can accomplish things in a cross-platform way via ExecutorService.
12  Game Development / Newbie & Debugging Questions / Re: Making color "see-thru" without changing it's color? on: 2011-11-24 11:15:09
Yeah.. taking into account a background as others have mentioned I don't think you'll reach a satisfactory result per se with color modification or saturation. You might get close I suppose. Also it will help to know if you want to work with a 2D API IE Java2D / Android 2D API or GL. Off the top of my head thinking aloud could you have too buffers and do some minor compositing. IE have an RGBA image you draw the text and your translucent shapes into then have a separate image as your background then do a Porter-Duff replace op when blending the text/shape image on top of the background image. Could that possibly work out?
13  Game Development / Game Mechanics / Re: 2D rotational velocity on: 2011-11-24 02:53:39
Check these tutorials. Demo code is in Flash, but can easily be ported:
http://www.wildbunny.co.uk/blog/2011/04/20/collision-detection-for-dummies/
http://www.wildbunny.co.uk/blog/2011/04/06/physics-engines-for-dummies/

OBB vs OBB is covered above. Other interesting posts on this fellows blog too.
14  Game Development / Newbie & Debugging Questions / Re: Making color "see-thru" without changing it's color? on: 2011-11-23 20:40:37
Is there some mathematical formula to do that?

Not that I've played around with this, but I believe it's easier to modify saturation with HSV vs RGB.

http://en.wikipedia.org/wiki/HSL_and_HSV
http://en.literateprograms.org/RGB_to_HSV_color_space_conversion_(C)

15  Game Development / Newbie & Debugging Questions / Re: Making color "see-thru" without changing it's color? on: 2011-11-23 20:32:21
Hrm.. Of course when you are overlapping one or more translucent colors / shapes intensity will be modified, but are you commenting say compositing a translucent object on a white background where the background itself affects the color intensity. I suppose if you could work out some way to composite a scene without taking into account the background you'd accomplish this. Perhaps modifying directly a BufferedImage. This seems more like a compositing problem. I can't off the top of my head think of a non-custom way to accomplish this.  
16  Game Development / Performance Tuning / Re: Android threading vagaries on: 2011-11-23 08:22:39
I'm pretty sure it'll misbehave on a couple of devices out there but it's really so brain dead simple, this code, it really shouldn't misbehave. The code itself is near as dammit identical to the code I've used for the last however many years on the desktop too - it's had a lot of lovely testing.

Very cool. Android caused me to step up my game as things go too. Testing never hurts.

Some of the silliness on Android is well just blatant lack of testing on big G's part. I'll throw out some stuff starting with Froyo though it goes back to the beginning; the "official" Java GL/ES 2.0 bindings in API level 8 are incomplete as code gen was used to create it, but it was never tested thus wrong signatures on some methods preventing some VBO usage. Gingerbread for the most part had no new problems as far as I'm aware for game dev. Honeycomb (3.0 / 3.1) had a major Java NIO regression where calling duplicate on a non ByteBuffer caused an _immutable_ endian swap on the buffer! Way non-kosher there and it broke all my GL code as I have a little extended NIO API that used duplicate on a FloatBuffer; that took me 45 hours of debugging to find and then provide big G a test case; I bitched them out over that though. ;P Only time I've seen the Android team fix a major regression in ~3 hours after test case was provided. Most items in the bug tracker languish forever. Last big thing to cause a ~4 day workaround in my efforts, IE 2 to fix, 2 to make clean, is the piss poor annotation support in Class likely taken from Harmony; horrible GC triggering code. All API levels affected up to Ice Cream Sandwich; had to implement caching myself. MotionEvent and such is an abortion of a proper API. So yeah.. There is always another big bomb shell awaiting around the corner.  Not exactly an exhaustive list and of course off topic.    

You should be able to get far more than 500 sprites on screen w/ mid level hardware. I'm sure the OG droid can pull that off. Fill rate / overdraw is the biggest issue, etc. Err.. this is not about threading anymore.. ;P

@Nate libgdx still require ~6 lines of code changes to configure between desktop & Android usage?  I'm aiming at no code changes.
17  Game Development / Performance Tuning / Re: Android threading vagaries on: 2011-11-22 17:26:59
... that may have been the case but it turns out I've solved them all on my own in 3 weeks

Or so you may think until you run your code on a different device / API level than the one you have in your hands...  Wink
18  Discussions / General Discussions / Re: Still hardly any games, why entity systems suck, and why 4k is good on: 2011-11-22 16:34:35
The whole notion of encapsulation has proved to be a complete waste of time over the last 20 years anyway. Of course I care about how something's implemented! I might want to bloody change it, whether I wrote it or not. Or even debug it. Ridiculous.

Eh heh heh.. So now you are implicitly for composition declaratively or otherwise / component architectures (CA) / entity systems (ES) as this is exactly what the "has a" relationship addresses. Your complaint is a valid one against OOP as "is a" encapsulation doesn't lead to easy code reuse, maintenance, or modification and is precisely why I moved on from that sinking ship.

As Java is an OO language through and through you can't stop anyone from using "is a" inheritance / encapsulation, but through careful construction of the CA one can force this to the leaves and prevent it overtaking the core at least as the central organizational construct.

Encapsulation as a concept in and of itself is not the enemy. I've mentioned this before, but in my particular efforts one can still achieve refined encapsulation by adding an internal control system component (AbstractComponentManagerControl / ACMC) to a component manager (may be an entity or whatever) that may veto or transform components or systems added / removed. If this control vetoes all additions / removals you just made that component manager final, etc. Want to change how it works then compose the component manager / entity with a different ACMC and series of components / systems. Potentially you may achieve your modification through composition (very quick) or you'll be able to just modify the smallest amount of components necessary to realize the change then swap out the offending ones. This also aids in debugging as with declarative composition w/ a little control flow especially on Android being able to filter with device and family names one could branch and load the old and new composition on two different devices testing both at the same time, but on different devices from one build.

Folks should realize that creating a CA and validating its performance characteristics for near real time usage is a difficult task. In my case the ES part is just an extension of a more generalized CA. Since my effort is a runtime middleware layer converting and granularly separating this runtime from its prior OOP configuration so that it runs well over J2SE, Android, <fill in next Java environment / GL binding / etc> is what has taken 99.5% of the time. Not everyone should create their own CA, but those who do will also become better developers and fully use and understand all the advanced language constructs of Java 5.

Conceivably using a well constructed CA / ES once one wraps their head around it and understands how things work together makes coding and prototyping faster and efficient in addition to flexibility through the entire design and implementation process to make quick changes vs massive refactoring.

Ack now to respond to all the good comments since my last post... erg.. will take a bit, but I'm on it... My initial verbosity was due to being on a plane with free provided chrome book and wifi... This next one due to good / interesting comments on the forums!  Cheesy


Edit: I suppose to make things more clear as of course in OO design the "has a" relationship is available as any member field fits this description. What component oriented programming in an OO language like Java changes from normal OO is that the "has a" relationship becomes implicit rather than explicit for component managers, entities, etc.
19  Game Development / Performance Tuning / Re: Android threading vagaries on: 2011-11-22 08:24:03
Why do people have so much trouble with multithreading? It's not hard to implement at all.

Uh, I highly doubt you have an efficient and general purpose framework for separating various logic oriented sub systems from rendering. Working with threads is not difficult on the surface and of course is the essential approach with networking, I/O, or long running processes that can easily be separated from the main update / render loop.

As I mentioned in the particular example case of glow ball NVidia has great multithreading here because the separate cloth / tapestries _do not_ interact with each other. I just recently attended an NVidia presentation at AnDevCon where they showed some very fancy tools for debugging GLES on Android and such; I do believe they will be public soon and are amazing for seeing thread / core utilization and debugging shaders and frame by frame rendering by each step / GL call.

What this example translates too is that it's easy to implement a trivial example in a multithreaded context if you know exactly how things will interact and they don't overlap. It's much harder to create a general purpose framework where there isn't advance knowledge of the task at hand which can scale from one to X processors.

There is absolutely a reason why Carmack stuck with the single threaded approach until Rage. Even at that if wikipedia is to be believed it only was likely in the last ~3-4 years that the switch got traction w/ id tech 5 given the WWDC '07 anecdote. http://en.wikipedia.org/wiki/Id_Tech_5 Even with all the neat potential cool stuff id Tech 5 does it still is a relatively closed system with 100% known sub systems thus the multithreading could be relatively baked in a specialized manner into the engine.

20  Game Development / Performance Tuning / Re: Android threading vagaries on: 2011-11-21 00:55:12
Yeah.. I'm still on the fence with multiple threads. I know I got to get there, but for now it seems like a specialized case. For instance in the NVidia glow ball demo which looks great they are spawning separate threads to deal with the cloth / physics simulation, but that is possible because in the demo each tapestry / cloth does not interact with each other. http://www.youtube.com/watch?v=eBvaDtshLY8 I'm first going to take a look at Scala, actors, message passing in Scala and evaluate on how to proceed. Haven't had a chance to dig into Scala yet, but I'm gathering the favor of immutable message passing won't be efficient per se on Android. So I foresee some sort of generalized COP (component oriented) message system similar to how I handle input events.

That being said I don't know how much one can get out of basic / general logic + render threads separated. It doesn't help much since in the general case as unless the rendering thread gets updates it's just duplicate frames being rendered. There is much to do in this area especially for Java oriented frameworks.
21  Discussions / General Discussions / Re: Still hardly any games, why entity systems suck, and why 4k is good on: 2011-11-21 00:25:03
>Firstly, this obsession with entity systems is the pustulent boil of a symptom which I used to call "object oriented wank".

Hah.. So I am late to the party on this one and mobile, so I don't have the quotes I yanked yesterday, but since I've been around here for ~9+ years _without_ releasing some code I suppose I'm obligated to chime in; by the time I do release my efforts which I'm squarely trying to get fully live / public by Q2 '12 w/ early access opening up to a wider audience in a month or so I'll have put in 12k hours min ~15k hours max  Roll Eyes I'm likely the biggest "offender" on JGO. While yes this forum is game dev oriented keep in mind this is also one of the few places where performance Java is discussed online. Not everyone is doing simple (but polished!) 2D games Cas. You are right in that you can stick with the same old approach you've done for years and keep it OOP for your particular case, but that is a limited case. Should beginner and intermediate devs do this; well actually, yes they should get a handle on essential OO dev.

For the longest time until the arrival of Android I couldn't really justify any ROI releasing a desktop only framework. My efforts for quite some time were focused on spatial audio, building a studio for it which took years (& $$$ that game dev would not provide), prototyping hardware and the Java software framework I created initially was for network / OSC (Open Sound Control) control of external hardware software & fast 2D / 3D GUIs. Basically due to long term funding concerns I had time to muck about with software and architecture experiments. While I dabbled in 3D efforts to learn GL via a Q3 class level renderer I also used it to send / control external spatial audio systems (via SuperCollider). It only was until Android came out and I jumped on it Oct '08 when the G1 hit my hands that potential ROI appeared for releasing a cross-platform client oriented framework for app & custom hardware dev (I'm working on a custom DSP box running Android). I already played around the the Danger SDK / Sidekick3 doing some porting work of my efforts back in '06, so I knew things were legit with Android.

I'm one of those "architecture wonks" though and went on a long path of refining my code base into ever increasing modularity. First mostly through OOP, but it broke down eventually and I turned to component architectures; COP (component oriented programming). Component oriented Entity Systems (ES) are just a special case of COP. I hardly think the handful of folks on this board who have examined and created their own prototype ES systems are / were wasting time. modularity is architecture. There are plenty of advanced language techniques one utilizes in COP and that alone improves the devs expertise.

I could have released a more OO oriented effort April '09 when I got everything ported over to Android, but realized the OO approach is even further flawed when trying to treat the Android ecosystem holistically and creating well written software that runs across the ecosystem. I jumped whole hog into component architectures at this point. It should be painfully obvious to most that the old school (just like your penchant for OOP) approach of tying the Android SDK to firmware and additively releasing new APIs was going to cause havoc. Even API level 1 -> 2 -> 3 it was painfully clear what was to come. Android is fully capable of advanced games and such. It doesn't create limitations on devs that will help them ship a quality game as Cas recommended. If anything there is a complexity / scope expansion if the dev wants to target more than a handful of devices w/ many pitfalls at each OS / API level to work around.  

And of course the SDK itself is OO derived. I could make a whole post about how the Fragment API addition is a botched example of OO dev where a short cut was taken at the total expense of future app / activity control flow modifications; IE they loaded the shotgun and aimed it at their knees. In my efforts I'll be able to supply Fragment API support as a component addition that can be enabled / disabled and work back to API level 3 (I'm pulling the main implementation from the compatibility API). Like I mentioned though I can expand on this for a whole post on a potential failure of OO and dirty implementation of a new Android API; where expedience of implementation won out over future maintenance concerns.

Anyway.. I'm one of those grand vision kind of folks and am creating a real time app / game dev client runtime / SDK that can be configured across J2SE & all of Android. Being able to create specially tuned runtime distributions for different vertical app categories or even running on custom hardware is important to me. Heck I want my stuff running satellites in space one day soon. None of this happens over night and I knew way back when I was in this for the long haul. My spatial audio / hardware focus alone indicated this was going to be my life's work and go on for years. I'm very happy that I can finally spin off a software product from all of this as it has way more ROI than custom / niche spatial audio hardware w/ small margins. I do plan to get back to the DSP hardware in the coming years especially now that I have the R&D media facility.

Back to COP and such. Yes.. Indeed my final push into component architectures has been a long and arduous one especially in refining and constantly refactoring a significant OO framework (~150k SLOC) into a very granular component oriented one. This has consumed most of my last 2 years of dev. Thank goodness when it's done it's done as it's a laborious and mind bending process. There are little performance downsides BTW; only amazing flexibility in runtime APIs offered and ability to run on practically any Java based environment.  I dunno... When the scope is limited OOP will do OK and be expedient.

I don't think anyone working with ES here at JGO are limiting the output of Java games. I'm considering for my next big demo to create a cross-platform renderer for the Grome level editor and COP + ES are not going to hold me back. To each their own I suppose. I think there is just as much chance for one of the JGO "architecture wonks" to make it big. New ideas though take longer to germinate. I know I'm a way better developer / architect because of my chosen path. I love coding and architecture and am passionate about "doing it right" and exploring new ways of doing things if the old doesn't pass muster. I finally found an approach to Java after 15 years that I'm truly happy with that make the grand vision possible. This approach will play nicely and work well with JVM languages and the next 10+ years of dev efforts. Now code code code and mmm... can't wait for it to get out now.
22  Game Development / Performance Tuning / Re: How to find the worst allocations in Eclipse w/ Android (Dalvik) JVM? on: 2011-11-20 23:29:55
Indeed. It's tedious and silly about the conversion, but the best way I've found to handle difficult to find issues. YourKit has been a good friend for many years. When you are bleeding as much as you are presently the current way you are searching for things works.
23  Game Development / Performance Tuning / Re: Android threading vagaries on: 2011-11-20 22:49:42
Yeah.. I've stuck single threaded this whole time, but use the java concurrent executor API to kick off longer running tasks. I have a little framework built up around the executor API to get callbacks and such. IE more powerful than asynctask and cross-platform. It seems a single threaded approach works best for the time being and I easily get 60FPS+ for Q3 levels on Galaxy S2 / Tegra2+. Cas, it also seems that you may be playing around with the stock GLSurfaceView.  I wrote my own "GLSurfaceView" that works with my clock/timing thread and handle GLES context creation and use eglSwapBuffers directly. It works well.
24  Game Development / Performance Tuning / Re: How to find the worst allocations in Eclipse w/ Android (Dalvik) JVM? on: 2011-11-20 22:40:09
I don't have the tools in front of me, but I dump hprof files from ddms (a button on the toolbar) then use the hprof convert tool and load them in YourKit to get a full view of allocations and such from known points when the hprof files are dumped. It's a bit laborious, but YourKit is a fantastic tool. If you are getting 1.5MB a second obviously there is a problem somewhere. It's certainly possible to have no runtime overhead on Android as in desktop Java.
25  Game Development / Shared Code / Re: Entreri: A new entity-component framework on: 2011-10-27 10:19:08
I honestly think bytecode transformation is the only way to make an entity system in Java. Without, the sourcecode just becomes too messy to work with. The Java language simply doesn't fit this non-OOP approach.

@Riven: Can you expand on this a little more? I may have missed earlier discussion in other posts if you shared anything before.

So far I've not seen a need for bytecode transformation in my efforts nor want to really go that way given J2SE / Android compatibility; I assume there may be some difficulty there. I admit maybe I'm missing something here. I've not pragmatically worked with bytecode transformation and things seem just fine without it for the component architecture / ES / and the whole expanded library of components with my efforts (600+ platform components!). Thanks for your thoughts. 
26  Game Development / Shared Code / Re: Entreri: A new entity-component framework on: 2011-10-26 00:41:15
I have not done any tests with Android, although you're welcome to try Smiley
I only use annotations the first time that a type's ID is created.

Not having looked too closely an Entreri are type IDs cached or is this something that gets hit every time a component or entity is created? If it's not cached you may see performance drop off considerably. Even so, something to test and keep in mind when you get a chance to looking at Android performance. I was very frustrated by yet another gaping hole in the Android API / core Java language support.
27  Game Development / Shared Code / Re: Entreri: A new entity-component framework on: 2011-10-26 00:27:59
Cool, took a quick gander at the code. I'm still uneasy about game specific entity/component systems, but that's just because I've embraced component architectures whole hog and everything in my efforts utilizes the approach. I think small light weight efforts like Entreri are good to have out there though. Congrats on finally settling on an implementation approach.

@lhkbob have you tried any tests on Android?

Recently in the finalization / release engineering process of unifying my component architecture / entity system efforts I happened to roll in some annotation usage into the core architecture and immediately performance dropped off.. It appears Android API 1-13 suffers from horrible annotation support and this is for Class annotation access let alone field and method usage which there are further inefficiencies in certain methods like "equals" in Method / Field doing insane string building / string comparisons, etc.  Just a heads up that performance may suffer greatly on Android due to annotation usage.

I posted more about it here with the relevant code snippets:
https://plus.google.com/u/0/117904596907381647757/posts/WBxsvqgP4iP

Sad Very sad panda as I can't believe such inefficiency was never caught for many years. As things go there is apparently a fix for Android 4.0 / ICS, but I'll believe it when I see it at this point. However, this doesn't help usage on the hundreds of millions of existing Android devices that won't see ICS.

I got around this by implementing my own annotation caching in my component architecture. You might have to do something similar for your ES if it is annotation bound / depends on it deeply.
28  Game Development / Newbie & Debugging Questions / Re: Enums ! on: 2011-10-14 03:49:02
I'm a huge fan of enums and particularly extensible enums.  One of the problems of extensible enums is that you can't use them in EnumSet. EnumSet is necessary to perform set operations efficiently otherwise things get particularly horrendous especially on Android. I created a new collection ExtEnumSet that is like EnumSet, but supports extensible enums. I wrote more here:

https://plus.google.com/117904596907381647757/posts/aHiaoA8f6WZ

I've moved to the ExtEnumSet for storing entity state in my ES.

Another problem with EnumSet is that under the hood it keeps track of a unique array of Enums for the given supported type for each EnumSet. Ahh.. This may be the case for Java 5, but I just checked in Java 6 source and it looks like this array is universally shared which wasn't the case in Java 5 if I recall correctly. I actually finally had to move to Java 6 due to javac / compiler issues with some sort of generic method failure with Java 5.

Anyway.. I'm a huge fan of extensible enums and they were the final missing key to really unlock state tracking between unrelated components in the component architecture I'm releasing soon; useful in so many ways. Also it's quite easy to use enums extensible or not as components in my component architecture. I yap on a bit about that in the long ES topic on B^3's blog:
http://t-machine.org/index.php/2011/08/22/entity-system-rdbms-beta-a-new-example-with-source/comment-page-1/#comment-30180

[edit] hah, that link to the ES comment is silly Adam / B^3 ruffled my feathers slightly, so I kind of go a little off in that reply.. It's the one where I described using enums as components though.  Shocked  The whole thread is a fairly spirited discussion of sorts..
29  Game Development / Game Mechanics / Re: Component based game objects on: 2011-10-14 02:35:59
@theagentd & others...

I'm very close to releasing a comprehensive component architecture framework as part of a platform for Java/Android called TyphonRT. There is an entity system (ES) extension as well. I've put a considerable amount of time into the component architecture and ES making it efficient and fast. While yes I'm indeed going to be charging for aspects of the larger platform the core component architecture and ES will be released under a slightly modified GPL classpath license allowing usage in any project.

I've spent a considerable amount of time on performance matters. Like Artemis and B^3's articles / reference implementation there is the component as data / system as logic separation. One performance aspect I'll mention though is the ability to recycle containers (an entity), components, & systems. Essentially this is a generic object pool such that when an entity goes away it is ripped apart and the container, components, and systems are recycled and when entities are composed they can pull them from the recycler. If the game is generally well tuned regarding entity lifecycle the recycler footprint can be kept low leading to none to minimal GC in runtime.

While yes there is a general performance concern when one is querying a container to receive a component (essentially a HashMap retrieval) even with the majority of code flow utilizing this method the bottleneck remains with fill rate for instance which isn't related to the ES / component architecture.

I'll be giving an all day workshop at AnDevCon II on Nov 6th and a large part of the discussion will be about entity systems and performance concerns. My main test case is a Quake3 class engine example, so it's reasonably comprehensive. I'll be doing to initial early access release at that time and am hoping to get to full public release by March. I've been working on TyphonRT for years, so it is well formed.

Like Cas mentions if you want to ship a game that is of low to moderate complexity with static unit types without being concerned too much about reuse for future games just go at it and don't worry about an ES. He's been successful with this approach for sure!

If you are an architecture wonk like me you spend years fine tuning and improving ones application of the larger craft; [edit] err games forthcoming! Roll Eyes I happened to end up fully in the component architecture / composition camp after years of minimizing ties to OOP as core architecture. My ES went through the pain of OOP and eventually buckled. As things go a lot of the Java component oriented based ES popping up are not necessarily refined and serve more as a reference implementation for the general idea.

theagentd, or others interested in checking things out in Nov drop me an email at the contact email from the TyphonRT site or send me a PM here. The basic splash page up now while not inaccurate doesn't give away all the details of what TyphonRT has become as a platform which will be revealed on public launch. Anyway, I'd be glad to spend a reasonable amount of time to personally work with you regarding ES matters and TyphonRT in Nov as it should particularly serve well for RTS games.
30  Discussions / General Discussions / Re: Hello ... and looking for advice on mixing Java & C++ on: 2010-05-27 22:43:49
One should be able to use the NDK on Android if the game engine already exists in C/C++. Obviously if the iPhone is a target it is necessary to work in C/C++. On Android each app even NDK still is tied to the Dalvik VM. There is full support for OpenGL ES in the NDK, but you have to buffer input controls (key / sensors) from the Java side to the native side. Also it is my understanding the audio has to be buffered back to the Java side as well and can't be played on the NDK side. Overall if iPhone compatibility is required the NDK is definitely an option on Android. I'll soon be releasing my middleware tech for Android which includes a bunch of input control configuration and virtual controller overlays for devices without a keyboard. I'm making an effort to make the input controller / virtual overlay code work with NDK apps.
Pages: [1] 2 3 ... 6
 

Add your game by posting it in the WIP section,
or publish it in Showcase.

The first screenshot will be displayed as a thumbnail.

xsi3rr4x (57 views)
2014-04-15 18:08:23

BurntPizza (55 views)
2014-04-15 03:46:01

UprightPath (68 views)
2014-04-14 17:39:50

UprightPath (51 views)
2014-04-14 17:35:47

Porlus (68 views)
2014-04-14 15:48:38

tom_mai78101 (93 views)
2014-04-10 04:04:31

BurntPizza (153 views)
2014-04-08 23:06:04

tom_mai78101 (249 views)
2014-04-05 13:34:39

trollwarrior1 (205 views)
2014-04-04 12:06:45

CJLetsGame (212 views)
2014-04-01 02:16:10
List of Learning Resources
by SHC
2014-04-18 03:17:39

List of Learning Resources
by Longarmx
2014-04-08 03:14:44

Good Examples
by matheus23
2014-04-05 13:51:37

Good Examples
by Grunnt
2014-04-03 15:48:46

Good Examples
by Grunnt
2014-04-03 15:48:37

Good Examples
by matheus23
2014-04-01 18:40:51

Good Examples
by matheus23
2014-04-01 18:40:34

Anonymous/Local/Inner class gotchas
by Roquen
2014-03-11 15:22:30
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!