Projects / VortexGE

VortexGE

VortexGE is a software 3D renderer for the X environment that was created without using OpenGL/MesaGL. It also supports 2D image manipulations and audio access and is intended for creating Linux games without needing 3D card acceleration.

Tags
Licenses
Operating Systems
Implementation

Recent releases

  •  28 Jan 2009 08:55

    Release Notes: The tarball distribution is now separated into two files: source with documentation and media. Many deprecated symbols and features were removed. VortexGE now would be correctly built using GCC 4.2.x and GCC 4.3.x. Lua 5.1.4 is now used as the scripting engine backend. The VDumpStack() function was improved a bit. Support for streaming Ogg-Vorbis audio as background music was added.

    •  13 Sep 2008 17:45

      Release Notes: Starting from this version, the tar ball distribution is separated into two files: one with source and documentation, and one with media. The _C, _T, C, and T prefixes for classes and structures have been removed. Support was added for a streaming sound buffer (but currently only supports Ogg-Vorbis). Lua 5.1.4 is now used as the scripting engine backend.

      •  08 Jun 2008 08:03

        Release Notes: Many of the symbols and features which were deprecated in the previous version have been removed. The function CDialogPage::GroupRadioButtons() now automatically checks the first radio button in the list. A new function, CDialogPage::CheckRadioButton() was added. VortexGE should be correctly built using GCC 4.2.x and GCC 4.3.x. Some code cleanups and bugfixes were made. Some improvements were made in the configuration script.

        •  10 Mar 2008 02:30

          Release Notes: Some deprecated features have been removed. New controls, CPopUpMenu and CMenuBar, were added. All styles of the CSpinButton control are now implemented. The CInputBoxML control is improved. Support has been added for loading Ogg Vorbis files. There are some improvements in the CPanel3DBuffer class related to rendering, collision, and bounding box calculation. Lua 5.1.3 is now used as the scripting engine backend. There are a few bug and documentation fixes.

          •  08 Nov 2007 03:34

            Release Notes: All symbols/features which were marked as deprecated have been removed. The CInputBoxML class now supports text selection and copying using the keyboard. A new CThreadKey class was added. VortexGE should now be built correctly using GCC 4.2.x. Some configuration script fixes and improvements were made along with some documentation fixes.

            Recent comments

            05 Jul 2005 23:36 blue_wind_25

            Re: Hosting problem
            Yes, I knew that SF will solve the hosting problem.
            But there is one problem: my internet connection here (escpecially the upstream) is slow, so maintaining a CVS repository in SF will be a pain :( Of course I can just upload via FTP, but that will beat the CVS idea of SF.

            25 Jun 2005 10:22 asfand

            Re: Hosting problem


            > I have just opened my hosting sites

            > yeterday and it still fine. But now it

            > refused all access, I don't know wheter

            > it is because my transfer quota has been

            > reached. I will wait till next mont, but

            > if somehow those account still

            > unavailable, well .. I really need some

            > help for the continuation of VortexGE.

            > If no one can halp, I think this is will

            > become the end of VortexGE.

            Why don't you just do the obvious thing and use Sourceforge.net ?!?!?!?!?!?!

            10 Oct 2004 09:52 asfand

            Re: what's wrong with mesa?


            >

            > % Well I thought that's exactly what

            > APIs

            > % are for: hiding the complicated

            > details

            > % behind more or less juicy API

            >

            >

            > No. APIs are for providing a clean

            > interface for tasks that require a lot

            > of code when the lower layer is used.

            > This is not hiding complicated details,

            > it is hiding unimportant details, which

            > is a serious distinction that many

            > programmers fail to follow.

            >

            >

            > % I've wrote my wireframed thingies

            > (after

            > % Ammeraal's book) some 8 years ago or

            > so,

            > % and frankly -- don't regret not doing

            > % even "simple" solid engine (having had

            > a

            > % look at the maths and sample code),

            > not

            > % talking of texturizer and so on.

            >

            >

            > Come on, 3D math is not that

            > complicated. If you want to write 3D

            > apps you should know it anyway to

            > understand how to define your data for

            > best performance. You may also want to

            > know how to write custom transformation

            > matrices.

            >

            >

            > % It's also about APIs and effort

            > duplication

            >

            >

            > It is about the API, and not about

            > effort duplication. Most libraries get

            > rewritten exactly because of a horrible

            > API. OpenGL is not so bad while you

            > issue drawing commands, since they are

            > going to be pretty much the same in any

            > API. But the rest of it is just ghastly

            > old C that I wouldn't let anywhere near

            > my code. As for the effort, I have no

            > desire whatsoever to contribute to

            > OpenGL code, because it is such a

            > tangled mess that only its core

            > developers can still tolerate it. When

            > will people learn that C++ is the right

            > way to make libraries? :)

            >

            >

            > % if I was considering

            > % which library to link my 3D app with,

            > % would either stick with something

            > % standard and widely deployed (read

            > -lGL

            >

            >

            > That's irrelevant. It is just a simple

            > to ship your own 3D library with your

            > product.

            >

            >

            > % So maybe it's worth considering

            > % developing a separate, faster

            > software

            > % renderer for Mesa, or at least doing

            > % some SDL hooks -- or is it exactly

            > about

            > % studying "behind the scenes"?

            >

            >

            > It is about the "I can do better" belief

            > that all good programmers hold. Mesa is

            > not suffering from lack of optimization,

            > but from bad internal design. The

            > rendering pipeline concept is fine, but

            > the way they implement it is not. If you

            > haven't actually read through it, I

            > highly recommend it to see how not to

            > write your code. I am not going to post

            > any detailed criticisms here, since they

            > would be rather large and off-topic.

            Have you noticed how Quake 1 and 2 (with software rendering) run at a high FPS? When I try to render just a handful of textured polygons in Mesa (software rendered OpenGL), my FPS drops to about 5 or 10, when I'd probably get about 40 or 50 in the Quake engine.

            This is because the Quake engine is a specialised software 3D rendering architecture. OpenGL has one purpose: pass data and commands to a 3D accelerator. If used to do software rendering, its a bucket of rubbish. For software rendering, VortexGE and the ilk are the only way to go.

            Why do you think they made a custom 3D software renderer for Unreal Tournament 2004? They didn't just bundle their own OpenGL software lib along, cos it'd have been too slow.

            03 Oct 2004 22:31 blue_wind_25

            Re: Some download problem
            It have been fixed. Rootshell allows direct link to the hosted file, without using the automatic indexing facility of the files. Thanks a lot to rooshell for allowing me to host my files there.

            21 Sep 2004 21:17 blue_wind_25

            Hosting problem
            I have just opened my hosting sites yeterday and it still fine. But now it refused all access, I don't know wheter it is because my transfer quota has been reached. I will wait till next mont, but if somehow those account still unavailable, well .. I really need some help for the continuation of VortexGE. If no one can halp, I think this is will become the end of VortexGE.

            Screenshot

            Project Spotlight

            OpenStack4j

            A Fluent OpenStack client API for Java.

            Screenshot

            Project Spotlight

            TurnKey TWiki Appliance

            A TWiki appliance that is easy to use and lightweight.