It’s hard to match the feeling of solving a difficult programming problem, especially after it’s been an obsession for far longer than would seem appropriate. Having learned a big portion of what I know about programming through trial and error, I’m certainly used to this type of issue popping up – you know, the kind where it seems so obvious that there theoretically exists a solution, but what that solution is is so completely beyond you.
Like last weekend when I learned how to load fonts into a Java app (a game I’m working on involving dinosaurs in space). It’s a sweet 8-bit videogame type font that I found on a free fonts site, very cool looking. After finding some example code from the Sun (now Oracle?) demo pages and adapting it to my needs, my program was completely laggy and using about 20% of the CPU time. I tried moving the method that loaded the font, I tried saving the font in a Font variable, but kept hitting a wall when I tried to show paintComponent() the font data.
As I’ve learned time and time again through hours of smashing my head against things, procrastinating, and eating too much chocolate, the surefire way to solve one of these issues is to start thinking like a computer. (I guess I don’t do this enough as it is, maybe I should have played with Legos more when I was little). But upon going line-by-line through the changes I’d made to the program since the CPU-destroying slowdown had begun, I discovered another previously unknown quirk of paintComponent() and the Timer class. As it turns out, my getFont() method was in the body of my main GamePanel class, outside the constructor and right next to paintComponent() (the GamePanel constructor contains the main Timer I use for animation, which uses repaint()). As a result, my getFont() was being called once per frame (!!!) which was causing the font data to be re-grabbed from the disk forty times every second. So apparently the Timer does that to methods that are on the same hierarchical level as paintComponent(). Who knew? Not me. But I moved getFont() to a completely separate .java file and that solved the problem immediately. And it took about 45 minutes to figure that out. Needless to say, that was the last problem I attacked that night.
That’s a pretty typical coding session for me. To summarize:
- Find the simple solutions to a bunch of problems that seemed impossible last session
- Gain confidence and decide to tackle a big new area of the app
- Quickly run into new, seemingly unsolvable problem
- Try at least five different approaches to solving the problem
- After about 90 minutes of this, close computer and play Super Mario World
- Repeat
Check out these pictures from the set of The Empire Strikes Back. Very cool.
One Response to “How to learn Java in 9000 easy steps”
Pings responses to this post
[...] why it was that I took that big two month break in the middle of my work. I feel like my brain is going to fall out of my ear – that’s how concentratedly I’ve been thinking in attempts to fix the [...]