Procedural City, Part 14: Feedback and Assessment

 By Shamus May 7, 2009 62 comments

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:

I’m using an ancient machine (think 2003 or 2004). Barely 1GB of DDR RAM across three sticks, I don’t even want to know what my processor is like, and the best thing in here is a 512mb AGP graphics card. But the screensaver runs relatively smoothly, provided I have absolutely nothing else running on my computer. With about four other applications open I average 15-20fps and managed to get up to 50fps when the camera swooped low and followed a street

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.

202020262 comments? This post wasn't even all that interesting.


  1. Alter-Ear says:

    Do you have a released scr version of the new revisions?

    EDIT: Please ignore me. That’s what “I’ll be releasing a new build” means, doesn’t it. I really have been out of the programming world for WAY too long.

  2. Ah, yet another problem you would not have in Linux. X11 screensavers are just programs which are invoked by a screensaver daemon which just tracks the conditions for screensaver activation, then calls your specific screensaver program. You’d still have all the efficiency and power of your program and be able to use it as a screensaver in any desktop environment.

    Why, yes, I do like to regularly advertise all the ways Unix/Linux sucks less than Windows :)

  3. Factoid says:

    Could there be an issue when running in an environment like VMWare Fusion for the Mac where you program doesn’t like a non-standard resolution? One of the cool things about Fusion is that I can resize my window to any parameters I like. Windows handles this fine as long as you have the Fusion video drivers installed, but every so often you find a program that absolutely chokes when running in “full screen” which is actually just a window on my mac desktop.

    I will try forcing the screen to something normal like 1024×768 and see what happens.

  4. Ed says:

    I have tried this on two computers.

    1) New Laptop, XP, Core 2 duo @ 2 GHz, 4 GB Ram, Intel Mobile 965 express video.

    It sits black for avery long time, then slowly goes though the countdown clock (~5 Mins to load the city). The city runs so poorly, I can’t even get a frame rate. Call it 1 a second.

    2) New desktop, vista x64, 4 GB ram, ATI HDS video card of some description

    Runs the countdown clock very rapidly, the city runs great.

  5. Mari says:

    I reluctantly admit that between PixelCity’s memory leak and Firefox’s memory leak my meager system was taxed to its’ limit after 24 hours. The impressive part is that you’ve already figured out how to fix your memory leak while Firefox is still promising the magic fix with every new release.

    Of course, the real lesson here should probably be for me to close my stupid browser window before I go to bed. But that would be a completely logical and thus impractical solution. It has been observed by bystanders that I am where logic goes to die.

  6. Nick says:

    In my experience, Running this screensaver on a Windows Server 2003 box is a no-no. But then, they are kinda bad computers, but their behavior is identical, despite their configurations, and are similar to how others describe their problem as well.

    However, running it on a windows XP computer I have at home (which is, admittedly my pride and joy), it runs fairly decent. With default settings, this Phenom 2( quad core), 4 GB of ram, 32 bit XP pro, ATI 2900HDXT computer runs at about 20-30 frames. Jumps higher to 80-ish in the final “E” setting.

  7. Eltanin says:

    I’m running it on an XPS Gen 2 laptop (2.13 Ghz) and 2 gb of RAM. And an Nvidia GeForce Go 6800 Ultra graphic card with 256 mb of memory. This computer is approaching the 5 year mark rather rapidly. It still handles PixelCity pretty well though. I generally get around 60 fps, though the first bloom setting drops that in half.

    However, the sky doesn’t render well at all. It’s pretty much black with a few artifacts in it. I apologize for the lack of screenshot. This doesn’t make a lot of sense to me.

    At work, my ancient workstation is using some 128 mb graphics card that I found lying around the shop. It renders the sky beautifully, but generally runs at around 20 fps. Bloom on drops that to around 5 fps. I’ll try to post it’s stats when I get in to work later.

    Thanks for the awesome fun. I just saw iRobotic go by which was entertaining.

  8. Foone says:

    Is your screensaver checking that it is only running once?

    The way windows works (I haven’t coded screensavers for windows in years and years, so this is by memory) is that every X minutes it runs your program. Your program has to check that it hasn’t been run twice, or you’ll get two copies of the screensaver running. That’d explain the slowdown.

  9. Ermel says:

    re Foone (#8): No, I don’t think that’s it. On my system (Samsung NC10 netbook), the screen saver is incredibly slow from the first try on. Moreover, I never had it really selected, just tried it from the Preview button in the Windows sceen saver dialog.

    The explanation with the WM_PAINT messages arriving too slowly makes more sense to me. It’s got to be some hiccup like that, at least it can’t be hardware limitations, since from the command line PixelCity is running okay.

  10. Ryan says:

    I seem to have the same problem as Ed, newish laptop, 5+ minutes to load and about a .4 FPS

  11. Ermel says:

    I found a HOWTO on Windows screen saver programming that after a quick overview seems to me like it might be helpful. Note however that I’m not a programmer (anymore, and never was on this level).

  12. CoarseSand says:

    I tried the screensaver functionality yesterday, but unfortunately my regular card, an Nvidia 9600 GT, is being RMAed with ASUS at the moment to do a black screening issue, so I had to test it on an older Nvidia 7300 GT. Horrible. But that might be because of the two 22″ monitors I use giving me a screen res of 3360×1050. So the card isn’t happy, but it can still get about 20 fps in letterbox mode.

    But it can’t seem to render any of the textures. Toggling textures off does the regular thing of only making lighting visible, but having them on makes every building into a giant pastel crayon. Very odd. I’ll have to wait and see how it goes with the 9600 when it comes back.

  13. Anachronist says:

    I posted from work in the comments to installment #12 yesterday. Now I’ve had a chance to test this from my home copmuter, a fairly new HP d5000z, AMD Phenom quad-core at 2.4 GHz, NVIDIA GeForce 9500 card. I have two monitors here of different sizes, 1650×1050 and 1024×768. The screen saver spans them just fine. Depending on what the camera is doing, the frame counter ranges from about 30 to 60 with default settings.

    I noticed a few problems. When the camera zooms toward the street, I see car lights appearing out of nowhere, almost as if the street is being populated with cars when the camera gets near. The glow around the car lights are rendered as discs rather than spheres (that may be intentional).

    Here and there I see an occasional building where the texture map inexplicably flickers. The “fog” setting makes the sky look blocky for some reason, as if the sky was made of large shaded rectangles with no blending of the edges.

    And of course I let it run all night and was greeted this morning by an error message saying that pixelcity.scr stopped running. Must be the memory leak.

    I did more observing at home than at work. I’ll have to check whether I see the same things at work.

    In my experience, releasing software, even as public domain, will put you well over your time budget that you wanted to devote to it, because you’ll find all sorts of things that need your attention that you’d otherwise ignore if you had kept it to yourself. I really appreciate what you’ve put into this project. I found it inspiring.

  14. Derek K. says:

    Mainly this thread makes me sad when I see computers I would be proud to own denigrate as old rust buckets.

  15. C-Money says:

    I’m running on a 3.0 Ghz P4 (w/HT), and 3GBs mem…I’m running about 30-60 fps (without the bloom), which is more than acceptable for me, considering it’s just a screensaver. With the bloom, it dips to about 20 fps pretty consistently. As I said, as a screensaver, that’s fine. If it was a game and running at 20 fps, THEN I’d have a problem. :-D

  16. This program is behaving strange on all my compuetrs.
    On my little almost-no-cpu-power notebook the sky renders fine, but it runs at about 6-15 fps without bloom. Also the program randomly shuts itself off frequently, around once every 10 seconds, give or take.
    (VIA Chrome9 HC IGP Family, VIA C7-M Processor 1600MHz, 2Gig RAM)

    On my desktop, however, it runs very well, but the sky is just a mess of black boxes with white blobs on them that are overlapping each other. I think they are meant to be clouds.
    (Nvidia geforce 7900gtx, dual core 2.4GHz cpu, 2Gig RAM)

    I have an old gaming pc from 2003-2004 somewhere that I’ll test this on as well.

  17. LotsofLuck says:

    Not sure I should have posted in the other section, but though I’d do a comparison test for the different effects. (Edit: Hmm, I might have tested this with the older version, dang…)

    I still figuring some terminology out, so excuse me I don’t everything completely correct. I’ve got a

    Lenovo Intel (R) Core (TM)2 Duo CPU
    T7500 @ 2.20 GHZ
    2.19 GHz, 1.98 GB of RAM
    with Windows XP, Service Pack 3

    I generally got about 40 fps (which is totally fine by me, I play Left 4 Dead @ 30 fps, which can be kind of scary at times during Survival), but here’s the low-down for the different effects.

    Link to 5 screenshots:http://img16.imageshack.us/gal.php?g=bloommode.png

    Didn’t know what names you had for modes, but here’s what I got:

    “Bloom Mode”: 21 fps
    Dull Colors Mode (mostly blues and purples): 41 fps
    “Matrix” Mode (just the lights from the windows): 41 fps
    “Rainbow” Mode: 41 fps
    “Vegas” Movie Maker Mode, (don’t know what effect is actually called but reminds me of the effect that everyone uses on the titles screens with Vegas): 40 fps

    Yea, it definitely looks pretty awesome. I’m going to use this for my screen saver. :)

  18. Reluctant DM says:

    It worked well enough on my multi-monitor Windows Vista setup. I would say the camera moved a little fast and I couldn’t get the framerate or the G (fog?) commands to work. And the skybox was just black. But the city itself looked pretty and ran smoothly aside from a few small stutters! Very exciting. Oh and it crashed once… LOL :)

  19. Julian says:

    I ran it in a 2.2Ghz Core 2 Duo processor (accordint to srtest, it works like a single 4.6Ghz processor), an NVidia 8600 GT GPU with 512mb of video memory, and 2GB of RAM.
    Without any fullscreen effects it runs at 60fps. Bloom takes it down to about 30-32 fps. The city builds itself in about 3 seconds.
    So, no problems here.

  20. R4byde says:

    I’m using an ancient machine (think 2003 or 2004). Barely 1GB of DDR RAM across three sticks, I don’t even want to know what my processor is like, and the best thing in here is a 512mb AGP graphics card. But the screensaver runs relatively smoothly, provided I have absolutely nothing else running on my computer. With about four other applications open I average 15-20fps and managed to get up to 50fps when the camera swooped low and followed a street.

    Interesting, I have nearly an identical setup from 2003, and I get a solid 50-60 FPS with everything all the way up.

  21. Zel says:

    I played around with the code a bit and implemented frame buffer objects for the bloom render-to-texture. It’s supposed to be faster than glCopyTexImage2D because the data stays in GPU memory. After a few hours of tweaking (I’m completely new to openGL), I’ve managed to double the program size, require some extensions only supported by certain video cards, and get an outstanding 2-3fps gain (from 19-20 to 21-23). I’ll leave vertex buffers in more capable hands.

    As Bloom still takes away half of my fps, I also tried my previous idea of a CPU blur of the bloom texture. Just a 4 sample blur made the program beg for mercy at about 1-2fps. Bad idea.

    In the end, I reduced the bloom texture to 256*256, reduced the passes to 9 (from about 36) and raised the intensity. There’s much less light bleed, but it makes the windows brighter and seem less flat. And last but not least : it runs at a solid 30fps without stuttering. Now my laptop too can look cool while idling thanks to you.

  22. Mr_Wizard says:

    Hey! I just tried it out and I would like to say that it runs on my old machine of an indeterminate age! I get between 10-20 frames per second, with the occasional slow down for about a half second, which seems to happen very regularly. At street level is where is smooths out the most.

    ATI Radeon 9800 128mb AGP
    AMD Athlon 64 3000+ (2.1 ghz)
    1gb ram.

  23. SiliconScout says:

    So given the explanation in the post my multiple monitor issue is probably because all 3 are at different resolutions.

    1024×768
    1680×1050
    1280×1024

    How long do you figure I would have to wait for it to actually launch?

    Also @ home running 1280X1024 on a gforect 8700gt with nvidia chipset I don’t get sjy regardless if I use fog or not.

    Still haven’t gotten it to launch @ work on the above screen config.

  24. DmL says:

    Add me to the large list of people with fast machines for whom the sky renders black and blocky.

  25. Eltanin says:

    Follow-up to my previous post:

    Now the screensaver only runs on that Dell XPS for about 10 seconds before it wakes up even if no one has touched the computer. I’ve even rebooted and still have the same effect.

    Work computer specs (as referenced above): 1.8 Ghz processor with 2 Gb RAM, and a Radeon 9600 SE SEC Family video card (128 mb).

  26. Robinson says:

    Got a roughly 3 year old XP machine – 1GHz Athlon, with 2.5MB DDR RAM and a GeForce3 Ti200 (64MB). I also tested it without any other programmes running to give it free rein on my system…

    First city took about 10 seconds to load, but following ones were faster, maybe two seconds minimum.

    It runs pretty well without bloom, topping at about 60fps, but bloom will automatically cause a drop below 15fps and it becomes pretty clunky. Lowest rate I’ve had is 6fps.

    Like other people, leaving fog on causes occasional rectangular blocks of sky, although sometimes it does look normal. Also, I think the cars actually look pretty realistic (even though I knew they are just lights) until the camera zooms in really closely and it does become a bit obvious they are just lights – maybe if the camera stayed a tad higher?

    Overall though, I am very impressed – I had high expectations from your posts and you delivered. I’ll be leaving it as my screensaver and will look to implement it at work too.

    Thanks, Shamus.

  27. Cuthalion says:

    I’m on Windows 2000 Pro, AMD Athlon 2000+, 512MB RAM, Radeon 9500.

    It starts with a black screen that sits there a while, then it pulls up the loading wheel thing, which takes about 5 minutes. Once the screensaver starts, it varies between maybe 1 and 3 fps, depending on the E setting.

    Hope this helps!

  28. Cthulhu says:

    Hmmm. I’m running it on a 7-year old computer, and it is running just fine, except for the memory leak mentioned above.
    Pentium 4 3.00 GHz
    GeForce 7900 GS
    1.5 GB RAM

  29. SatansBestBuddy says:

    I’m expecting part 15 “It’s done now.” to be shortly followed by part 16 “Okay, scratch that, NOW it’s done.” with a low percent chance of a part 17 “You know what, it’s done for me, so if you’ve got another problem to add then fix it yourself!” depending on how many bugs and patience is left.

  30. It works fine as a screen saver for me. Thanks, Shamus, I was getting rather bored of the vista default ones I could use.

  31. AlfieUK says:

    I’ve been following this project with some interest, thanks for blogging it Shamus.

    Testing on my old’ish gaming rig; P4 3GHz HT, 2GB RAM, BFG nVidia 7800 GS OC (fastest AGP card I could find 3 yrs ago).

    Initial build (1.0.005) starts in under 5 seconds, ran at high 70′s without bloom, high 40′s with.

    I tweaked my GPU settings (anti-aliasing) a bit and the current build (rev 14) runs at high 70′s/low 80′s with or without bloom, which surprised me.

    All versions have messed up fogging for me, black and blocky sky, no matter what GPU tweaks I try, other than that it looks stunning :)

  32. NBSRDan says:

    Wow, Shamus. I’ve been a long time lurker, but this was just interesting enough to make that no more. It was certainly an experience seeing a programmer progress through the alpha stages, and I got to feel smart every time I understood something. Thanks for giving me something cool I can show my friends.

    And now for the beta test information:

    Hardware:
    Pentium 4 3GHz processor, single core
    1.5 GB of RAM
    One monitor, 1280×1024 resolution
    Two interchanged graphics cards were used in the same machine. The first was an Intel 82845G Graphics Controller, which is 4 years old, and the second is an NVIDIA GeForce 6200, which is 3 years old.

    Performance, Intel 82845G:
    The city takes about 40 seconds to build, though it gets to 50% in about 3 seconds.
    Once the buildings are in view, the FPS stays firmly planted at 1.
    The effects obviously make things even slower, but the FPS counter seems incapable of registering less than 1. FPS hovers around 8 with textures turned off.
    The program runs smoothly however in the 152×112 preview window, though the FPS counter can’t be activated.

    Performance, GeForce 6200:
    The city now builds in only 3 seconds total. The fact that the CPU has not been upgraded tells me that the GPU is being given an obviously unnecessary burden during the building screen. Confirmation of this hypothesis comes when pressing E (thereby turning on bloom lighting) slows the building process, and pressing E again (thereby switching to zoom blur) speeds it back up.
    Average FPS is anywhere from 30 to 55 depending on how much else I’m running. When zoomed in for a low street view, FPS gets to 60 easily and peaks at 75.
    Bloom lighting knocks the FPS down to 8-10. Zoom, hue cycle, and Matrix terminal effects have a roughly equal impact of about 20 FPS. With textures turned off, FPS wavers between 60 and 85, and reaches 95 in street view.
    This time, the 152×112 preview window always displays FPS instead of never, which wavers between 150 and 300, going as low as 100 and as high as 500.

    In each case, “fog” and letterboxing have no noticeable impact.

  33. RetSpline says:

    @14 Yeah, I’m right there with you.

    I’m running Windows XP SP3 on a 3-4 year old Inspiron B130, a budget laptop back when it was new. CPU is 1.7GHz with 2GB RAM and an integrated Intel 915GM/910GML graphics card. Running on lowest resolution (800×600) with no other programs running and all possible processes shut down it took about 80 minutes to load the first city and ran at <1 FPS.

    I tried messing around with the full-screen effects to see if I could turn anything off, but since it took so long for the program to recognize my keystrokes and the first city showed about 7 frames sideshow-style before loading another city nothing really got done.

    Definitely seems to be a CPU bottleneck, when I exited the screen saver I was at 100% load and the max temperature before it starts throttling.

    The few screens I could see looked AMAZING, though.

  34. Sauron says:

    Weighing in with my experience:

    Athlon 64 X2 5000+ OCed to 3.0GHz (stably), Geforce 9800GTX+ 512 MB (stock overclocked), 8 gigs of DDR2 800, WinXP 64-bit, and a busted memory controller (really need to get that fixed…)

    The screensaver BSODs almost instantly half of the time and eventually the rest of the time. I’m guessing bad interaction of memory leaks and a busted memory controller, though….

    Gets a decent 60 fps while it runs, though, with or without bloom.

  35. Darius says:

    Since this is my first post on your blog, I feel obligated to let you know how much I enjoy it. Also, this procedural city thing is awesome, and makes me jealous I didn’t write it myself.

    I’m running Windows XP Pro SP3 on an AMD Athalon 64 X2 6400+ with 2 Gb of System Ram. My video card is an GeForce 8800 GT with 512Mb of Ram.

    I haven’t had any problems with the screen saver, until a few minutes ago when it was running and I plugged in a USB hard drive. It froze up, and I had to reboot my system. It’s running beautifully otherwise.

  36. Zaghadka says:

    Success!

    Athlon XP 3200+, Radeon X850 pro video (12 pipelines, 256MB RAM), 1.5 GB single channel RAM. Windows XP-32bit SP3. All manner of background apps running.

    Takes about 4-5 seconds to initialize, then runs at ~35 FPS with bloom, 75-100 FPS without bloom.

    Nicely done, sir.

  37. Rattus says:

    1) GREAT WORK!
    2) Even with FPS over 30 ( more like 50+ ) i’m getting choppy camera movement in screensaver.

  38. Bryan says:

    In case you’re interested:

    I’ve done a bunch of cleanups in my fork at github (mostly case and backslash issues, but some C++-ification as well, using more of the STL). It should still compile on VC6 (if I remember that environment well enough); if you want to try pulling any of my commits that aren’t in your tree at github, go ahead. I am not sure whether VC6 is smart enough to do and its std::sort(), but hopefully.

    I’ve also wrapped GetTickCount in a custom function (calls GetTickCount on Windows, or gettimeofday elsewhere). Along with a few other cleanups I don’t remember at the moment (should all be in the commit messages).

    (It doesn’t quite compile on Linux yet, but it’s a lot closer with these changes. :-) )

    I assume the skeeto/pixelcity.git tree’s interface makes it easy to pull these changes? The “fork queue” link looks like it should help — or at least, it looks that way on my page.

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

  39. DaddyHoggy says:

    A whole bundle of questions and apologies if they’re answered elsewhere and if they seem a bit noddy!

    Firstly though – performance:

    PC1 – My hand-built (from other’s discarded parts) main Machine.

    XP SP3, Athlon XP2800+ (333MHz Barton), 1GB DDR333 (512 x2 Dual Channel), nforce2 mobo, 128MB Leadtek A350 (FX5900XT, 8x AGP).

    Irrespective of running as a screensaver or from the Command line I get no less than 15fps and no more than 19fps.

    PC2 – My wife’s work Latitude D630, XPSP2, 2GB RAM, 2GHz Dual-Core Centrino, 384MB shared Intel GMA965 gfx.

    Can’t run it as a screensaver as it’s locked down but from command line running I say I get about 2-3fps which just goes to show how much Intel integrated gfx suck.

    Right questions:

    Everybody is talking about all the fancy options but how do I access them? If I run it as a screensaver on PC1, clicking the “Settings” button when selecting PixelCity as my screensaver just results in it starting again in the tiny preview window. On both machines running it from the command line creates a pixelcity.ini file but apart from the obvious about windowsize what do the rest of the settings do?

    Bloom, fog, in-built fps – how? is this related to the ini?

    Finally, went to location of the source code – clicked the download button – nothing happened – am I being dumb? Do I have to join or register or something first? (IE6 on wife’s machine – FF2 on PC1) – I want to give the code to my students so they can be amazed and overawed and suitably inspired to do something equally sublime for their projects!

    Again, apologies if I’m being dim – but go gentle on a newbie.

    TIA

    DaddyHoggy

  40. C-Money says:

    @Robinson:
    How in the world is the machine that you just described only 3-4 years old? I think I had a machine comparable to yours (though with less memory) about 8 years ago…

  41. Zack says:

    Actually F1 didn’t work for me until I turned on and off textures and then it appeared, seemed kinda random when the help would render. I was only able to get the city to render in wireframe at 10 FPS as well, I wonder if my video card does not support some of the texturing features you use. Like a earlier user when textures are enabled buildings are large pastel blocks, disabling textures I get everything to run fairly smoothly.

    Win XP SP3 Intel Core Duo 2.13GHz 2Gig Ram.
    (I am using dual WS monitors with a crappy Dell built in graphics card with way too little memory for the textures, but this is at work. :-P)

  42. DaddyHoggy says:

    Hi Shamus – thanks for the speedy response. Ah hah! Your link to Google Code works a treat and therefore one final noddy question – do I need to mandrolically need to download the individual files? Or is there some kind of zip file somewhere with all the necessary .h and .cpp files in it. Did look around the site first before asking such a potentially dumb question – so sorry if the answer to this is obvious. BTW – latest version is Soooo much faster – even on my wife’s nasty D630 (good work loptop but terrible for gfx!)

  43. DaddyHoggy says:

    Forgot to say that’ll mention this fabulous screensaver next time I blog…

    I’ll plug it on my Facebook too – it needs to be seen by everybody!

  44. Colin Thompson says:

    I really enjoyed following this project of yours and being able to see the final result, it looks fantastic.

    I would like to pass on a few ideas I had while playing around, maybe they are of some use.

    The street lighting, it seems to me you have far too many lights surrounding each city block, looking at pictures of real life cities, you’ll see 2-4 sets of lights along the side of any given block, but your’s seems to have somewhere around 20 or so? also, they seem too large in comparison to the size of the car lights & windows, I think in real life they’d be only a little larger but have the same amount of diffusion.

    Another thing is building types…. maybe some church type buildings? every city has something similar, Maybe the odd clock tower/Big Ben/or clock face dotted around. some lower level Signage/billboards. I know, you aren’t going for great detail at street level, or for adding too much complexity. Just thought I’d put some ideas out there.

  45. Bryan says:

    OK, another update on the port I’m doing: I CAN SEE A CITY! o/

    Well, most of one, anyway: it doesn’t do text yet. It also doesn’t quite work right with all the keys, or the mouse buttons (but arrow keys, F-keys, pageup/pagedown, and escape work). :-)

    I should note: when the default return value of IniVector() is a zero vector, and you run the program for the first time in non-SCREENSAVER mode (with no INI file present), the camera’s initial position is (0,0,0). This means that the camera can’t actually see anything. This caused me to waste a few hours trying to figure out *why* the program wasn’t showing anything, assuming I was setting the window up incorrectly (so it wasn’t showing GL results that were obviously supposed to be there). But no, hitting F5 finally fixed it. (Duh…)

    I’ve committed a change in my github repo to call CameraReset() from CameraInit() if the position and angle vectors are both zero. You might consider pulling f920c5cd; it should be self-contained.

    Also, I’ve reworked the (broken!) way that I was doing the “struct entity” wrapper around the CEntity pointers (in Entity.cpp), where it was wrapped into a std::vector to automatically destroy the CEntity instances when the vector was cleared. When I wrote that, I had forgotten that STL containers do a *lot* of copying (copy constructors, operator=, etc.), and deleting the wrapped object from the wrapper class’s destructor is horribly wrong.

    (Saw this via a glibc “ZOMG you have a double-free!” crash after one entity wrapper got copied twice, and the destructor was called on the source of the copy, deleting the same pointer twice.)

    I’ve added a really basic shared-pointer. See the state of Entity.cpp / Entity.h after commit 30646fe9, which should include all the previous fixes:

    302d852d (initial attempt, crashed)
    7bc7366e (yours)
    7b265b8a (mine: pulled your change in)
    8e643fb1 (fixed the double-free initially)
    28188eda (added the shared pointer)
    30646fe9 (added a typedef to make the names shorter)

    All of these together should make the entity-tracking a bit cleaner.

    (Finally, it’d be great if you could merge some of the initial changes fixing capitalization on includes, and maybe the change that added the GetTimeInMillis() wrapper. Ideally I’d like to eventually get all my changes merged in, making the sources as you distribute them cross-platform. But that’s just me; VC6 is happy enough for now. :-) )

    Up next: Fixing the keys and mouse, and then pulling in Xft to make the text rendering go… (Though I might have to do those tomorrow.)

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

  46. DaddyHoggy says:

    Question: As this is a Procedural city should it be random on each (re)generation? If I run it from the CMD line (all I can do on my wife’s work laptop) I seem to get the same fly-by, same buildings, same building names, colours etc…) This is true whether it restarts itself after time X, or if I stop it and then fire up a new instance from the command line. May be it’s not supposed to be randomised, I just thought with it being procedural that it could/would/should be…

  47. Miral says:

    I don’t know much about the screensaver architecture, but my impression (from watching how screensavers behave — from a user perspective, not actually watching code) is that in a multi-monitor setup it creates one window per monitor, not a single larger window as you suggest above. So if the code isn’t written to tolerate two separate cities rendering in parallel, that could be the source of some problems.

    Also: I don’t think the city generation should be bound to WM_PAINT — that seems like completely the wrong thing to be doing. It ought to be generated on window creation as a single task (perhaps on a background thread if you want to be able to provide progress updates on WM_PAINT in the meantime).

  48. Sec says:

    I have one thing to add to the whole multi-monitor setup thing. For me it performs sort of OK with a single screen and bad with dual-screen. I have so far assumed this is because the integrated graphics on this Laptop only supports HW acceleration on one display at a time. — This may be completely wrong, but I was operating under this assumption for a long time now. Maybe one could check that by running a windowed version of PixelCity placed across the monitor boundary? Is there an easy way to get the released binary to run in a (fixed-sized) Window?

    Btw.: My Laptop is a Thinkpad T61 with a “Quadro NVS 140M” running on Windows XP and a dual-monitor setup (1680×1050 + 1280×1024 @ 32bit). It runs at 20fps if bloom is disabled and somewhere in the single-digit area with bloom enabled.

  49. Great project. Are you aware of Infinity Universe? (http://www.infinity-universe.com/). A procedurally programmed universe. Looks like you guys can learn from eachother.

  50. [...] 7, 2009 Final blog post out of a series of fourteen by Shamus Young documenting the development of a procedural city [...]

  51. Darren says:

    Found out about this project from Kotaku. A very interesting and cool read!

    I got about 60 fps without bloom, and 20fps with bloom (1920 x 1080 res).
    -Athlon 64 X2 4200
    -Nvidia 7800GT 256mb

  52. Sandman4432 says:

    Nice work, this whole procedural stuff is pretty amazing, have been spending all my time (I should be working) reading up lately and trying to learn it for textures, this building stuff, etc.

    Your screen saver runs perfect on my machine.
    Usually get a steady 20 fps, never varies.
    Takes about 3 seconds to load (max)

    3040 X 1050 (dual monitor)
    AMD Phenom II (~3Ghz)
    GeForce 8600 GTS

  53. Noah Lesgold says:

    When you were doing this series, I was using an 8 year old desktop that could not even get through building the city. I just got a sweet new PC and it occurred to me that I needed to check this out. It looks sweet as heck, and plus I am pleased that the new rig runs it very well. Good times. :-)

    Thanks again for this article series – I found it quite intriguing.

  54. koala_man says:

    Fantastic series on a positively romantic endeavor. I love the writing style!

  55. Hiroe says:

    first thing I did upon discovering this is emailed the guy at
    http://rss-glx.sourceforge.net/
    about this. well see if he’ll convert it for you.

    second thing is I have an idea of what you could do with it, it would be a fair amount of work but awesome. the game play in this http://www.wolfire.com/black-shades would fit very well with your demo and you definatly have the skill to pull it off. throw in some closed source extensions to allow for missions and a storyline, make sure it’s cross platform, and I’ll buy it.

  56. nfwu says:

    Just a headsup: Mac users can run the screensaver under WINE (Wine Is Not an Emulator). It runs at a fairly consistent 19 FPS with any combination of settings, so I put the low-ish framerate as due to the hoops that Wine jumps through.

    Note that the /s command line parameter is required for some reason. Command+Tab to the X11 window (without touching the mouse) for the keypresses to be picked up my the program.

  57. Kimari says:

    Hey Shamus, I think I noticed your pixel city being used in this video right here: http://www.youtube.com/watch?v=q73NsYxadaw at the 3:30 mark. It’s a shame that the video hasn’t got any sort of credits in the description.

  58. jim d says:

    Such a great screen-saver, thank you! Just re-installed after upgrading my computer. If I ever get some spare time I’d like to use the source and and a ‘settings’ dialog that lets you configure the building titles (unless there’s already a way to do such a thing?”) Anyway, great work, and thanks again for releasing it to the community.

One Trackback

  1. By Procedural Content Generation: News on May 15, 2009 at 9:19 pm

    [...] 7, 2009 Final blog post out of a series of fourteen by Shamus Young documenting the development of a procedural city [...]

Leave a Reply

Comments are moderated and may not be posted immediately. Required fields are marked *

*
*

Thanks for joining the discussion. Be nice, don't post angry, and enjoy yourself. This is supposed to be fun.

You can enclose spoilers in <strike> tags like so:
<strike>Darth Vader is Luke's father!</strike>

You can make things italics like this:
Can you imagine having Darth Vader as your <i>father</i>?

You can make things bold like this:
I'm <b>very</b> glad Darth Vader isn't my father.

You can make links like this:
I'm reading about <a href="http://en.wikipedia.org/wiki/Darth_Vader">Darth Vader</a> on Wikipedia!