Curves and Helixes

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)…




As you can see, so far I’m just messing around with boxes and writing code to handle mouse interactions within the orthogonal views. The greenish colored box will be for a 3d preview. Shouldn’t be too difficult, but what I would have really liked would have been to render using the Curve rendering engine. I still have to do a bit of research, but it looks like it might be very difficult to interface between the two as Curve is unmanaged C++ code and Helix is managed C# code, not to mention throwing unmanaged DirectX 9c and Managed DirectX into the mix.

Oh, and finally, I’ll be doing some final patch work on FTPX after a short trip to Canadia. Nothing too difficult. Also, I’ve actually been able to port the FTPX code from wxDevCpp to VC++ 2005 fairly easily, so I have a better and faster compiler to work with. I still have to do the form design work in wxDevCpp, so it’s not ideal, but it’s better than before and I don’t feel like bashing my head into the monitor as much.

oh, almost forgot, here’s simple logo for Curve I whipped up in a few seconds…



This was actually extremely easy to do since 99% of the design is in the font, which is Amerika Sans, btw; so thanks to whoever created the font. I was experimenting with different lighting, shadows, etc., but I decided to stick with something simple. Also, making it darker makes the edges (which are a yellowish glow) stand out too much and making it lighter makes it seem too cartoonish (as the blue becomes lighter). And doing a combination of light and dark just looks stupid.

well, that’s all for now. later.


FTPX

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:




RexUtil 1.4

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 🙂


Portfolio, Resume, and Visual Web Developer 2005

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.


Doppler rename and something about shoeboxes

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.


Doppler Redesign for Beta 2

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 🙂


xstr 3.1

xstr has been updated with some minor changes. I haven’t updated the xstr page, but the download links point to the new version.


Random Thought: Bilinear filtering of images by web browsers

It’s always troubled me as to why no web browser (well, none that I know of anyway) does bilinear filtering of images. The thought hit me again yesterday when I posted the screenshot of RexUtil. Granted bilinear filtering is more expensive than nearest-neighbor filtering, but even on what would now be considered a low-end CPU, bilinear filtering should be fairly fast. In fact, IIRC, software-based bilinear filtering was done in realtime by some older games including Unreal and Unreal Tournament.

In addition to the visual improvement, bilinear filtering may also result in less web space usage (no extra space needed for thumbnails) and less time spent by a user to put an image on page (no additional work/time required to make bilinear/bicubic-filtered thumbnails). Of course this wouldn’t always be the case, since there are other reasons for using thumbnails (e.g. they allow you to view a gallery w/o downloading all the full-sized images). However, all in all, I think bilinear filtering would be a nice addition to a web browser.


Rex stuff is finally up

All the rex stuff is now up, including the specifications and RexUtil 1.0. I’m considering updating the NZ engine to use Rex files instead of the Quake 2 PAK files it currently uses. Although I don’t know if it’ll be work the effort.

Anyway, here’s a screenshot of RexUtil:


xstr 3.0

The new, revised and improved version of xstr is up. I’ll be updating the xstr page with more information soon, particularly documentation; however, using the class and most of its member functions should be fairly simple even w/o any documentation.