Spent most of Sunday setting up my wife's official business web page. I think it turned out quite well. We tried to keep it simple, and not as stuffy as the web pages of other engineering firms. She made good use of the Whip plug-in (which is basically Acrobat for CAD drawings) to show off her work.
It's at www.civilgrrl.com. Be sure to let us know if you've got any comments. Shelly's a big advocate of getting girls to pursue science-oriented careers, so she plans to greatly expand the "hobbies" section with pictures of her favorite rocket launches, and she'll probably also add a developer diary. It'll take some work, but I think she might very well end up with the only civil engineering site on the web that's actually interesting :)
One neat free utility I found is called Buttonz & Tilez. It's a little wizard that lets you make buttons for your web page. The nicest thing about it, though, is that once you've got your button designed, you can just hand it a list of captions, and it will generate all of your GIF's in batch-mode. We used it for the blue buttons on Shelly's page.
Finally, the "Wonder Woman by Ruben" logo isn't quite complete. The designer, comic artist Shannon Wheeler, is gonna get rid of the wonder woman costume so the comic book cops don't get bent outta shape. Shelly found the original WW picture on Wheeler's page and loved it (her quote was "It's me in a Wonder Woman costume!"), so she wanted him to do a civil engineer version.
Just signed myself up for the GDC Austin RoadTrip. If you're there, be sure to say howdy.
Someday I'm gonna have to put together a presentation for these things. Looking at the list, I see a couple of presentations that I know I've seen before. If I put together a presentation on how to make a game for peanuts, I could probably recycle it over and over and get into all of these conferences for free :)
Taking a break from game-programming for a couple of weeks. I've got a pal who's got a fine product, but needs somebody with programming skill so he can improve his implementation. I'm putting together a couple of applets for him that'll help him get started. This is the first time I've done any production code in Java, so I'm a bit daunted.
Interestingly, the biggest hurdle I had wasn't the lack of pointers, it was the declarations. You've gotta new a class in Java, no matter where they are. I think I'm over that now. I've got a couple of security issues I'll have to handle, but I figure I can solve 'em.
I'm also gonna have to have a little server-app that'll need to run 24/7, so I'll have to find somebody to host it for a few bucks. I figure if that's my biggest problem, then I'm in good shape.
Just found a genuinely-interesting piece of software. It's an add-on to Visual Studio called RadVC, and it's very impressive-looking. Basically it's a Visual Basic clone interface builder that works with VS. I haven't tried it yet, but the interface looks like a duplicate of VB.
Wondering how they did it, I took a look at the specs. It appears that they've built a buncha classes on top of MFC that add interface widgets and properties (Form, Label, etc.) that look like VB. Their interface-builder works with those classes to make something that looks like VB, but uses C++.
I'm giving this tool a hard look. One thing I liked about my old class-library, StarView, was that building a user-interface was so simple that I could hack together a quickie utility in an hour. MFC and ClassWizard never came close. It appears, though, that these folks might've come up with something that finally equals and even improves on my old standby.
Note: Yes I know that Inprise C++ Builder and even the old Optima++ have the same motif. I'd really rather have an add-on for my old tried-n-true compiler than to have to defer to a different compiler every time I wanna write a little quickie file-filter.
The previous mention brought up a thought. . .
Remember Optima++? About three years ago, that was the tool that was gonna take over the industry. Sybase spent a lot of money to build a very cool VB-style user interface coupled with the very nicely-optimizing Watcom C++ compiler. It appeared in stores for a few months, got a few decent reviews, then fell into obscurity. It still exists as Power++, but it never became one of the big players.
Ditto for Symantec C++ for Windows. Symantec proudly stated that, after buying Zortech, that they had the finest compiler and IDE programmers around, and they were gonna do what it took to take over the market. They spent a lot of effort to make a compiler compatible with Visual C++, and their user-interface was a winner. That, however, didn't keep it from fading away within a year. Symantec still has a page describing it, but there hasn't been an update in over three years.
Even more interesting, however, were the VB killers put out by Oracle and Computer Associates. Oracle put out a tool that was a virtual duplicate of VB, but ran on the Mac as well as Windows. While an interesting product that would certainly have had a market (if only to folks who wanted VB on the Mac), it seems to have disappeared without a trace.
Computer Associates also released their own tool. While it looked a lot like VB, it had some important improvements. For one, the language was extended to be fully object-oriented. Second, it was a true compiler, using their Clipper technology and pre-dating VB's compiler by at least a year. While I was able to find a page about it, it's obviously well on CA's back burner.
I'm just wondering. These products certainly cost the developers quite a lot of money to make. What was it that doomed these products to obscurity while other similar products, like Delphi, actually got a following? Was it a lack of advertising? Was it a negative perception of the companies? Was it a failure to capture the imaginations of the user communities (which Delphi certainly did)? Was it just a frighteningly clogged market that was unable to support that many products?
OK, this is something I've been thinking about for a while, and today's the day. I'm adding a new item to my long-running list of "things game developers should and should not do". My item for today is a misquote of Jeff Goldblum's annoying character in Jurassic Park. . .
As far as user-interfaces go, just because you can do something doesn't mean you should
This is something that's been bugging me with products nowadays. It's especially true of big companies with competitive products. In an attempt to be competitive, they're allowing tons of feature-creep into the apps, and we're ending up with apps that are a big mess!
There's no better way to show off this problem than with the media players out there. There are three major media players out there (two if you're not using Windows). First, there's the Windows media player that comes with Windows. Here's the latest version. . .
It's fairly simple, and it's easy to figure out the first time. The area with the big logo is where the video plays. The controls under the video are fairly self-explanatory (except for that three-line thingy next to the volume control). The volume control's use is obvious. If you hover the mouse over any button, it'll tell you what it does.
My only complaint is that toolbar under the menus. It contains buttons that link to Microsoft's web sites. Given that the Windows media player has a "Favorites" menu that works like your browser's bookmarks menu, why add extra buttons to duplicate this functionality? Why not just put up "radio", "music", and "media guide" as pre-defined bookmarks?
Anyway, that's a minor complaint. Otherwise, it's downright easy to figure out. Let's move on.
My next example is Real Inc's RealPlayer. . .
Uh oh. Things are getting busy here. The play-controls and volume are still pretty obvious, but they felt the need to spread 'em out. The big problem here, though, is that there are no fewer than five different places where you can click-through to sites. First off, there are TWO menus which contain links. The "Presets" menu works like your browser's bookmarks menu. The "Sites" menu is basically the same, but you can't change or add entries. The panel to the left of the video window contains even more bookmarks. Finally, there is a way to search snap.com (because I often feel the need to search the web from my movie player) and YET ANOTHER button that takes you to yet another list of bookmarks. Why?
Another problem with this program is that they decided to do cute things with the non-client area. Even though I don't have gradient title-bars set up, RealPlayer decided that they're smarter than I am, and they added a fade-to-black in my title bar. They also decided that the System Menu in the title-bar was a lousy idea, so they replaced it with their icon. Why?
Finally, the player emits a noisy flourish whenever it is launched. I don't know why it feels the need to remind me that I've launched it.
Finally, we've got the newest and worst offender. Apple's newest QuickTime player. While Apple's earlier players were a model of user-interface simplicity, their new player is an example of "think different" run amock. Check this thing out. . .
What the hell? First off, Apple has apparently followed McDonald's lead in unlabeled signage, apparently feeling that their users cannot read. The interface is blissfully free of anything that would indicate what anything does.
Next problem is the volume control, which is on the left. While the volume indicator may be obvious, the way you set it is not. You must grab that little gray wheel and turn it, just like a little volume control. While it is cute, it's less obvious and more difficult to use than the slider used by the other players. The controls, while sparser than the other players, are also more difficult. There's no stop button, rewind, or fast forward.
Firthermore, the title-bar isn't just modified, it's gone! Apparently Apple found that users didn't like that whole "minimize-maximize-hide" thing, so they just put a close-box in the corner and eliminated everything else.
The worst problem, however, are the bookmarks. While Apple admirably got away from Real's policy of "bookmarks on every flat surface", Apple did manage to make a bookmark scheme that's slow, cumbersone, and miserably hard to use. Right under the big "play" button, you'll find a tiny handle. If you drag this handle, you pull out a drawer (really!) that contains little unlabeled windows that are your bookmarks. It's a miserably bad motif that manages to not only be more difficult and slower than a browser-style hotlist, but also took a lot more time to develop. Good work, Apple!
The other handle on the right of the drawer is used to resize the window, getting away from their own little motif.
Finally, there's a second "hidden" drawer that's in the same place as the hotlist-drawer. It actually contains the controls for fast-forward and rewind. Apple apparently felt that their users are too dumb to figure out how to fast forward and rewind, so they hid them.
OK, back to my point. Just because you figured out how to write to the non-client area of your window does not mean that you should. Just because you figured out how to launch a URL from your app doesn't mean that you should. Just because you thought up a really cute control doesn't mean you should use it. If you need a scrollable field in your game, use a plain old scrollbar rather than an escoteric slider that mimics the look of your game. If you need the user to click something to continue, use a plain old rectangular button. Forcing the user to learn an entirely new user interface right after he's figured out the user-interface of his computer is just rude.
As far as interface goes, my rules are. . .
Whenever possible, use native controls (button, scrollbar, checkbox, etc) or controls that mimic the function of the native controls. Users already know how to use 'em.
If you've got a particular function that doesn't fit with native controls, try to make it as simple as possible. Don't automatically mimic a real-world control (like a round volume knob), as people don't interact with the real world with a mouse.
If you've got an idea for a terrifically cute, yet useless, interface element, and you feel like you're gonna pop if you don't add it, at least give the user the ability to shut it off.
If it slows things down, dump it. Trust me, it's just not worth it.
Don't add gratuitous colors and bitmaps to controls, thinking that it'll make things easier.
Finally, USE WORDS! Your users know how to read. The old adage "a picture's worth a thousand words" works in some cases, but not all.
More example of good and bad interface is available at the Interface Hall of Shame.
A way to view unicode strings in the debugger. When you quick-view (or simply hover the mouse over) an ordinary string, you are shown the contents of the string. Unfortunately, this doesn't work for unicode. The only way to view unicode strings in the VC++ debugger is via the memory viewer, and even then it's not as nice.
A warning for variables that are unused in a class. VC++ warns if you have an unused variable in a function, but not in a class. This might be something that appears if you crank the warning level up, but I doubt it.
Give up on the Class Wizard. It was a halfhearted effort to duplicate the neat editor motif of VB/Delphi/C++Builder, but it just never worked that well.
The bitmaps are working beautifully. It took a bit more debugging than I thought, because I had a nasty bug in my String class that was causing an endless loop when reading in the high scores. One-bit bitmaps still aren't working, but I don't even know if I'll use that mode. The other modes (2bpp, 4bpp, and 8bpp) work just fine on my little Uniden UniPRO test critter.
One problem I see is that nothing in the world (except for MS Paint for CE palmtops) supports the new 2bpp BMP file format. It was something created for CE, so it's not very widespread. I've been toying with writing a Photoshop import/export filter that'll handle 2bpp BMP files. In the latest version of JTGame, the author wrote his own little filter to write custom bitmaps, so I've got some nice source code to cannibalize. I looked at it just a bit, though, and the Photoshop API looks like a bear to program. Because I'm a lazy bum, I might just write a little command-line utility that converts 4bpp bitmaps to 2bpp. We'll see.
First off, I've got a utility you need if you've ever used the Windows character map applet.
It's Character Map Pro, and it's everything I look for in a utility. It's reasonably small, requires no extra DLL's or even an install program, and it's much better than the one that comes with windows (i.e. it's resizable, has a separate preview window, and can automatically copy if you double-click). All in all, if you've ever used Charmap, there's no reason you shouldn't replace it with this one.
Did a lot of debugging on my CE rasterizer. It's now working in 8-bit and 4-bit modes. 1-bit mode isn't working on the emulator, and 2-bit mode will not work on the emulator, as the emulator doesn't support 2-bit bitmaps. I'll need to actually test these modes on the device. Not looking forward to that, as debugging over the serial port is every bit as fast as it sounds.
My eventual goal is to have four different resource-only DLL's that you can choose from. They will support 1-bit, 2-bit grayscale, 4-bit grayscale, and 8-bit color graphics. The user can then pick the DLL that best supports your machine. For example, if you've got a color machine, you could choose the 8-bit color DLL for the best quality, or you could choose the others to save space. My goal is to have every DLL work with any machine by converting the bitmaps to screen resolution as they're loading. So far, it's working. Exciting!
Got a couple of good pieces of feedback on my stuff about stylus control. A couple of people made the same point, that control in a maze game should be "smart" and allow the user to tap a bit ahead and have the player follow the tap.
Interestingly, the real Pac Man game actually works this way --try it if you can find one locally. If your man, for example, is moving in a vertical channel, and you jam the stick to the right, it doesn't stop and face the wall. He'll continue up the tunnel until the first opportunity he has to turn right. Only when he's got an opportunity to turn, he'll turn.
That's why Pac Man probably felt a bit awkward the first time you played it. Once you got a "feel" for the game, you would anticipate turns and move the stick a fraction of a second *before* making the turn, and the man would move much more smoothly.
Incidentally, I do the same thing in a couple of my games, specifically ThinkTank and Suzy Sushi. When you press a direction key or move the stick, I set a flag called "IntendedDirection". On every move, I check to see if the user can move in that direction. If the player can't, then the player just keeps moving in the current direction.
What I'll probably do is allow the user to tap one turn ahead. For example, if there's a right turn coming up, the user can tap anywhere in the right-hand tunnel, and the man will turn when he gets there. It'll probably just be one of those things that requires some playtesting to work smoothly and easily.
Got the first cut of my new CE bitmap rasterizer up and running. Well, "running" is a bit of a broad statement, as the bitmaps currently look like burned mud. I've got so much bit-fiddling in there that I might be tweaking on this for a while.
When it's done, though, it should be nice. It's basically two classes, Bitmap and DrawableBitmap. Bitmap is just a tight little buffer full of bits and functions to copy and move the bits from one bitmap to another. DrawableBitmap looks exactly the same from the outside, but it's got extra functions to draw the bitmap to the screen. Even though they look the same on the outside, they're quite a bit different on the inside. A DrawableBitmap is currently a DIBSection, which is a Windows bitmap that allows you to futz with the bits. Eventually though, I could make it a GameX screen-buffer or a DirectDraw surface.
My goal is to have a single DrawableBitmap for the game. It'll be the size of the screen. Everything else will be my little custom bitmap objects that draw to it.
One idea I'm toying with is automatic portrait-landscape adjustment. Some games work better with a horizontally-oriented screen, but palm devices all have tall vertically-oriented screens. I've been toying with the idea of making a landscape mode that'll rotate bitmaps as they're loaded and will transform the X-Y coordinates as they're drawn.
It'd be fairly easy to do at the bitmap level. For the program itself, though, I'm not sure how I'd adjust things. For example, consider the screen layout for ThinkTank. For a vertically-oriented screen, I could simply tuck all of those score-boxes in a row on the bottom. I'm just wondering if there's a way for a program to look at the size and orientation of the screen and decide the best way to arrange things. It'd be awfully neat if I could just define the size of the rectangles and have the base classes automatically arrange them. I'll probably end up doing it manually, but it'll be an interesting challenge nonetheless.
While you're listening, lemme get your opinion on something. . .
Unfortunately, most palm devices don't have little joy-buttons like the Casio devices have. Most of 'em either have a horizontal row of buttons on the front or a vertical row of buttons on the side. Controlling something like a pacman with a row of buttons just doesn't work (trust me, I've seen games that do it). Looks like I've got two choices for directional control.
One way would be to have the stylus "guide" an on-screen object. For example, tapping above the pacman would make him move up. Tapping to the right of the pacman would make him move right, etc. It'd be pretty obvious to the user, but there's a chance that the user could obscure the screen with his hand while playing.
The other way would be to have a little on-screen graphical joystick that the user could control with the stylus. It'd require less stylus-movement and there's less chance that the user would obscure the screen, but it could be more cumbersome and less obvious. I'd also need to be able to move it to different corners of the screen to accomodate left/right handed users.
A quick annotation to the Paint Shop Pro update mention I made in the news page. If you buy any version of PSP before the end of September, you can upgrade to version 6.0 for free (OK, eight bucks with shipping). At Electronic Discount Sales, a D/FW discount computer chain, they've got copies of PSP 5 for only $25, which is even cheaper than the $49 upgrade price. You might wanna check out your local software outlets to see if you can find a similar deal.
On that note, I no longer like Surplus Direct. A couple of years ago, they used to be a great place to buy reconditioned hardware or old versions of software for great prices. After they merged with Egghead, though, they started getting away from what made 'em good. Now it seems like they're just yet another online computer store. Except for a small liquidation section, they just don't have it anymore. Given that PC Connection seems to have the ability to ship products before your finger is all the way off the "submit" button, I find that I just don't use 'em anymore. 'Tis a shame.
Just a quick note that I've officially crossed the line in the sand. That What Language Should I Use article that I wrote a couple months ago for gamedev.net (a small-time site run by a couple of development monkeys) was bought by Miller Freeman (a bigass company that runs gamedev.net's inferior clone, Gamasutra).
You can now read it here if you didn't catch it the first time around.
Thanks to an astute reader, I am now on my way to getting DirectX running again under NT!
If you'll remember a couple of days ago, I reported my DirectX-under-NT woes. Well, a helpful reader has pointed out that there is an unofficial DirectX 5 for NT available. I don't think Microsoft's too keen on this product escaping, so I'll just say that a search for nt4dx5.zip and a little legwork in a search engine will find the file for you. There were a few red herrings and dead sites out there, but the file is most assuredly available.
Interestingly, one discussion group mentioned that they were able to get DirectX 6.1 running under NT. I'll just be happy for now with version 5.
After a week of my venerable old mouse (a cheap Logitech Wheel Mouse, specifically) missing clicks and accidentally dropping items in the wrong place due to a failing button 1, I decided that it was time to retire it and buy a new mouse. I was gonna just buy an identical replacement when I saw that my local CompUSA had those new shiny silver IntelliMouse Explorers. Well, I couldn't resist the thought of a mouse with no ball and cool red lighted ground-effects, so I plonked down my cash.
So far, I'm really happy with it. Here are the pro's and con's I've found so far. . .
It's big. Really big. Bigger than their white mouse and a lot bigger than my dinky little Logitech. When you've got huge hands like mine, it really feels good.
The wheel is excellent. It's similar to the old wheel, but they molded little grooves into it, so it's easier to flick with your finger. The old mouse wheels got slippery if your fingers were wet.
The driver software is much better than the old wheel-mouse software. In the past, I had set up the Logitech software on Shelly's computer (which had the Microsoft wheel-mouse). The old Microsoft software limited all of the cool wheel scrolling capabilities to Internet Explorer and Office, while the Logitech software could use it pretty-much everywhere. The new software now allows wheel scrolling everywhere. So far, it appears to be every bit as good as the Logitech software.
The movement is superb. It had a little trouble with my old plastic Ouija-board mouse pad. I dumped that and tried it on my plain white desktop, and it works very nicely. Their optical technology really works. The mouse-pad industry's gonna feel the pinch if these things catch on :)
I'm never gonna have to clean a mouse again!
The color. Actually, I don't know if it's really a pro, but it cracked me up when I finally figured out what it looks like. It's sort of a satiny primer-gray. After looking at it for a while and trying to place where I'd seen the mouse before, I figured it out. It's exactly the same color as a TRS-80!
To quote my wife, "you've finally come full-circle" :)
The ground-effect lights aren't as cool as I'd hoped. The tail-light glows bright red, but you can't really see the glow under the rest of the mouse unless you have the lights off.
The buttons aren't as stiff as I like. I usually rest my fingers on the buttons while I'm mousing around. It seems a bit easy to accidentally press 'em.
They're expensive ($75). On the good side, though, their driver software shows that they're coming out with an standard mouse soon. From the picture, it looks exactly like their standard "melted dove bar" mouse, except it's got the tail-light.
Finally, this mouse is USB, and includes a USB-to-mouse port convertor plug. There isn't a 9-pin serial option for it, and it doesn't look like there will ever be. Looks like the old serial mouse has finally gone the way of the dodo.
On the games front, I've decided to make a new bitmap object that'll solve all of my ills. Basically, all bitmaps are gonna be an identical bit-depth (either the screen depth or a set depth you choose). As you load bitmaps out of resources, they'll be converted to the standard bit depth. This will make things like bitblt's much faster and easier.
I also figure that this way, I can support several different screens just by distributing a different resource-only DLL with the game. For example, I could have three different DLL's for 2-bit grayscale, 4-bit grayscale, and 8-bit color screens. The games could work with any of the DLL's, simply converting the bitmaps to the standard bit depth as they are loaded.
This'll also be handy for people who are trying to save on memory. If you've got a cool color handheld, but you don't wanna spare a lot of memory for games, you can just use the (presumably much smaller) 2-bit DLL. The games will be B&W, but they'll work just like the color versions.
If it seems like I'm really over-planning things, I am. I plan to re-use the hell out of 'em.
Amazingly, I actually had a good "I wrote this" experience today!
I was out at my local pack-n-mail, sending that copy of CodeWizard (see 9/1/99) back to the manufacturer with a note that would singe your eyebrows. In the course of chatting with the guy who ran the place, he asked what kind of games I wrote. I mentioned that they were discount rack stuff, and probably nothing he'd heard of. He commented that he didn't really know anything about computers, and the only games he played were some that he was given as a gift. He then pointed to the desktop of his computer. He was pointing at the big red "24" icon that was the icon of 24 Games for Windows, my original game pack!
At first, he didn't believe that I wrote the games he played every day. I then instructed him to bring up the "about" box and showed him that I was indeed the author. He was quite impressed, as he'd never met a real live author before. He started to mention his favorite game when I cut him off with "Lemme guess. . .Bulldozer". He concurred, saying that he was up to level 19. He asked if I had any sneaky cheat stuff in my games. I admitted that I have no cheat codes, and I don't normally give away Bulldozer passwords.
FWIW, if you are really stuck in Bulldozer, call Expert tech support. Last I spoke to 'em, they would provide Bulldozer passwords if pressed.
Secondly, kudos to Symantec for actually following through with their beta testers. About two months ago, they posted an announcement that they were looking for beta testers for Speed Disk for NT. Since I didn't have a disk defragmenter for NT, I signed up. I sent 'em a report on my disk usage, using a utility that they included with the beta. I tried out the product, but didn't really notice anything resembling a bug. It worked just fine.
Anyway, I got an email from 'em last week thanking me for the report and asking for my address. I got a bright yellow package today containing a copy of the shipping version. Nice work guys!
FWIW, it's a nice product that works very well. One big speed-thing that it does is defragment your swap file. NT, unlike Win98, uses a fixed size swap file, but it doesn't necessarily put it in one contiguous block. SpeedDisk can, as you use it, defragment your swap file into one big block, speeding up your machine noticeably.
I was actually rather surprised that Symantec was getting into the NTFS defragmenting market. For the uninitiated, the market is currently dominated by Diskeeper, a very nice product. Given that Diskeeper works and is only $40, I can't imagine that Symantec will be making a lot of money on this product. I imagine, though, that it's the first step in Symantec releasing NTFS versions of all their Norton Utilities, given that Win2K is gonna make NTFS much more ubiquitous.
Finally, one more slab of anti-kudos to Microsoft for their support of DirectX under NT. It doesn't bother me much that DirectX for NT is behind the times. It bugs me that I can't install it at all!
Lemme explain what Microsoft did. MS released DirectX 3 with one of their service packs (specifically SP 3). When you install SP 3 on your machine, it also installs DirectX. MS never made a standalone DirectX installer for NT, and they did not put DirectX on any of the later service packs.
When I installed NT on my development box, I obliviously went ahead and installed SP 5, because it contained all the fixes in the previous service packs. Little did I know that it did NOT include DirectX. I now have all the fixes, but no DirectX. I cannot retroactively install SP3, as it recognizes that a later service pack has already been applied and refuses. I'm basically screwed for DirectX unless I somehow can figure out how to install it manually. There's little chance that MS will be releasing a DirectX installer for NT, as Win2K is coming out in a few months that contains a much more up-do-date DirectX.
I found the Fourth Wave article about the Death of 3D interesting. I think the article's right on target, but they need to properly define the word "death". By "death", they're basically saying that 3D isn't gonna be the next magic bullet that takes over the industry.
Think of early personal computers in the early 80's. While the original Apple ][, TRS-80, and VIC-20 computers were cute, they weren't useful for much more than games and very simple word-processing and spreadsheet. By around 1984, the personal computer was pronounced dead by the popular press simply because virtually all computers were too underpowered to do anything. While many PC's didn't survive the industry shakeout (TI, Commodore), some did manage to find a niche. Today, computers are everywhere, but in a very different capacity than people thought they'd be around 1980. They're not controlling your house, and they're not vacuuming your carpet, but they found their place.
Furthermore, think of Object Oriented Programming in the late 80's and early 90's. When OOP first started to get a following when decent C++ compilers hit the market, the hype-machine hit OOP with all barrels. After the hype died down and the OOP settled into a mainstream niche, people pronounced it "dead". By that, nobody thought that it would disappear entirely, it just didn't meet up with the hype. Frankly, I never really understood how a programming language can take over computing, but that didn't stop Byte magazine from declaring Object Oriented programming "dead" around 1993.
3D, frankly, isn't a magic bullet. Think of conventional board games for a minute. Despite how cool and futuristic 3D chess looked in Star Trek, the half-dozen 3D chess efforts out there haven't even come close to unseating the 2D classic. That's because 3D, in and of itself, doesn't automatically improve things. For some games that are 3D by their very nature, like flight sims and auto-racing games, 3D adds a lot to the effect. To think that every facet of gaming would be improved by throwing 3D into it is simply ignoring history. There are board and card games that have survived for hundreds or thousands of years without a 3D update. There's no reason to thing that adding a computer would change the arena. Games are fun because they're fun to play, not because they look cool.
In conclusion, don't sell your stock in nVidia just yet. Just don't expect that 3D graphics is gonna be ubiquitous in every piece of game software. The microwave oven, it isn't.
Made some more headway on what is quickly becoming the premier sprite library for Windows CE. Heck, once I'm done with this beast, it'll be more marketable than any games I make with it :)
I also took some time to fully const my classes. Const is a C++ keyword that specifies that something cannot be changed. For example, in the following distance-formula function prototype. . .
int Distance (const Point &rPoint1, const Point &rPoint2);
The function is guaranteed not to modify the Point objects that are passed to it, as any attempts to call non-const functions in the Points will raise a compiler error. It's a great sanity-check for your programs, and it can often point out some errors. In my case, it did find a couple of problems where I was modifying a parameter I was passing rather than a copy of the parameter I made for that purpose.
Reminds me a bit of a freshman-level programming class I took in college, in which our professor was showing off a function comment-header from a commercial software product. One thing the programmers were required to document was "side effects", which was a detailed list of parameters or globals that were modified by the program. Using const, while a pain to enforce, is a way to not only document the changes you're making, but to actually have the compile help enforce it.
One piece of common wisdom when adding const to your objects. If you're adding const after the fact, start with your lowest-level classes and work your way up to the higher-level classes that depend on them. If you start the other way around, you'll eventually end up drilling down to the low-level objects anyway, so just start at the bottom and eliminate a step.
Most of my time, however, has been spent helping to set up Shelly with her Civil Engineering stuff. I put NT on the main net-surfing box, as AutoCAD works downright beautifully with NT. Upgraded the memory pretty heavily and reformatted the hard drive with NTFS. It made a big difference in the performance of the machine. Despite it only being a 233 Mhz Pentium, Shelly commented that it's probably the fastest AutoCAD machine she's used.
I had to switch out the video card, as NT just didn't get along with the Graphics Blaster TNT that was in it. I ended up getting completely frustrated and buying a 3D Blaster Savage4, which claimed to have good NT support. Thus far, it seems that the claim is true, as it's working just fine. The TNT supposedly is a better card for 3D, but the only games it's run so far are Windows Solitaire and Shi Sen, my wife's two weaknesses.
AFAIK, the TNT didn't improve their performance much :)
I don't wanna start sounding like Jerry Pournelle at Chaos Manor, but I've gotta recommend Partition Magic if you plan to change the OS on your machine. Using it, I was able to create a new NTFS partition, install NT in the NTFS partition, convert the old Win98 partition from FAT32 to FAT (because NT4 doesn't grok FAT32), and move over most of our old files to NT without losing a byte of old data. It's a terrific product, and it works well under Windows 98, NT, and DOS.
Also, kudos to HP for making a high-quality product with good driver support. Since Shelly needs to print out big AutoCAD drawings, we invested in a printer capable of printing 11x17 pages. After a bit of research, we settled on the HP 1120C. It's a big color inkjet that'll print to all sorts of paper sizes up to 13x19. Also, our local OfficeMAX had 'em for $499 with a $100 mail-in rebate, which made it a lot cheaper than the other 11x17 printers out there. Well, the NT drivers installed flawlessly, the utilities were easy to use, and Shelly was able to plot an 11x17 drawing first-time. Good work HP!
Finally, I've got a big slab of anti-kudos for ParaSoft. While buying the new memory for Shelly's machine, I noticed that my corner computer store had an old (1996) shrinkwrapped copy of CodeWizard (a command-line C++ tool that points out common errors in your objects) languishing on the shelf. Figuring that it was probably something somebody ordered and never picked up or was the result of a buyout of an IT department, I asked "how much?" The owner was surprised to see that I knew what it was, and he sold it to me for a low price. When I installed it, though, I found that I was supposed to call ParaSoft for a password. Upon calling ParaSoft, I was told that it was an old version. I told him that I was aware that it was an old version, how I got it, and that I'm just a one-man shop without much need for the latest version. The phone-rep refused to give me a password, instead offering to "upgrade" me to the latest version for the full retail price of $995.
Now, I understand that the product's an old version, and that I didn't pay full price for it. That doesn't mean, however, that I'm ripping off ParaSoft. The fact that the product was on the shelf indicates that somebody paid the licensing fee, whether it's the person who never picked it up or the department that bought it and never used it. This is a fully-licensed product. There was nothing in the package suggesting that I was breaking any kind of licensing agreement. For them to refuse me a password is, quite simply, bullshit.
I don't think anything's gonna come of it, but I intend to ship this product back to ParaSoft with a detailed letter explaining where they can shove their ad-hoc licensing policies. I don't think I'm ever gonna get a password out of the deal, but hopefully they'll re-think their policies for the next potential customer.
For the uninitiated: Jerry Pournelle is a sci-fi writer and columnist for the mostly-dead Byte magazine. His columns were basically rambling stories of the new stuff he added to the various cutely-named computers in his house. Then and now, nobody knows when he has time to actually write anything on his computers, given that he seems to do nothing but upgrade them constantly.
Still doing a lot to help the wife's business get off the ground. She's got a couple of contracts already, and her last day at her day-job is Friday. Yesterday we nervously placed an order for AutoCAD 2K with Civil Engineering extensions. I don't wanna be too graphic, but it cost more than both of our first cars put together :(
Biggest problem right now is office space. My office is a little 9x13 former bedroom with three computers and a lot of bookshelves. Needless to say, we're gonna be at each other's throats for a while having to share such a dinky space. I'll probably be calling the home remodeling people today to get some estimates on fixing up the garage into an office. It's a two-car garage, so there'll be a lot of elbow room there for an office for Shelly. Biggest problem is that the washer/dryer is out there, so we'll have to seal them off in their own little closet.
Home office hint: Got this one from my parents, who've been working out of the house since I was a kid. If you occasionally need a conference or meeting room for a group, talk to a local hotel. They've usually got several styles and sizes of meeting rooms for rent. You can usually rent a small meeting room from them for a few bucks.
There's a new version of STLPort out. If you're using C++ and you don't know about STL, you really should read up on it. It's basically a container class library. If you've ever used MFC or OWL, you're probably familiar with their container class implementation. Basically, it's a bunch of common data structures (list, queue, stack, etc), but they're generic and can hold just about anything. The old MFC and OWL implementations worked, but they had limitations. In order to be typesafe, they generally would only hold a certain type of data --specifically objects descended from a common root. It worked, but it often forced you to be multiply-inherited, and it couldn't store primitive types (like int's or pointers).
STL gets around this by being implemented as C++ templates (macros on steroids, for the uninitiated). For example, if you need a linked-list of integers, you can simply declare. . .
To insert an element into your new list, do. . .
Very simple and clean. Of course, there are tons of other stuff you can do with STL, mostly having to do with algorithms that you can attach to these data structures, but it does make a heckuva nice container library if you're just starting out. Having written ten thousand linked lists and grow-able arrays in C, I've learned to appreciate when something like this is already written and free.
Anyway, STLPort is an actively-updated free STL that's portable to just about everything out there. There's some good documentation here if you wanna learn more.
First, a quick plug. An old college pal of mine, Pat Down, has his own project page at www.codemoon.com. He's been dabbling in game development for as long as I've known him (14 years now, boy I'm old). He's currently working on a small project. Check it out!
FWIW, Pat contacted John M. about putting his journal entries up as a development diary. Nothing has come of it yet because they're both disillusioned ambitionless layabouts. I guess not everybody can be a dynamic captain of industry like your humble narrator. I know both of 'em personally, and I can confidently say that I can do seven things in the time it takes either of 'em to do one. They're both pathetic wannabes, but I do my best to be understanding --showering them with pity rather than scorn. No matter how much I wish it so, not everyone can be like me.
I finally got to spend a little time with my book-queue (the pile of books waiting to be read). I'm finally about one chapter away from completing The Design and Evolution of C++ by Bjarne Stroustrup. It's quite an interesting book. It's basically a chronicle of C++ --how it got started, why it looks the way it does, and why it works the way it does. I'm not just hyping things up when I say that this book is the best way for advanced C++ users to get a complete handle on the language. You'll learn what stuff is in there, why some stuff didn't get in there until years later, and what stuff was proposed and never made it in there. The book also manages to answer a lot of unanswered questions. If you ever wonder why anyone would allow such hideous constructs as blank parameter lists defaulting to void, but blank return types defaults to int, then this'll have the answer. Unfortunately, sometimes the answer is "we knew it's wrong, but it'd break old code", but at least you'll know why.
One warning, though. This isn't a storybook. While some of the history is narrative, most of it is told in code. Code that was proposed, code that shows off a language example, and code that shows a problem that needed to be solved. It's a deep book and probably not one for novices. The whole book is structured and numbered in outline form, though, so you can easily skip over some of the escoterica.
If you're one of those folks who wants to get to the bottom of C++, you realize that objects are more than just structs with functions, and you often puzzle about stuff that doesn't seem right, then this is the one to read.
Wow, two weeks since the last update. That's gotta be some kind of record. Sorry about that. I'll try to keep you posted more regularly.
I haven't really done much on the games in the past couple of weeks, as I've had some extracurricular activities going on that you don't know about. My wife, the incomparable Shelly, passed her Professional Engineer exam (the engineer equivalent of the bar or CPA exam). It's now legal for her to market her skills as a professional civil engineer. She had planned to keep her day job until the end of the year, but she got some very strong leads from folks who wanted to hire her for their projects. She couldn't resist such pressure, so she put in her two week's notice. A lot of my time has been spent getting stuff ready for her.
I spent a lot of time looking for local office space, but we finally decided just to build more office space into the house. Since we don't keep the cars in the garage, we decided to gut the garage and build an office in there. It'll take quite a bit of effort, but it'll still be cheaper and have a better return on investment than leasing office space.
As for office supplies, we had to buy some, but we should be able to use a lot of my existing stuff. The main net-surfing machine (the one I'm using to write this) will be promoted to her main AutoCAD machine. We got a good deal on a 19" monitor over the weekend, and the machine's already capable enough to run AutoCAD. There are plenty of good plotting services in the area, so we decided not to spend the big bucks for an E-size plotter. We did buy a nice HP ink-jet printer that's capable of printing 11x17 pages (only $399 after a $100 rebate!). In Shelly's experience, 11x17 is great for draft drawings, and we can let the services to make the big plots for us. Looks like our biggest expenditure is gonna be AutoCAD upgrades and add-ons. Ugh.
We're also looking for office furniture. We lost our favorite used office-furniture store when they renovated their building, so we're scrambling there. We bought a couple of cheap tables that should do fine, and used file cabinets shouldn't be hard to come by. Our biggest worry was finding one of those specialty file-cabinets with wide flat drawers that are used to hold plots --cheap 5-drawer ones typically go for $500. Suddenly I got a call from my dad, who had found a ten-drawer cabinet in a government clearinghouse in Arkansas for $125! Good work dad!
Finally, we're looking for health insurance. We'll probably use COBRA (a way to buy your existing insurance when you quit) from Shelly's company for a couple of months, but we'll need to find a decent plan after that. Any self-employed folks out there have a plan that they like?
I found the news article interesting that MS is gonna be releasing Windows CE 2.12 with some DirectX components. Here's my take:
The Windows Media Player moving to CE
This didn't surprise me. The new Casio palmtops were released with stereo and MP3 support, and people are finding that CE palmtops make dandy little MP3 players if you endow 'em with enough memory. IBM's new 340 meg drive that's the size of a quarter and the new long-life batteries are gonna open up new avenues for pocket-sized computers, and I wouldn't be surprised to see CE-based palmtops that double as digital cameras, camcorders, and mini TV's before long.
The new 4.0 browser
Actually, I'm a bit mixed on this. Having a more capable browser is certainly a necessity as CE moves into the set-top box market, and stuff like the WebTV certainly could use a more capable browser with support for Java, RealVideo, and ShockWave. I'm worried, though, about putting such a big powerful browser on handheld machines. Palmtop screens are simply too small to view conventional web pages. I liked the AvantGo folks' idea of making news mini-pages that are one-column text with some very simple graphics, designed to work on palm-sized screens. I think I'd prefer to see the CE browser broken up into a collection of DLL's, so you can choose how much browser you want your handheld to have.
The DirectX components
I don't think any CE devices have specialty video hardware yet, so I don't think it's overly important right now. As CE gets into more set-tops, however, DirectX will be more important.
The version number debacle
MS is completely messing things up with their CE version number nonsense. Here's how MS's version numbers went, as far as I can tell. . .
- Windows CE 1.0 - The original CE for H/PC (laptop fetus) computers.
- Windows CE 2.0 - Lots of changes to the kernel and UI to make it more Windows-like. Ran on basically the same machines as 1.0. Good so far.
- Windows CE 2.1 - Some bugs fixed. Runs on the same machines as 2.0. No problem yet.
- Windows CE 2.11 - A few changes for P/PC (pilot clone) machines. Essentially the same as 2.1, but with changes specifically for palmtops. Confusing, as 2.11 was only for palmtops.
- Windows CE Pro 3.0 - CE for improved H/PC machines (those new baby laptops like the Vadem Clio). Really not different from 2.1, but with some new apps like PowerPoint and Access for CE.
Now MS is preparing version 2.12 which has support for some DirectX and has newer features than the one they were calling 3.0! In addition to that, MS is working on a next-generation Windows CE with a friendlier desktop and real-time features, and they're calling it CE 3.0!
I'm still waiting to see if someone will step up to the plate and make a CE-based handheld for games. It'd be awfully cool to have a toy that looks and acts like a Color Gameboy, but supports DirectDraw/DirectSound and can download games from the internet rather than storing them on cartridges.
Finally, I got to play a Dreamcast machine at Best Buys yesterday. I'd like to say I was impressed, but playing the new 3D Sonic game just didn't feel like anything new. Nintendo did it with their 3D Mario game. Playstation did it with Crash Bandicoot and Spyro the Dragon. The Dreamcast version might've had higher resolution and more polygons, but that doesn't make the experience any more interesting. They're gonna have to release something really interesting to get me to change from my 3 year-old Playstation, but I don't see anything like that on the horizon. Looks like Sega's just releasing some new racing and fighting games. Unless they've got something that'll change the world, I don't give it much of a future.
Just a note to let you know I'm not dead. I'm just resting!
Just got back from a week long vacation in Niagara Falls. Not specifically game-oriented this time; just something fun. In the aim of feeding yet another stupid and meaningless hobby, the wife and I went to the International Jugglers Association convention. Had a lot of fun, met lots of folks who've forgotten more about juggling than I'll ever know, and saw some terrific shows. If the IJA convention ever comes to your town, try to get into some of the shows. They are truly remarkable.
Note: The author regrets making a trite Monty Python reference in his opening sentences. It will never happen again.
Nextly, I'm sorry to see that the venerable RW Bivins has returned. This time, he seems to have gotten involved with the otherwise high-quality Game Programming MegaSite.
A bit of background on Bivins, pieced together as best I can. Bivins is/was a college kid. First he claimed to be the president of AIE Entertainment, a company that had the best-n-brightest VB programmers and Bryce artists on the planet, and he was presiding over a game that would take over the industry. one fine day, for reasons that were never really clear, he got a giant bug up his ass and posted the infamous "Death to the RGP Lamerz" post to rec.games.programmer. Later, he apologized to the group, claiming that he was handing over AIE entertainment to the other owners so that he could finish college and grow up a little. AIE Entertainment and the game that was gonna bury us were never heard from again.
Fast-forward six months to the beginning of 1999. Bivins had apparently made good on his promise to avoid pissing people off, when suddenly a post appeared in one of the new game development newsgroups. The post, sent by Bivins using a sock-puppet account, was an "interview" with Bivins, who was now claiming that he was making $60k per month in internet porn and would soon be taking the gaming industry by storm.
After the unintentionally hilarious "interview", he once again disappeared from radar screens (or at least he appeared to have --he changes email addresses as often as most people change their socks) until this week when I see that his new company, ShadowLore, is partnering with the GP MegaSite.
I sincerely hope that Bivins has truly changed his ways and is willing to contribute something more than childishness to the game development community this time around. If this is not the case, I hope he doesn't do permanent harm to the GP MegaSite. It's a fine site and, frankly, deserves better.
Been working with my publisher on a new re-packaging of my products for other markets. I haven't gotten the numbers from this quarter yet, but I hope they'll be good. The games seem to be everywhere nowadays. My brother reported a sighting in a Nashville Wal Mart, and I saw the 2-packs at Sam's last week.
It's always gratifying to see my stuff on the shelf, but here's one tip if you ever get one of your products on the shelf. No matter how tempted you are. . .
Never, but never, tell anyone "I wrote this"
In almost four years of seeing my products on the shelf, I've never had a positive experience from this. The best I've ever gotten is a blank look from the CompUSA salespeople. If you see your product on the shelf, just enjoy the display and smile smugly to yourself. Don't point it out to other folks, because they just won't understand.
Sorry about not having any updates in a bit. After that article I wrote, I decided to take a little hiatus from writing web pages.
The responses to the article have been very good. A few beginners thought it was spot-on and appreciated the overview. I had a couple of complaints from folks who thought I wasn't saying enough nice stuff about C and another person who keeps contending that C is not portable because the object code is not cross-platform. Can't please everyone, I guess.
One addendum, though. I didn't have many good assembly resources because I hadn't written any code in quite a long time. A reader pointed out that, in addition to the stuff I had, there is a very good book on assembly out there that's free. It's The Art of Assembly Language Programming. Consider yourself informed.
Still working on my CE sprite library. Much of it is ported over from my old code, but I still have to put together some test stuff for it. Voracity pretty-much works, but there was never really any animation in the game. I'll probably just throw some bitmaps on top and slide 'em around so I can get the whole thing working.
Just a quick note today. There's an interesting interview with Roger Corman, father of the discount rack, on the ZineZone.
Almost as interesting as the interview itself is the fact that the interview is available in two formats. For each page of the interview, you can load up a RealVideo clip or you can simply read the text. While I started out with the RealVideo interview, I found that the text of the interview was much faster and easier to follow. I imagine that's some kind of metaphor that will eventually appear in a book by Cliff Stoll :)
One other note if you play the video. I dunno why, but Corman's voice sounds slightly deeper than Barry White in the clips. He actually has a rather normal voice.
In other Corman-related news, Kanakaris Communications has announced that they will start offering free streaming "movies of the week" from their site. The first movie that they will be playing is the Corman classic, Death Race 2000.
Ahh, the long Fourth of July weekend is over. Now I can get some rest! The wife and I spent all weekend driving everywhere, helping to set up a city fireworks show, and generally doing everything but getting some rest.
I got a good email back about my sprite library woes. Somebody in the know did confirm that doing a BitBlt under Windows CE ranges anywhere from deathly slow to glacially slow. Looks like my scheme of fiddling with the bits and doing a single BitBlt per frame is the way to go rather than the presentation's method of doing one or two BitBlt's per sprite.
I rather suspected this, because I don't think that any Windows CE machines yet have any kind of hardware assistance for video. It's basically back to the old VGA days when all you had was a bigass block of memory and no hardware support for anything other than the simplest operations.
I saw the Vadem Clio at our local Fry's last week. It is a seriously cool machine. It's good to see that people are finally thinking up interesting new form-factors for computers rather than the old form-factors (the very-small laptop and the Newton-clone).
They are still gonna have to make the screens tougher, though. I'd never put this thing in a briefcase with the screen facing out.
Wow, July. Where is the year going? Still don't know what I'm gonna do for Y2K. Probably just set a couple of lawn chairs on the back porch and await The Rapture :)
On the CE front, I have a question that I'll throw out into the ether here before posting it to the newsgroups. After hearing the presentation on CE Games, I'm wondering if I'm doing my sprite engine in the most optimal way. The Sprite engine that the authors present is pretty simple. Their sprites are basically wrappers around HBITMAPs. To put a sprite on the screen, they just do a couple of BitBlt's (or a transparent BitBlt if the hardware supports it). The way I'm doing it is quite different.
Basically, I'm planning to do things similarly to the way I did 'em with my existing game packs, only under CE. This means that I'm triple-buffered. Behind the visible screen are a Background (the background stuff that almost never changes, like the maze in Pac Man) and a Canvas (the background with the sprites drawn on it). These are both DIBSections, so I can mess with the bits. To draw stuff on the screen, I actually copy stuff to the DIBSection's bits and then BitBlt the changed stuff from the Canvas to the screen. This is considerably more difficult then simply transparently BitBlt-ing HBITMAPS to the screen, but it seemed much more optimal. Since all the sprite stuff is drawn to the canvas with memory operations, I only need to do a single Blit to replace the changed stuff on the screen.
The other big advantage of this approach is that Sprites don't need to be HBITMAPs. Since I'm never actually drawing 'em to the screen, just to the canvas's bits, they can simply be little bags of bits.
The presenters made it sound like Blitting a buncha HBITMAPS to the screen is fast fast fast, so you don't need to be as clever as I am being. I'm skeptical, though. They kept talking about how HBITMAP stuff can be kept in video-memory, but is this really the case? I wasn't aware that CE devices had separate video hardware.
Any opinions? Am I overengineering? Their demo didn't seem overly impressive, but it might've been the low framerate of the internet-streaming that was making it look less-than-optimal.
Interestingly, this little column seems to have gotten some new readers. I got some good comments on older news items.
On my complaint a few weeks ago about how stuff like the hPrevInst parameter seems to stick with us like a bad case of herpes, I got some info from a former Windows API guy. It was pretty-much what I had expected. The philosophy is basically "don't change anything unless you have to". I guess having an unused parameter on the stack is better than having to go and re-tool the parameter lists every release. It's also one less hassle, as it's easier to keep the documentation honest. I'm still torn.
I guess it's a better solution than Apple had with their Toolbox calls. In the past, whenever Apple figured out a better way of doing things, they just wrote a slick new set of functions, but they left the old one in place as-is. Hence, if you want to play a sound or read a file, there are two or three ways of doing it. Of course, only one way is the "right" way, but it's awfully difficult to figure out which way is recommended and which way is just a holdover from 1987. Apple's new "carbon" API is basically their attempt to dump everything but the latest way of doing things, so they're not porting fossil functions to their new Mach-based kernel.
I think my favorite method is that used by StarView (AKA the best class library that you've never heard of and never will). When they went from version 1.0 to 2.0, they didn't look back. They rewrote the stuff that needed rewriting. They included a utility, however, that scanned your source code and told you which stuff you'd have to change. It wasn't too sophisticated --it would just point out functions and classes that had changed. stuff like:
Line 103: Accelerator is no longer a separate class. It is now an attribute of Menu.
Line 372: OutputDevice::Line() no longer takes X and Y coordinates. It now takes two Point objects.
Once you had addressed all the stuff that the 1.0-to-2.0 utility pointed out, you were pretty-much ported to the new version.
Interestingly, it appears that Apple is doing just this with "carbon". They've got a utility that scans your source code and tells you which functions will be going away. I certainly think this is a better solution than a person scratching his head and wondering why his app isn't correctly detecting the other instance of the app, because hPrevInst has been NULL since 1992.
I also got a message about one of the comments about my bookshelf. I had mentioned that I didn't really like Debugging the Development Process much because it didn't cover debugging too well. He pointed out that the book is more about modifying the development process itself than debugging. I guess this was a pun that went over my head when I originally read the book. I read it several years ago and don't currently own it, so I probably ought to give it a second look. Thanks for keeping me honest.
FWIW, the bookshelf page is probably going to go away eventually. I plan to write reviews of the best stuff there and put 'em in the gamedev.net book review page. That way, everything will be where you're looking for it, and you won't see stuff like book reviews scattered around everywhere.
Why do all first person games have lens flares in 'em nowadays?
Lens flares are an artifact of camera-usage. Basically, it's caused when a camera pointed at a too-bright source (like the sun) causes bright spots to appear on film. Sometime a few years ago, every space-scene had to include a few lens flares to give added realism to bright objects on the screen. The technique, interestingly, seems to have migrated into 3D games. Every 3D game you see nowadays, especially racers, have lens flares.
What I don't understand, however, is this. If game-makers are working hard to make their games a completely immersive experience in which you "become" the character in the vehicle, why are they showing an artifact that only occurs when viewing something through a camera? It seems to me that if designers were trying to make a game more realistic and less movie-like, they'd want to avoid lens flare effects.
Actually, I know why. It's the same reason that guns make a "PaTANG" sound in movies when they just make a dull "POP" in real life. People just expect things on-screen to work a certain way.
Sure, I'll try. It can be a bit hard to explain though........ We have an octree of voxels divided into chunks. A chunk is basically some point in the octree and everything below it. The depth of leaf nodes for a chunk is determined by the distance the chunk is from the player. However we don't build down to our leaf nodes unless there is a sign change, (i.e. mesh data) otherwise it would defeat the purpose of the octree. So most parts of a chunk's octree or even the whole octree will not go all the way down to it's leaf depth, and it's leaf depth could be several levels down from a bottom voxel.......The problem is as you approach an area of terrain, the leaf node level will increase to provide more detail, and we can not assume that just because a voxel has no data it's children will not have data also. A good example of this is if you have some floating terrain in the middle of a voxel. However this can also happen without floating terrain. For instance if some geometry pierces the side of a voxel but doesn't contact any of it's corners the voxel will appear empty, but after you subdivide it you might find data.
So for build iterations we have to go all the way down to where leaf nodes should be, just to check if there is data. We need to do this because our terrain functions accept X,Y,Z coordinates and we don't have those until we have built the octree down. So it's kind of a chicken and egg problem. We need the octree to find the data, and we need the data to figure out where the octree should be. Instead of building the whole octree down however, we use a lightweight tree without all the faces edges and nodes, just to find coordinates to feed to our functions. Since our coordinates are on the surface of a sphere we need to subdivide an icosahedron and that's really what our unit sphere is. Then to calculate the position of a given voxel vertex we just multiply it's corresponding unit sphere vertex by it's altitude to get our final voxel vertex X,Y,Z coordinates. We are really dong this for virtual vertexes since they don't exist yet. The ghost-tree code handles this stuff. Also we don't un-subdivide the unit sphere on every iteration. We use it to cache the sphere related part of our coordinates between build iterations, in addition to height related components of any terrain functions we are using. We therefore don't need to recalculate all that stuff on each iteration. We just recalculate the height part when we do our ghost walking which is a simple calculation..... Our ghost walking is implemented by recursion and on the way back up we throw away any parts of the ghost tree with no data, so we are left with a map of how to build the actual tree. Note this whole processes is only done on cells that appear empty. Cells that already have a sign change will be at the current leaf level, and when we increase the level we can just subdivide them normally. This handles the vast majority of cases. However as I said you can't make the assumption because for anything but the simplest cases it won't hold true very long. Generally you won't have to ghost walk very deep but there are cases where it's possible. For instance say you have a long thin spike that avoids all nodes up until the last level of LOD.
There is one more feature I didn't really talk about yet but I'll add it in here. if we have simple height-map data, we can store those terrain function values in the unit-sphere vertexes no problem. However when we start getting into caves and stuff like that, you really can't do that. So now there is another problem. As as you build your ghost tree down to find your data, you are running terrain functions on 3D coordinates and those can be expensive. Note that each voxel vertex is used by 12 voxels ( just like for cube voxels, each for vertex is used by 8 voxels). Since during the ghost walk process there are no voxel vertexes built yet, there is no place to store calculated terrain function values. Ostensibly you would have to calculate the same terrain function value 12 times, but that would be a disaster. Instead we have a 3D matrix cache that we use for temporarily storing terrain function values as we search for data, and there is a special "chunk address" that we index it with so we can quickly see if we have already calculated a needed value. Since our voxels are prisms it uses something akin to barycentric integer coordinates. In fact there is a partially implicit addressing system that assigns each voxel a unique ID.
I call it GNOLLS coordinators
If you you start at the top, the world is constructed from an icosahedron. That's twenty faces. we can combined those into pairs to a get a diamond shape which we call a "Group". The group has two axes one that points roughly "North" and the other is at an "Oblique" angle to it. That gets us to a pair of voxels which we call "Legs" (a term I stole form investment jargon, there is a one "up" Leg and one point "down" Leg). Then we have the altitude of the a voxel which we call a "Level" and finally we have the "Subdivision" as defined by our octree. So its:
GNOLLS! (Yes I had to think a while to make the acronym work :D)
@Gnollrunner, can you explain this part
"We also use our unit sphere to help the horizontal part of our voxel subdivision operation. By referencing the unit sphere we only have to multiply a unit sphere vertex by a height value to generate voxel vertex coordinates. Finally our unit-sphere is also used to provide coordinates during the ghost-walking process we talked about in our first entry. Without it, our ghost-walking would be more computationally expensive as it would have to calculate spherical coordinates on each iteration instead of just calculating heights, which are quite simple to calculate as they are all generated by simply averaging two other heights."
A little more?