Monday 31 December 2007 at 12:36 am
I'm in Sapporo now, where we will stay for 5 days. What's even better is that it's snowing (I don't like hot weather, in case you don't know. And when I say "don't like" that's an understatement :) )
Now for some photos:
This is the view from a window of the first hotel in Narita looking out over the hills.
Downtown Narita - building rooftops.
Looking up the tower you see on the left of the previous photo.
Looking down the road (near where previous two were taken)
Entrance to the
Narita-san temple.
This is the temple itself. Well, the roof of. It's simply massive.
Boeing 747 in the foreground, industry in the background.
View from the hotel's glass elevator.
Monday 03 December 2007 at 12:20 am
The OpenGL rewrite has begun. That said, I do have slight regrets as it means I can't do a Maemo port. This is because while SDL is supported on those devices, OpenGL isn't. The problem is, though, that if the software-based rendering library is getting on the slow side for a 1.33GHZ G4 (and according to Shark, spends 98% of it's time in SDL_BlitSurface). Now imagine what it will be on a ~300mhz ARM CPU. Not good. And the PDA's screen is running at a similar screen resolution, which is rather cool, but not in this situation (800x480 on the Nokia tablet, 800x600 in a window here).
There could still be some optimizations to do here - and smarter ways of doing things, but it's going to be a lot faster in OpenGL.
But those of you who remember what kind of hardware SimTower originally ran on are probably wondering why zTower can't do it. There are a few reasons for this:
1. In those days, directly accessing video memory or the window contents buffer was not unheard of. While SimTower may not have done the first, I can't tell for sure whether it did the second (and can't be without the sources). And drawing library routines were so much faster in those days.
2. SimTower used a 256 colour pallete. It used this not as a limitation, but as an advantage. If it wanted to draw the sky a slightly different shade of blue - it simply reassigned the sky colour in the colour pallete to that shade. One graphics call. We cannot, however, put the monitor into 256 colour mode, or use a 256 colour pallete directly mapped to the video hardware (not really supported in a modern OS, again - nobody uses 256 colours any more). Instead, we have to make 473600 modifications to the pixels being drawn (800x600, minus 8 rows for the ground at the bottom). Which is a little slower. And we have to do that every frame. Then we have to redraw things - SimTower was very careful about what it redrew.
3. SimTower may have had assembly components in it. Again, without the sources (Actually, I would love to have the sources, and do a port to OS X - that's the reason I started this project, so we can have a game like this again), I can't tell. Given that it was ported from Windows to Mac, it would not have had much assembly (Given that the Mac version was a "Fat" binary (68k and PPC), and the Windows version (x86) were all produced, spanning three architectures, it seems unlikely any assembly was contained). While I could do this - again - I have to port to multiple architectures and OSes. (OK, and I don't really know assembly.)
Number 2 in the list is mainly what I suspect was responsible. Plus, I would think it was very careful in the way it reused screen images. zTower is careful, but it redraws in many circumstances where it is not necessary. OpenGL is a lot better for this - the OpenGL version can afford to be indiscriminate. I don't have to be as careful with what to redraw - I can simply re-render the entire frame. Each object (office etc) to draw onscreen - that's one polygon. Even a big complicated tower will only have a few hundred polygons to draw - that's Quake 1/2 era stuff!
Also, OpenGL has viewports and a lot of other fun stuff - zooming in and out from the tower should be simple to implement! Do that with SDL_Blit calls (only direct pixel copies, no scaling)!
Anyway, onto the code. Here's what happens if you don't clear the screen before rendering (hey, it was my first time...)
Looks rather artistic, actually. But anyway, I digress.
The most annoying thing about OpenGL is the lack of support for NPOT (non-power-of-two) textures. What this means is that the texture has to be 32x32, 32x64, 64x128, 256x32 or some other value that is a power of two. It can't be any size you want. Strictly, this is untrue, as there is an extension ARB_texture_non_power_of_two. The downside of this is that it's not supported on all graphics cards, and OpenGL implementations. To keep things simple, and guaranteed to work, textures should be kept to powers of two. A simple image loader was written that works out the next biggest power two is, creates an empty image that size, and pastes the desired image into the top left corner. When we render this, we get...
... openGL squashing the whole texture, empty space and all, into the original area. Of course, it's only doing what it's told. What needs to be done is to work out what proportion of the power-of-two adjusted texture (is it half? 0.67? 0.75?) is the actual texture, and tell OpenGL to use this (left 0.67 and top half, for example). Got that? Here's what it then renders.
It's now in the right place, and the right size. The reason why it has the bright pink background is because that is the colour key. Pixels that are this colour are transparent. OpenGL doesn't easily support a colour key (yes, you can do it with shaders...), but it has no need to as it supports alpha channels and all. A colour key is used because: 1. In this application, only one bit of alpha is required (i.e. transparent or not transparent), and 2. BMP doesn't support an alpha channel, and SDL only supports BMP images without SDL_Image. The solution is very simple - at load time, why not just go through all the pixels and mark the ones that are the colour key as transparent. This requires changing the format of the OpenGL texture image to GL_RGBA.
I'll give you a hint here:
glTexImage2D( GL_TEXTURE_2D, 0, 3, image->w, image->h, 0, GL_RGB, GL_UNSIGNED_BYTE, image->pixels );
is what you use for a 24 bit texture (RGB), as specified in many tutorials.
So when you go 32 bit (RGBA):
glTexImage2D( GL_TEXTURE_2D, 0, 3, image->w, image->h, 0, GL_RGBA, GL_UNSIGNED_BYTE, image->pixels );
is what you'd suspect you'd need to do. Wrong. Your texture still works, but transparency doesn't. Where's the issue here? See the 3? What does this do? The format of a glTexImage2D call is:
void glTexImage2D( GLenum target, GLint level, GLint internalformat, GLsizei width, GLsizei height, GLint border, GLenum format, GLenum type, const GLvoid *pixels )
If you want your alpha channel to work... you need to make that 3 a GL_RGBA as well. Otherwise, your texture image will be read in as GL_RGBA, but converted to GL_RGB before being stored. This is not what you want. And what took me a fair while to work out!
Now that the alpha works, and there is a routine in place to knock out the colour key pixels, we get this.
... whoops, forgot the 8 pixels for the ground...
There we go - same as before, only much faster!
Though while you may say "It's only the background, now re-implement the rest of the graphics code!" - this is a very significant moment as it's the first bitmap to be drawn. Now that I have the code in there to draw one bitmap, it's a lot easier to draw any other - just change the inputs to the function. More of the tower - coming soon, when I strip all the strangeness out of the code that was made necessary to keep the software-based drawing somewhat fast...
Saturday 01 December 2007 at 12:17 am
zTower is being rebuilt from the ground up (using parts of what is there already). This is the result of profiling showing that it spends 95-98% of it's time in SDL_BlitSurface. Let's let the graphics card handle that one.
On a related note, it seems to run a bit faster on Leopard. I don't think it's the OpenGL improvements in Leopard (it's not OpenGL yet as per above), and it can't be a newer version of SDL (running the same as on Tiger). And I've got a ton of apps going too. Strange.
I think it's because I now have 120GB free for the system to play with on the hard drive. In case you're wondering how I got that on a 60GB drive, yes, I put a new drive in, the old one acquired a few bad blocks, hardly surprising after the laptop's been dropped.
Anyway, I've been busy building a certain camera system. Will blog about that later. And I haven't forgotten Stack Underflow.
