Large scene rendering
There is one thing I don't like about floating point and integers and that is that they consist out of only certain amount of bits. An integer is at least 32 bits (on 32 systems at least). A float is also 32 bits. A double is 64 bits.
Since I'm currently thinking about a space game, I was wondering how to create a huge battle field (a whole solar system) in real time while having all the precision I need.
Doubles are not fast and take a lot of space and although I don't worry about space, speed is a bigger issue. If I want a huge battle and here I'm going to throw some numbers: One side can have as maximum 85 huge ships, 3010 fighters, makes 3960 weapon slots, which makes 19800 bullets flying around. And that is only one side. Since I need two sides for a war, I need to double the values (190 ships, 6020 fighters, 7920 hardpoints, 39600 bullets). Lets say that everything is represented by one location (which a 3D vector) it would mean 53730 locations. 53730 locations times 3 would be 161190 and that times sizeof(double) would be 161190 * 8 bytes = 1289520 bytes (about 1MB) which is a lot to start with even if you ignore the fact that the problem is more that I have a lot than the doubles are bigger.
As I was considering the problem I realized something else. When I'm rendering, I will need to use floats. DirectX 9 requires floats and although I could send doubles it would half my data bandwidth. So what ever I choose, in the end I will need to use floats unless I want to have some penalty.
Using doubles for vertices are is a bad idea for the sake of precision alone.
But then I started thinking...
I don't need to render using doubles, I can simply render everything with floats and to ensure that precision is maintained. If something is not within the safe area of floating point rendering (let's say floats can have a maximum of 1024, and yes I now it can be a lot more) but the object in question is 2048 units away, I still want to render it. You can't simply let a sun disappear because it is beyond the range of your numbers, that would be weird.
Instead everything that is more than 1024 units away will be rendered first (farthest away first) and the distance also scales it down. Than I clear the Z buffer and render everything in the 1024 range.
1 2 3 4 5 6 7 | Sun has a size of 100 Sun is 2048 units away Sun needs to be rendered. To render it but maintain the correct look: Scale sun down so that at 1024 it would have the same size on screen as if it was rendered at 2048. |
It was so simple that I thought it was silly I never thought about it. How you scale it however depends on the view and projection matrix.
I'm still not certain if I want to use doubles, but for my second problem I have a solution. Now I need to find one for my first.
Developing for the iPhone
For those who follow me on twitter this post is old news or it might be a minor refreshment as the majority of the content has already been posted on twitter.
At my internship I have been developing for the iPhone and boy oh boy, can I make a list of things to complain about. Luckily there are also a few good things and they balance each other but it’s a pain when you cannot unleash every bit of skill you have. Let’s start with the sour part.
- There is no stencil buffer. I think that the stencil buffer is as old as Duke Nukem 3D, which was released in 1993. It’s used for shadows and a few other things. However for some reason it is not supported on the iPhone (at V2.2.1 but this might change in the future) and it makes no sense.
- Secondly the iPhone is under clocked (meaning the CPU is running at lower speed than what it should run at). The majority of the hardware these days are able to dynamically set the clock speed of the hardware. I can accept the reason why apple has done it (preserving the battery) but when it comes to games it’s like with racing cars. You don’t want a F1 car being capped at 120 KM/H because you aren’t suppose to go faster than that on the highway. In apple’s defense, the iPhone has never been intended to be primarily a gaming device.
- Third is apple is really strict in what is allowed or not and some parts of the iPhone (like the photo camera) should only be accessed by calling a function and then except you have no longer control until a picture has been taken using the graphical user interface apple designed. Using it directly in some other fashion increases the chance that the application will be rejected. On the other hand some applications are allowed because some big guys back it (google is one of the companies that ignored the guidelines of apple and still got accepted).
There are still a few other problems (no multitasking for example, API might break with new firmware update) with the iPhone but let’s move on to the sweet part of the iPhone.
Actually the only one I can think of is that the distribution of applications can only be done through the apple app store. There is no such thing for the windows mobile or symbian. This way apple can also guarantee the quality of the applications, however I find it a mood point since an application that is poorly written is unlikely to be successful.
Actually there are a few more things, the emulator is good (better than the one for the Nintendo DS) and the API is reasonable documented (inconsistence in quality, but overall reasonable).