Interesting option for gfx engine

[Blake]

Introduction: The DDG Toolkit is a Library of C++ classes to build real time 3D graphics applications.

http://ddg.sourceforge.net/home.html

It's opensource and almost cross platform, so could save some time on the graphics.... (or looking at it another way, give us something that looks a lot better....)

Something I like is it is reasonably compact (weighing in around a meg). Worth looking into, anyway.....

[Kurilka]

Blake, do we really need at all such a fullfeatured 3D engine?
IMHO TBS graphics most of the time are 2d. I mean that we could have 3D units and so on, but all of them are on 1 2D surface. And also i doubt that we need such things as terrain and some special effects or something. Of course this would be cool, but when then the game will be finished if we will try to incorporate all cute looking graphical stuff in it?

[DeathByTheSword]

well i would be great for pictures of the units....

[Kurilka]

And BTW there is no much activity, files seem to be quite old - from 2001

[Kuciwalker]

I think a three-d game would be amazing - intra-system warfare would be so much more interesting, and orbits could be simulated better.

[Blake]

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]

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.

* 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.

[Kurilka]

OK then i should take a bit closer look today evening
But why wee need to port OpenGL/GLUT to SDL? As i see it OpenGL (and GLUT) could be used with SDL, with SDL you just make app initialisation and stuff not related to graphics (threads, input and so on). By the way there are some common parts between DDG and SDL (e.g. timers)

[Blake]

Yeah there are some common parts, like some of the I/O stuff, I think the timer in DDG is higher precision tho.

GLUT is used with OpenGL for things like window managment, however SDL does the same for OpenGL, so porting basically involves replacing the GLUT functions with equivilant SDL functions.

Only a relatively small part of the code would need to be ported to SDL because of the way it is structured, the stuff that needs to be ported is primarly the app initialisation code, basically SDL fullfills the same role as GLUT, except SDL is better It would probably be possible to use both, but that should be a last resort...

[DJ]

hehe, for some reason i thought this game was an RTS....

[targon]

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]

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.

[targon]

And check out www.openscenegraph.org, too.

[Blake]

Thankyou for those links, OSG looks quite interesting.

[Blake]

Correction, OSG* looks VERY interesting.

*Yeah, they abbreviate to the same thing, I mean Open Scene Graph

[Kurilka]

And there is osgSDL,
but i'm still not shure that we need such a complex engine...
as i see all we have will be IMHO:
1. Rectangle with tiles on it (textured)
2. Objects on tiles (may be a little bit complex, but not very, as the units should be small we don't need very detailed models) - units, something like weather effects (rain, clouds etc.)
3. Some GUI stuff (but it's 2D, isn't it?)

[targon]

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...

[Kurilka]

For me space combat is something i don't understand at the moment
There is quite a lot of post by i still don't see clear picture...
So I mentioned only "planet" level.

[targon]

OK, as veteran Elite gamer I'm surely know something about space combat
I think that it may be something like IG2 (but with modern graphics) Homeworld or ORB, but with Stars! BattleVCR taste.

[DJ]

I was thinking IG2! Great game...

[targon]

OK, just look at IG3 screenshots... IMHO, StP must be better

[Kurilka]

A link?

[targon]

www.ig3.de

[Kurilka]

But we have TBS, don't we?
And how do you see such nod-discrete (read realtime) combat in TBS?

[targon]

Did you ever played Stars! ? It has something called "BattleVCR" that shows battles taken place in last turn. Civs also show you attacks of your rivals in their turn. This part may be as eye candy as we desire and in fact realtime with play/stop/back buttons << < [] || > >>

[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.

[DJ]

IG3 is made by a completely different company then the ones who made IG1 and IG2.

[targon]

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.

[targon]

You may also chech out here:
http://www.quelsolaar.com/technology/verse.html
and around.
http://www.quelsolaar.com/quelsolaar/index.html
I think these engine is't what we're looking for (but who knows?) yet its client-server aproach deserves some attention.

[Frozzy]

Originally posted by Kurilka
But we have TBS, don't we?
And how do you see such nod-discrete (read realtime) combat in TBS?

IIRC, a while ago the basic outline for gameplay was an RTS/TBS hybrid. Much like pressing pause in the middle of an RTS to hand out new orders.