 |
| |
|
|
Blake
|
 |
Brainfallocatione
Oct 2000
time: 17:24
|
|
Kurilka, you are quite correct that we dont *need* such a full featured 3D engine, however DDG is not a 3D engine, rather a toolkit (it's a library) so we can just take what we do need. With such a library we could feasibly do things like low flybys of planets which would otherwise require a lot more time and an unreasonable amount of effort to code.
The normal game mode would lock the camera into an above view of the planets surface, that can be scrolled around and stuff, making the control the same as any TBS (or RTS, for that matter).
While it would be interesting to have a full 3D starmap as well, I'm not convinced that such a setup is better, it is generally not easier to play, it might look amazing, but it might also play amazingly bad 
|
|
| |
|
|
|
Blake
|
|
Brainfallocatione
Oct 2000
time: 17:24
|
|
quote:
And BTW there is no much activity, files seem to be quite old - from 2001 |
Yes but because it's opensource we can hack the source as nessecary, the library itself seems very well designed, with rendering classes and 1 class per file.
Looking into it briefly, what would be required would be:
Port the OpenGL renderer (GLUT parts, anyway) to SDL.
Maybe do the same with the I/O and/or event stuff
But look at the feature list, it has all sorts of stuff we need, I underlined stuff that grabbed my eye, as not directely related to rendering terrain, but still required.
quote:
* Has 2/3/4D Vector, Matrix classes.
* Angle class for degree to radian conversion as well as LUT versions of sin/cos.
* A Utilility class for min/max interpolation.
* A String class for pure C++ string operations.
* Error handling infrastructure.
* Clock to measure time, scalable for simulation.
* File logging class, console output class.
* List, SplayTree classes with iterators.
* Multiple Viewport architecture (allows for PIP/HUD). supports keyboard and mouse control via EventHandler classes.
* A Control class to control events and bind to keys to actions.
* Scene graph architecture allows multiple Cameras to view the same scene with independent Contexts.
* Bounding Box, Convex Hull classes. and Octree classes for View frustrum and Occlusion culling
* Easy scene graph construction.
* New classes can derive from Node and Group classes and plug into Scene.
* Transformation node and Scale, Translate, Rotate with support for bill boards.
* Color and ColorGroup classes.
* Material, Light LightModel and Fogclasses.
* Text class to render text using sprintf like functionality.
* Image buffer and Texture classes which can read/write RGB, TGA, frame and z-buffers.
* Support for Terragen's height map format through the heightmap class (also support for DEM and other formats).
* Performance measuring infrastructure allows you to record and play back 'flight' paths and record their performance to log files.
* 3D/4D Noise (Perlin/Wyvill/Turbulant/Spectral) functions.
* Generic objects like Box, Cylinder, Axis, Grid, Lattice, Camera and Light.
* 2D HUD objects to provide onscreen information include a texture based Text class and a Histogram class.
* Geodesic object to create faceted spheres with visiblity culling for Domes.
|
|
|
| |
|
|
|
DJ
|
|
hehe, for some reason i thought this game was an RTS....
|
|
| |
|
|
|
targon
|
|
Dolgoprudny, Moscow region
Nov 2002
time: 08:24
|
|
Blake, FMH if I'm wrong, but GLUT and SDL are _very_ different. SDL offers fast cross-platform blitting, window/resolution management, sound support, some image loaders, rudimentary threading support and some other things such is OpenGL context handling. GLUT is completely other thing, it looks like window toolkit with OpenGL support, it has event loop with callbacks, own keyboard/mouse handling etc. IMHO, GLUT is for programming examples and toy projects while SDL was used for many serious projects (e.g. porting commertial games to Linux)
|
|
| |
|
|
|
targon
|
|
Dolgoprudny, Moscow region
Nov 2002
time: 08:24
|
|
Concerning other's 3D engines, I could say that good library design with lots of features is good but 3D technology grows explosively today, so 3D engine last updated at 2001 may be very stale and unhealthy in sense of modern views. Let's count
1) Once upon a time, were glBegin/glEnd
2) They born display lists
3) Later, client state and gl*Pointers were introduced.
4) Display lists and arrays give a strange crossbreed called compiled arrays (used in Q3 engine)
5) Next, vertex programs (AKA shaders) were born. This stuff may drive things like grass renderning, refraction, IK, motion blur and many others on accelerator side. Fragment programs (AKA pixel shaders) may give your surfaces completely other taste, with loads of things later known to offline special-fx only.
6) Today, modern graphics engines use both vendor-specific modifications of arrays allowing them to do their job without tight sychronisztion with accelerator and vertex/fragment programs to inprove visual impact and rendering speed.
So what stage of the above was the last for 2001 year amateur engine? 2nd, I fear, or better, 3rd. Third is critical, HW T&L begins approximately here, and real perfomance of modern 3d cards too.
If you seek for reasonable modern 3D engine, I suggest your look at Open Scene Graph, www.opensg.org. This thing is't revolutionary, but it seems to improve.
Last edited by targon on 17-12-2002 at 16:04
|
|
| |
|
| |
|
|
|
targon
|
|
Dolgoprudny, Moscow region
Nov 2002
time: 08:24
|
|
IMHO, you may use as simple engine as you dare, but only if you will be able to switch to something better at any time. Open-source project community is _very_ different form commertialware, as open projects live as long as someone needs it. This comunity promotes code reuse, too. So last thing we need is our beloved StP tied with messy graphics and the only way to get out as complete rewrite from the scratch. This is silly, among other things.
So either write graphics code _true_ modular (so funky things like Cg may be added without much of pain) or use some existing general-purpose engine with all these things available from its roots. In later case, we will obtain another collective of 3D guru and their community as our best friends rather than our own buggy code. I'm just an artist , but I love OpenGL and computer graphics and I know that burden of programming without some good scene graph implementation grows exponentialy with increase of features.
And one more thing about tile rendering: did you mean that space combat will be something 2d tiled? Oh no, do't spoil good game from beginning, it's to young to die, please, dear developer, think again! Eye candy can't make turn-based game worse than its gameplay, belive me! Just imagine epic battles, mysterious space wonders and all these alien worlds, properly rendered, realtime! Nowdays, even cheap 3D cards offer great rendering power, so why we stick to old century style of graphics? I'm hungry for drawing all this beautiful graphics, and I'm sure other from artist group too, so do't backstab me, us and entire community! Universe awaits you...
|
|
| |
|
|
|
DJ
|
|
I was thinking IG2! Great game...
|
|
| |
|
|
|
Leland
|
|
A long time ago, in a message board far, far away (read: old FreeAC discussion forums) the battle system was outlined as such that the battles do in fact occur "for real" instead of being just statistics, but the units follow very simple rules (for example "shoot, move forward, repeat until dead") instead of complex AI so that the battles can be simulated in advance to some extent. So, it's not just eye candy, but an integral part of the game mechanics. If my memory doesn't fail me, Stars! was even mentioned as one of the inspirations of this idea.
|
|
| |
|
|
|
targon
|
|
Dolgoprudny, Moscow region
Nov 2002
time: 08:24
|
|
quote:
Originally posted by Leland
... the units follow very simple rules (for example "shoot, move forward, repeat until dead") instead of complex AI so that the battles can be simulated in advance to some extent. |
I fond of Stars!; it's simple yet very playable game. But Stars! were plagued with various glitches in targeting code and so on, so crafty people exploit this flaws in order to obtain unrealistic results (infamous "chaff" etc). For me, simple is "easy to break and spoil" by not too kind fellows.
So units may be controled even by complex rules, but compute it _once_, record via some format (for example, interpolated positions of units with "fire", "dead", "hit" marks etc) and play as gamer desires.
|
|
| |
|
| |
All times are GMT. The time now is 05:24.
Apolyton Time is 00:24. |
top of page
|
|
|
Forum Rules:
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts
|
HTML code is ON
vB code is ON
Smilies are ON
[IMG] code is ON
|
|
|
|
|
|
15-12-2002 14:19
|