Fun with GEL!
A Tale of Two Character Encodings
Sunday, June 12, 2005 by GreenReaper | Discussion: Software Development
This friday I finished up some work on a new version of one of Stardock's products, which'll probably see the light shortly after the company finishes moving to Plymouth. So what do geeks do with their down-time? Well, in my case, it's often pretty much the same to what I do for money, only for the communities I'm interested in. Recently, a lot of my time has been spent on the Creatures Community, the group of people who've played the Creatures series of artificial life games. When I'm not contributing to the Creatures Wiki, I'll be writing some sort of tool, like this sprite thumbnail viewer, or polishing the next version of JRNet. But enough about my projects, as this one is actually about someone else's . . .
GEL is a genetic editor for Creatures 2. It is used to edit the genes for the various creatures (Norns, Ettins and Grendels). There are other editors, but people get attached to their favourite programs, and GEL is no different.
The trouble is, although GEL worked great on Windows 98, it didn't seem to want to work on XP. OK, so that wasn't great, but the real problem was that the source code - the words that the programmer types and gives to the compiler to turn into a program - had been lost in a hard disk accident, and so he couldn't fix the problem. Without the source code, you just have the "compiled" version, and it's very hard to make any changes to that.
There were several people upset about this, though and it's always a shame to lose a useful program, so I decided to see if I could do something about it. Overall it took about two days of work to get it back up and running, which I thought was pretty good. I figured it would be kinda neat to tell you how I did it, and show you some of the different tools I used, so I wrote this article. Just skip over the bits that get too technical!
Let's start with what I got when I installed the program and tried starting it up myself:
OK. I got this error, and then when I pressed OK it closed on me. That didn't work out that well. I'm sure you've seen similarly confusing errors on your own computers! Turns out, it's not always easy for programmers to figure out what it means, either . . .
So, we have a problem. But where? "Path not found" isn't a very helpful message - it doesn't tell you what path, for a start! I decided this would be the first thing to try and find out, so I started up FileMon, a utility that monitors what files are accessed by running programs. I was looking for any "not found" messages, and there were a few, but they all turned out to be dead ends.
By now it was clear that it wasn't going to be as easy as a missing file or a permission problem. The next thing I tried was another of the Sysinternals tools, RegMon. This does much the same thing as FileMon - monitor what's happening - but for the Windows Registry, so you can see what settings are being written and read. I consider both of these tools essential if you want to know what's really going on.
This was the last registry read before the error
As it happens, RegMon did turn up something - the last thing that GEL read before it all started to go wrong was the main path of Creatures 2. The thing was, this registry read didn't fail. This just happened to be the last thing that it did with the registry that I couldn't narrow down to other causes. I did try modifying this value in the registry, but this just resulted in slightly different errors.
After that, I briefly tried using another utility called API Monitor in order to see what calls the program was making to the operating system. This program is rather like a general version of Regmon and Filemon - while they monitor specific things, API Monitor "hooks" pretty much every system function that there is and records their use. Unfortunately, I couldn't find what I was looking for; I later found out that it didn't even start sending messages until a window had been created.
A small aside . . .
One thing I did notice using API Monitor was the amazing number of calls that were made - almost ten thousand of them - just to display an error box on the screen.Of course, it wasn't just displaying the box, it was:
- Loading the code to process the error
- Looking up the error message
- Playing the error sound, which meant:
- Loading sound libraries
- Checking what sound devices were available
- Figuring out what sound was the error sound
- Loading and playing the sound
- Loading up the screen reader library in case it needed to read the message to me
- Lots of other things that might have been useful if it had actually done anything after showing the error
There's a simple reason CPUs keep getting faster - they have to, because if they didn't, there's no way we'd be able to use all the things our computers do for us! The really crazy thing is that displaying such a box (with all the above features) just takes one line of code; something like this:
MsgBox "Hi there! This is the message" & vbNewLine &, vbInformation, "This is the title!"
Truly, we live in an age of wonders.
To recap: I'd found it wasn't a case of failed registry entries or a file not being there. It was time to bring out the big guns.
My first tool is recognizable to pretty much all Windows programmers, even if they don't use it themselves - Microsoft's Visual Studio. This is the number one tool for Windows development, and although it has its detractors, it's pretty good as development environments go. I would use this to run the program and stop it halfway, examining and changing the memory that it used.
The second might be a little less familiar to most programmers - IDA, the Interactive Disassembler. A disassembler is a program that turns compiled programs back one step into "assembly code", the last point at which it can be considered remotely readable. Few programmers actually write code at this level - most use a higher-level language like C++, Pascal, Java or Visual Basic - but it is usually possible to get a good idea of how parts of a program works through reading it in assembly.
Disassembling programs (also known as reverse-engineering) is something of a shady activity - one of IDA's most popular uses (though not one they advertise) is to figure out how to get around serial code checks, and this is one reason why disassembly is forbidden in most software licenses. However, all tools have their uses, and when you need to know exactly what a program is doing in order to fix it, but don't have the source, a good disassembler is a requirement.
Anyway, I started the program running in the Visual Studio debugger - a mode in which you can control exactly how a program executes, and modify the variables it is using - and ran through the code to see where the problem occurred. It was pretty easy to see what part of the error was in - a file called glsupcts.dll that came with the program. To see exactly what the code did, I set IDA running on it; after a few minutes it had an assembly listing of the code ready for me to read.
A note about DLLs
DLLs are not that much different from EXEs - they're both files that contain "code" (and sometimes other things like icons or embedded sounds). The main difference is that the EXE files contain the bit of code that starts the whole thing going, whereas DLLs tend to get called up by those EXEs to do their share of the work.
Of course, the assembly code wasn't actually all that easy to read. Something that made it even difficult was that the program had been written in Visual Basic, a language that I like which has a very easy to use system of programming, but which is often more general than required. As a result, it often did things in an odd way, and the code made a lot of calls to functions in the Visual Basic library. Of course, since these library calls were not documented, I ended up having to decompile this library as well, just to figure out what the program was doing! Hopefully nobody from Microsoft who cares is reading this.
Reading through the IDA output, I found the check for the registry value just before the error occured. It certainly seemed these were linked in some way. Then I found a reference to "AllChemicals.str", a file that contains the names of chemicals in Creatures. It made sense that GEL would try to load this file, so that it knew what each of the chemicals was called!
Now I had a clue - since I knew from reading the FileMon output that it never actually managed to load that file, it was probably failing while trying to. Using Visual Studio to look at the memory when the program crashed, I saw there was something odd about the path it had given to the "open file" function. It started off fine, but the end didn't look at all right. Here was my problem!

The system had used part of the memory given to it to work out the path (see the end for details), and GEL had thought this was part of the path itself. It was all clear now - the buffer was not being trimmed of the working copy, and this was getting left after the path name, so when the program put "AllChemicals.str" on the end, the middle of the path was invalid. This was the reason it wasn't showing up on FileMon - it didn't even get to the point where it looked for the file on the disk.
So what could I do? Well, I knew it was trimming off the last part of the string - the trouble was, it thought it was twice as big as it actually was, so it was keeping twice as much as it should. The length had to be stored as a number somewhere. Eventually I found the number being returned from a call to a function called vbaLenBstr
- which naturally calculated the length of the incorrect path. Now I just needed to divide it by two and it would only use the correct portion of the string.
Remembering my computer operations, I knew that the best way to divide by two was to shift the number to the right. What does this mean? Well, you can think of numbers inside a computer as being like a group of people all standing in a row, with flags with numbers on - starting from the right, they'd go 1, 2, 4, 8, 16 . . . all the powers of 2. When you shift right, the people all look at whoever's holding the next-highest flag, and do what they're doing. It looks like this:
Flag num 128 64 32 16 8 4 2 1 Before: 1 0 1 0 1 0 1 1 = 128 + 32 + 7 + 2 + 1 = 171 After: 0 1 0 1 0 1 0 1 = 64 + 16 + 4 + 1 = 85Voila - division by two! Of course, you lose any remainder, since there's no 0.5 flag. Fortunately there's no such thing as half a character.
Of course, I'm not a whiz at assembly, so I had to look up exactly how to do the shift - I actually found the one I needed elsewhere in the code, so I could just use that. Now I had my instruction, and I knew where it had to go. It should be simple from here, right?
Well, no. The trouble is, you can't just add another instruction to the middle of a compiled program, moving all the others along. It would be like rearranging pages in a book and not updating the index (which is regenerated each time you "compile" a book). Worse, since machine instructions usually take more than one byte, moving them means instructions would start in the wrong place, changing their whole meaning - imagine what would happen if you kept all the spaces in a book in the same place but moved each letter along one position! When things get out of order in a computer, programs crash.
One thing I could have done would be to overwrite what was there already (perhaps something that didn't matter much). It had been enough trouble figuring out what one piece of assembly did, though - I didn't want to have to go through that all over again!
Fortunately, I didn't have to try that, because there was a convenient area of
NOP
instructions nearby. NOP
stands for "no op" - it's an instruction that does nothing but move onto the next instruction. This seems useless, but it can in fact be useful for various things.
In this case, it was useful because it meant I had some space to work with. Because this space was free, I could fill it with more code. I needed to add just one instruction, but to get to that instruction I needed to put a jump instruction in. I looked these up, and it turned out the one I needed was a whole five bytes long, including the place to jump to.
That meant I had to move the code it replaced down into the section of NOPs as well, after my right shift. I then needed to jump back up to the point after the first jump instruction, so that the code could continue as if nothing had happened.
So, after that, the big question is did it work?
. . .
Yes! It finally loads!
For those who've read this far, congratulations! I hope you found this little view into my world educational.
This is a bit more than you'd usually have to do when debugging a problem, but it's pretty representative of what most programmers do in real life - it's not all fast cars, mansions and stock options! Sure, you don't usually have to go as hardcore as writing assembly-code patches for broken DLLs (I'm sure I'm going to get nasty comments from the real hardcore folks out there who do stuff like this every day , but a lot of the time you're figuring out problems with existing code, not just writing new code.
Often it's not our code, either - it'll be written by someone else (who left six months ago) in a way that seems totally nonsensical. Sometimes you're right to think that, other times you just don't understand it yet; either way, you have to fix it, and probably add a few new things, too! Ahh, well, all in a day's work . . .
Bonus! (warning: very techy)
If the program was buggy, why did it work on Windows 98? Well, the difference is the way in which the operating system works with text. On Windows 98, the standard is to have one byte per text (UTF-8), which is nice and fast, but which means you only get 256 different characters to choose from at any one moment; not enough for many languages. In Windows XP, the standard (called UTF-16) is to have two bytes, which gives you 65536 characters, which is good enough for most purposes.
Asking for a value from the registry is done by preparing a memory buffer - an area of memory to hold the result - and telling the operating system how you want the data. Because GEL had to work on both operating systems, it used the Windows 98 method, asking for a UTF-8 string (step 1 on the text diagram), and expanded the text later (step 2). But on Windows XP, this meant that the operating system had to reduce the size of the text, since it stored everything in UTF-16.
What was the easiest way to do that? Why, to read the output into a buffer and then collapse it down to UTF-8 by copying each character back just the right amount (computers rarely "move" data, since it costs twice the time it takes just copying it - deletion is an extra step) - first 0 steps, then 1, then 2 . . .

Where should this conversion take place? Since the memory space to store the text in was already available, it used that, safe in the knowledge that any extra text in the buffer should be ignored by the program, which was told how much had been returned. At least, that's how it should have worked . . . but instead, the program used the whole string and just counted the length of it rather than relying on the value it was given. On Windows 98, that space was never filled with text, as it was UTF-8 to start with. Although the bug was still there, it had no actual effect, since counting the length of the text came up with the right answer.
By the way, this explains why the "extra" text is quadruple-spaced - it was UTF-16 to start with, and it was left there because it was the second half of the text, which was not overwritten by the UTF-8 version of itself. It was then incorrectly read as part of the UTF-8 string, and expanded again by GEL into UTF-32.
The irony is that if it had been read straight from the registry as UTF-16, no conversion would have been necessary, and the application would probably have worked. Such are the ways of code!
Icon-A-Day, Icon # 103, Recycle Bin - Full
The last of our IconPackager 2.5 Icons.
Monday, June 6, 2005 by mormegil | Discussion: Icons
Icon 103 (Recycle Bin - Full) Today we will finish up our IconPackager 2.5 icons with the "Full" Recycle Bin. We will do this primarily by using many elements from our file icons, as well as making a few minor tweaks to our Empty Recycle Bin icon. This will work out to be several steps, but they are all pretty simple for the most part. | ||
Step 1: First we start by making a copy of our "Empty" Recycle Bin icon from last week. ![]() |
Step 2: Now we are going to do some layer management. I have not talked much about this during the tutorials, but I have an extensive tutorial on it in the Corel For Skinners videos. I have 3 layers that we will use. ![]() |
Step 3: I group all the objects that make up the back of the Bin, and move them to a layer in my file called "Folder Backs" ![]() |
Step 4: Now I Group all the parts of the front of the Bin, and place them on a layer called "Folder Fronts" ![]() |
Step 5: |
Step 6: Now I ungroup the file icons and start stealing pieces from them. I start by taking the Document file, removing the bitmap from it, then using the Perspective Tool to slant it back. Because it is one "Folder Content" Layer it aromatically sits between the font and the back of the bin, making it look like they are inside the bin. ![]() |
Step 7:
Now we repeat the last step, but with the BMP file. I have to remove the Bitmap, and the Mesh fill on the tile of the file, because they will not work with the Perspective Tool. I will put them back later. |
Step 8:
Now we continue, placing our pieces-parts in the Bin. Next we add the Sharpie, rotating it and skewing the shadow a bit to make it look like it is being cast on the files. |
Step 9:
I have a green Shear in the PNG file. I take it and place it behind the files in the back of the bin. |
Step 10:
Once more we grab our music note from the Wav file and place it inside the Bin. This one looks fine just how it is, so it is simply set in the proper place and we call it done.
|
Step 11:
Now I want to stick in one more element, so we take the paint brush, rotate it and flip it and place it inside the bin.
|
Step 12:
Last I take the bitmap from our BMP file and skew and crop it a bit and place it behind the brush and note. So it is back at home on our BMP file.
|
Step 13: Now by turning off the visibility of our "Folders Front" I can look clearly at what's inside the bin, and make sure it is what I want. When I am happy with it I simply turn the layer back on. ![]() |
Step 14: Now I need a new reflection, so I take our existing reflection bitmap, turning off the transparency that I gave it before. Then copy all the bin Context, flip it, and using our reflection Techniques, we give the new bin a nice shadow. ![]() |
Step 15:
Last we need to add a bit to the bins shadow. We do this with our standard Drop Shadow Techniques. |
Finished Icon Image. |
||
.Well, that wraps up our IconPackager 2.5 Icons. If you have an Icon package, and you have not already done so, you can simply open it up, go to package builder mode, and assemble a completed pack. |
Memory use myths
Customization software is not resource intensive
Sunday, June 5, 2005 by Frogboy | Discussion: OS Customization
I'm not sure where the myth began. But somewhere down the line, a false belief has turned into pseudo-fact amongst some people that customization software uses a lot of memory. That's never been the case. Not even in the beginning.
At the dawn of Windows customization, software had to run on Windows 95 which only had 128K (that's kilobytes) of GDI resources. Customization software ate up a lot of those GDI resources since they were reserved for the user interface. But even in 1995, 16K of memory was trivial. It's just that early versions of Windows were so limited in their GDI resources that it was a problem.
But Windows 2000 and Windows XP have never had any such problem. And yet, we still see some uninformed, but vocal, user claim that <Program X> is "bloated" and uses a "ton" of memory. Those people come in two forms: The guy who really has no idea what he's talking about and the guy who thinks 10 megabytes of memory is a "ton" of memory.
The former guy is annoying because he matches his ignorance with his prolific posting. The latter guy makes you wonder if their source of income is mom's allowance or something. I can buy a 256 meg stick of memory for my PC for around $20.
So let's get this out of the way: Desktop customization programs do NOT use much memory.
Here's WindowBlinds wbload.exe process use:
That's 576K.
Here's DesktopX:
That's only a couple megabytes of memory and it's running a useful object in this instance.
I could go on through a variety of programs both made by Stardock and made by third parties. None of them are "memory hogs". You can certainly load up enough stuff with something like DesktopX to make it use a ton of memory. Graphics, animation, etc. has to be stored somewhere. But that's not the desktop customization's fault any more than it's Photoshop's fault if the user loaded a gigabyte sized image.
So next time someone tries to claim that some desktop customization program is "bloated" or something, point them here.
Icon-A-Day, Icon #102, Recycle Bin (Empty)
Let us sum up what we have learnd, and make a important Icon.
Thursday, June 2, 2005 by mormegil | Discussion: Icons
Icon 102 (Recycle Bin - Empty) At last we come to the much anticipated and much dreaded (by me) "Recycle Bin". This icon is always somewhat daunting since it is seen the most of any, with exception of the folder perhaps. You can count on people judging your entire pack by it. The pressure is not so bad in this pack, since it is not being done to "wow" but rather to instruct, but still we want to do something nice. This is the second to last icon for a standard IconPackager 3.0 icon pack, and since many of you have been following along closely I decided to be a bit more thorough on this one, using it as a kind of summery of what has been shown through out the tutorial series. We will use almost all of our techniques in this one, and I will show a bit more detail on some of the fanciers steps. So without further ado, I bring you, da, da, da... The Recycle Bin. | ||
Step 1: As has almost always been the case, we start with some rectangles and the Mesh Tool. You can see here how we start to give the bin some shape. At this point we only have four shapes, two of them are almost entirely hidden behind the others. ![]() |
Step 2: Now the theme of this set has become, more or less, Metal and Glass. So what I have decided to do is make the body of the bin glass, and the bottom and rim metal. So I create a few more mesh rectangles and start shaping them to our needs. You can see that the top and bottom are actually only one shape each, even though they show two sides of the can. ![]() |
Step 3: Now to get our glass we do a few things. First I edit all of our glass sections with the Mesh Tool to give them some gradients, like in our first gloss tutorial. Then using the Interactive Transparency Tool, I set the rear piece of glass to a 50% uniform opacity, and give the two front pieces nice Transparency Blends; each slanting away from the other, to give the illusion of dimension. ![]() |
Step 4:
Now we give the front, and side faces of the bin some simple glare. Just like in our Gloss tutorial. |
Step 5: |
Step 6: Now we go in and do some more detailed mesh editing, making sure that we are keeping with the paneled style we have established thoughout the icon pack. In this case, I make an end panel on the rim and tint all the nodes slightly darker. ![]() |
Step 7:
I more or less repeat this same thing on all the edges of our rim, giving it the same kind of panel effect we have used in most of the metal icons of the pack.
|
Step 8:
We move down, doing the same thing to the bottom of the bin, except in this case I only add two two grooves.
|
Step 9:
One mesh shape to note here is the back of the bottom of the tray. It is pretty simple, but since it is beside the glass, it adds a lot of believability to the overall image. The little details can make or break the "reality" of an icon.
|
Step 10:
Now we have the basic Empty Bin done, we need a shadow. Since we want our shadow to reflect that the bin is made up of two different materials, glass and metal, I draw a few template shapes where I want my shadows to end up.
|
Step 11:
Now I put a 50% shadow on the gray piece, which is the shadow of my glass. Then I pull a 100% shadow off my black shape, which is the shadow of my metal pieces. Once I have this, I delete the template pieces, select both of my new shadows, and convert them to one bitmap. I also send it to the back of our image.
|
Step 12:
Last we take our resulting bitmap and bleed it out with the Interactive Transparency Tool.
|
Step 13: One thing we have on all the metal of this pack is the brush texture. So I copy our rim, and bottom shapes, give them a grey fill, and a Brush Transparency. See Icon # 1 and the Interactive Transparency Tool tutorial for more on this. ![]() |
Step 14: Now we need our reflection. This will be done with our standard reflection techniques, but I wanted to point out a few details. In this case we could not simple mirror the image because it has a lot of dimension to it. So I had to copy the can and skew and edit the new image quite a bit to make it match up with the bottom of our bin. ![]() |
Step 15:
Last we convert the resulting image to a bitmap. Crop it to the bottom of our guide box, and blend it out with the Interactive Transparency Tool. |
Finished Icon Image. |
||
This has turned into one of the longest, and most detailed tutorials in our series so far. Hopefully it will be useful. Tomorrow we will add some more detail and color in the "Full" version of the Recycle bin. This will use all the techniques we used today as well as everything else that we did not cover. |
Icon-A-Day, Icon # 101, Briefcase
Almost there, 3 more to be done with the 2.5 Package
Wednesday, June 1, 2005 by mormegil | Discussion: Icons
Icon 101 (Briefcase) Well, we are almost done believe it or not. My original plan was to end with the full and empty Recycle Bin icons. However, due to popular demand I have made a few tweaks to my schedule. IconPackager 3.0 is scheduled to come out next week and my plan is to release the finished icon package at the same time. For that we still need about 10 icons. I realized that there were only three (3) icons left to have a completed IconPackager 2.5 icon pack, and since most of the people who have been following these tutorials have been building an icon package as we have gone, I figured we should jump ahead a bit. So today we will start wrapping up the last of the IconPackager 2.5 icons with the Briefcase, tomorrow we will do the Empty Recycle Bin, and Friday we will finish up the 2.5 pack, with the Full Recycle Bin. After that we will go ahead and polish up the rest of the IconPackager 3.0 pack and finish up in about a week more with a Tutorial and Video on building the final IconPackager 3.0 icon package. I am going to use IP3 because it has a very cool new Packager Builder, which will save me tons of time and make life a lot easier for us all. With that, let us begin. | ||
Step 1: As usual we will start with some mesh rectangles. ![]() |
Step 2: Now we start molding our Mesh Rectangles with the Mesh Tool. ![]() |
Step 3: Here is a bit more detail of how the meshes are being done. ![]() |
Step 4:
Once we get a nice look to the body of the briefcase we go ahead and give it a nice Brush Texture, using our Transparency Techniques. |
Step 5: |
Step 6: We need to give our briefcase a handle; we do this with 3 more rectangles, the mesh tool, and a bit of Gloss. ![]() |
Step 7: Here is a closer look at our handles done with the Mesh Tool. ![]() |
Step 8: Once we have the handle, we give the case a nice drop shadow, using our Drop Shadow techniques. ![]() |
Step 9:
As usual we will finish up with our Reflection Technique. |
Finished Icon Image. |
||
Check in tomorrow for the much anticipated, Recycle Bin. |
10 years at Stardock
From "office staff" to VP of Operations in 10 crazy years.
Wednesday, June 1, 2005 by KarmaGirl | Discussion: Internet
Today marks my 10th year of working at Stardock. It's been 10 crazy years of learning the business and changing the business.
When I started, Stardock was *very* new. I spent the first days before I was officially employed helping build furniture. I was the first official employee of Stardock...my how things have changed. I had no idea how much my life would change, or how much Stardock would change over the following 10 years.
We started out as an OS/2 ISV. We didn't have a network in the building. We went months with dial up before we could get an ISDN line installed. We took all orders over the phone, and when "online order" technology came out, it meant that the online order was faxed to us. The "internet" was new, and it was a big deal to have free Compuserve accounts.
We quickly grew out of our first office, and found a new office where we currently are. We grew...then we fell. In 1998, the bottom dropped out of our market when IBM decided to drop OS/2. We went from a dozen people down to 4 in a matter of months. At this point, I took the most perfectly planned maternity leave and was away for 8 months.
But, Stardock didn't die. Through the vision of our CEO Brad Wardell, and the brilliance of Neil Banfield (WindowBlinds only at the time), Stardock picked itself up and dusted itself off and was reborn as a Windows developer. After seeing WindowBlinds in action, and being asked by Brad a few times: "so, when are you coming back?" I rejoined the very small Stardock crew. The day I came back, one of our staff members left (he returned a year or so later) and a new staff member started (who now works at Microsoft). Things were really changing.
The Stardock that we now know is really only about 6 years old. The Windows market is nothing like the OS/2 market was, and the staff that we have is a lot different (mainly, larger). I can remember everyone that ever worked here, even Tamra who only worked here for one day back in 96, because we have such a low turn over rate. We've lost a few to larger companies (mainly Microsoft) and we lost a few due to downsizing, but we still have managed to maintain our great company culture.
So, today I am remembering the past, and looking forward to the brilliant future that is ahead. We are growing like crazy, and we are about to move into a new building (buying this time instead of renting). It will be interesting to see what the next 10 years will hold.
Icon-A-Day, Icon # 98, PST File
A bonus Icon no more.
Monday, May 23, 2005 by mormegil | Discussion: Icons
Icon 98 (PST File) Tonight we will continue on with our IconPackager 3.0 File icons. This icon is one I had intended doing as a bonus icon - part of the Office icon sets - but now it is supported in the defaults file types. I will do just the file tonight. Tomorrow I will do the Bonus Application icon and Folder as well. This will more or less be the same as the Access and Word files we did way back toward the middle. | ||
Step 1: We will start by copying the MDB file and removing the Access Overlay. We also change the base colors to Outlook's signature golden yellow. Also we change the title to PST. ![]() |
Step 2: Now I have an Outlook logo in my scrap graphics, so I import it and give it our standard perspective. ![]() |
Step 3: Now we give the Logo a poor mans bevel with the Contour tool. ![]() |
Step 4:
We give the bevel some gradients to make it match. I also give the face of the logo some gloss. |
Step 5: |
Step 6: Last using our shadow techniques we give it a nice custom shadow. ![]() |
Step 7 During the process of making this file, I had a nice crash and had to start over. So once again I have to change the title back to PST. ![]() |
Finished Icon Image. ![]() |
![]() Download the Completed Icons here. |
Tomorrow we will make a nice bonus pack of the Outlook Application icon and an Outlook Folder. |
Icon-A-Day, Icon # 97, PDF File
Good times with file extentions.
Sunday, May 22, 2005 by mormegil | Discussion: Icons
Icon 97 (PDF File) One of the most common file types that has been added to IconPackager 3.0 file format is the PDF file. PDF files are mostly used for documents, but they can contain text and graphics, so I try and make sure there is a bit of everything in the file. On top of this we will overlay an Adobe Acrobat logo. | ||
Step 1: First we copy the Write file. Remove the pen and tweak the copy with the Text Tool. ![]() |
Step 2: Now to set it apart a bit I change the background title bar to black. ![]() |
Step 3: Now I need an Acrobat logo, so I draw one with the Bezier Tool. ![]() |
Step 4:
Now that I have drawn the logo as a line, I use the Artistic Brush tool to give it a calligraphic effect. |
Step 5: |
Step 6: I give our new shapes some fills to flesh out our logo. And place it in front of our file. ![]() |
Step 7 Now we give the logo a shadow and break it apart and crop it, so it only falls on the file. ![]() |
Step 8 We pull one more shadow off the logo and fade it out, so it falls behind the file. ![]() |
Step 9 Last we once more give our new file a new reflection. ![]() |
Finished Icon Image.![]() |
![]() Download the Completed Icons here. | |
We are approaching the end of our pack; more file types to come. Tomorrow we will do anther new IconPackager 3.0 File type. |
Icon-A-Day, Icon # 96, TIF File
Back form E3, back to work.
Saturday, May 21, 2005 by mormegil | Discussion: Icons
Icon 96 (TIF File) Well, I'm back from E3 alive and kicking, though just barely. Today I want to get back into the new IconPackager 3.0 default file types. When we left off we were doing the PNG file. Today we will do one of the new image files: the TIF file. This will be done in almost the same way as the PNG file with a few exceptions. Once more this is a good example of how the same techniques can be used over and over and yet achieve quite different results. | ||
Step 1: First we copy our PNG file, remove the overlay graphics, and change the title to TIF. We also remove the existing reflection. ![]() |
Step 2:
Now again with the techniques from Gloss Tutorial we make a nice cyan colored lens shape. |
Step 3: Now I pull a simple drop shadow with a nice dark cyan color to give it a more glassy look. ![]() |
Step 4:
Now we simply copy our cyan shape, and change the colors to Yellow. |
Step 5: |
Step 6: And one last copy in black. ![]() |
Step 7 Now we go through and convert the four shapes to bitmaps giving them a slight transparency so they look more glassy. ![]() |
Step 8 Now I tighten up the color shapes to a formation I like and place them above the file. ![]() |
Step 9 Once more our last step is to give the new file a new reflection. ![]() |
Finished Icon Image.![]() |
![]() Download the Completed Icons here. | |
Tomorrow we will do anther new IconPackager 3.0 File type. |
Be careful what you blog for..
Your public blog is..well public..
Friday, May 20, 2005 by Draginol | Discussion: Internet
Last week I had my first really bad experience with the power of JoeUser's automated category syndication. You see, when you write an article on JoeUser.com, the system will look at what category you filed it under and then syndicate it out to other sites on the Stardock.net system. So if I write a blog on politics, it will show up on JoeUser.com. Write a blog on skinning and it shows up on WinCustomize.com. The system does work both ways where those sites feed into JoeUser.com as well. But those sites have much more restricted choices for what category something can be filed.
Well, back in April I wrote a couple blogs on gaming. The first one was about Will Wright's Spore and how I think his concept could be revolutionary because it puts the player in the role of the content creator. If developers can find clever ways to make the player part of the content creation team, costs can be reduced, quality kept high, and players made happy.
I reposted my blog on a semi-private forum I hang out on called Quarter To Three where many gaming professionals hang out. On there, one respondent indicated he worked at a major game developer and strongly disagreed with my points. I debated the issue on there but also wrote a follow-up blog on JoeUser.com that quoted his material and mentioned what game developer he worked for. That blog, categorized as a PC gaming article, got syndicated to several sites such as GalCiv2.com, SocietyGame.com, and TotalGaming.net. And then got featured on TotalGaming.net by a forum moderator (along with the original).
The guy who worked at the game developer was ticked off (to an extreme) that I would put his comments on a "corporate" website. I think he thought I was trying to get him into trouble or something, I'm not quite sure as the profanity-laiden emails did not make the exact issue very clear to me what exactly the issue was.
But what I did learn is something I should have already known -- blogs ain't private. Whether it's via a auto-syndication engine or a search engine, what you write publicly is -- well public. It's is the blessing and curse of the blogsphere. A blog someone might toss off in 15 minutes one Saturday afternoon could end up one day being quoted 2 years later on some major site.
While the incident definitely was unpleasant for me, it was a good wakeup call too to be more aware that what I write might be taken very differently than intended and may get out there a lot further and wider than I had ever thought.