Java-Gaming.org    
Featured games (78)
games approved by the League of Dukes
Games in Showcase (429)
Games in Android Showcase (89)
games submitted by our members
Games in WIP (468)
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 3 ... 10
 1 
 on: 2014-04-25 08:17:31 
Started by pploco1996 - Last post by trollwarrior1
I'm pretty sure if somebody knows how to do it, they would just tell you.

 2 
 on: 2014-04-25 08:04:51 
Started by Rayvolution - Last post by 65K
There is another culprit with the presented approach: you can't use the class (safely) without looking at the implementation details, which should usually not be the case.

 3 
 on: 2014-04-25 07:59:27 
Started by Rayvolution - Last post by Rayvolution
If you make something static, you leave the main path, so the question should be why instead of why not ?
For reading up on problems with statics, just do some research.
Why pull it out ? Because of the mentioned one-task-per-class rule for instance.

In a separate resource loader, it shouldn't be static either. Otherwise you could have multiple loaders operating on the same animations list. To prevent that, you could make a singleton of the loader - only to introduce another bad practice.
Besides that, it is perfectly valid to have several loaders keeping their own private animations. You don't have to do that, but to restrict class usage with no benefit by (bad) design makes no sense. And you never know what might be needed some day.

Hrm, I see what you're saying. What you described is similar to how my entities system works, although it also uses a static entities arrayList to keep track of everything. But really, I kept it static under the philosophy of "why not?" since I only ever want that single array to exist.

 4 
 on: 2014-04-25 07:49:56 
Started by Rayvolution - Last post by 65K
If you make something static, you leave the main path, so the question should be why instead of why not ?
For reading up on problems with statics, just do some research.
Why pull it out ? Because of the mentioned one-task-per-class rule for instance.

In a separate resource loader, it shouldn't be static either. Otherwise you could have multiple loaders operating on the same animations list. To prevent that, you could make a singleton of the loader - only to introduce another bad practice.
Besides that, it is perfectly valid to have several loaders keeping their own private animations. You don't have to do that, but to restrict class usage with no benefit by (bad) design makes no sense. And you never know what might be needed some day.

 5 
 on: 2014-04-25 07:46:53 
Started by Zarkonnen - Last post by Roquen
I notice (huge) performance improvements when pooling big stuff like bytebuffers.
So in this situation it could be handy, or am i wrong?
Special case reuse of objects will be manageable for most people so yeah this is a more than reasonable thing to do.

Ages ago in one of our "what features does java need" threads I talked about contracts and one of the examples I gave was one for the compiler:  @NoReference.  Which would allow a programmer to explicitly state where reference cannot escape.  This suggestion requires the verifier to make some trivial checks and then EA doesn't have to deduce anything about the marked reference.  There are non-escaping objects that the deduction will never catch (because it would take too much time and/or memory) but the programmer (can) know cannot escape.  win.

 6 
 on: 2014-04-25 07:24:04 
Started by Rayvolution - Last post by Rayvolution
- As a rule of thumb, let classes do one thing, means have one for rendering animations, one for loading.
The sheets are loaded as needed within the class, when an object is added it's checking to see if the sheet exists, if not, it loads them.

- The first animation is implicitly loaded, all others must be specified externally. Why ? Do not store resource paths and names inside, rather pass them in.
That's just to fill the array with at least one sheet off the bat, for testing purposes. Not going to be in the final code. The rest are loaded on-the-fly as they are requested, that way I don't need to load thousands of animations and only use a few dozen.

- Upper case names are usually seen only for constant fields.
My mistake, I was thinking all statics were uppercase, not just constants. I just rechecked the naming conventions and realized I'm wrong. Hmm..

- Let the number of animation frames be flexible.
Already planned, just not part of the test code. Eventually the number of frames and delay will be determined based on the sheet loaded.

- Put all members in private scope. MAP_ANIMATION_ARRAY is an implemention detail that should not be exposed.
Final product will have it private.

- As a beginner, do not use static. Ever.
There's nothing wrong with statics, they have their place. I think this is a good place. Why wouldn't I want it static? I only want one array to exist, ever. I could make it non-static if I pull it out of the object and make a resource loader, I just don't understand why I'd want to other than to make all the "statics are evil always" programmers happy.

But, to clarify your answer to my actual question; Basically I should stick the ArrayList in a separate resource loader class all by itself?

 7 
 on: 2014-04-25 07:07:55 
Started by Rayvolution - Last post by 65K
It feels awkward ? Alright, let be guided by your feelings...

- As a rule of thumb, let classes do one thing, means have one for rendering animations, one for loading.
- The first animation is implicitly loaded, all others must be specified externally. Why ? Do not store resource paths and names inside, rather pass them in.
- Upper case names are usually seen only for constant fields.
- Let the number of animation frames be flexible.
- Put all members in private scope. MAP_ANIMATION_ARRAY is an implemention detail that should not be exposed.
- As a beginner, do not use static. Ever.


 8 
 on: 2014-04-25 06:58:37 
Started by dleskov - Last post by dleskov
We are doing it again:

http://www.excelsiorjet.com/charity

What would be the good places beside JGO and Javalobby to post this announcement?

To moderators: Any chance to get a sticky topic here and/or in the "Engines, Libraries and Tools" forum until May 31? Thanks.

 9 
 on: 2014-04-25 06:33:23 
Started by pploco1996 - Last post by pploco1996
Pleaaaase I need to fix this for this weekend's ludum dare

 10 
 on: 2014-04-25 06:21:43 
Started by Nausica - Last post by HeroesGraveDev
I kind-of saw it coming, but I was hoping that OP would notice and fix it themselves

Pages: [1] 2 3 ... 10
 

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

The first screenshot will be displayed as a thumbnail.

theagentd (6 views)
2014-04-24 23:00:44

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

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

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

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

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

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

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

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

trollwarrior1 (217 views)
2014-04-04 12:06:45
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!