This shot shows the now Fully Operational Batt… er Texture mixer.  In this shot you can see how I’ve replaced the smooth stone half-block with the bookshelf textures.

I now have it loading all it’s data from files, opening texture packs that you specify on the command line, and saving the resulting mixed terrain.png in a .zip for use in the game. 

Stuff left to do before I release the very first Alpha version:

• Finish the sample.mdl file.  Currently I only have Grass, Dirt, Stone, Wood and StoneStep (Smooth halfblocks) defined
• Finish the texture_index.txt (This describes what model to use for the preview when a tile is selected on the left hand picker.)

The Alpha will only work on two packs at a time and will require specifying both source packs and the name of the pack you want to save to on the command line.  I’ll include more info about it when I release it.  

After a little bit of bug fixing, I got the preview display to play nice with my 2D GUI stuff.  (Depth buffer testing + drawing on a 2D plane = Why is only my first GUI element drawing?)

This is also probably not that far off what the initial alpha build is going to look like.  I’m picturing a scrolling ‘list’ of blocks across the top for previewing (just click on one to center it.) and then two textures open down below similar to how the web version works.  I have other ideas for what the final interface is going to be, but this setup will suffice while I get the core functionality worked out.

I have the model loader working now.  Those three blocks are being loaded off the sample file I linked in my last post.  I think the next step now is to finish defining just how I want the user interface to look and what data structures I’m going to need to support tracking the Texture pack specific data.

Spent some time working on the model file concept and I have an initial rough draft for what it might look like. 

http://thefool76.com/yummy/sample_mdl.txt

I’m going with the ‘tag’ based format because that would more easily convert over into a binary format later on.  That and not using XML means not having to add an XML parser which I think would be using a sledgehammer to kill a fly.  The rest of my logic and reasoning should be contained in my comments in the file.

If anyone has any suggestions or comments, let me know. I always appreciate constructive criticism.  :) 

After doing the preview and getting the small spinning block, I did some thinking about exactly how I wanted to define the blocks and other elements.  If the game consisted of just blocks it would be easy.  Just have a single block class and then put whatever textures on that I need.  However the game has more than a few non-block elements so I need a way of drawing those as well.

Additionally, I have the goal of re-using as much of this as possible. With that in mind I decided I needed a general purpose model definition file, preferably in plain text (at least to start with).  Unlike Notch, I like being able to easily add stuff without having to re-compile.  So when new stuff is added, all I would need to do to support it is edit a few text files.  (As opposed to recompiling the entire program.)  A side benefit to this is that it would also be easy to add support for any mods.

If I can get it to work like what is in my head, this model engine may turn out to be the single most useful thing I get out of this Texmix project, even more so than the GUI stuff.  Now to see if I can’t come up with a good design for the file…

Just a little teaser showing one of the features that’s going to be part of the Texmix tool.  A block previewer so you can see what the textures will look like in the game.  The funny colors and arrows are there so I could be sure to get the same orientation on the textures as you see in the game.  (Fun fact: The bottom texture on most blocks is actually mirrored.)

One of the first things I had to do was add support for loading images from a zip file. This picture shows my successful first test of that.

I have this month set aside for working on Minecraft related things.  (texture packs, my story, etc.) However, I still want to continue working on my GUI stuff as I think I’m making real progress with that.  So I have decided to combine the two.

I’m going to do a stand-alone version of my texture mixer using the GUI elements I’ve written.  This should give me a nice test of my design as well as give me an excuse to continue to add more widgets as I need them.

It should also keep the GUI development more interesting as I won’t just be going down a list of widgets.  Having a real program to test them in is a lot more fun than just a screen full of widgets with some hacked in testing commands.

A shot showing the new button widget in it’s three states.  The widget is the gray rectangle at the bottom if it isn’t obvious. ;)

Progress was made on the GUI elements this month. I still have a few lingering bugs in the last class I added so I will probably work on trying to get that fixed off and on till I have it sorted to my liking.

Here are the things I got done:

• Base Gui Class - base class for all my GUI elements
• Event Handler - base class for any object that needs to handle events from the gui.
• Font - A simple tool for drawing text to the screen. Currently it uses a bitmap font image in a 16x16 grid
• Texture - A simple wrapper for images/textures.  Supports re-loading the image into graphics memory if needed.
• Panel - A very simple object with a background color, background image, and optional solid fill border
• FancyPanel - Constructs its border by chopping apart a base image.  Allows for more interesting borders.
•  VLayout & HLayout - Positioning objects that will resize their contents dynamically. 
• TextPanel - A container for text. It does word wrap and will scroll if too much is added but it does not have a history.  It is simply meant as a way of displaying text, not storing it.
• Button - The first interactive element.  It is supposed to support changing it’s graphic when the mouse moves over it and when a button is clicked while the mouse is over it.  Still working out the bugs though. 

Here is what I still have on my list of things I want for my GUI elements:

• Draggables - Elements that can be dragged around the screen by the mouse. Comes in two flavors, sticky and non-stick.  Sticky ones would ‘stick’ to the mouse cursor after a click and would require a second click to release them. Non-stick would require you to hold the button down.
• Resizable Pannel - Basically a panel with a Draggable edge/corners.  What edges/corners are allowable for grabbing for a drag would be configurable.  
• Window - A complex composite element with a title bar, some standard window buttons for closing/resizing and a draggable frame
• ScrollBar - A composite element comes in two flavors, vertical and horizontal.
• ScrollPanel - A panel with built in scroll bars that can be toggled on or off for scrolling oversized content.