Intel sponsors gamedev.net search:   
The One With Aldacron's GamesBy Aldacron      
The One With Aldacron GameDevMike The One With D

Friday, December 16, 2005
When I'm into a project, I'm really into it. I mean, I bury myself in my office and only come out long enough to go teach my classes (and to watch Survivor with my wife - which in Korea is about 3 or 4 weeks behind the US, so don't tell me what happened). I'm rather obsessive about this and, while I may waste a bit of time now and then surfing the web or getting in some DAOC play time, I get really stressed when other obligations arise that take me away from my desk.

Knowing that, and knowing that December is usually full of obligations, I decided to take a break for a month. By putting the project aside completely, I am denying that obsessive side of myself the opportunity to stress out. While I do have a general target date that I would like to finish by, I have the luxury of working at my own pace. I always set aside time in the day for my wife, but I learned a long time ago she likes me better when I'm not anxious to get back to work on my current project. Shelving the project for a month will keep my blood pressure down and make me a more pleasant person to be with, for sure.

So for a few days after I implemented the font renderer I did no coding at all. I bought some new DVDs and watched them all (including season 1 of Deadwood, which I had been dying to see but hasn't aired in Korea yet to my knowledge - fantastic show). We took in a couple of movies, did some shopping, and hiked up a small mountain in the first snow of the winter.

My wife also has obligations through her job, and this is a busy season for her normally, so the past few days I've spent more time back in the cave. When working on a seious (i.e. for pay) project I find it helps to keep a fresh perspective by working on a side project simultaneously in a different language. Since I'm using C for Game #1, I decided to start a new Java project. It's a fun project I've been wanting to do for a long while but never had the time (it's a huge undertaking, actually). Since I'm working on it 'for fun', I'm not being too disciplined about it. I'm certainly not being obesessive!

Work will resume on Game #1 in January. And the first thing I have in mind to do is a bit of a refactor. I tried to get fancy with some of the module interfaces and broke my design goal of keeping things simple. The problem is I've been working with one degign paradigm for so long it's difficult to shake it. That's one reason I wanted to do this project in C and keep the design as simple as possible. I believe regularly working with different design paradigms helps to keep your mind open to a wider range of possibilites and, ultimately, helps you to become a better software architect.

Comments: 0 - Leave a Comment

Link



Sunday, December 4, 2005
Font rendering is in. There was only one little hitch I ran into. When I implemented the texture loader I included code to always flip the loaded image. Since the data Bitmap Font Generator saves is based on a normal, unflipped image, it was causing garbage to be displayed. My options were to change the way I calculate the texture coordinates to account for the flipped image, or to just not flip the image in the first place. So I opted for the latter approach, as the whole reason I implemented flipping in the first place was to avoid the need to adjust texture coordinates. The texture loader now flips images only when told to.

My design calls for 2 fonts, a small one and a large one. I haven't settled yet on which face to use, but for now I'm using Arial. The big thing now is data configuration. The fonts will be used to implement that system. I alrady have a config file reader implemented, so that's half the battle. The other half is a csv (comma separated values)file reader.

My data configuration has two parts: the first is a config file that associates file names with object keys. For example, the fonts will look like this:

SmallFont=default_small
LargeFont=default_large

In code, I'll request the value associated with SmallFont and pass that on to the font loader. The font loader knows to look in data/fonts for default_small.fnt and default_small.png. All objects in the game will be handled this way, most likely in multiple data configuration files.

The csv files will be written in different formats for different needs. The texture loader needs to know how to configure the texture object state when uploading it to OpenGL (clamp or repeat, force point sampling or use the user-configured filtering [bilinear/trilinear], generate mipmaps or not, and so on). So this will all be stored in a csv file. When the font loader requests the texture loader to load default_small.png, the texture loader will look up the properties for that texture name.

So the next task on the list is the csv loader. Once that's implemented, the first data set will be that of the fonts. From there, I'll look into optimizing the font rendering. Right now I'm using a simple loop, calculating the same data multiple times per loop, and rendering in immediate mode. I doubt it will ever be a bottleneck, but still there are more efficient ways to implement it. I just don't like leaving first-pass code in when I know it warrants a second or third pass.

Comments: 0 - Leave a Comment

Link



Saturday, December 3, 2005
In the last post, I explained how I had found that I had passed the wrong parameter to glfwSleep, causing the app to become unresponsive. That still didn't explain why I kept getting an invalid texture object error in the log file. I discovered today what was happening, by accident.

When the app was hanging and hitting the escape key did nothing, clicking the close button usually closed the app after a brief delay. After I fixed the sleeping issue, the escape keypress was getting handled and worked well, so I wasn't clicking on the close button. Later on I did. The invalid texture object error was back.

Turns out I hadn't set a window close callback. The GLFW was destroying the window, and thereby the OpenGL context, before my cleanup code was getting called. Hence the invalid texture object. So that situation is remedied. Back to work.

Comments: 0 - Leave a Comment

Link



Friday, December 2, 2005
While trying to debug a texture loading issue, I dropped some code in to the game loop to render a textured quad. Once the bug was squashed and all was working as expected, I deleted the code. A few minutes later, when trying to display my font bitmap from within the font module, it wasn't showing up. The first place I looked was the game loop since I had just deleted a chunk of code. Sure enough, I had zapped two lines that called glfwSwapBuffers and glfwSleep. I added them back in without any extra thought.

So now the font bitmap displays all pretty and nice. Great, thinks I, it's loaded properly and I am now ready to start implementing text rendering. But wait! The escape key isn't closing the app like it should. What's up with that? Oh wow, and the close button is sluggish. Why us all of this going on suddenly?

Once I got the app closed, I check the error log. One line stood out: "Opengl error while deleting texture [name][id]: Invalid Operation". This struck me as extremely odd. So before the call to glDeleteTextures I added a validity test: if(!glIsTexture(tex->id)). Next run, I see this in the log: "OpenGL says texture [name][id] is not a texture object". And to top it all off, the printed id matches the id that I logged when the texture was loaded.

At first glance, this looks like an issue with an invalid OpenGL context, the sort of thing that crops up from time to time when doing multi-threaded loading and rendering. Unfortunately, I'm running a single threaded app. I'm also doing nothing to change the context. So next I assumed I had some sort of memory problem somewhere. The debugger gave me no clues, neither did the mem tracker. I thought about adding a feature to the mem tracker to test for overruns, but I decided instead to take search the net.

After quite a bit of searching I came up empty handed and hit the sack. Today, I came back to the problem with a fresh perspective. I did some more searching. At one point, I considered installing the evaluation version of gDEBugger. Ultimately, I opted to work through the code by commenting out different sections. The result surprised me.

The problem turned out to be the call to glfwSleep. When I had added it back to the main loop, I did this: glfwSleep(1). It's fairly common on Windows to call Sleep(1) rather than Sleep(0) at the end of a loop (there's a good timing article somewhere that explains why, but I lost the link in a Firefox crash). The problem with that is that glfwSleep the type of the parameter is a double and it represents seconds, not milliseconds. I already knew this and had implemented it properly the first time, but it slipped my mind when I added the call back in.

So now things work perfectly (in the current state anyway). The texture and font loading code appear to be bug free, there are no memory leaks, no crashes, and no problems jumping out at me.

I reworked the memory manager a bit as well. What's funny is that each refactor brings it much closer to Peter Dalton's implementation, on which it was based. I thought that my implementation was a great simplification of his. Turns out it was probably too simple to be useful. I'm sure I'll be implementing overrun detection before I'm done. I also added two sets of memory statistics to track. One set is to make sure that the memory tracker itself isn't leaking anything, which it currently isn't - but who knows what will happen when I modify it again. The other set tracks individual allocation sizes. Currently, I'm only tracking the smallest and the largest, but as the project progresses I will add ranges (<32kb, 33-64kb, 65-128kb, and so on). Later, I can use that to optimize allocations if I need to.

How wonderful it would be to spend a solid day coding and not introduce any new bugs. Next up: text rendering.

EDIT: Where are my manners? This is the first graphically visible step on the project. Here's a screenie:

Font Bitmap Display



Comments: 0 - Leave a Comment

Link


All times are ET (US)

 
S
M
T
W
T
F
S
1
5
6
7
8
9
10
11
12
13
14
15
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31

OPTIONS
Track this Journal

 RSS 

ARCHIVES
June, 2006
February, 2006
January, 2006
December, 2005
November, 2005
October, 2005