Blog for Robert Blanchet Jr. at GarageGames.com

Rack 'em Up Road Trip

Robert Blanchet Jr. — 2006-10-02T19:40:12+00:00

Today I am going to let everyone in on a little secret, one that involves a small dedicated team here at GarageGames working on a project that has been kept under wraps for a little while now. Rack 'em Up Road Trip is a Torque Game Builder based game that I have been working on as the lead programmer with the direction and insight of Joe Maruschak as project manager, Justin DuJardin, Mark McCoy, and Zachary Zadell comprised the core team.

Rack 'em Up Road Trip is a product GarageGames has been collaborating with Oberon Games for their casual games space, and as you can probably guess from the name, it is a pool game. Rack 'em Up Road Trip was built on a pre-1.0 build of the then Torque 2D engine, now Torque Game Builder and marks the first time GarageGames had to "eat their own dog food" on the TGB suite of technologies. After the first month of development one of the more important decisions we had made was to bring Justin on the project to help him eventually carry over some of the experiences he would be having developing the game into the work he was doing on Torque Game Builder.

I know what some of you may be thinking, "Why is GarageGames making games when they should be fixing their tech so I can make my game?". The short answer is that our tech isn't broken, at least not to the point of being unable to make games with it. The long answer is that in order to find what is wrong with our technology we must be allowed to experience it ourself, in the same manner that any other community member would use it, and that is to make games with it. By doing so not only do we find areas our tools and technology need to improve upon, but we also find the strengths of our technology, which is just as important.

Designing and building games is an extremely iterative process. At the end of it all that 100 page document on the look and feel of a game will more than likely not resemble the final product. This iterative process is most evident in the art but involves all aspects of the game from the flow of the user interface to the difficulty of AI players and feel of the physics. For anyone who has finished a game this process is understood and accepted. I emphasize finished because it is easy to say you've made a game, but it is something entirely different to make a game that hundreds or even thousands of people will play, and hopefully enjoy. Even the most seemingly trivial of things can make a huge difference to the overall enjoyment a person gets from the game. Literally no stone is left unturned.

It's also important during this process to be able to recognize when something is just good enough. Some feature or art can be changed and tweaked, and maybe each time it gets better. But the cost of implementing or changing those features gets higher as the project carries on. There is an excellent plan that touches on this, The Complexity Barrier by Dan MacDonald.

I think an excellent example of this iterative process from Rack 'em Up Road Trip is the entire GUI system that we eventually settled on. It seems funny to mention the GUI's as an example of this, after all it is just a GUI and there are many other examples: ai, quest, physics, just to name a few. But with the GUI system it is immediately obvious, looking back over the various incarnations, what it is I'm talking about. What we eventually ended up with really seems like a little mini-game, the way the GUI's transition from screen to screen, etc. It is very enjoyable.

For Rack 'em Up Road Trip our GUI went largely ignored for the first few months of development. During this time our main focus was on the pool table. How big was the table, how big are the balls and what does the physics feel like. Finally, and probably most importantly, how does the player interact with the table - what is the control scheme like. However, we still needed a way to get in and out of games, so during this duration the GUI was slapped together as quickly as possible with whatever the artists could conjure up. Doing this also lets us explore what the GUI flow will be like, what buttons should take the user where and why or why not provide them. All very important things to consider when designing the game because the first thing a user sees when they launch your game executable is your GUI, so it is important that initial reaction is a good one.

Initially we used the GUI controls that are provided by default from the engine, replacing skins and art where necessary to help convey the theme that we had finally decided upon, a road trip theme. Over the course of several months however, focus was gradually shifted over to utilize the TGB objects instead: static sprites, animated sprites, etc. This facilitated a need to be able to know when the mouse pointer has entered or left a particular 2d scene object which Melv May was able to put together for us as well as some other extra goodies like the ability to mount UI objects to TGB objects. All of these features have since made it into the core TGB tech.

The GUI design was constantly changing to meet particular needs, usability standards, and the bling factor. When a part of a game is in a rapid stage of development like this, it is important to communicate. I think the best form of communication is visual. Words on a page can be skimmed over and easily ignored or forgotten. A picture, diagram, or mockup more easily expresses ideas and encourages the imagination. Mark McCoy's UI mockups did more to advance the design of this game than a thousand pages of words. And the added bonus was the time and art that was involved in those mockups could then be reused, recycled, and put into the actual game. Even the time and effort that went into scripting the GUI was positively effected by having mockups laying around to look at.

Having just interned my second time at GarageGames from college I had very little experience with making and producing games. Some may know me well enough to know that a lot of my experience with Torque came from working on a Tribes inspired community project called Legends. Before then, all of my Torque Script experience came from having played Tribes and Tribes 2 for years.

One of the things I've found when working on Torque is that it is such a huge code base that when I learned an area of the engine really well, I began to forget things about other areas of the engine. For instance, working on the GUI systems for a couple weeks I started to become really familiar with the little quirks and details of it but then forgot little details about some other area. This isn't to say no one can become an expert with Torque, because I don't think being an expert includes knowing every single detail about Torque.

Torque is like a city. Like any city a person must get lost a few times before they can become familiar with the place. Road signs help us along the way and one can get a tour guide but in the end it is really just up to ourself to commit to finding our own way around. That tour guide is our Torque expert. They know their general way around, and they may know where some of the more significant shops and places are located, but they too have to look things up once in awhile.

I'm a product of this community. Everything I didn't know about Torque I learned with help from this community and my willingness to get my hands dirty and find the answers myself. When I was hired by GarageGames no one sprinkled magic fairy dust on my head. Correction, Ben Garney tried to sprinkle fake magic fairy dust on my head and Jay Moore mentioned something about Kool Aid. But I didn't walk into the GarageGames office door and suddenly become some kind of Torque demi-god. In fact I came across a couple of issues when working on Rack 'em Up Road Trip that I turned to the community for help, mostly by searching through our forums.

Rack 'em Up Road Trip was completed because the team working on it was dedicated to seeing it through. Granted, we may know Torque like the back of our hand, but knowledge only gets a project so far. It takes hard work and passion to cross the finish line. I know these are things the people in our community possess. There are some things we had to create for this game that will not make it back into Torque Game Builder. A very good example of this is the 3D-like ball physics. But let me make something absolutely clear, our ball physics for the game are just an extension of what is already available in TGB. We didn't have to rewrite the core TGB physics to get the results you see in the game, our technology is built to be extendable. The Rack 'em Up Road Trip ball physics was built on top of that framework, it did not replace it. Please don't let little things, like the exclusion of pool ball physics from the TGB core, stop you from creating your game. The tools and technology is there, and getting better, use its strengths and express yourself.

You can play Rack 'em Up Road Trip now at MSN Zone.

O Memory, Where Art Thou?

Robert Blanchet Jr. — 2006-09-22T23:31:18+00:00

I wanted to address some issues I've seen people bring up about memory, memory leaks, etc. This .plan isn't meant to discuss finding memory leaks. For that I'll point you to the Memory Manager TDN article. What I do want to talk about however, is how to tell if there is a memory leak in your program.

You may be thinking, well this seems quite obvious, open the Windows Task Manager and look at your executable's memory usage. If the memory goes up but never goes down then I'm leaking memory, right?

Wrong.

While the Windows Task Manager may give you an indication of the memory "requirements" of your application, it isn't giving you the entire story.

Quote:

From MSDN:
If you think that you are experiencing a memory leak, be aware that memory leaks may not be what they appear to be. You may discover that a memory leak is not a true memory leak, but is a performance enhancement.

The Windows OS employs something like a memory cache for each actively running program. This cache may grow as the needs of a particular program require using magical algorithms Microsoft developers have produced for determining the optimal size for that program. For instance a program over the course of it's life time may require 20 megs of memory but occasionally needs to load data requiring allocations of up to 10 additional megs which is released seconds after it is loaded and processed. The Windows OS may determine then, that the memory cache for this program must increase from the base 20 megs to 25 megs instead. Looking at the Windows Task Manager then, you may see that this program is now using 25 megs of memory, even though currently, it may only be using 20 megs.

That is, the Windows Task Manager is reporting the memory cache allotment and not the memory allocated and used by the program. This is not the same as a memory leak. The program has little to no control over the memory cache allotment the OS has given it.

You'll find that Torque uses similar methods for enhancing performance, for instance the FrameAllocator. The FrameAllocator allocates a chunk of memory, which can then be divided out in smaller chunks to those who request it. When faced with making a bunch of small allocations the FrameAllocator can save us the overhead of making those allocations by just giving us small portions of an already allocated memory chunk.

To determine whether or not a process is experiencing memory leaks, use Windows Performance Monitor (Perfmon.exe) and monitor the Private Bytes under the Process category for your application. Note, that the Performance Monitor also suffers from the same problem the Task Manager does. It is showing us the cache allotment for our program. However it does so using a nifty graph that helps us keep track of the memory over time.

There are two key things to pay attention to when using the Performance Monitor. Private bytes is the total memory that the process has allocated, but is not sharing with other processes. Note that this is different from Virtual Bytes, which is also interesting to monitor. Virtual Bytes is the current size in bytes of the virtual address space that the process uses. An application can leak virtual memory, but may not see a difference in the private bytes that are allocated. If you do not see memory increase when you monitor private bytes, but you suspect that you are still running out of memory, monitor virtual bytes to see if you are using up virtual memory.

The Performance Monitor defaults to some wacky display settings for the graph and counter. You'll want to adjust those settings so you can better read the graph. For the counters for private and virtual bytes you'll want to change the scale to a setting of 1.0 and for the graph you'll want to change the vertical scale to 100,000,000 which gives you a graphing scale of 0mb to 100mb.

To make sure that your application is leaking memory, put the suspect code in a loop with many iterations, and then monitor private and virtual bytes for any increases of memory. Watch to make sure that the number of private bytes and virtual bytes does not eventually stay the same and the number stops increasing. If there is a point at which the memory stops increasing, (for example, it does not continue to climb indefinitely) you do not see a memory leak but more likely, you see a cache that is growing to its maximum size.

Mind your SimSets

Robert Blanchet Jr. — 2006-07-22T09:43:51+00:00

It has been a long time since I have updated my plan. In fact I haven't updated it since I was hired by GarageGames over two years ago, although it only seems like yesterday. Over the course of those two years I have been witness to lots of cool shit. Some you already know about: TGB, TSE, Marble Blast Xbox, Think Tanks Xbox, various incarnations of 360 dev kits, and Marble Blast Ultra just to name a few. And some things you don't know about, but when you do find out you'll find yourself smiling, nodding your head, and whispering 'Hey, that's some cool shit!'.

Anyway, that is not why I am posting today.

With the release of TGB behind us there has been an increased amount of discussion around SimSets and I thought I would chime in on that discussion. Now, before I begin I should probably mention I'm generally fairly poor at explaining myself, especially when it comes to topics of a technical nature and especially when it is late at night. I like to blame this on my brain wiring.. I just understand things differently that doesn't necessarily translate well to text or speech. For this reason I am using lots of script snippets below!

I am going to start off by asking a simple question. What is wrong with the following script:

script:

function example1()
{
    // Create a SimSet
    %set = new SimSet();

    // Create 10 ScriptObjects and add them to the SimSet
    for(%i = 0; %i < 10; %i++)
    {
      %object = new ScriptObject("object" @ %i);
      %set.add(%object);
    }

    // Print the names of the object's in the SimSet
    for(%i = 0; %i < %set.getCount(); %i++)
    {
        %object = %set.getObject(%i);
        echo("Object in SimSet:" SPC %object.getName());
    }

    // I'm done, now cleanup
    echo("Deleting Objects...");
    for(%i = 0; %i < %set.getCount(); %i++)
        %set.getObject(%i).delete();
    %set.delete();
}

console output:

==>example1();
Object in SimSet: object0
Object in SimSet: object1
Object in SimSet: object2
Object in SimSet: object3
Object in SimSet: object4
Object in SimSet: object5
Object in SimSet: object6
Object in SimSet: object7
Object in SimSet: object8
Object in SimSet: object9
Deleting Objects...

At first glance the above function seems fairly harmless. In fact the bug is so cleverly deceptive as to be mocking. For those of you who proudly shout 'it's a memory leak!' please give yourself a pat on the back and enjoy a cookie. As for the rest of you, for shame. I'm kidding, I'm kidding. Actually, the bug is rather sneaky and I've seen many people, new and skilled alike, fall victim to it including myself (but you can pretend I didn't say that).

So, lets look a little closer at the offending lines of code:

    // I'm done, now cleanup
    for(%i = 0; %i < %set.getCount(); %i++)

What we have here is a for loop that continues until %i is equal to or greater than the number of objects in the SimSet. Now, sometimes our brains fail to make the connection (SimSets are NOT arrays) and mistakingly believe that SimSet::getCount will return the number of elements initially in the SimSet each iteration of the loop, in this example 10. This is wrong because in the body of the loop we deleted an object thereby removing the object from the SimSet, thus decreasing the element count as a result.

Bonus round!

Multiple Choice: How many ScriptObjects did the above script fail to delete properly? Was it:
a) One
b) Five
c) All but one

Let's have a look, shall we? Below is 'programmer art', enjoy!

SimSet::getCount:
v

Next element:
^

SimSet representation:
O0 O1 O2 O3 O4 O5 O6 O7 O8 O9


-----------------------------


iteration #0 (0 < 10 = true)
-----------------------------
                              v
O0 O1 O2 O3 O4 O5 O6 O7 O8 O9
^

iteration #1 (1 < 9 = true)
-----------------------------
                           v
X  O1 O2 O3 O4 O5 O6 O7 O8 O9
   ^

iteration #2 (2 < 8 = true)
-----------------------------
                        v
X  X  O2 O3 O4 O5 O6 O7 O8 O9
      ^

iteration #3 (3 < 7 = true)
-----------------------------
                     v
X  X  X  O3 O4 O5 O6 O7 O8 O9
         ^

iteration #4 (4 < 6 = true)
-----------------------------
                  v
X  X  X  X  O4 O5 O6 O7 O8 O9
            ^

iteration #5 (5 < 5 = false)
-----------------------------
               v
X  X  X  X  X  O5 O6 O7 O8 O9
               ^

Final representation:
-----------------------------
O5 O6 O7 O8 O9

As you can see from the outline above, the script function failed to delete HALF of the objects in the SimSet. Thats a lot of objects to leave lurking around. Now imagine if that function is called multiple times in your game scripts, it adds up quickly! So, let's try and fix it.

script:

function example2()
{
    // Create a SimSet
    %set = new SimSet();

    // Create 10 ScriptObjects and add them to the SimSet
    for(%i = 0; %i < 10; %i++)
    {
      %object = new ScriptObject("object" @ %i);
      %set.add(%object);
    }

    // Print the names of the object's in the SimSet
    for(%i = 0; %i < %set.getCount(); %i++)
    {
        %object = %set.getObject(%i);
        echo("Object in SimSet:" SPC %object.getName());
    }

    // I'm done, now cleanup
    echo("Deleting Objects...");
    %count = %set.getCount();
    for(%i = 0; %i < %count; %i++)
        %set.getObject(%i).delete();
    %set.delete();
}

console output:

==>example2();
Object in SimSet: object0
Object in SimSet: object1
Object in SimSet: object2
Object in SimSet: object3
Object in SimSet: object4
Object in SimSet: object5
Object in SimSet: object6
Object in SimSet: object7
Object in SimSet: object8
Object in SimSet: object9
Deleting Objects...
Set::getObject index out of range. (5)
<input> (0): Unable to find object: '-1' attempting to call function 'Delete'
Set::getObject index out of range. (6)
<input> (0): Unable to find object: '-1' attempting to call function 'Delete'
Set::getObject index out of range. (7)
<input> (0): Unable to find object: '-1' attempting to call function 'Delete'
Set::getObject index out of range. (8)
<input> (0): Unable to find object: '-1' attempting to call function 'Delete'
Set::getObject index out of range. (9)
<input> (0): Unable to find object: '-1' attempting to call function 'Delete'

Uh, oh.. whats going on here?! Well to be truthful, I lied to you earlier. A SimSet doesn't look exactly like how I represented it in the 'programmer art' above. But I did it to drive home a point:
SimSets are NOT arrays

To help us understand what is going on, lets modify the example1 script function.

script:

function example3()
{
    // Create a SimSet
    %set = new SimSet();

    // Create 10 ScriptObjects and add them to the SimSet
    for(%i = 0; %i < 10; %i++)
    {
      %object = new ScriptObject("object" @ %i);
      %set.add(%object);
    }

    // Print the the names of the object's in the SimSet
    for(%i = 0; %i < %set.getCount(); %i++)
    {
        %object = %set.getObject(%i);
        echo("Object in SimSet:" SPC %object.getName());
    }

    // I'm done, now cleanup
    echo("Deleting Objects...");
    for(%i = 0; %i < %set.getCount(); %i++)
    {
        echo("\nIteration #" @ %i);

        %set.getObject(%i).delete();
        for(%j = 0; %j < %set.getCount(); %j++)
        {
            %object = %set.getObject(%j);
            echo("   Object in SimSet:" SPC %object.getName());
        }
    }

    %set.delete();
}

console output:

==>example3();
Object in SimSet: object0
Object in SimSet: object1
Object in SimSet: object2
Object in SimSet: object3
Object in SimSet: object4
Object in SimSet: object5
Object in SimSet: object6
Object in SimSet: object7
Object in SimSet: object8
Object in SimSet: object9
Deleting Objects...

Iteration #0
   Object in SimSet: object9
   Object in SimSet: object1
   Object in SimSet: object2
   Object in SimSet: object3
   Object in SimSet: object4
   Object in SimSet: object5
   Object in SimSet: object6
   Object in SimSet: object7
   Object in SimSet: object8

Iteration #1
   Object in SimSet: object9
   Object in SimSet: object8
   Object in SimSet: object2
   Object in SimSet: object3
   Object in SimSet: object4
   Object in SimSet: object5
   Object in SimSet: object6
   Object in SimSet: object7

Iteration #2
   Object in SimSet: object9
   Object in SimSet: object8
   Object in SimSet: object7
   Object in SimSet: object3
   Object in SimSet: object4
   Object in SimSet: object5
   Object in SimSet: object6

Iteration #3
   Object in SimSet: object9
   Object in SimSet: object8
   Object in SimSet: object7
   Object in SimSet: object6
   Object in SimSet: object4
   Object in SimSet: object5

Iteration #4
   Object in SimSet: object9
   Object in SimSet: object8
   Object in SimSet: object7
   Object in SimSet: object6
   Object in SimSet: object5

SimSets do not guarantee any order. To be as effecient as possible, when an object is to be removed from a SimSet, they take the last element in the set and replace the element they are removing, and then remove the last element (this should be stated more clearly, but I fail). So what about that fix?

script:

function example4()
{
    // Create a SimSet
    %set = new SimSet();

    // Create 10 ScriptObjects and add them to the SimSet
    for(%i = 0; %i < 10; %i++)
    {
      %object = new ScriptObject("object" @ %i);
      %set.add(%object);
    }

    // Print the the names of the object's in the SimSet
    for(%i = 0; %i < %set.getCount(); %i++)
    {
        %object = %set.getObject(%i);
        echo("Object in SimSet:" SPC %object.getName());
    }

    // I'm done, now cleanup
    echo("Deleting Objects...");
    while(%set.getCount())
        %set.getObject(0).delete();
    %set.delete();
}

The fix I like is to replace the for loop, with a while loop. Sometimes, however, it is not ideal to use a while loop and in those situations I recommend you pay extra attention. Take care that, if you call other methods from your for loops, that those functions don't delete the objects in the SimSet the loop is iterating over, and if they do it needs to be accounted for in the loop. In fact, the best practice would probably be to anticipate that some code, some where, will delete an object in your SimSet and to account for it in your loop appropriatly.

Wednesday Dec 17 20:03

Robert Blanchet Jr. — 2003-12-17T20:03:30+00:00

Interning at GarageGames has been a very rewarding and awesome experience!

Firstly, I just wanted to give a big Thank You to everyone at GarageGames.

Not until you've had the opportunity to witness GarageGames firsthand will you fully appreciate everything the guys at GarageGames do for indie development and the GarageGames community. It is not apparant in day to day chats on the GG IRC or in the GG forums how hard they work everyday and they do it because they want to see you succeed.

I had just finished what was about 4 months of internship work at GarageGames. It was a very rewarding experience and I look forward to future adventures with them. As is stated in Rick's plan most of my work at GarageGames involved getting the Torque Documentation converted into a DockBook XML format.

If you are at all interested in helping out the Torque Documentation efforts please contact Alex or Rick and they'll get you the information you need.

Also, I'm posting this to let the guys at GarageGames know that I made it home okay. Hey guys! /me waves :)

Tuesday Oct 28 21:44

Robert Blanchet Jr. — 2003-10-28T21:44:50+00:00

Legends update and other stuff.

I don't do .plan files too well, which is why I hardly have any :) I've been extremly busy and I'm loving every minute of it.

I started interning with GarageGames back in September. I arrived here with certain expectations, some hopes, and some worries. I can certainly say that I'm having a blast working here and I would gladly continue to do it, even for free if I could find some other means of getting money. I came here hoping to reaffirm why I wanted to be a programmer and I believe I'll be leaving with the desire and thurst to accomplish that goal. On to other things.

IGC was a blast for me. I got to meet a lot of really cool people. I also got to show off Legends, which has made this entire trip worthwhile in its own right. I can't even begin to describe how it feels to see people playing and enjoying a game you've helped create. Throughout the course of developing Legends there have been many times where it would have been easy to give up. What makes this especially difficult is we create this game for free. The small group of people that help make Legends what it is all do this for free, because they love to create games, and so there is no reward for us. We aren't paid in checks or royalties, or any other form. But being able to see people, in person, play the game at IGC has been a very rewarding experience for me and I just wish the other members of the Legends team could have been there to see it as well. I'm very proud of all the members of the Legends team and I look forward to see what we can do next.

As far as work with GarageGames is concerned, look for some updated guides and some new tutorials coming soon. Also, if you find any bugs in Torque, feel free to post something in the bug tracker or drop me a line.

Oh and play Legends =) We try and host weekly games so people can play with the developers.

Sunday Jun 16 0:15

Robert Blanchet Jr. — 2002-06-16T00:15:47+00:00

Havn't done this in awhile.

Wow. I havn't updated in a long time.
However I'm going to try and make an honest effort to post at least one .plan every two weeks.

I've learned alot about the Torque Gaming Engine since I've started about a year ago.

I just wanted to thank all the people at GarageGames for making the great engine and the entire community for all the fun :)

I posted my first code snipit not to long ago titled "Mission Area Bounds". Unfortunately it was a bit too premature for me to do so. I've learned a valueable leason: always test your code.

Even though I did fix the resource and clean it up, the damage has been done :( At least I learned something from the experience and next time I'll make sure not to repeat the same mistakes.

Over the course of the next year I plan to contribute a great deal more to the community. Currently the only 'real' contribution I have made was to fix the zip file archive support in the engine. However I plan to provide a number of tutorials, hopefully for later inclusion into the script documention, that will cover a wide variety of topics such as creating GUI controls and making that all important leap into the Torque Engine: creating a game.

That about wraps everything up. Until next time, see you in the forums :)

Thursday Apr 25 22:04

Robert Blanchet Jr. — 2002-04-25T22:04:22+00:00

College, summer, and programming.

I sure do need to do more plans don't I? :)
School is nearing an end. Finals week next week eek.

If any of you are in highschool, I got once piece of advice: College finals are very different then High School finals! LOL

In any event I'm doing pretty good. After this year, which is my freshman year, I'll officially be considered enrolled in the Comp Sci Major.

I can't wait until classes actually start to get interesting :/ Most of what I've learned this year is rather elementary, even though it was in Java, which is the devil btw.

Don't get me wrong, cross-platform programming languages are just fine.. it just seems that Java does a lot of it wrong :) It's probably easier to go from a Java language to a C/C++ language then it is the other way around cause you miss a lot of things about C++ that you just can't do with Java :)

In any event. After this next week I'll be able to poor my heart and soul into Legends. It's coming along on a nice pace but hopefully it will pick up greatly during the summer time.

As far as side projects go, I've managed to help out the Torque community by finalizing the zip archive fixes for Garage Games that we've been in discussion about since January. Although I was unable to complete one solution I believe they are to a state that can be added to the HEAD revision soon. I have yet to figure out how to solve this one problem when implementing a particular zip feature, so hopefully I can hammer that one out during summer.

Wednesday Oct 24 15:01

Robert Blanchet Jr. — 2001-10-24T15:01:21+00:00

Completed a working skinnable button control.

I've been pretty busy with college life! It is fun as heck but sure takes up a lot of free time (speaking with girls and all) ;)

I havn't kept up with my .plan(s) very well, one post! heh. Oh well, I'll just do it whenever I can.

Some of the things I've completed since my last .plan include:

1) Finished an early version of the new texture2bm8 utility. The DEV Team I'm currently working with however has decided not to use the bm8 image format for the slower end machines. This means that I'm going to be holding off work on the utility until 'Legends', is finished and ready for download. The new texture2bm8 is currently not available for download anywhere, however it will be shortly.

2) Working on an online resume/portfolio. I got great hosting at www.evolt.org. Wonderful web programming/designers hangout...check it out sometime.

3) Currently polishing up a skinnable button control that I designed for the 'Legends' project. It has 4 different states that the button can be in, including normal, n/a, hilite, and depressed. I might add more but there really is no current use that I could see. The button can also be stretched/skewed however we need it.

4) Starting work on skinnable controls for all the other control types that can't be skinned.

5) Hashing out plans for avi controls. For instance, text edit controls, buttons, you name it, that will play movies under certain circumstances. This should be fun.

Wednesday Sep 5 1:04

Robert Blanchet Jr. — 2001-09-05T01:04:42+00:00

Over the course of the week I decided to, and have now completed a new version of texture2bm8. Here is a list of some of the key changes:

- Moved file handling for both opening and saving into their own functions. Each function is passed a pointer to the appropriate image resource to save both time, and memory allocation.

- Images now need to be located in a sub-directory called 'images' for processing.

- Added two new command line options. These new options will help enhance the functionality of the utility and provide a backbone for things I plan to do in other releases.

- One option is that of '-f'. An example of its use on an image such as player.png is as follows:
texture2bm8 -f player player

This will look for, and convert the file images/player.png and store the new image file as images/player.bm8 . Note that extensions are no longer needed in the arguements and will cause an error.

- The other option is that of '-d'. An example of its use is as follows:
texture2bm8 -d

This will look for and convert ALL image files it finds in /images/ with the extension *.png to *.bm8.

Another build of the utility will be made available a few weeks after the release of the revision to the V12 Engine. There are a few key things I would like to include in that build:

- More command-line options, such as the ability to process multiple sub-directories, and the ability to choose your own sub-directories.

- The ability top place both the original image file, and the converted one into a volume(.zip) when compiling sets or groups of textures at once.

The source code to the build will be made available after the next release and only to the appropriate V12 Engine holders. I'm waiting to release anything until I can get these last features into play.