PixelCity update 1

In the last entry, I forgot to include the progress made so far. I’ll dump that here then move on to the progress this week.

First up is the texture generation. Starting with windows:

Basic window texture

Nothing too fancy to begin with. I later discovered that there was an issue trying to push too many vertices. Reducing the texture memory helped, but I don’t like how fast-and-loose I’ve become with the project so far. The source code for it is quite unsightly.

I exposed the Kamui statistics via a set of diagnotic displays that have been bounds to function keys and is always active in the debug version of the game:

Kamui diagnostics panel

After the windows came the sky cylinder texture. It’s got quite some way to go before it’s useful. At the moment, it’s broken and I only managed to get these two captures. The first one is testing out a circle texture that fades to black at the edge and the second one fades to white. I’m not sure which one I prefer.

Skyline with a circle fading to black Skyline with a circle fading to white

Lastly, there’s the buildings themselves. The first image is the building without any trim, while the second one puts a hat on top.

Building without a hat Building with a hat

So far, it’s just some simple buildings. I decided to eschew textures when testing the layout, as the pattern was fairly distracting, especially without any mip maps.

That was everything that I had ready with the previous entry.

At this point, I wanted to get the building generation down from the ten minutes it was taking. Initially, I used the same method as Shamus. A big block of data (1MiB) to hold the 1024^2 map. There were a few problems I could see. Number one was the size and number two was accessing the data while keeping the cache happy. I’ve elected to use a loose quadtree to handle the allocation of buildings within the empty lots. It has the time down to 6 minutes, so it’s better, but not great.

The first image shows the inital quadtree setup with around 48 buildings. The colours assigned are white, green, blue, yellow, and red, in descending order. For the test, the yellow and red were transposed, after this image they should be correct.

Quadtree test

Next, I had hit a bit of an issue with the way I was inserting data into the quadtree. The rest of the buildings were off to the side due to how I was iterating over them.

Quadtree population issue

After that was resolved, the whole area was populated with buildings. There is still an issue with the buildings preferring to stick to the west side more than the east.

City populated

Here’s a screenshot without the quadtree visible.

City populated (no quadtree)

Today, I started on laying out the lights. At this point, the clumsy rendering that I’m doing is really starting to take its toll. There’s around 20,000 polygons and the framerate is going down to 25-30FPS.

I cleared out the buildings and added some different colours for the roads.

Street lights

Aliasing makes the image harder to read and I’m not sure if I can use antialiasing without getting into the single digits for the frame rate.

With everything enabled, this is what we get.

Roads, buildings, lights, and quadtree

It comes out to 30FPS when the quadtree isn’t being rendered. I still have a lot more to add before this is even close to done. Next, I’m going to add the texture to the street lights and will add more variety to the building types. I have to add the top of the building back for these simple buildings, too. Mip mapping and twiddling the textures will follow, as will using the render passes to break up the scene. Hopefully, that helps when it comes to rendering the translucent objects.