Taking The Plunge

Sometimes during development you find obstacles or challenges you don't know how to tackle. Features you've never coded before or situations due to already written code that just make sense. You can count on a little bit of pressure here. You need to get the implementation done by Friday but you know it wouldn't take you that long if you only had done it before. Or there is a certain mysterious piece of code that somehow eludes you. Maybe the situation is one where you can't figure out exactly why a function isn't working the way you had expected or you had thought it did things that it does not do or handle situations that it wasn't written to handle. In these types of situations your best option is to just simply plunge right into trying things and looking at their result.

Many times API or programmers on your project simply overlook certain situations. There is always a reason why they didn't handle situation x or y. Usually it comes down to purpose they didn't intend the code to be reusable for a different purpose. This is can also be the reason for performance problems where the code was written using reusable principles and designed to be generic but it was never optimized for the situations that it allows. You end up either rewriting it altogether as a separate piece of code that looks a little similar or you deal with the ramifications of reusing it. This usually happens more often than not when the code is part of your project rather than 3rd party code. Though a lot of times its directly related to the misuse of 3rd party of external APIs where the programmer using those APIs didn't understand how to use the API the way it was intended.

Again just plunge right in attempt to use the code you have and look at the results. Almost all the time the code could use refactoring if it is to properly handle what you want but you must know that if  you decide to use it and not refactor it but instead use work-a-rounds to get it to do what you want rather than changing it you will inevitably be building performance or maintenance problems in the future. Reuse can be a crutch, more on that later, the main piece of advice I can say for productivity is to just start changing it find that better way swap out the current implementation for something that handles the existing situations as well as your new one.

Many times in programming you can feel trapped and get yourself into a loop of inactivity while you stew over how to hack around structural issues presented by poor design from the past. More often than not it is a lack of redesign activities which are causing your frustrations. Depending on which path you choose you could end up feeding the beast and mangling the code breaking consistency. It's usually readily apparent in any codebase to recognize learning code from real functional code. You can notice subtle programming mistakes brought on by unconstrained use of misinterpreted patterns. If you know what I am talking about and have witnessed coding atrocities feel free to recount your painful experiences here as each new situations presents the opportunity to learn ways to mitigate the overlooked risk of poor design.

Integration

Level and animation creator editor
application started back in 2009

I have a game engine project that I have been working on since 2009 it's gone through quite a few transformations and iterations. Multiple design changes and I hope it will actually become fully functional sometimes soon but I haven't had much chance to move it forward. This integration effort might help that.

So I was looking back at my old editor code that was written for the engine to do animations and level creation. I found some old bugs that I had never fixed and set about debugging and fixing them which took an hour or two. I also was working on some art in my newer "Pixel Painter" program which I created for drawing pixelated graphics. I've used that drawing program a lot since I started creating that last year. It's very useful and makes drawing images pretty quick but there are a lot of features it lacks including basic undo/redo functionality. Still need to work on that.

So I was testing some graphics out in the editor cause I wanted to see how they looked tiled and together and was desperately wanting the ability to simply edit the tiles I was testing with my drawing program and see the changes appear in the editor. Because of the way I had designed the drawing program I knew I could integrate the two very easily. In fact it was even easier and worked better than I had hoped minus a small piece of optimization code that got in the way.

I set about quickly adding a menu item to a right-click popup for "edit"ing the tile image. Created a new ImageController passing it the tile image after doing some extracting from the resource loader it was in, create my new drawing program class and called the createAndDisplay method giving it it's onClose instructions of JFrame.DISPOSE_ON_CLOSE so that it doesn't exit the entire program when I close the drawing window and viola I had the ability to get my tiles from my map program into my drawing program. Awesomeness!!!!

But when I went to try this out to see if the image would update in the editor with the changes made from the drawing program bang exception. Apparently my editor images were not exactly BufferedImages which is what my drawing program needed to be passed they were indeed SunVolatileImages I was like what the freaking hell. After about an hour of digging around the code tracing through things I came to the source of the problem inside my ImageResource wrapper class. Indeed I had done a little image optimization at some point and had this line in my resource class

image = AssetManager.accelImage(img);

Drawing application "Pixel Painter"
started some time in (2011)

That method turns the BufferedImage into a Volatile image if it's image capabilities say that it's not hardware accelerated. I had run into a problem with another game project that slowed framerates to a crawl because the images weren't accelerated and pretty much had rigged the resource to transform itself to be accelerated if it wasn't already. After making a toggle method where I could specify I didn't want them accelerated and skipping over the acceleration line I reloaded the editor popped some tiles in using drag n drop from my images stash and viola editable tiles in my drawing program that will update in the editor when changed and I could save them as separate files in either program.

There are a bunch of other integration's I want to do now for instance creating new tiles using the drawing program from the editor, editing animations and sprites. Creating tilesets from the editor and editing the tiles with the drawing program which if the above is any indication shouldn't be hard at all. And of course upgrading the editor, I don't have layer support or object placement support. So there is a lot to do there but it's definitely fun and worthwhile to do hopefully it will be able to support games in the future but for right now it's just a little testing tool.