Your source code is there:
http://prime.turquoisegrotto.com/java/bluefiend.java
Isn't it?

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.

The bottleneck seems to be there:

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?

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".


Maybe separate the JFrame, the KeyListener, the MouseListener and the MouseMotionListener (principle of "separation of concerns").

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

ever tried putting a XBOX 360 game in a ps3?

"hey if you wanna play XBOX GET ONE!" lol

Overall I can recommend "Programming Methodology" which is a course at stanford "CS106A"

was posted on youtube by stanford

http://www.youtube.com/watch?v=NPzPnycCFuE&feature=PlayList&p=84A56BC7F4A1F852&index=4

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... if you deliver this kind of code at a software company, you get your ass handed to ya

this is just gargabe

functional code is nothing compared to structure and comment


If I would write this kind of code at my university, I would, even if everthing works, get 0 points...

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

I didn't say you code 'sucks', I'm just trying to help.

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.


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.

one thing you can do is using checkstyle

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.

http://checkstyle.sourceforge.net/

But adapting your code to every single error checkstyle will output... well I wouldn't recommend that either

just, I don't know, read a book or watch youtube link I posted

since you are programming quite procedural you need to learn basic java and OOP stuff, I guess

"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! 

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

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

// Json

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