3D framework / game engine related resources

T

TerryP

I've a few projects planned for creating a couple games, of which they are supposed to be generally portable Win/Lin/Mac/BSD, and for which I prefer to be able to do testing on the platforms I personally use (FreeBSD/WinXP), but the pickings don't look promising. Is there actually anything decent available on FreeBSD for dealing with 3D graphics, that isn't outdated as hell?


In looking through the ports collection at stuffs that may help out on the 3D side of things, this is what I've noticed in the past year:

  • Irrlicht is one major version behind. (1.5.1->1.6)
  • CrystalSpace is so outdated compared to present developments, that it may as well be marked unmaintained. This is so horrible, I've emailed the maintainer to see if he/she is alive... lol. The only upside is the Makefile appears to offer multiple language bindings, assuming they still work. (1.0.x->1.2,1.4,1.9)
  • Py-Game is about the only offering for Python that appears maintained (1.8.x->1.9.x), I have not *dared* to look at other dynamic languages.
  • Py-soya3d is even more out dated then the CrystalSpace port.

Various Id Tech Doom/Quake derived engines aside, the selections are pretty damn slim.... SDL 1.2 and several OpenGL related libraries aside.... it seems all there is, is essentially the current stable version of Ogre 3D.


I have yet to try linking code against the Ogre 3D in ports, but having tested builds of Ogres trunk on FreeBSD 7, the experience proved to be "Exceptionally irksome" to say the least about run time. Which presses things back to dealing with SDL and OpenGL by hand. Everything else in ports is so hellishly outdated that I haven't tried seeing if newer versions of the previously listed software compiles without additional belly aches. So... this suggests the only thing reliable is using SDL or OpenGL by hand, unless one wants to hack at ioQuake3, prboom, or something similar until it works.



Am I missing something, or is using FreeBSD as a development platform letting me down for the first time ever?
 
Personally I use pure OpenGL (with FreeGLUT (static))
It really isn't that hard to use with a bit of playing and is what the *nix version of Irrlicht and ID software games are based on.

It works great on FreeBSD!

If you believe it to be a bit "raw" for you, then I strongly suggest Irrlicht. Its very clean and gives you the freedom to use pure OpenGL if you want for cool shaders etc...

Don't start with ID's engines (quake, doom etc...) They areally arn't meant to be used as standalone engines and will limit you in what you may want to create...
 
adamk said:
So what's wrong with the "Various ID Tech Doom/Quake derived engines"?
Click to expand...

Nothing, if you're creating a game that can take advantage of such an engine -- or wish to abuse it into becoming something it's not.


kpedersen said:
Personally I use pure OpenGL (with FreeGLUT (static))
It really isn't that hard to use with a bit of playing and is what the *nix version of Irrlicht and ID software games are based on.

It works great on FreeBSD!

If you believe it to be a bit "raw" for you, then I strongly suggest Irrlicht. Its very clean and gives you the freedom to use pure OpenGL if you want for cool shaders etc...
Click to expand...

From what I've been able to find, it seems that it's possible to use FreeGLUT under a Win32/MSVC environment. I'm not familiar with OpenGL issues under Windows, other then the SDK came with revelvent headers and libraries. I assume FreeGLUT would work on OSX as well as it does on FreeBSD and Linux.


The idea of working straight in OpenGL doesn't bother me personally, but the features offered by things like OGRE, CrystallSpace, Irrlichet, Delta3D, Panda3D, etc... when it comes to loading 3d models out of file format xyz, animation tasks, shadowing and lighting effects, all sorts of stuff like that;the idea of rolling such things by hand starts to feel some what superfluous. For everyone else using FreeBSD, GOD only knows what resources other individuals may demand when it comes to engines, components, and fun, lol. Even for simple algorithms, I've seen people vary from not being able to code their way outside A Paper Interface, down to shunnful NIHs.


For my own projects, I intend to develop a loose frame work to share common code between them; issues any game will need to sort out. Not so much a game engine as throwing the glue on the fire pit. Present open loops could easily be done in OpenGL for some and any suitable FPS engine (prboom, ioquake3, sauerbraten, etc) but such a split would jack development time up several extra years.


Only Irrlichet seems to be suitable item for relying on ports as a way of 'easy installation' purposes, without having to practically build a new game engine around OpenGL :-/.



kpedersen said:
Don't start with ID's engines (quake, doom etc...) They areally arn't meant to be used as standalone engines and will limit you in what you may want to create...
Click to expand...

I've great respect for ID's engines, but always try to remember that there original purpose, was for the game they created for (e.g. Quake). The architecture of Id Tech 3 represents a lot of things I like and supports every important feature (for a shooter), but it's quite a lot of stuff to wade through in order to make something, other then Yet Another Quake III: Arena clone.

Your advise there however, is probably the best that's been given on such subjects in a long time.



If I was going to develop the next action shooter as a commercial product, I would likely try licensing ID Tech 5 or Jupiter Extended. For creating games that will largely exist for my own enjoyment, and anyone else who cares to play them, leveraging libraries beats dealing with any given engines particulars, hands down. I favour tools that help get work done, over having my hand held while it rides the SOE.


==
``Thou shalt study thy libraries and strive not to reinvent them without cause, that thy code may be short and readable and thy days pleasant and productive.``
 
Personally I wouldn't be so quick to dismiss the Q3A engine. It did a great job with American McGee's Alice, which is not your typical FPS.

Adam
 
adamk said:
Personally I wouldn't be so quick to dismiss the Q3A engine. It did a great job with American McGee's Alice, which is not your typical FPS.

Adam
Click to expand...
Yeah, that was a cool game. :)
 
You must log in or register to reply here.
Back
Top