I still don't understand that... I've never gotten lost in my own code, even when it was ASM and everything looks the same.

Also, apparently, the things I do are not good... so you could try the opposite. That may be worse, though. xP

Remeber to comment all your code so you can go back to it later and understand what it all means.

What grade are you in? Your school doesn't offer programming classes?

Java may be slow but its cross platform and popular.

I'm still a little confused on where to start? Should I just read up on everything I could? Should I read then test something out? Should I just open someones program and learn from that? Put me in your shoes. How did you learn? Was it effective? Would you have changed something if you could of? <--Directed towards vivid programmers.

Comments are like the story of the 3 bears & goldilocks. Too many comments is just as bad as too few. For the most part, code should be self-describing: resist the temptation to use single-letter variables. Make every identifier (names of variables, functions, classes, etc) very explicit about what it is for. If you do this, you only need comments for the most complicated bits of code.

I really don't think any managed language (like C# or Java) is a good foundation for C++. C++ is such a huge shift in memory management and pointers. You really take it for granted in managed languages. Learning C++ forces you to understand how and why managed languages work like they do.
For instance in C# why is this bad?
string a = "haha!!";
for(int i = 0; i != 5000; i++)
{
string a = a + "!!";
}
In C++ you'd have to create and delete the memory of "string a" every time so you understand why this is costly. However it's not as prominent in C# or Java because the garbage collector deletes and creates the memory for you.

This is where I revisit many discussions (i.e. arguments) about why Java is not a crazy
choice for games programming. Possibly this chapter isn't necessary since you're
already convinced of Java's qualities. But maybe you're not quite sure.


1. First the Advantages, but briefly...
One of my assumptions is that the reader (that's you) already has an introductory
knowledge of Java, the sort of stuff gleaned from a semester's course at college. Near
the start of that course, you'll have been regaled with Java's many advantages: object
orientation, cross-platform support, code reuse, ease of development, tool availability,
reliability and stability, good documentation, support from Sun Microsystems, low
development costs, the ability to use legacy code (e.g. C, C++), and increased
programmer productivity.
Rather than explain each of them again, I'll take a different approach. I'll discuss
Java's suitability for games programming in terms of the typical
misconceptions/complaints wheeled out by people who think that games must be
implemented in C, or C++, or assembler, or whatever (so long as its not Java).
Here's the list, briefly:
• Java is too slow for games programming;
• Java has memory leaks;
• Java is too high-level;
• Java isn't supported on games consoles, so why bother using it;
• No one uses Java to write real games;
• Sun Microsystems isn't interested in supporting Java gaming.


2. Java is Too Slow for Games Programming
They mean that Java is slow compared to C or C++, the dominant languages for
games programming at the moment.
This argument was valid when Java first appeared (around 1996), but has become
increasingly ridiculous with each new release. Some figures put JDK 1.0 at 20 to 40
times slower than C++. J2SE 1.4.2 (the current release) is typically 1.1-1.3 times
slower.
These numbers depend greatly on the coding style used. Java programmers must be
good programmers in order to utilise Java efficiently, but that’s true of any language.
Jack Shirazi's Java Performance Tuning site
(http://www.javaperformancetuning.com/) is a good source for performance tips, and
links to tools and other resources.
A recent benchmarking of Java vs C++ by Keith Lea caused quite a stir
(http://www.theserverside.com/news/thread.tss?thread_id=26634). He found that Java
may sometimes be faster than C++. The response from the C++ crowd was typically
vitriolic.
The speed-up in Java is mostly due to improvements in compiler design. The Hotspot
technology introduced in J2SE 1.3 enables the run-time system to identify crucial
areas of code that are utilised many times, and these are aggressively compiled.
Hotspot technology is relatively new, and it’s quite likely that future versions of Java
will find further speed-ups. For example, the forthcoming J2SE 1.5 is meant to be 1.2
to 1.5 times faster than its predecessor.
Hotspot technology has the unfortunate side-effect that program execution is often
slow at the beginning until the code has been analyzed and compiled.

2.1. Swing is Slow
Swing often comes under attack for being slow. Swing GUI components are created
and controlled from Java, with little OS support: this increases their portability and
makes them more controllable from within a Java program. Speed is supposedly
compromised because Java imposes an extra layer of processing above the OS. This is
one reason why some games applications still utilise the original Abstract Windowing
Toolkit (AWT) – it's mostly just simple wrapper methods around OS calls.
Even if Swing is slow (and I'm not convinced), most games don't require complex
GUIs: full-screen game play with mouse and keyboard controls are the norm, so GUI
speed is less of a factor.

2.2. My Program is Slow Because of Java
A crucial point about speed is knowing what to blame when a program runs slowly.
Typically, a large part of the graphics rendering of a game is handled by hardware or
software outside of Java. For example, Java 3D passes its rendering tasks down to
OpenGL or Direct3X, which may emulate hardware capabilities such as bump
mapping. Often the performance bottleneck in network games is the network.


3. Java has Memory Leaks
When C/C++ programmers refer to memory leaks in Java, it may mean that they don't
understand how Java works. Java doesn't offer pointer arithmetic, and typical C-style
memory leaks such as out-of-bounds array accesses are caught by the Java compiler.
However, they may mean that objects which are no longer needed by the program are
not being garbage collected. This becomes an issue if the program keeps creating new
objects, requiring more memory, and eventually crashes when the maximum
allocation is exceeded.
This kind of problem is a consequence of bad programming style, since the garbage
collector can only do its job when an object is completely dereferenced (i.e. the
program no longer refers to it).
A good profiling tool, such as JProfiler (http://www.ejtechnologies.
com/products/jprofiler/overview.html), can be a great help in identifying
code using excessive amounts of memory. JProfiler is a commercial product; many
open source profilers are listed at http://java-source.net/.
Another memory related complaint is that the garbage collector is executing at poorly
timed intervals, causing the application to halt for seconds while the collector sweeps
and cleans.
The JVM comes with several different garbage collectors, which collect in various
ways, and can be selected and fine-tuned from the command line. Information on the
performance of the chosen collector can be gathered and analysed. A good hands-on
explanation of this topic, centered around the JTune visualization tool, can be found at
http://www-106.ibm.com/developerworks/java/library/j-perf06304/.

4. Java is Too High-level
This complaint is the age old one of abstraction versus speed and control. The details
of the argument often include the following statements:

1. Java’s use of classes, objects and, inheritance add too much overhead without
enough coding benefit;
2. Java’s machine independence means that low-level, fast operations, such as direct
Video RAM I/O, are impossible.

Statement (1) ignores the obvious benefits of reusing and extending Java’s very large
class library, which includes high-speed I/O, advanced 2D and 3D graphics, and an
enormous range of networking techniques, from lowly sockets to distributed agents.
Also forgotten are the advantages of object oriented design, typified by UML, which
makes complex, large real-world systems more manageable during development,
implementation, and maintenance.
Statement (2) impacts gaming when we consider high-speed graphics, but it's been
addressed in recent versions of Java. J2SE 1.4 introduced a full-screen exclusive
mode (FSEM), which suspends the normal windowing environment, and allows an
application to more directly access the underlying graphics hardware. It permits
techniques such as page flipping, and provides control over the screen's resolution and
image depth. The principal aim of FSEM is to speed up graphics-intensive
applications, such as games.
Statement (2) also comes into play for game perpherals, such as joysticks and
gamepads; machine independence seems to suggest that 'non-standard' I/O devices
won't be useable. Java games requiring these types of devices can utilize JNI, the Java
Native Interface, to link to C or C++ and so to the hardware. There's also JInput, a
new game controller API, due to be finalised early in 2005.
An interesting historical observation is that the gaming community use to think that C
and C++ were too high-level for fast, efficient games programming, when compared
to assembly language. Opinions started to change only after the obvious success of
games written in C, such as Doom and Dungeon Master, in the mid 1980s. Also
important was the appearance of cross-platform development tools that supported C,
such as Renderware.


5. Java isn't Supported on Games Consoles so Why Bother?
Unfortunately, this criticism has some justification.
Video gaming is a multi-billion dollar industry, with estimates placing revenues at
$US 29 billion by 2007. The market will cater to over 235 million gamers.
PCs and game consoles account for almost all the income, but only about 10-20% of it
is from PCs, the majority coming from three consoles: Sony’s PlayStation 2 (PS2),
Microsoft’s Xbox, and Nintendo’s GameCube. Sony is the dominant console maker,
having nearly twice as many units in homes compared to Microsoft and Nintendo
combined. Microsoft accounts for about 95% of the desktop PC market.
Arguably, there are only two important games platforms: the PS2 and Windows, and
Java isn't available on the PlayStation.
This problem has long been recognized by Sun: back at the JavaOne conference in
2001, Sony and Sun announced their intention to port the JVM to the PS2. Nothing
has been released, but there are persistent rumours about a JVM on the PlayStation 3,
earmarked to appear in 2006.

In the future, Java may have a better chance of acceptance into the closed-world of
console makers because of two trends: consoles are mutating into home media
devices, and the meteroic rise of online gaming. Both require consoles to offer
complex networking and server support, strong areas for Java and Sun.
The Phantom console from Infinium Labs was announced at JavaOne in 2004
(http://www.phantom.net/index.php). It's essentially a PC running an embedded
Windows XP, with a nVidia graphics card, a hard drive, and a broadband connection.
Most importantly for Java gaming, it will come with a complete JRE. It was also
demoed during E3 (Electronic Entertainment Exposition) in 2004, where it was shown
running Law and Order: Dead on the Money (which uses Java 3D).
Diehard programmers may point out that it's already possible to get Java running on a
PS2. One approach is to install Kaffe, an open source, non-Sun JVM, on top of
PlayStation Linux. Kaffe can be obtained from http://www.kaffe.org/; details on
Linux for the PlayStation are at http://playstation2-linux.com/. The gallant
programmer will also need a Java-to-bytecode translator, such as Jikes (http://www-
124.ibm.com/developerworks/oss/jikes/).

The Linux kit adds a hard disk to the PS2, so this development strategy will not work
for ordinary PlayStations. Configuring the software looks to be far beyond the
capabilities (or desires) of ordinary console owners, and I couldn't find any
documentation about using Jikes/Kaffe on a PS2. The PlayStation only comes with
32Mb of RAM, while a typical JVM and its libraries requires 5-10Mb, so how much
would be left for a game once Linux was up and running?
The difficulties with this approach should be compared to the availability of feature
rich C/C++ tools and engines for consoles, such as RenderWare
(http://www.renderware.com/) and Gamebryo (http://www.ndl.com/). They have a
track record of best-selling games, and can port games across the PS2, Xbox,
GameCube, and PCs.

The lack of Java on consoles is a serious issue, but the remaining PC market is far
from miniscule. Microsoft estimates that there are 600 million Windows PCs at
present, growing to more than 1 billion by 2010. Games on PCs benefit from superior
hardware, such as video cards, RAM, and internet connection, to offer more exciting
game play. There are many more PC games, particularly in the area of multiplayer
online games. It is throught that the 40% of all gamers will start playing online by
2005. Revenues may reach US$ 1.1.billion by 2008.
Another rapidly expanding market is the one for mobile games, with sales of US$ 530
million in 2003, potentially rising to US$ 1.93 billion in 2006. There are perhaps 200
million Java-enabled phones at the moment.

I'm still a little confused on where to start? Should I just read up on everything I could? Should I read then test something out? Should I just open someones program and learn from that? Put me in your shoes. How did you learn? Was it effective? Would you have changed something if you could of? <--Directed towards vivid programmers.

I actually learned JavaScript as my first computer language.

I understand your argument in terms of lower-level management, but especially for anyone learning to program, it is much more important to teach the fundamentals of good coding than trying to learn the gritty side of managing memory and garbage collection.

Unless I'm mistaken, your little code segment should result in a compile-time syntax error...