Sunday, February 17, 2013
Summary
Heh, well, you may or may not be excited to know that today was yet another day of battles...sadly, I haven't the time to write in as much dramatic detail as yesterday
For the greater part of the day, I worked on memory. I've been too lax about deallocation of memory for a while now. Part of this is a result of the fact that, often times, deallocation is not necessary. An interesting - albeit not necessarily popular - fact is that there's really no reason to clean up systems that last for the span of the program. In fact, doing so is actually wasting CPU time. Ever closed a game and had to wait for many seconds while the game closed? Yeah, probably because they were very careful to deallocate memory. Strictly speaking, it is purely a waste of time, and the game would do just as well to print a message that says "wasting your time" and make a call to Sleep(). All modern OSs will free the memory allocated by the program regardless of whether the program deallocates it. Still, there are advantages to performing strict deallocation. If you do so, then you can easily find leaks, because you can just find anything that wasn't deallocated by the time the program terminated, and that qualifies as a leak. It took a long time to re-work the memory system into something stricter, and it's still not done, but I've already got a better handle on the game's memory usage.
Other than that, I'm still working toward this unified ship interface. Today I was able to leverage some of the "generic programming" functionality won in yesterday's battle to do some neat things, like properly tie the opacity of rendered views to the opacity of the widget containing them. With the new functionality, it takes no effort to do so in an automatic way. The result is that things like the command interface can smoothly fade in and out rather than just appearing and disappearing sharply. I like for things to be smooth, and I think you will find that most such transitions in LT are smooth
Speaking of the user interface, I am still uneasy about it. Not the visual design/organization style that it uses, which I do like, as I've laboriously described in previous logs - it's very dynamic and intuitive. But the code structure makes me uneasy. There is no clear design pattern that is being leveraged. This is probably a result of the fact that I went for a traditional inheritance hierarchy (ew.) for the UI rather than a component design (which the rest of the engine uses). I realize now that, even for seemingly-smaller tasks like a UI, it probably still pays to ditch inheritance altogether and go with the more elegant component option. I can see a lot of things that would become more beautiful under this system. Sadly, I'm not sure that I'm up for a total rewrite at the moment.
Sorry for the lack of linguistic excitement in this log. I'm sure medieval Josh will come around again someday
Hour Tally
Coding: 5.21
Composing: 1.30
Internet: 3.05
Testing: 0.93
Total Logged Time: 10.48
Post
Mon Feb 18, 2013 12:31 am
#1
Week of February 17, 2013
“Whether you think you can, or you think you can't--you're right.” ~ Henry Ford