Not logged in, Join Here! or Log In Below:  
News Articles Search    

Submitted by Ricardo Santos, posted on August 20, 2000

Image Description, by Ricardo Santos

Here is a screen-shot of our game engine. Its an OpenGL engine based on an octree-bsp-terrain_LOD technique. The sea cannot be seen in the screenshot but is moving, and so its the sky. Right now is running on a Pentium2 450 with a TNT1 with 16Mb video ram and 128Mb main memory. Its getting between 24.2 and 31.2 fps. The name of the game is Omega2040. We expect to finish the engine with exterior-interior on January. Having beta testing in the same date. And release the game itself around May.

We have a question on how to implement the same engine on Voodoo cards. We plan to have a different executable for those cards. But we wonder if there is an equivalent opengl.lib for those cards. (Thus eliminating unecesary waste of time) And what difference does the initialization of those cards on openGL have.

-John Mustance
-Richard Draxson.
Draxson Enterprises.

Image of the Day Gallery


Message Center / Reader Comments: ( To Participate in the Discussion, Join the Community )
Archive Notice: This thread is old and no longer active. It is here for reference purposes. This thread was created on an older version of the flipcode forums, before the site closed in 2005. Please keep that in mind as you view this thread, as many of the topics and opinions may be outdated.
Andreas Umbach

August 20, 2000, 06:51 AM

As for Voodoo cards, you need to dynamically load 3dfxogl.dll
Check out and especially, the (currently
developed) glsetup API at


August 20, 2000, 08:04 AM

Just to test if your engine works with Voodoo cards rename 3dfxogl.dll to OpenGl32.dll and put it in the same folder where your engine
executable is. Be sure your program runs in FULL SCREEN directly.
Aproposito....the screen looks great.
What is the size of your world ...and what is it's density ? I am writing my self a terrain engine and i have troubles to find the good ratio
between density (high field data / meter) and RAM.

The Aero Section :
The Aero Section is a large military aircraft photo gallery.


The Aero Section :

The Aero Section is a large military aircraft photo gallery.


August 20, 2000, 08:28 AM


Amitt Mahajan

August 20, 2000, 08:29 AM

Wow, amazing shot. I'm just startin OGL and knowing I can create stuff like that makes me even more excited to learn, btw what is your webpage? I'd love to see more on this engine.


August 20, 2000, 08:47 AM

Just so you remember, its only the Voodoo1, Rush and Voodoo2 that have to deal with this. The others have an ICD.

Phil Carlisle

August 20, 2000, 10:40 AM

I'm sure your aware, that the texture size on voodoo cards is capped at 256x256 (dont know if thats true of the latest voodoo cards)

Nice enuff shot tho.. very stylized.



August 20, 2000, 10:56 AM

Like i said for test copy the 3dfxogl.dll as OpenGl32.dll in your EXE folder. I have a voodoo2 card and for a long time that was the only way to see the OpenGL demos. Simply ensure that your program starts in FULL SCREEN or it will crash ..and as Phil suggested Voodoo1,2,3 support only 256x256 sized textures and that may cause problems too.
I think that the new 3dfxogl.dll (1 year or less) is a full ICD with the FULL screen limit. (Q3 works fine on V2 with the 3dfxogl.dll)


The Aero Section :

The Aero Section is a large military aircraft photo gallery.


August 20, 2000, 11:01 AM

Oh my bad. I must put some ,,,,,

Like i said, for test, copy the 3dfxogl.dll as OpenGl32.dll in your EXE folder.
I have a voodoo2 card and for a long time, that was the only way to see the OpenGL demos.
Simply ensure that your program starts in FULL SCREEN or it will crash ..and as Phil suggested, Voodoo1,2,3 support only 256x256 sized textures and that may cause problems too.
I think that the new 3dfxogl.dll (1 year or less) is a full ICD, with the limit of FULL screen ONLY for the V1 and V2. (Q3 works fine on V2 with the 3dfxogl.dll)

TRY it !


The Aero Section :

The Aero Section is a large military aircraft photo gallery.


August 20, 2000, 11:47 AM

Nice screenshot! Is the water animated? Is there a downloadable demo?

Phil: I don't know about the 5500s, but the Voodoo 6000 will have 2048X2048, like the latest nVidia chips.

Richard Draxson

August 20, 2000, 12:42 PM

The sky and water are fully animated. When the camera goen on the sea, it go into swim mode (Avove the water) or dive mode (inside the sea). As I say the waves animated, both in movement and in texture movement. The Ocean floor is vertex lighted, and have cautics when you go inside.

Right now its only first person, but the 3rd person view is on the works.

Altough we have a working copy we prefer not release a demo, until all the bugs are worked out, we dont want people to think this is an sloppy work, just because we release things too early. As for the site, we are a VERY small company, and between the game and our lives we havent found time to put a web site yet. Altough we separated for that purpose.

Omega2040, as we call our project, will be an online game. We planed to be like something like Everquest(Altough it is NOT RELATED in ANY way to it), instead of being medieval and have magic, it will take place in the future, and the magic will be technology. It will take place in various planets.

Anyway, we are not ready yet for a demo. We plan to have a limited public beta on January. (limited on the sense of how many users can be at a time, in other words only one server). After that if everythings goes right the game will be released on May.

Richard Draxson

August 20, 2000, 01:07 PM

The terrain in the screeenshot is just 256x256. We taselate the near sqares with a noise function, thus giving the impresion of a bigger terrain. The important thing is having a function noise that has predictable, good and scalabe results and at the same time being fast.

The world itself is composed of 256x256 areas having about 4 to 9 areas in memory at the same time (depending on the ram available), and a small loading if the area is not in memory (small if the textures between areas are similar wich they are in one world), to make a comparation on the loading, its like the one on Ultima IX. You notice it only because you hard disk slows your system a little. This means that the world itself, (in theory at least) can have any size, as for the density, it depends on the noise function and the processing speed of the hardware (in other words, SLOW cpu and card, have a lower impression of taselasation, Higher CPU speed and good video card, bigger taselasation). As for the colision detection with the terrain, it only takes place with the 256x256 grid (Actually the posible squares of it). This is to have the same colision in high end machines as in low end ones.


August 20, 2000, 02:52 PM


Are you sure the Voodoo 1 & 2 support is worth the cost of the port? I've heard that those cards are supposed to have a diminishingly small part of the market and have really funky OpenGL support.


Mark Friedenbach

August 20, 2000, 04:28 PM

An official ICD for Voodoo cards was released almost a year ago by 3dfx. No added configuration (or renaming of drivers) is necessary for OGL apps to work.

Voodoo 1, Rush, 2, Banshee, and 3 all have 256x256 texture limits built into the hardware, not the software. The drivers *should* (I haven't tested this) break up large textures into smaller ones. The Voodoo 4 and Voodoo 5 series (which is pure marketing crap - they're identical except for the T-Buffer) all have 2k by 2k texture limits, but (should you ever need more than that), the drivers should break down the textures into smaller ones too.


August 20, 2000, 05:28 PM

Mark: OpenGL only specifies that the driver be able to handle textures up to 64x64. After that, there are absolutely no guarantees as to how textures are handled, and the driver is well within its rights to reject textures which are larger. It's up to the application to determine whether they can actually upload their texture (using the GL_PROXY_TEXTURE_2D target is recommended).

Of course, the driver CAN be nice and tesselate your polygons down to split textures, but actually, I'd prefer that it didn't - that'd be a huge speed hit, without any reasonable way to know that the hit will need to be avoided (namely by just downsampling the textures). Also, split polygons with separate textures tend to look REAL crappy when it comes to bilinear filtering, and it leads to a lot of other crappy crap that the driver has to deal with which can break easily.

Basically, don't assume that the driver will break up the textures, and it's not something which you really want anyway. :)


Code. Music. fluffy.


August 21, 2000, 12:16 AM

Richard: If you can tell me this, are the water heights and textures animated with a filter? how many textures do you have to generate for the water per frame? For the world, i'm not sure i understand: you have a 256X256 grid that contains the entire world, and then when the user loads a block, a smaller 256X256 block is loaded from the disk, or do you just use a predictable tesselation to generate it? And then you tesselate the are near the player again? Do you do more tesselation nearer the player, or just the same amount over an area?

Mark Friedenbach

August 21, 2000, 12:26 AM

fluffy: According to the OGL standard, you are correct. I was referring to the implementation done by 3dfx specifically for their cards. I think I picked up that piece of information while sifting through some 3dfx glide docs (their OGL ICD is just a wrapper for glide, right?). I could be wrong though..


August 21, 2000, 01:14 AM

mark: Ah, okay. It sounded like you were talking about OGL in general. :) And technically, any OGL ICD is just a wrapper for the low-level driver (in this case, Glide), so yeah. Does Glide do automatic texture splitting though? That seems quite high-level behavior for such a low-level API...

Disclaimer: I've never programmed in Glide, nor have I wanted to.


Code. Music. fluffy.


August 21, 2000, 05:12 AM

Hi Richard,

You say this game is going to be massively multiplayer? Do you plan to set up your own arsenal of Servers to maintain your persistant world? This is something I would not expect from a small company. Or are you going to freely distribute the serverside software so that anyone can run their own persistant world.

Oh, Nice Screenshot.


Isaack Rasmussen

August 21, 2000, 07:39 AM

About GLiDE driver and big textures, it does not split the polygons or something like that, it was Creative(I think) that one day made a (Mini)OpenGL driver, that did excactly what you described, to enable Quake players to play with highres textures, but performance really sucked.

For multiplayer network, why not set up a Napster system and then count on that there will allways be at least one gameserver online. Then each time a new (user)gameserver goes online, it will somewhat be invincible for the users, maybe they will notice a speed increase or something,

Has this been considered, or am I being a bit vague in my explanation?


Stratos Tsiavis

August 21, 2000, 10:00 AM

I was just wondering, how much code has gone into your game so far, to produce the screenshot above? I'm a complete newbie, so any info you can throw at me would be great... You can contact me on ICQ (51185604) anytime... thanks

The Wolf

August 22, 2000, 11:23 AM

I love it, from what i see, looks like engine gives you the feeling you are on a another planet. can't wait
to see it in realtime.

But if I may make a couple of suggestions.

a lot of distributors are sick of the old alphabet names (apha, sigma ... etc), instead try and use a word that has
a meaning, like Nova2040 (maybe incorporate a supernova into the story, PS Nova = new)

second (and i dont know if you already thought of that), have more than one moon/satellite orbiting the planet
or even 2 or 3 suns, extra lens flare effects dont usually bog down the speed too much.

best of luck.

This thread contains 21 messages.
Hosting by Solid Eight Studios, maker of PhotoTangler Collage Maker.