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