semi/signal

A few days ago I started thinking about 2d game engines and games that run at fixed (and typically lower) resolutions (e.g. Starcraft). Many older 2d games have no choice when it comes to running at a fixed resolution b/c if the game ran at a higher resolution one of 2 things must occur:

(1) a larger portion of the game world is rendered. This can break many of the gameplay mechanisms of the game and/or decrease the difficultly of the game as the player is able to see more of the game work w/o moving the camera. This can be especially disastrous for multiplayer games where different players may be running the game at different resolutions. Another downside here is that units (which are 2d sprites), although still in proportion with the game world, appear smaller. It should be noted however that some games (typically strategy games, where you have a fog-of-war, such as Age of Empires) have supported multiple resolutions in this way.

(2) The second option is that the game’s rendered output is scaled from its original resolution. The higher the new resolution and the lower the original resolution, the worse the game looks. This is what’s done by LCD screens, since they have a fixed resolution.

Well thinking about 2d games and the fixed resolution problem got me thinking about how a modern “2d” game engine (2d only in terms of gameplay), targeting contemporary hardware, could be designed so that it could run at any resolution? Well if all the units are 3d models, the sprites used are for things such as particle fx – which will typically scale well, and the environment is either a 3d terrain or scalable 2d tiles, the resolution issue seems somewhat solved, as you can go to a higher or lower resolution gracefully … well, yes and no, there’s one other thing you have to consider that will affect any type of rendering engine …

As LCD monitors continue to grow in popularity, the new models have a certain oddity about them; they don’t conform to the historically popular 4:3 aspect ratio that many developers have depended upon. The popular resolutions now seem to be 1280×1024 (5:4) and the wide-screen resolutions such as 1920×1200 (16:10). Of course if you want to target, or eventually target, output to an HDTV you also have to worry about the HD resolutions, 1920×1080 or 1280×720 (16:9). The problem with multiple aspect ratios is that, unlike multiple resolutions at a given aspect ratio, you can’t gracefully go from one aspect ratio to another and retain the look of what your rendering, you have to letterbox/pillerbox the output, stretch the output, or modify the field-of-view (FOV).

Modifying the FOV seems to be the “right thing” to do, but this can lead to problems similar to (1) above, where players with wide-screen monitors can see more of the game world than those with normal monitors, giving them an unfair advantage.

So what’s the solution? I’m not sure. I came across this forum thread a while back (the only one I could find thru google) where 2 posters reply that the stretching really isn’t noticeable (I don’t have a wide-screen monitor, so I can’t give an opinion). FOV may or may not be an issue. Some people find letterboxing and pillarboxing annoying (pillarboxing does annoy me, but I’m comfortable with letterboxing).

Finally, one solution not mentioned is smart stretching. The HDTV my parents have does a smart-stretch on standard definition content, where it, I think, stretches the pixels further away from the center more than it does the pixels that are closer to the center. It actually looks really good and greatly minimizes (to the point where it’s not noticeable) the “squashed-down” look you’d get from running a standard stretch algorithm on a 4:3 picture.

That’s all for now 🙂

I finally got around to creating firesync, a file synchronization utility. I’ve been using (and testing) it over the past few days and so far I’m really happy with how it’s turned out.

I previously messed around with file synchronization when I created Doppler. Dopper didn’t quite live up to my expectations. It’s architecture and functionality was overly complex, and the result was a fairly unstable and bug-ridden piece of software. In contrast, firesync has a much simpler, or I guess I should say more structured, architecture, similar functionality, and is much more stable and usable.

One of my goals for Doppler that didn’t translate over to firesync was the idea that files should automatically be sync’d and, at the same time, the application should remain invisible and not interrupt the user’s workflow. The way I attempted to do this in Doppler was to compute an md5 checksum of the file and compare it to a checksum computed earlier (that was stored in memory). Putting the thread responsible for this to sleep for a few ms after a checksum was computed was my way of trying to maintain low CPU usage. However, there are 2 major problems with this approach. The first is that computing checksums require reading a ton of data off the hard drive and there was a very large and very noticable slow down in system performance (since the cache gets changed because your jumping around the disk computing checksums). The second problem with this approach is that even for a handful of files, it takes an increadibly long time before all the files are sync’d since the thread is going to sleep so much in order to keep CPU usage low.

firesync doesn’t compute checksums and only uses the file’s last modification date/time to figure out if one file is older than another. I was actually surprised at how fast I was able to get the last modification date/time, as well as other file attributes, (it looks like windows caches them) and it makes the sync operation very fast. In addition I threw the idea of automatic sync’ing and, consequently, low CPU usage out the window. However, given how fast you can get the last modification date/time, automatic file sync’ing might be something fun to try in the future.

Anyway, so far I’m really happy with firesync in almost every respect – interface, functionality, performance, etc. and I’m considering taking the lessons I’ve learned and doing a new backup utility, as Shoebox Backup hasn’t quite lived up to my expectations either; but that’s a while away, it’s back to game development work for now.

oh, and of course, a screen shot…

I came across an interesting article on Next Generation yesterday that talks about a study that divides of gamers into 6 classes instead of the standard 2 (hardcore and casual).

• Power gamers: This group represent 11 percent of the gamer market, but accounts for 30 cents of every dollar spent on retail and online games.
• Social gamers: This group enjoys gaming as a way to interact with friends.
• Leisure gamers: This group spends 58 hours per month playing games but mainly on casual titles. Nevertheless, they prefer challenging titles and show high interest in new gaming services.
• Dormant gamers: This group loves gaming, but spends little time because of family, work, or school. They like to play with friends and family and prefer complex and challenging games.
• Incidental gamers: This group lacks motivation, and plays games mainly out of boredom. However, they spend more than 20 hours a month playing online games.
• Occasional gamers: This group plays puzzle, word, and board games almost exclusively.

Not really sure where I fit in here. I guess I’d like to think of myself as a power gamer, but given the amount of time I usually spend writing code instead of playing games, I’m probably more of a dormant gamer, and I have found that when I have to or want to focus more on coding, school, etc. I tend to play games where I don’t need to spend hours to finish a level. So I usually play an FPS or some type of action game (Quake 4, UT2004, or, recently, Freespace 2) instead of an RPG (still haven’t finished Guild Wars: Factions or Planespace Torment, and I haven’t touched either lately) or RTS (I’m half-way through Homeworld 2 and I’ve had it for over a year; however, to my credit, it is a very difficult game).

I really hope that the result of this study is that more is spent towards advertising games. Analyst Michael Cai states that “…Dormant gamers who are not heavy on gaming time actually have fairly good gaming motivations and spend a high dollar/gaming hour ratio. The key is to design games/services that fit these peoples’ lifestyles, maybe snack- or bite-sized games. On the other hand, the leisure gamers spend a lot of time playing casual games yet pay little money. They are ripe for game-advertising solutions.” I’m not sure I agree with him about making “bite-sized” games; while I don’t always have time to play an RTS or RPG, I’d hate for the experience to be cheapened and/or shortened when I do get the time to sit down to play. However, I think advertising is something that is sorely lacking in the video game world. It’s a fair assumption that power gamers read gaming websites, magazines, etc. and as such are exposed to previews and ads of upcoming and released games. For everyone else, it becomes a chore to find out what the latest releases are; there are virtually no TV commercials, no magazine ads outside of gaming mags (even tech mags like Wired, which on occasion does features on gaming, doesn’t have gaming ads), no billboards, no radio commercials, hell…outside of gaming websites you’d be hard pressed to find a game ad. There are exceptions of course – the new super mario bros, grand theft auto (all of them after and including 3), and halo 1/2 come to mind, as each had quite a bit of TV coverage, but I think more games need to be given the same (or better) treatment.

I think I’ve finally settled on what the interface will look like. All the standard geometry manipulation stuff is already implemented (translate, scale, rotate). I’ve added a resize tool , which is like the scaling tool, but allows you to stretch/shrink the geometry by using handles on the sides of a bounding rectangle/box that encompasses the geometry. Next up I’ll probably add more primitives, begin working on the 3d preview, add support for light entities, and file saving/loading support (so I can have some data to work with in Curve).

I’ve also been trying to find some info on CSG (constructive solid geometry); this is what allows you to carve one primitive from another (the boolean difference operation). You can also add primitives together (boolean add) or get the result of the boolean difference (boolean intersection); however, carving is probably the most popular and important for a level editor. So far, the only useful information I’ve found is this QA on Flipcode. This is really helpful, but I think I really need something that goes into more detail. I’ll have to see if I can get my hands on either of the two papers mentioned in the QA.




oh, some of the icons used are from http://www.famfamfam.com/. They’re the work of Mark James. The icons in the lower left (the cyan-ish colored ones) are ones that I created (just messing around with wingdings font and photoshop).

Well, I’ve been busy with school over the last few months, so that’s why there hasn’t been any updates, but now I’m finished, completely finished! I’ve graduated and I now have my B.S. in computer science; although, I think, I don’t actually get the diploma until sometime in August. Anyways, I’ll be looking for work now and hopefully I’ll be able to land something in the gaming industry.

I’m been keeping busy working on some new projects. First up, Curve, a 3d graphics engine (or, I guess, 3d game engine would be the more appropiate term as I plan to have components that handle more than just rendering). This is something I’ve wanted to start for a long time but never really got around to b/c I would busy with Nemesis Zero, school, FTPX, Zerospace, etc… It’s still in the very preliminary stages of development, but I’ll post a screenshot anyway…


The screenshot basically just shows a simple render of the big ears head that comes with the DX SDK and me messing around with vertex shaders and HLSL (the model warps on the z-axis and the colors “move” – just sin/cos stuff). Things are going somewhat slow b/c I’m focusing more on the engine architecture rather than making a flashy tech demo. What I’m aiming for is to create somthing that’s robust and reusable; moreso than the Nemesis Zero code, at the very least.

I look back at some of the Nemesis Zero code and I cringe and how horribly hack-ish everything looks and almost none of the NZ code can be used in another project without major bits of modification (I know first hand, as the input system for curve is derived from the NZ’s input system). However, I really have no regrets, NZ was a great learning experience; from NZ I know what a lot of the architecture design issues in curve going to be and how to solve them. Curve is probably going to have it’s own set of design issues and probably its fair share of hack-and-slash code as well, but, whatever, you live, learn, write better code.

The other project I’m working on (yes, there’s another, actually 2 more, read on…) is Helix. Helix is the accompanying level editor for Curve. I really couldn’t find a decent editor that had the features I wanted, so I decided to make my own. This is a fairly big project as well and might turn out to be as big as Curve. There’s so much to deal with in terms of user interaction and there are, of course, a whole new set of design issues as well. Still in the very preliminary stages (even moreso than Curve)…

Long time since my last update, but I’ve been silently updating certain aspects of this site. In particular, the Firefly page is up and the Shoebox backup page is up. I think I’m picking up a knack for this web design thing. The pages I’m creating now are still fairly simple, but they certainly look better than anything I was able to do a year or so ago.

In other news, I got a little job through Nilesh to make an FTP client for uploading photos. I would have loved to do this in C# with the .NET Framework and WinForms, but since this has to be supported on Win 9x and it has to be available to novice users who just want to fire up the exe and don’t like scary dialogs asking them to install the framework, I had to resort to other measures. I ended up choosing wxWidgets and working in wxDevC++. It’s no where near as nice as the stuff from MS, but I’ve found it to be pretty solid in terms of features and fairly easy to use as well. My one major pain on the this project so far has actually been the compile time of wxDevC++. It’s increadibly slow and even making a small update requires a fairly significant amount of time to build the executable.

I’ve also found it difficult to find an SFTP client library. What I’m currently doing is using the PuTTY source, the PSFTP component and writing a wrapper on top of it to simplify file transactions. This approach is working well despite some headaches and ugly code with trying to interface between C++ and C code (I left the PSFTP code to compile as C source files, since there appears to be some hardcore C stuff in the PSFTP source and I was afraid of what things would break if I converted everything to C++. When I get a bit more time I will see if I can do a pure C++ compile however).

Anyways, here an early preview shot of FTPX:

Finally got around to fixing a ton of bugs in RexUtil; most of which I discovered when I began integrating the Rex code with the Firefly code. Errors in compacting the memory holes caused by deleting files were the biggest headaches. Aside from not filling the holes correctly (and being left with a file that was bigger than it should be), I also wasn’t correctly updating the file offsets in the file list (eek!). So after deleting a file, a fair amount of the other files in the archive were left inaccessible and corrupt (trying to access/extract them resulted in going to the wrong offset and reading/writing the wrong bytes).

Anyway, RexUtil 1.4 is up which I believe fixes all the major problems with RexUtil and updates the Rex format to make it more flexible and expandable in the future. Yea, I did sort of jump version numbers as there was no RexUtil 1.1, 1.2, or 1.3. I have no good reason for doing this other than to help me keep track of what versions I had flying around between my PCs; build numbers would have been a better idea.

Oh, and the Rex page has been updated with a nicer design. Nice and pretty, with a new logo for Rex/RexUtil 🙂

wow, it’s been a long time since my last update. Been feeling very lazy lately; guess I’m just recovering from finals (my last one was last friday, being postponed due to the NYC transit strike).

In any case, I did make time to finally update my resume and portfolio. The resume update was fairly easy. As for the portfolio, since I changed the design, this update was fairly involved and time consuming. In the past, I’ve used Frontpage 2002 to do most of my web pages, but I’ve switched over to Visual Web Developer 2005 Express (fyi, available free until Nov. 2006). Even though it’s made for ASP.NET projects, it’s a very competent HTML editor as well; much nicer than Frontpage.

I also got a chance to toy around with Javascript a bit when making the function that opens a popup window to display the full-sized screenshots. Seems like a nice, little scripting language; however, Visual Web Developer doesn’t seem to support features to edit/debug scripts. So, my workflow was something like: write code, view web page in browser, open javascript console to see errors/warnings, update code, view web page in browser, … This wasn’t a big deal for the simple stuff I was doing, but for larger javascript projects, I can just imagine how painful it would be to deal with such a workflow.

I found out that there is a popular podcast aggregator called Doppler. So I’m thinking renaming my Doppler to Reflex. However, I googled Reflex and found a few software apps with that name as well. So I’m not sure what to do now. Maybe something like ReflexSync or DopplerSync? Who knows, coming up with names it hard work 🙁

On another note, one of the original uses of Doppler was going to be for automated file backups. That is, whenever a file was updated, the file would be automatically copied and updated on another drive, folder (hmm, backup to a folder on the same drive seems dumb), whatever. Anyway, I was thinking of making an application to perform this function. Of course, again I’m faced with the daunting task of coming up with a name. I saw a christmas card I got on the floor the other day (the floor is, of course, the ideal storage location for christmas cards) and on the back was “shoebox” (which I now know is a “tiny little division of Hallmark”). I thought to myself that that would be a really cool name. I googled it and found there’s a photo organization app for OS X called shoebox. Bummer, but maybe I an append or prepend something to the name.

I ended work on Doppler Beta 1 (B1) a little over a month ago. The goal was for Doppler to be an automated file syncronization solution and, as a bonus, would also provide functionality for keeping backups. Since then I haven’t used Doppler at all! I don’t even keep it running in the system tray. Needless to say, Doppler B1 is a failure. So before starting B2, I thought I would look over the Doppler’s failure with a critical eye and redesign it from the ground up. Here’s what I’ve come up with so far:

• The ultimate goal of B2 will be simplicity. Support for backups will be dropped, as well as the plans to implement file versioning. Doppler B2 will be strictly and simply an automated file syncronization application.
  
• Doppler will no longer keep its own “file system” (the /fsroot directory that mirrors all synchronized files).
  
• The Doppler application will function implicitly as both a server and a client. Instances of Doppler on a network will be referred to as Doppler Nodes. (hmm, starting to sound a lot like P2P)
• Each Doppler Node will have a username/password combo that it uses to connect to remote nodes (done automatically). This username/password combo will also be used to authenticate connections from remote nodes. Therefore, a network of Doppler Nodes will all have the same username/password information.
• Username/Password information will be entered when Doppler is first installed, and the user will never be prompted for this information again unless the user chooses to change this information.
  
• Users will no longer be able to/have to setup directories for syncronization nor setup directory mappings from an /fsroot directory to a another dir. on the hard drive.
• Only the system’s “My Documents” directory, and all its subdirectories, will be synchronized. This simplifies much of the operations of Doppler (e.g. no need to worry about directory mappings since another My Documents folder is guaranteed to exist on the remote system) and allows Doppler to be more automated, requiring less interaction with the user to get things up and running.

And some of the more technical changes:

• The FileSystemWatcher will be used instead of looping through all files in a directory. It should be far more efficient and since only one, specified, directory (“My Documents”) will be looked at, its usage should be trivial.
  
• Doppler B2 will use a more standardized interface. The current setup on the main form involves switching between multiple panels. The code to handle and maintain these panels, as well as designing and positioning these panels is a pain in the ass, and its simply not work the effort.

Now to start coding 🙂