The Chosen

The whole reason I had to design and implement a new mouse engine was because the addition of units before was seriously conflicting with the old mouse engine. With this new mouse engine working perfectly in the RTS I was then free to change my focus back to the units. Before this big haste, I had units, and they were clickable, and even movable. Of course all of this fancy movement was a direct location change and not a fancy, slow, speed based movement, and all of the selection and move orders only worked at the origin view location. Basically, interacting with units didn’t work after scrolling and the movement was actually more like a teleport. However, all of that has been changed now. (more…)

While the new mouse engine did fix countless obvious bugs and prevent lots of future headaches, that’s not to say that it didn’t come with a few bugs of its own. To start, because the new system was repositioning the now invisible mouse cursor to the center of the screen, it had some issues that arose whenever I would try to move the window from its default loading location. I also have to convert all of the old mouse action code to flow through the new mouse system. In addition, because the new mouse engine locks the cursor inside the window, i added a procedure to unlock the cursor when pause to allow the user to exit the exit or perform other tasks when necessary.I also fixed a bug that popped up that was throwing the scroll engine into overdrive ever since I started painting the cursors with the graphics engine. After finishing all of that, and finalizing the new mouse engine I made one final change and fixed some of the liking for use hovering and mouse cursor sensors to show off some of the new cursors. At this point the new mouse engine and taken the full load and has completely replaced the stock old one, which leaves me with no other choice but to move on to bigger and better, and cooler tasks.

After returning to the RTS again, I decided that I would no longer live in fear of the major unit issues that I had run into before. When I last worked on the RTS I discovered that because I was using Java’s swing classes just for their mouse listeners, the class was running much more code then was necessary for my needs. For example, every time I would change the cursor, every swing child would automatically repaint, which was totally unnecessary because I am maintaining my own graphics engine. To correct this, and numerous other problems that were a result of using the swing classes, I changed the type of my base game object to no longer extend swing’s JComponent. I also went ahead and stripped out the old mouse engine which let windows control the mouse, and replaced it with my own. My new custom mouse engine allows me to much more control over what the mouse can, and cannot do. By handing all mouse movement from within the Java code, I can easily, and smoothly, lock the mouse inside the window making scrolling and other complex interactions much simpler.

With the new mouse engine I have added modifiers for numerous things that I could not have controlled before such as mouse sensitivity and also allows me to handle all mouse actions a new all in one procedure. Because the new mouse engine is running from within the Java I can directly what happens when the mouse is pressed and no longer have to worry about mouse listeners or which object is on focusable or anything else. With this great progress I hope do some more work with the units soon.