Maze Design

I am struggling on how to internally represent my roguelike maze. Currently I maintain a 2D array as well as an array of StringBuffers. The array is used for easy lookup of objects in the maze. The StringBuffer is used to quickly generate a string to draw on the screen. The problem is that I need to update both structure every time something moves in the maze.

I could just keep the 2D array. Then I could generate the Strings on the fly as I need to display. However I do a lot of display updates (whenever the player moves). That might take a lot of time to generate an 80x25 worth of character Strings.

Or I could just keep everything in the String array. Then I could index into it when I need to check different cells of the maze. That just does not feel as natural as the separate 2D array though.

Breakout Performance

I coded up an epic game of Breakout. Most of my effort was spent on my intro screen. I also spent a good deal of time on special effects for the high score screen. The thing rocks on my development machine. But I ran the same game on a laptop with limited hardware, and the results were disappointing.

The intro screen draws a lot of random lines to produce a static effect. It also draws text in increasing font sizes that get really big. This screen works but is painfully slow on the laptop with limited hardware.

Luckily the main game mechanics adjust themselves according to the amount of time it takes to render the game screen. So it plays well whether there is high power hardware, or limited resources. I should have done that with the intro screen as well.

JDBC to the Rescue

I just read a chapter on the JDBC. This allows me to access databases from my Java code. Now I have the power to write CRUD apps. Yeah. So far I have written some code that uses Statements to do basic querying. I have also delved into PreparedStatements to insert and update.

To test out and play with this capability, I downloaded and installed the latest MySQL database. It is taking a while to get used to MySQL database administration. I also got MySQL Connector/J so that my JDBC can talk to the MySQL database. So far it works like a charm.

I have studied and modified a little bit of code that uses an AbstractTableModel and JTable. This seems to be quite the powerful combinatoin. It is also something that will take a while to learn. Now the world of databases it at my fingertips. Perhaps I shall try to connect to an Oracle database with JDBC as well.

Towers of Hanoi

In my Java class this semester, we went over the Towers of Hanoi problem during our study of recusion. The recusrive solution is elegant. It is also simpler than any iterative solution. We did not code a solution. We just studied one intently to understand the recursive nature of it.

Recently I saw one of the sample problems you need to solve during a Facebook interview. One of them is the Towers of Hanoi problem. Nice. Facebook even let's you code the thing in Java. It has to work correctly. And you need to complete the thing in 45 minutes.

Not sure if I can meet that metric. But at least I have seen the problem and solution before. I guess I could google the code. That would be cheating. I feel good about what my Java college class is teaching me.

Multithreading

I am just starting to learn multithreading. My second exercise was to put 20 balls on the screen. Each one is moved using a different thread. On the surface I was surprised what little computer resources the 20 threads used. My machine is dedicating 3 percent of its CPU to the bouncing balls app.

I have some nice and smooth animation too. Every frame update causes the whole screen to be repainted. Right now I am using the basic Thread class to start up and Runnable. My main thread, which I assume is the event dispatch thread, updates the GUI on a timer (which happens to have its own thread).

Next I should try a whole lot more threads. Or I could make the graphics more intense. I need to figure out where the performance bottleneck is, if any.

Eating the Keys

I am learning about the finer points of GUI development with Java this week. It turns out there are some GUI basics in Java that I don't know about. So I am studying them first. One topic of interest is catching events. To practive, I started coding up an event viewer. It is supposed to get and print out events that fire based on a bunch of different GUI components.

For the most part I can knock out the even viewer code. I am setting up listeners that log events to the screen. Then I try to do a KeyListener. But my event handlers are not getting called. What the heck? Initially my text area control was displaying the keys. Okay. I disabled it. Still no keyboard events.

I am a good debugger. I traced the issue down to the presence of a JButton on my GUI. If I remove the JButton, the keyboard events fire and I get the calls. What could be going on here? Is the JButton receiving and eating up the keyboard events? It looks like I am going to have to consult an expert here.

The Need for Wildcards

We are covering generics in my advanced Java community college class. The weak book has a tough time explaining concepts clearly. I get the main idea behind generics. Java gets to keep up with C++ templates. But then we get to something which does not seem right.

Since the Integer class extends Number, you can pass in an Integer object when a function requires a Number parameter. That is clear. But when you use those types with a generic class such as Stack, things get weird. You cannot pass in an object of type Stack when a function requires a Stack parameter. What the heck?

Integer extends Number. The Stack is a Stack. Why can't Stack act as a Stack. Makes no sense on the outside. The book cooked up some example to try to explain it away. I was still not convinced. Later I read about the use of wildcards to solve this problem. You get a Stack argument type that can then receive a Stack. But why do we need this new syntax in the first place. The textbook could not explain it. Time to dig deeper.