I'm watching it now. I would like to discover why it requires 3 Ghz. Please split your source code into several classes/files, 1719 lines in a single file are a bit too much. Put the classes bullet, ship, enemy, boss... into separate files. It would be better if you added more comments too. Thank you very much for open sourcing it.

You create a new BufferedImage in the paint method that is called often of course. The use of alpha composite is costly too. I'm trying to understand how to work around this. Avoid recreating fonts and colors in the paint method too even though the impact on the frame rate is tiny.

Are you sure you need the line below in the main loop?

1

Thread.sleep(10);

It would be required in C++ but not in Java as the JVM is able to do what is necessary to drive this useless.

In the class bullet, lots of "new" calls could be avoided as the array called "bounds" contains 4 points. You should rather call "new" once for the array, once for each point inside the array and after that, modify the coordinates of the points in your methods update and update2. I do the same remark for the classes called "enemy", "boss" and "ship".

I concur with gouessej, a lot of things that are static and wont be needed to created dynamically while drawing shouldn't be called in the draw method. It would also be nice to structure the code somewhat.

I concur with gouessej, a lot of things that are static and wont be needed to created dynamically while drawing shouldn't be called in the draw method. It would also be nice to structure the code somewhat.

// Json

ok good, so I am not the only one who looked at the source and went "waa"

like goussej said, seperate all of the classes, it also makes developing easier, casue you can have more than one class open at a time

Watching the sourcecode is indeed a bit 'worrying' - which is not meant as an insult BTW.

There is no structure. This is very much like procedural programming. In Object Oriented Programming (OOP) one of the goals is to spl;it your code into parts that make out the 'things' in your game. If you have an enemy, you need an Enemy class, same for Bullet, Laser, Wall, Player, etc etc. Suddenly your code becomes much more structured, and coding becomes easier. All functionality of a 'thing' much be coded in the class of that thing. For example: your particle engine should have a lot of private methods to handle all the dirty stuff, and public methods called tick() and render(g).

Now your Game class only has to call particleEngine.tick() at a fixed interval, and particleEngine.render(g) whenever you're drawing stuff to the screen.

Same goes for Bullet and Enemy. All code that is responsible for them, should be in those classes. Only very abstract (highlevel) functionality should be available to other classes through public methods.

You might want to read some tutorials (like those of Keven Glass) that clearly guide you through the process of building a nice asteroids game.

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

Okay I find this has become really stupid. Saying I don't know proper programming methodology just because I prefer my classes be in the same .java file is insane. It would take less than 5 minuets to add public before each of those classes, and put them in a java file with their class name. I prefer it how it is. Not only that, but there is actually structure if you look. It's something like ship -> playership -> enemy

Both the play and enemy are ships, so it makes since that they should extend ship. bullets aren't so they don't. Don't say I have no structure just because I use a different structure than you.

Okay I find this has become really stupid. Saying I don't know proper programming methodology just because I prefer my classes be in the same .java file is insane.

It isn't the only thing that we criticized. I'm a bit disappointed by your behavior. I thought you would be happy to see that some people have watched your source code carefully. Some of us quoted some good practices and principles ("separation of concerns") that are known to improve the quality of the code, we don't criticize your source code only because you program differently, you're wrong.

Quote

The term separation of concerns was probably coined by Edsger W. Dijkstra in his 1974 paper "On the role of scientific thought"

Quote

In computer science, separation of concerns (SoC) is the process of breaking a computer program into distinct features that overlap in functionality as little as possible.

What about my suggestion that could improve the performances, especially the frame rate and the memory use? Do you find them useless too?

Hi!It isn't the only thing that we criticized. I'm a bit disappointed by your behavior. I thought you would be happy to see that some people have watched your source code carefully. Some of us quoted some good practices and principles ("separation of concerns") that are known to improve the quality of the code, we don't criticize your source code only because you program differently, you're wrong.

What about my suggestion that could improve the performances, especially the frame rate and the memory use? Do you find them useless too?

I only wanted to give you some help. Is it stupid?

No, I liked that. I wasn't talking about your post at all actually. your post was very helpful, thank you.

Edit: Okay, so it was you that talked about spiting up my code, but that wasn't what bugged me. I thought I remembered someone saying something like "You're code isn't even split up, and there's no structure!" I was wrong.

Look people are just trying to help.They are right, the code has horrible structure and no JavaDoc/comments. If you want people to help you work on this then that's something you need to accept and fix.I don't understand why he needs to give you examples... Just look at someone else's work and you will see.I'm willing to help if you want to know what areas need to be changed, if you don't want to go read books about this.

the bullets seem to miss the correct direction towards the mouse position. I think it's because the mouse coordinates start from the very left upper corner of window but drawing coordinates start from where u paint your graphics. So you probably need to subtract from mouse y like -14 or something before you pass it to calculations

Look people are just trying to help.They are right, the code has horrible structure and no JavaDoc/comments. If you want people to help you work on this then that's something you need to accept and fix.I don't understand why he needs to give you examples... Just look at someone else's work and you will see.I'm willing to help if you want to know what areas need to be changed, if you don't want to go read books about this.

The structure is fine, and no comments doesn't automatically make code bad. It's not helping to just say something sucks. You need to provide examples.

The structure is fine, and no comments doesn't automatically make code bad. It's not helping to just say something sucks. You need to provide examples.

Edit: This kind of shit is making me not want to open source anymore.

It's true, the structure is fine and no comments doesn't make it bad, FOR YOU. It's your code so it's sure that you can understand it very easily.

While you still have structure, it might not be the same structure as the structure people are used to, so they consider that this is a bad code. If you want to be able to work in a group, you got to use the structure that is normally use because it's what most people are used to and it's hard to get used to a new structure. So most people will consider it a waste of time to work with someone else who code completely differently than they are.

I won't give examples, that you can look up. But say a few basic things that will help you improve your code.

-Public fields are a no no. You needs to make sure everything is encapsulated. So make all fields private and only use methods to access them.

-Spilt the classes in separate files.

-Class name first letter starts as a capital.

-A method should only have one function, not doing many things at once.

... and its late here, so someone else can take over.

Alright, I'll agree to that. But Cero is saying my code is bad, and my game is running baddly because I don't have comments or capitalisation. Once I finish a project I go through and clean up it's code. This code is "sloppy" (I.E. lacking in minor manners) because the game isn't done yet.

It's true, the structure is fine and no comments doesn't make it bad, FOR YOU. It's your code so it's sure that you can understand it very easily.

While you still have structure, it might not be the same structure as the structure people are used to, so they consider that this is a bad code. If you want to be able to work in a group, you got to use the structure that is normally use because it's what most people are used to and it's hard to get used to a new structure. So most people will consider it a waste of time to work with someone else who code completely differently than they are.

Thank you. The thing is that no one is giving an example of what "normal structure" is and why mine is "abnormal." I agree that the no comments thing is bad, but really I'd just be adding things like "//this is the paint method. It paints the screen" I don't know what NEEDS to be commented, as I was never very good at explaining my code.

Don't forget there are a lot of experienced people lurking around these forums, and the last thing they want to do is to annoy new folks, and at the same time they want to prevent those new folks to make the mistakes that everybody once made: we all started somewhere, and the guys here are mostly autodidact, so most of us have learnt by mistake, trial and error, the hard way. You can't blame us for trying to defend you from your mistakes - that we made too - to help you get further, quicker, with less hair pulling and fewer grunts.

Now I think the problem is that people don't tend to learn from other's mistakes, only from their own. So when you put a lot of effort in a project of yours (and judging by the code, you put that effort into it), you must feel very proud of your work, showing everybody what you cooked up, and even releasing the sourcecode. Now this is the time at which every experienced programmer takes a peek, scratcches it's head, and probably remembers how it felt like to actually write such code. It's hard, debugging is a nightmare, it's not maintainable at all (which might be the least concern for you - as it works!). So it's only natural for 'us' to try to push you in the right direction, while at the same time you feel there is nothing wrong with your code. Please don't take it too personal. In a few months, you'll look back at your code and wonder what incredible progress you've made since then. You'll gain more and more experience with programming, and you might change your ways, not because we told you, but because they start to make sense, when your projects get bigger, and need structure for you to work on them, let alone get them debugged, tested and polished.

Seriously, I've been programming for almost 10 years now, and I can hardly look at code I've written 3 years ago, I get all itchy. Now when somebody else would have read it at the time, and would have told me all that was wrong with it, I might have felt offended, because... it works, I get my own design, I think it makes sense, and who are 'they' to judge my code. Well... 'they' might have more experience, and only for that reason, I should take such advise seriously, even if I think there's nothing wrong with my code.

In conclusion, we're trying to prevent you from making our mistakes, but may be forgetting that those mistakes have contributed to our experience. You need to make mistakes, just not too much, so it helps to be openminded towards seemingly harsh criticism, so your can grow faster than you'd have otherwise managed on your own.

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

I really hate checkstyle because it really takes it up in the f**king ass, but at my former university, if checkstyle reported only one major error on your code, you would get 0 points for your assignment.

Thank you. The thing is that no one is giving an example of what "normal structure" is and why mine is "abnormal." I agree that the no comments thing is bad, but really I'd just be adding things like "//this is the paint method. It paints the screen" I don't know what NEEDS to be commented, as I was never very good at explaining my code.

"The paint method takes all the enemies and the player ship and paints them, as long as they are in active state (e.g. not killed). The paint method handles all the gamestates, so the code for the title screen, the boss fight and the pause as well as the gameover screen is also contained in here. The positions of the ships are _not_ updated here, but from the update() call in the main loop."

Another good candidate would be the collision method. This could at least contain the method of collision detection (AABB, OOBB, Sphere intersection). As a rule of thumb, just thow in some comments as soon as you don't do something obvious. You will be thankful, once you look at code older than a couple of month, trying to understand, what you were thinking.

Splitting your code into smallert parts is also a way to overcome this. If you have properly named classes (and base classes) and small methods doing one thing and are named like that, you can easily omit most comments, since your code would read like object oriented english text (to all our non-US/non-UK fellows: don't use your native language in class names and method calls!!!).

Some hints:

- Start classnames with a capital letter. Don't ask why, just do it. (If you ask why, it's a distiction of classes and variables for the human readers of your source. it also helps to identify the constructor of a class)

- You could also use accessors (getter/setter) for your fields and don't use public fields (this one is debatable; I personally use public fields when I am _really_ sure that the field will always have read/write semantics and I never would need a "realtime" change notification. This is in my experience only true for final struct like datasets/argument containers or temporal instances of private inner classes)

- Use separate files for classes (You might prefer it in one file _now_, but trust us, you won't like it later)

- Find yourself a decent IDE and learn it's keyboard shourtcuts (especialy for goto type/class) (This way, there is also no disadvantage anymore for having classes in separate files)

- Use javadoc comments - at least for classes (Try to describe the purpose of the class in "human readable" form, like explaining it to your mother )

Having said that, I don't find your code too bad, just more like a sketch or prototype instead of a game.

On performance:

- PROFILE, PROFILE, PROFILE!!! Even if you need a week or two to make sense of a profiler, it is the most valuable tool you will have, not only for performance improvement, but also for memory leak debugging (Yes, this will occur!)

- Try to create images/sprites/whatever possible beforehand and only paint them

- If you have to create things on the fly, try to cache them and successive only paint them (only for objects that are expensive to create, don't cache Points and such!)

- For your blur, you combine 5 images into one, couldn't you just use 2? - The last screen already including the accumulated screens from the frames before - The new screen

- Eventually use spatial divisioning for collisions (but probably not be necessary for your amount of bullets/enemies, but good to know anyway) - divide your screen area into a grid (e.g. 16x16) - make a collection for each grid cell - on every ship update, remove the ship from the last collection ist was in - after that put the ship instance into the collection representing the grid cell it is now positioned in - on collision detection, evaluate the cell, your bullet is in - just check for collision with the ships in this cell

One last note:Don't whine and call criticism bullshit only because we do not pamper you!

Quote

Edit: This kind of shit is making me not want to open source anymore.

This is just childish. Have a job? You'll be surprised what kind of feedback you might get there...

I'm sure there's plenty in there that people can criticize me about, but I do at least follow all the Java coding conventions and I've Java doc style comments for every single method (even if they're "obvious") as well as line-by-line comments.

I've really gotten in the habit of putting a single line comment above almost any line in my code. Stuff that is obviously together, like:

x += dx;y += dy;

Obviously only gets one comment, but I'd put a comment in there even though the functionality is pretty obvious.i.e.

//Moves the object by the change amount.x += dx;y += dy;

The whole reason for all this is so that theoretically anybody anywhere could understand your code just by reading a bunch of comments, never needing to actually read a line of code. Every bit of functionality should have a comment about it, to the point that you could make a big pseudocode summary of your code with just comments.

This also makes it really easy to port your code over to other languages, which can be very important in a professional environment.

And comments aside, putting all your classes in one java file isn't a good idea, like everybody has told you already. Sometimes it makes sense (like Point2D.Float Point2D.Double) or in my code MazeGenerator.Coordinate, but you do that when that class is inseparably linked to the main class in the Java file. As in, the Coordinate will never be used unless you're dealing with a MazeGenerator. Private classes are useful for stuff like ActionListener implementations, but once again you typically want to split everything up as much as possible. There is no right way to do this, and you'll see some people decided to couple two classes together while others won't, but you should always at least have a reason if you're going to embed classes.

(Also, before you harp on my code, I should note that the comments are in the areas that are meant to be learned from - the maze generation. The Swing stuff in the GUI has practically none at all because that's just so people can test the maze generator)

Please don't give up. Opening your source can be very useful, my game would have never existed if Vincent Stahl had not opened the source of Art Attack. You cannot predict how it will be used. Thank you for your contribution and try to learn from the (sometimes harsh) critics.

I prefer it that way as well and I agree its A LOT more readable however work is using the damn Sun code convention so I need to go the other way. But I just have the Eclipse auto formatting enabled as a save action on all my altered lines of code

++ I found that much more logical too as the brackets have nothing to do with if/else/while etc... so this is pretty unlogical to not put those on a new line as it delimit unbreakable/local code block and can be used without specific instructions before.

++ I found that much more logical too as the brackets have nothing to do with if/else/while etc... so this is pretty unlogical to not put those on a new line as it delimit unbreakable/local code block and can be used without specific instructions before.

1 2 3 4 5 6 7 8

{doublex=3;}

Stringx="2";

for(intn=0;n<10;n++) System.out.println(x);

However I dont do what you did there, not doing brackets because its just one line, although you might do it =P

However I dont do what you did there, not doing brackets because its just one line, although you might do it =P

brackets exists to make a bunch of code to appear as only one instruction/line, you put brackets because you have more than one line or you are doing something like "I make my single line appear as a single line" wich is useless.

EDIT :

IF act like the following

if condition do this single instruction (and so requiere brackets if you have more then one things to do at once)