For anyone that knows one of these games, I have some questions. First, they ran fine in a 386, at 320x200 (a ridiculous resolution nowadays, but more than enough for the time) and have textures, flat shading, some transparency effects, and a huge galaxy, with very complex solar systems. Not to mention the physics...
My question is, how the hell they have managed to do that? I''m pretty certain that, If I could implement the same thing in OpenGL, without a powerful hardware accelerator(mind you, at a higher resolution, like 640x480) I would not get a decent performance. But they did that in software! I know they sacrificed resolution, texture detail (after all, the original game took 3 discs) and probably used a palleted mode.
Another question... the near and far clipping plane. If I have a planet 60AU away(I''m using Frontier units, think of this as veeeery far away...) the planet should be invisible. So far, so good. But I cannot draw the planets this way. When the planet get closer, It should get bigger on the screen. But wait, the planet has been clipped by the far clipping plane, so it is invisible. Only when its extremely close to you it''s polygons will start popping on the screen. How to avoid that? I believe you can put the planet very near to you (in opengl coordinates) and resize the planet as needed. But this is a complicated solution. Is there another one?
Firstly, due the the sheer distances involved, using built in (c/c++) data types is insufficient. for example:
int 64 = +/-9.7 lightyears, with a resolution of 1 millimeter
Now, in terms of galactic scales, this is totally insignificant, depending on what you are trying to achieve.
I''m doing a similar thing right now, but i want to be able to use one coordinate system for an entire universe, so it''s possible to fly from one star to another, without the need to ''hyperspace'' between them. It will also show accurate star positions from any position in the universe.
the only way to do this, is to use your own large data types. I''m going to be using signed 96 bit itegers, which give a universal scale (accutare to 1 millimeter) of:
+/- 48,873,004,216 lightyears
Now that''s accurate enough for everyone!
However, serious clipping problems can come into effect if you''re not careful. To avoid these problems, disable all depth buffering when drawing stars, and distant planets, and re-enable it for close planets. just make sure you draw the furthest planets first. To further enhance depth buffer usage, you can also change the near and far clipping planes to suit the distance a planet is away from you.
Well... I''ve seen what assembly can do, in the hands of an experienced programmer... just take the game Frontier is based upon (Elite). It ran on my MSX, who had a memory capacity of 64kb total, powered by a less than 4 Mhz Z80 processor (8 bit registers), 16 kb of video memory(it used a graphics processor, so the cpu wasn''t on charge of updating the display every refresh). It was the first time I saw 3D graphics on a personal computer (Polygons, no filling). Ah! Even particle systems!
Fly from one system to another? In your universe, does the lightspeed barrier apply? Even a flight from our position to the nearest star at lightspeed would take more than four years...
As for the clipping problem, Frontier uses bitmaps for objects very far away... "popping" is very noticeable, but it gets the job done quite nicely.
But what if I want to make things more on a scale? I''ve noticed that the stations on that game are not as big as one would expect, compared with the size of the ships (but they still look convincing). The stations could be so big that I couldn''t fit one inside the view frustrum. Of course, this is not an issue with just this kind of game; if I make an 3D RPG and I want to render a big landscape I may not be able to display it all. Of course, fog in space is not an option