Milestone 2

[RonHiler]

I've partially updated the milestone list for Enzyme. But I've been on planes since 4 this morning, so I have no energy to finish it right at the moment. I'll finish it up tomorrow and I'll talk in more detail about a few items in M2.

Ron

[Pix]

Oooh, flying. Gotta love it.

Next week I am flying back home early early Saturday morning to set up a computer for a family member, and then flying back Sunday afternoon.

[RonHiler]

There's nothing I hate worse than flying. I wouldn't say I have a phobia about it, but it's close It's a true testament to the love I have for my partner that I allow her to put me on a plane once or twice a year, heh.

I finished putting up the M2 list. In what is a very odd development for me, the M2 list is actually shorter than the M1 list. It's mostly about putting up the project screen, which is essentially a jump off point to all the sub-parts of the program (see item 12, especially). A lot of those buttons are for future development, I don't intend for every single sub-section to work right away. A lot of that stuff is overkill for what we need for Sov right now. But I think all of it will eventually be handy to have around, so you can expect that Sov and Enzyme development will go back and forth quite a bit.

What I'm working on right now is fixing a particularly vexing bug with fonts. They don't stay the same size depending on what resolution you have selected (the higher the resolution, the less space they take up). This is no good, as I need to have some idea of where the fonts end up for the purposes of doling out screen real estate, so I have to fix that little quirk This will, of course, completely mess up most of the font routines, but that's programming for you, heh.

Ron

[RonHiler]

Well, I'm done with the constant font size thing. I'll explain why that's kind of a big deal.

When I first made the list for M2 in my head, the font thing wasn't even there. I noticed the problem with the fonts only after the screen resolution changing code was working. It became especially obvious with the edit boxes. You see, the font was designed to fit in the edit boxes correctly at the default resolution. Once I changed the resolution, they no longer fit right (the letters were too small, height wise). From there, it was obvious that all the fonts were doing the same thing across the entire screen.

"So what", you say, "what's the big deal?". The big deal is that the fonts take up screen real estate (which, in my experience, there is NEVER enough of), and if they change sizes with every different resolution, there is no way I could create consistant screens for the users to use, and this would inevitably lead to problems. So this had to be fixed, and thus it was added to the M2 list.

After the M2 list was done in an official form, and I looked at it, I thought to myself, "self" (I thought), "the font thing is going to be one major bitch of a bug to kill".

Why?

Enzyme, like any good object oriented code base, is built in layers. In this particular case, the bottom layer is the font class. This class is responsible for creating the bitmap, handling character extents, and actually drawing the text (one letter at a time).

On top of the font class is the font manager. The font manager has a whole load of individual fonts (one font class for each font). The job of the manager is to channel requests for text drawing to the appropriate individual font. It also keeps a master list of all the fonts available.

On top of the font manager class is the static text class. This holds the actual string that will be displayed, where it shows up, what font it should be in, and so on. Although it's called a static text class, the text actually can be changed dynamically, it's just that it *normally* doesn't change much (compared to how often it is displayed [e.g. 60 times per second]).

On top of the static text class are a bunch of UI components (though the static text class itself can be a UI component, it often is used inside other components). These include things like the edit box class, the selection box class, the drop-down box, the radio buttons and so on. Each of these has one (or more) static text classes associated with it.

On top of all the UI components are the individual screens. Like the user setting screen and the project screen, each which has a bunch of UI components on it. On top of that is the screen manager that controls chanelling to individual screens. I don't think these need much of an explanation.

So that's the structure of the code base (or one branch of it anyway) from the fonts up through the screen manager. So, now that we've got that out of the way, what was the question?

Oh yeah, why is the font bug a big deal? Because it involved, at a fundamental level, changing the way a base class worked. The class that controls the drawing of individual characters is the font class, which is the class right down at the bottom of the code pyramid. This has the potential to break stuff on many many levels of the code, all the way up to the top of the branch (the screen manager).

As a designer, this is exactly the sort of thing you *don't* want to have to deal with. Adding new functionality to a base class is fine (you won't break anything above it by adding a new function, because it's a NEW function, nothing uses it yet), but changing how an EXISTING function works can definitely affect everything above it. And that's why I thought this whole deal was going to be a big messy terrible pain in the arse.

In fact, it didn't work out that way.

I tried a couple of methods to proportion out the fonts, but didn't like the results and ended up ripping back out the new code. My third solution was the one I finally went with, for three reasons. One, it was simple, two, it didn't have any significant effect on the framerate (most of the calculations were done in initialization), and three, it didn't adversly affect the classes above it! I made a small change to the font manager class to send a desired screen height (in percent) at initialization, let the font class calculate pixel height, which translated into a scale, then used that scale in the drawing routine, a TADA! Instant constant sized text, without any need to majorly modify any of the classes that sat on top of the font class. I did have to make a slight modification in the code that returned text extents to account for the scaling, but that was it, not much else to it. Essentially a static text class requested a text draw from the font manager and the font manager channeled it to the rght font which drew the text in the correct place, just the same as it was before.

So a change I thought would be very difficult actually turned out to take only about a day to finish. Have to love when things like that happen.

One slight downside is that the text is now scaled, and therefore I had to put in a filter (if you scale something without filtering it it looks very bad). As a result, the text is a tiny bit more blurry than it was. This is less a problem the higher resolution you select. At the lowest allowed res (800 x 600) it's a little distracting. I'm going to try out a couple of filters and see which one I like the best, so this may improve. If not, it's not really a huge deal, even at the low res it's not bad, just not crystal clear. And I don't think many people will use the low res anyway.

Ron

[RonHiler]

I've been quietly working on Milestone 2 for the last week. I still have a lot of projects going, so my time is still more limited than I'd really like, but I decided I needed to get off my lazy butt and work on the real stuff at least a little bit

I wrote a whole long disertation last time about the fonts in Enzyme. The system is a good one, but it had one drawback that really nagged at me. The filters I had to put on the drawing routine to compensate for texture shrinkage were causing a slight bit of blurryness, which I mentioned in the last post. I said at that point that we could live with it.

However, it's something that really bugged me. Any amount of blurryness in a font is bad news, no matter how slight it is. Text is the one thing above all others that you have to have crystal clear, heh. So I did a small rewrite that fixed it. Instead of shrinking the textures with the fonts on them and compensating with filters, I simply made sure there was no shrinkage at all. This involves destroying and recreating all the fonts whenever there is a screen resolution change, but that's no big deal. The result is a million times better than the previous iteration, and something I think I'm now 100% happy with. There's still a bit of work to do on this front, as it's kind of a major change to the system, but nothing too difficult (basically just making sure all the options I want are still working, like italics, bold, centering, and so on).

I've also been continuing work on the file/directory crawler, which has been a thorn in my side. I think I'm was trying to get it to do too much at this point. The crawler is something that will get a few passes and get better as it matures, but right now I just want basic functionality from it, hehe. It's about 90% there right now, you can move through directories and files, but not change drives from the current one. Have to do that, and allow for the creation of new directories, and add in the flag for whether or not the user should select a directory or file, and so on. It has a few things left to do, but hopefully nothing major. The Directory Crawler has definitely been a bottleneck in the progress of Enzyme.

After that, the M2 list should move along pretty quickly, I think. That's good, because M3 is where things will really start to get more interesting

Ron

[Shane Christopher]

Excellent to hear you're working on it again

[RonHiler]

I'm going to bitch and moan for a few minutes. If you don't want to hear it, feel free to skip over this post

As I've said, I'm working on the Directory Crawler. This is a User Interface (UI) window that pops up whenever you need to tell the program what file or directory you want. If you don't know what I'm talking about, open any standard Windows program (like Excel or Word) and hit the "Open" button (Usually found under the "File" menu). The window that pops up is a Directory Crawler.

Although I've used Directory Crawlers plenty of times in the past, I've never programmed one from scratch. There is a very nice call in the Windows SDK called "GetOpenFileName", that, when called, pops up a ready made Directory Crawler complete with all the bells and whistles you are so used to. Whenever you are inside one of those Crawlers, you are actually dealing with code produced by MS, not the code of the application. Basically, I (as the programmer) pass you off to "GetOpenFileName", and I don't get you back until you hit the "Okay" or "Cancel" button on that window.

Unfortunately, with Enzyme, we haven't got that luxery. Because we are displaying everything with Direct3D rather than Windows GUI (for performance purposes), we have to do all the UI stuff ourselves, from scratch, and that includes the Directory Crawler.

I knew the DC was going to be a royal pain before I ever started the damn thing. I have to deal with a lot of outside MS calls that I have no control over in order to get the info that I need. Fortunately, many of these kinds of things I've done before for one reason or another (such as scan directories, read files, and so on), so much of the DC is complete at this point.

However, there is one area that is totally new to me, and that's the "Look In:" box. It's the drop-down menu you see at the top of the window that allows you to change drives or to go to specialty folder (like Desktop et al). In order to get the information I need for this drop-down to work properly, I have to use a bunch of Shell commands, like "SHGetMalloc" and "SHGetSpecialFolderLocation" and "SHGetFileInfo". Sounds pretty straight-forward, based on the names, but don't let that fool you. Once you start trying to use them, they are cryptic and unwieldy, hehe.

Anyway, sometimes using Windows SDK functions is really nice (like the aforementioned "GetOpenFileName") and sometimes it's a real PITA. At least when I'm using my own functions, if something goes wrong, I can look at the function and fix it or expand it or whatever. If something goes wrong inside a Windows function, I have to figure out some way to retool what my program does in order to match what MS *wanted* me to do, which is sometimes troublesome. A lot of times the SDK functions are kind of arbitrary in the way they work, and it doesn't always fit with what I want to do.

Okay, I'm done venting for now. Back to the shell functions....

BTW, the fonts turned out great. All done with them (again) except they messed up my edit boxes slightly. Not a truly big deal, just a bit of debugging to work out.

[Innocence]

sometimes it's a real PITA

[HOMER]Mmmmm.... pita... arrrrrr.....[/HOMER]

[RonHiler]

You're so funny Jorn

I'm coming up on the end of the Crawler programming. Yes, it's been several days worth of work! The day before yesterday I finally got the "Look In:" box to stop displaying gibberish, hehe. It will display specific folder paths. Now I just have to get it to display drives and we're all set.

Everything else works, I think. All the buttons and boxes and scrollbars seem to be doing what they're supposed to do. Except the "New" directory button, still have to work on that one.

I've decided to split the Directory Crawler (where you select a directory) and the File Crawler (where you select a file) into two seperate classes. To this point I've been trying to create a hybrid class that would handle both cases, but I've since rethought that decision. They do share a lot of the same characteristics, but there are enough differences that seperate classes would probaby be best. This is a perfect place for inheritance, as a matter of fact. I will probably write a base class with all the basic functionality that both of them have, then inherent the base into both the Directory and File classes, where they will get their specific functionality.

See, I am a OOP/OOD programmer

Ron

[RonHiler]

Milestone 2 list updated. The directory crawler is done and works fine, though at some point (maybe in Milestone 3) I'm going to revisit it and make a few improvements.

Working on progress bars now. A much easier UI component

In other news, I'm upgrading my compiler today (going from Builder 4 to Builder 6). I've actually had this sitting here for a while now, but haven't had the time to install the dang thing, hehe.

In my experience, it takes a day or two to finish the installation of a new compiler and then figure out why your legacy code no longer compiles There's always differences between what the compiler likes to see, even when changing to the same compiler with a new version. So I may slow down a bit for the next couple of days.