T w e n t y S i d e d

Short version:

Thanks for all the feedback on Pixel City. Stating your version of windows and graphics chipset along with problem reports is invaluable. The current release version has a rather embarrassing memory leak in it, so prolonged use will make the system thrash for a while when you exit it. For those of you compiling along at home, this is already fixed in the codebase and you should integrate revisions #11 and #12, regardless of what else you’re doing with your own forked version.

For this reason, I’ll be issuing at least one more build of Pixel City that fixes this problem. I’d like to kill a few other issues in that same release if I can gather the data needed to do so.

Long version:

I want to start with this comment from Brandon:

This is very much what I expected: Just barely useful on a five year old machine. That fits with the my impressions on what we should be seeing, which is why I was very taken aback by reports from people with two or three year old machines that said the thing took ten minutes to start and ran at 2 frames per second. This was very alarming and had me worried that I’d somehow grossly misjudged what I was asking of the graphics hardware and the CPU. Brandon’s comment hints that I was probably right in the first place, and that these extreme slowdowns are coming from somewhere else.

Also interesting are reports from people claiming that it doesn’t work with multi-monitor setups, and other comments saying that it does.

The screensaver functionality was added late in the project, and was thrown together more or less at the last minute. I was slightly dubious about taking a system I’d built carefully (but not adequately tested) and setting it atop a system I’d built in great haste and hadn’t tested at all.

For the record, the program makes no special effort to support or not support multi-monitor setups. How Windows screensavers work is that your program is invoked and instead of manually creating a window yourself like you do in most programs, you are simply given a pre-existing window to use. This can be a bit strange when you’ve got a 1920×1200 monitor in front of you and (say) a 1024×768 monitor to one side and Windows is creating a single frame to encompass them both. One obvious problem is that windows must be rectangular. Assuming the small window occupies the same vertical space as the larger one (which is by no means certain) then your program is going to have a 2944×1200 region to fill. Even worse, within that render-hungry expanse is going to be a 1024×432 rectangle that’s being rendered and then discarded.

(EDIT: And just to be clear, the program doesn’t really have any idea that it IS on a multi-monitor setup. It’s just handed a window. I’m sure it’s POSSIBLE to query the setup and the monitor sizes and their geometic relationship, but I’m sure that would be a lot of work, and I’m not even sure what benefit it would be. The program still has just one window and one render context.)

How that window behaves and what monitors is spans is very much open to how multi-monitor support has been implemented. I know some graphics cards have their own multi-monitor setups that exist outside of the same functionality as provided by windows. Couple this with the fact that different versions of windows probably have different ideas about how window regions are stitched together and you have a recipe for something that will take a lot of time and experimentation with different monitor setups to understand. Keep in mind that I was never really that interested in wrangling with the Windows screensaver functionality. My real goal was the procedural city stuff, and the rest of the project was just scaffolding to support that idea.

The extreme slowdowns are a little more perplexing, and right now my instinct is to again blame the unknown behavior of the Windows screensaver functionality.

The directions I’d read online indicated that Windows would provide your program with a pre-existing window, and would then call WM_PAINT as fast as possible. I was a bit surprised at this, as this is a break from the behavior we see elsewhere in the operating system. Normally a window only gets a WM_PAINT when its contents need to be redrawn. If you move a window around the screen, resize it, or bring it out from behind other windows, it gets a WM_PAINT message letting it know that it needs to redraw. But here we have a situation where WM_PAINT is supposedly being called indiscriminately, and at an unknown (or undocumented) interval.

I’m strongly suspecting that WM_PAINT isn’t getting called very often on some systems. In screensaver mode, everything is bound to that one WM_PAINT message, which is putting a lot of trust in a feature that I don’t know much about and didn’t make sense to me in the first place. If Windows only calls WM_PAINT twice a second, then the program will take ~512 seconds to build the world and will run at two frames a second no matter what hardware you have. This seems to meet with observations.

One solution is to set up a WM_TIMER and see if that solves the problem. This would let me direct windows to call me every (say) 17ms or so, which would give me the desired 60fps framerate.

Shamus Young is a programmer, an author, and nearly a composer. He works on this site full time. If you'd like to support him, you can do so via Patreon or PayPal.

Screensaver

But I don’t have any machines suitable for testing right now, and I don’t have time to run some sort of open beta. Besides, any such effort would quickly fill up with people who were just there for the software and not really into the whole “test unreliable software and then report in detail all the ways in which it failed to work”.

So I’ll preface this release with a stronger version of the usual disclaimers: No warranty is implied, it might not work, use at your own risk.

Sorry to the Mac users. I do not omit you out of malice, but I’ve never developed for Macs before and have no means of doing so.

Download PixelCity v1.0

Take the PixelCity.scr file out of that archive and put it into your /Windows directory and you should be ready to go. There is no configuration dialog, so when you hit the “settings” button in ScreenSaver configuration, nothing will happen. Just hit F1 while the program is running to get a list of things you can do. Be sure to press ‘E’, as it will show off some full-screen effects I haven’t mentioned or showcased before. (I wanted to have some surprises! Although perhaps seeing the message “This program as performed an illegal operation and needs to close” will sate your desire for surprise.)

Please do consider spreading the word on this project on your blogs or wherever you tell people about cool stuff. Reluctant DM was nice enough to put it up on Digg, but Digg has yet to respond to anything I’ve done. Projects, comics, articles. I’ve gotten links from some internet hotspots, but I’ve never earned more than an indifferent shrug from Digg. It’s a very FARK-esque audience and I doubt I’ll get any digs until I write my magnum opus: Procedural Man Getting Hit in Balls with Baseball. (It works on so many levels!)

Source

I’ve put the project on Google Code, although I’m not sure if I will continue with the project or not. I’d love to keep working on it, but further changes will most likely make for dry reading, and that means the project would no longer be feeding this website. We’ll see.

I’m using MS Dev Studio 6, which turns eleven years old this year. Sorry to those of you using development environments forged sometime during this millennium. This is something I cannot change. Although to be fair, migrating from my platform to your is likely much easier than going the other way.

Development

In Win.h there is a #define that lets you disable screensaver mode, which is crucial for development. Setting SCREENSAVER to 0 will change the behavior of different parts of the program and give you access to the primitive and unintuitive development camera.

If you want to test it in screensaver mode, set SCREENSAVER to 1 and invoke the program with the /s command-line option.

Porting

The program is very much tied to Windows at this point. I tried to quarantine all of the Windows-specific code into its own ghetto module (Win.cpp) but that didn’t really work. The stuff for generating a render contex and loading fonts in Render.cpp is also windows-specific, and of course you must #include windows.h everywhere you use Gl.h, which is just about everywhere. And finally, checking the millisecond timer means calling the Windows-specific GetTickCount (). So those items will probably form your to-to list if you’re looking to port.

Optimizations

There is a lot of work that could be done to speed this thing up. Many promising ideas were suggested in the comments during the three optimization posts.

Switching to vertex buffers would likely give a huge boost. (See the comments at the top of Mesh.cpp.) A lot of improvements could be made to the visibility table and how cell visibility is determined. And I suspect there’s a better way to fill the bloom buffer than the one I’m using now.

I didn’t pursue these because there’s just no point in trying to optimize any further on this machine. To be done right, the changes need to be done on an older machine. Profiling can help, but only in cases where old and new hardware encounter the same bottlenecks. The thing runs at 200fps+ on my machine, and it’s entirely possible that I could ratchet that up to 300fps in such a way that provides almost no benefit to the poor guy running the thing on an old laptop. Furthermore, at this speed it’s pretty hard to detect improvements amid the noise, so it’s hard to get a feel for how effective changes are. (Again, profiling doesn’t tell you about those every-ten-frame lurches that are imperceptible at 200fps and nauseating at 20fps. There is simply no substitute for testing on the right hardware, which is why the loss of my old computer was such a terrible blow. I’m currently watching family members to see if any of them are going to upgrade soon. Ideally, I hope to inherit a ~2004 machine.)

Still, I’d start with vertex buffers.

Derivative Work & Collaborations

I am gratified to see that so many people want the source and are eager to do new and cool things with it. I’m not sure how we should go about this. Google Code isn’t up to tracking a dozen forks of the project, and I don’t have time to administrate that sort of activity anyway. Ideally we want someplace where people can swap code, knowledge, and screenshots. Some people will no doubt struggle getting it to compile on their different (from mine) development environment, and a little help from others can go a long way towards saving everyone time & headaches.

This is ideally the job of a forum, but I’m not in a position to provide one of those right now. It would be perfect if such a thing was available along with Google Code, alas.

I’m open to suggestions.

UPDATE: The codebase is now available on GitHub, which has the source file / social functionality we’re looking for:

http://github.com/skeeto/pixelcity/tree/master

Future Work

While I have many features I’d like to add, I don’t have any immediate plans to do so. Right now I’m going to wait and see if there are any egregious problems with the screensaver.

But if pressed, I suppose I’d like to add the following someday:

1. Port the thing to wxWidgets, which might give me the cross-platform access I’ve always wanted. (Win, Linux, Mac.)
2. Implement vertex buffers.
3. Fiddle around with the city-generation parameters. I don’t think I’m getting as much variety out of the existing code as I could. More mid-size (25 story) buildings with a large footprint might do a lot to break up the “bar graph” effect I have going now.
4. And of course, the street-level detail is a timehole which is happy to consume any effort I’m willing to put into it.

Thanks for reading. It’s been fun.

Shamus Young is a programmer, an author, and nearly a composer. He works on this site full time. If you'd like to support him, you can do so via Patreon or PayPal.