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 (547)
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
1  Discussions / General Discussions / Re: Component Systems: Artemis style systems vs. traditional fat entities on: 2014-07-31 09:16:46
https://github.com/junkdog/entity-system-benchmarks - Nothing complete, but it's a start.

Thanks for doing this... I'll take a look and maybe one day have some time to do some comparisons with my efforts.

At work, so just a short notice: ashley 1.0.1 doesn't compare favorably to artemis forks - it spends a lot of time sorting, but I'm assuming performance artemis vs ashley will converge with later releases. Briefly discussed on their issue tracker: https://github.com/libgdx/ashley/issues/36
2  Discussions / General Discussions / Re: Component Systems: Artemis style systems vs. traditional fat entities on: 2014-07-27 17:34:27

I suppose that brings up an interesting distinction in classifying ES. None of this is rock solid terminology, so I'm curious if folks have any input. I'll classify Artemis / Ashley as type I ES. Type I basically lending themselves to having distinct structure such as having specific classes like "EntityManager", "Entity", "EntitySystem" where processing of entities occurs sequentially in a fully composed state. A type I ES often has hard coded classification schemes baked into the API that can't be altered. This is the aspect / family classification in Artemis / Ashley. In this case the CA elements that may be marginally present are hampered by a hard coded relationship to the classification scheme.


What exactly do you mean by processing of entities in a "fully composed state"? In both artemis and ashley, entities are only a little more than glorified integers (entityId - and some additional metadata, not necessarily stored by the entity itself).  Or is the hint in your definition of "Type II Es", being "fully generic" and having "self-modifying capabilities" (components as more than data-holders, I guess) - not entirely sure what either implies.

Mhhh okay...Still not too convinced here I guess. Let's wait for that performance benchmark  Grin Grin
(Not that it matters too much because Artemis is already pretty fast? So if you want to use an ES you already have a pretty good option there imo)

https://github.com/junkdog/entity-system-benchmarks - Nothing complete, but it's a start.
3  Discussions / General Discussions / Re: Java Swing GUI Creator on: 2014-07-16 13:09:28
Have to agree with Kevin.

If you want to go the route of GUI builders, make sure that the GUI format is not source code. Android has a pretty decent xml format for  everything GUI, but last time I checked I didn't find anything similar for pure swing or SWT.

My personal recommendation is to skip GUI builders and instead download MIG layout: it gives a lot of power without being obtuse.
4  Game Development / Newbie & Debugging Questions / Re: Should I move to LibGDX? on: 2014-07-08 08:12:28
Having y=0 at the bottom of the screen is actually really useful. Most objects are located by where their feet are, rather than where their head is, which makes positioning objects into an incredibly fulfilling experience.

Also, it feels more natural when objects are moving along the y-axis, especially in platformers: a falling object shouldn't have its y value increased, in my head.
5  Discussions / General Discussions / Re: Component Systems: Artemis style systems vs. traditional fat entities on: 2014-06-26 08:32:32
If feels like the prickly and gooey people have a hard time persuading the other kind why their point-of-view is the right and just way. Now I feel like waging a war on tabs vs spaces... which is counter to Watt's point, but I feel so very gooey right now.
6  Discussions / General Discussions / Re: Component Systems: Artemis style systems vs. traditional fat entities on: 2014-06-25 10:12:08
I'm actually not attempting to enter into the debate of component based or not.  You ask a question:  Do I do "A" or "B"?  I'm saying that's the wrong question.  The correct question is: "Here are my requirements (ATM)"  What options do I have?  By arbitrarily settling on "A" or "B" you're placing the importance of code before your requirements.

I read the question as - even if a bit vague - this is my higher level design, and what are some common, general approaches to these set of problems. It's no different than asking about approaches for avoiding heavy inheritance or other issues that are common to a specific domain.

@princec One layer of inheritance takes a lot more of skill/experience and forethought to pull off - code quality tends to degrade over time (I'm working in an 18 y.o. product - I stare into its perplexing depths every day); ECS's flat hierarchy tends to be more resistant to that. As Orangy Tang said, it also makes it more feasible having several programmers working on the  same code without getting in each others way.

Personally, I find ECS to be very intuitive - it lets me focus on the problems and scales very gracefully from a complexity POV (which was [the/a] primary reason for their being, not cache-friendliness - as is often brought up nowadays).
7  Discussions / General Discussions / Re: Component Systems: Artemis style systems vs. traditional fat entities on: 2014-06-24 11:41:33
I have this fantastic HDR, physically based, screen space shading code!  It runs at 200FPS!!!  So you can just drop it in any old game and not worry about performance!!!  Except that ain't so.  It ignores the math...even assuming the "user" has the same (or better) GPU.


Of course, but I don't think anyone claimed anything to that extent in this thread? The original touched CPU processing speed in regards to component/system design; certainly it doesn't make any guarantees about how often the screen redraws.

When developing for mobiles, I'm assuming everyone has (alternatively wants) a few lower-end devices to test on.

Edit: Ok, I kinda did *hrm*.
8  Discussions / General Discussions / Re: Component Systems: Artemis style systems vs. traditional fat entities on: 2014-06-24 11:22:44
FPS isn't a benchmark, rather an overall performance target. On mobiles, I think one can easily get away with 30FPS, as long as it doesn't dip below it.

Also, does the figure include actual rendering or is that just logic or is it logic and preparation to render?
Cas Smiley

Logic + preparation, I didn't/haven't investigated how to reliably get the FPS on android.
9  Discussions / General Discussions / Re: Component Systems: Artemis style systems vs. traditional fat entities on: 2014-06-24 10:53:33
500 entities isn't that much. I've managed just below 60 FPS on an old Desire Z (android 2.3, single core 800 MHz Scorpion) with 500 +/- 100 entities and ~25 entity systems.

- Don't use getters/setters for components. The JIT will inline them, but it will take time before everything is inlined
- Override processEntities and optimize which entities get processed; either by splitting the processing over two ticks or by some clever filtering (this implies that you manage the entities yourself in an optimized list, override inserted/removed in EntitySystem or roll your own)
- Direct array access is faster than getting each entity individually (processEntities): artemis-odb does this by default.
10  Discussions / General Discussions / Re: Component Systems: Artemis style systems vs. traditional fat entities on: 2014-06-23 22:48:28
I try to keep both my entity systems and components as specialized as possible: naturally, different games warrant different solutions, but I haven't found the need for optimizing in regards to marker components in a long time.

Marker components aren't *that* expensive, normally. Where and why is your CPU time consumed - because of a high entity count, sporadic insert/remove bursts, something else? It's hard to reason about an approach without seeing some example code or knowing more about your design - the risk is that you end up getting vague recommendations that don't really apply to your project.

A recent discussion over at reddit gave some ideas on how to more efficiently deal with batch insertion/removal of entities. It will find its way into 0.7.0 (sometime during the summer) - it might cover your use-case, or at least be slightly easier on the CPU.
11  Discussions / General Discussions / Re: Component Systems: Artemis style systems vs. traditional fat entities on: 2014-06-23 21:28:55
No need to poll, better sacrifice some memory and have each system maintain a list of all entities with a matching component composition. Entity Systems are notified whenever an entity has components added or removed, keeping the list up-to-date. This is how artemis and most ECS frameworks do it.

Edit: Sorry, misread your post. If dealing with a lot of entities... simply setting a flag here and there as a marker for being processed by another system, I could see why it might be a problem (are you sure it is the bottleneck though?). One solution might be a custom EntitySystem to which you manually insert entities that need to be processed as a result of some state. Alternatively, make the components even thinner, effectively having marker components and more specialized systems.
12  Discussions / General Discussions / Re: Component Systems: Artemis style systems vs. traditional fat entities on: 2014-06-23 21:14:45
I don't really have much experience coding games that don't use an ECS; maybe I've just been exposed to poor design, but imo an ECS does help structure the design and - thanks to the emphasis on compartmentalizing game logic in distinct entity systems - isn't as sensitive to spaghettification/ridiculous coupling.

Benefits of using an ECS - or stuff one pretty much gets for free:
- Since components are pure data, serialization comes almost at no cost (code-wise).
- Entity systems can easily be reused outside the game, very handy for level/game editors.
- New types can be defined on the fly - another boon for editors. Furthermore, it's pretty straightforward writing a generic reflexive editor for manipulating component data.
- Behavior reuse > code reuse.
- Easy to profile, both via profiler and in-game.
- Entity Systems can be toggled at runtime; pretty useful for debug renderers, disabling collision handling etc.

Lastly, to respond to the OP and fat components; it's certainly doable, but it tends to make the code a little more rigid and hence harder to refactor.

It's true that one of the potential benefits of ECS is writing cache-friendly code, but aside from us being in java-land now, it's not quite as simple as strapping on an ECS and automatically reaping the benefits of a happy cpu/cache relationship - Adam Martin wrote an interesting post on it recently: http://t-machine.org/index.php/2014/03/08/data-structures-for-entity-systems-contiguous-memory/

Most of the early work with ECS appears to have more to do with fast iteration times, rather than fast execution.
- http://cowboyprogramming.com/2007/01/05/evolve-your-heirachy/
- http://t-machine.org/index.php/2007/09/03/entity-systems-are-the-future-of-mmog-development-part-1/

13  Java Game APIs & Engines / Engines, Libraries and Tools / Re: JRebel on: 2014-06-18 13:53:26
And whats the difference from Eclipse?

You're not limited to only modifying method bodies, if that's what you mean. It's also possible to jack in custom resource parsers (loading level data from json or whatever). Only used it for web development myself; very handy.
14  Discussions / Miscellaneous Topics / Re: Longest program you have written? on: 2014-06-16 20:22:30
That would make for a fun java game jam/contest. Instead of "under 4k", "in 48 hours", etc, we could have a "best game with less than 500 lines of code" contest. It would have to include external settings/config files so no one cheats and stuffs all the meat into a .properties file or something.

Could be a fun idea down the road.

This would work only if everyone used (or someone who verifies used) the same [eclipse] formatter settings. It could be done though.

A more interesting approach would be to only measure the opcode count: this way it wouldn't encourage excessively obfuscated code or discourage meaningful naming conventions.
15  Discussions / Miscellaneous Topics / Re: Longest program you have written? on: 2014-06-16 19:35:39
Let's see some smaller numbers. Cheesy

I recently stumbled upon this self-playing flappy bird clone in 155 lines, incl graphics: http://glsl.heroku.com/e#14407.0
16  Discussions / Miscellaneous Topics / Re: Longest program you have written? on: 2014-06-16 17:03:46
Not sure, somewhere in the 50k-100k range. The code tends to be more expressive the longer you've programmed though, meaning the LOC to feature ratio decreases significantly. I remember back when I was somewhat fresh at programming - I could easily spew out 2-3k LOC per day; I rarely write more than 500-700 on a good day now, yet I manage to implement a lot more functionality in that same timeframe nowadays.

In the end, LOC isn't really a useful metric of anything - even if some backward companies encourage such nonsense.
17  Discussions / Miscellaneous Topics / Re: [Girls] How to completely block them from our lives? on: 2014-06-09 16:25:55
Are there not any girl programmers on this forum? I would think that there would be at least one.

This thread certainly isn't helping...

Not everyone is a programmer.

There are VERY few female programmers.

The majority of programmers don't work on games.

Thus, a female on this EXACT forum is pretty much a statistical impossibility.

Actually, the majority of the female programmers I've met have worked in gamedev.
18  Game Development / Newbie & Debugging Questions / Re: Entity Framework on: 2014-06-08 22:59:24
I was also thinking of maybe having a "root" entity that all of the entities can attach to. Then, you can specify rotation, scaling, and translation for the root. Without having to deal with pesky screen shake caused problems.

But basically what I'm asking is that if you were to make a entity framework with a nice working and learning curve, how would you do it?

Entity system frameworks typically don't have different kinds of entity types, only different component compositions making up the entities. The seminal series of articles on entity systems is still Adam Martin's Entity Systems are the future of MMOG development.


Vanilla artemis shouldn't be used anymore - it hasn't been in development for a long time and has plenty of bugs. Use one of the many forks floating around, if you like artemis' API - such as mine or gdx-artemis.

19  Game Development / Newbie & Debugging Questions / Re: [LibGDX & Artemis] Random Null Pointer Exception in System on: 2014-06-06 18:17:41
As a quick check; if you make the SpriteRenderSystem the first system to be processed (ie; add it to the world instance before any other systems), does it still throw a NullPointerException?
20  Discussions / Miscellaneous Topics / Re: Quad core + 2gb of ram on: 2014-05-30 13:53:00
If you're buying a new computer today, I wouldn't consider getting anything less than 8gb. I had 4gb in my old quad-core and I was hitting the memory barrier every day - even a browser can easily hover around 1gb mem usage when enough tabs are open; then consider IDE, background processes, the OS, gimp/photoshop etc. Ideally, you never want to close applications due to running low on RAM.

21  Game Development / Newbie & Debugging Questions / Re: Does anyone create custom annotations in their game code? on: 2014-05-21 15:14:37
And let's not forget project lombok for some clever hacks involving annotations and the JVM.
22  Game Development / Newbie & Debugging Questions / Re: How do you name variable for angles? on: 2014-05-15 09:19:56
What's wrong with angle? Or degrees - if it's the unit used.
23  Discussions / General Discussions / Re: Value Types Proposal for Java on: 2014-05-07 13:50:58
In C++ (and C#, I believe) a struct is only superficially/syntactically different from a class; so constructors and initializer lists work.
24  Discussions / General Discussions / Re: Value Types Proposal for Java on: 2014-05-06 21:54:43
Heh, must experiment with this during the weekend!

It's very unlikely that a 3rd party class would be suitable to be used as a struct. There is just theoretical support ^.^

I was thinking along the lines of libgdx's vector classes. Right now I'm using my own, more constrained struct-like approach, but it results in having to re-implement a lot of the math utility classes.
25  Discussions / General Discussions / Re: Value Types Proposal for Java on: 2014-05-06 21:40:10
Sorry, by "normal" classes I meant classes that came from an external library; would be neat to if it were possible to retrofit those too but that might be much harder.

26  Discussions / General Discussions / Re: Value Types Proposal for Java on: 2014-05-06 21:28:43
Derailing back to Riven's original reply.

I only very briefly skimmed the outer layers, but LibStruct looks really interesting!

When you say stack allocation, does that mean that you do the equivalent of scalar replacement? If so, are there any clever tricks to ensure that the intermediate representation doesn't grow too big for the JIT to optimize - apart from fiddlling with XX:MaxInlineSize etc?

I'm assuming the Vec3 class in the code snippet is one's own and not something out of an external library - or is it possible to allocate "normal" classes on the stack too (via external configuration or similar)? Would be super-useful, though maybe not plausible.
27  Game Development / Newbie & Debugging Questions / Re: Are HashMaps bad for Entity-Component-System Architectures? on: 2014-05-06 18:23:06
Most ECS frameworks have some sort of array-like data structure per component type. In artemis each entity is given an integer id: the id represents the index at which the component is stored.

Unless you have a lot of entities, you probably won't see a noticeable performance hit (ofc depends on platoform, entity count, GC and so forth). One of the ideas behind ECS, besides reducing complexity as the project grows, is performance: if all instances of ComonentX are aligned in memory, you'll get faster memory access (better cache locality), but java doesn't easily lend itself to contiguous memory layout when it comes to objects.

edit: If entities hold on to their own components, how do you get all entities matching a specific component composition?
edit 2: If you want to stick with your current approach - consider using the component's class as key and replacing the HashMap with IdentityHashMap - getClass() always returns the same object per class.
28  Game Development / Newbie & Debugging Questions / Re: Using files in META-INF on: 2014-04-24 12:05:03
Class#getResource is what you're looking for, see: http://stackoverflow.com/a/1273432/431535
29  Discussions / General Discussions / Re: The Big Linux Distro Thread on: 2014-04-03 15:03:14
1. Resizing window borders appear to be 1 pixel thick. The mouse flickers in a terribly ungainly fashion when attempting to hover over a border or

I think most (all?) window managers support resizing by Alt-RMB anywhere in the window.

For the most part though, it mostly comes down to a matter of familiarity. I feel like I can't do much whenever I'm confronted with a different OS: I switched over to linux back in 2000-2001 - OSX is ok (got acquainted with it last summer),b ut windows is just unbearably obtuse from my pov.
30  Discussions / General Discussions / Re: The Big Linux Distro Thread on: 2014-04-02 13:15:04
Granted I'm not using file managers often - except midnight commander, but I find dolphin to be rather clean: https://dl.dropboxusercontent.com/u/1615755/dolphin.png - certainly a long way from Directory Opus (heh, old times...). Dolphin can speak sftp too - good enough for simple operations.

Dropbox for linux is ok, but I believe the OS integration is better under win and osx.

If you go the KDE way, amarok is really nice. Quite different from how I remember winamp though. I also believe Ark (KDE's zip/unzipper) handles most formats, although gzip and bzip are more common in linux land.

Edit: KDE is butt-ugly in its default configuration, but can be made to look really nice. Also much less mouse-centric than the other window managers etc.
Pages: [1] 2
 

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 (13 views)
2014-08-16 06:20:21

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

Rayexar (58 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!