fmII
Sun, Jul 27th home | browse | articles | contact | chat | submit | faq | newsletter | about | stats | scoop 01:22 UTC
in
Section
login «
register «
recover password «
[Project] add release | add branch | add screenshot | broken links | change owner | email subscribers | update project | update branch (urls) [Project]

 VortexGE - Default branch
Section: Unix

 

Added: Mon, Apr 12th 2004 00:17 UTC (4 years, 3 months ago) Updated: Sun, Jun 8th 2008 08:03 UTC (1 month, 19 days ago)


Screenshot About:
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.

Author:
Aloysius Indryanto [contact developer]

Rating:
8.35/10.00 (1 vote)

Homepage:
http://bluewind25.org/
Tar/BZ2:
http://bluewind25.org/tarballs/VortexGE-0.6.9-1.tar.bz2
Changelog:
http://bluewind25.org/changes.html

Trove categories: [change]
[Development Status]  4 - Beta
[Environment]  X11 Applications
[Intended Audience]  Developers, End Users/Desktop
[License]  OSI Approved :: GNU Lesser General Public License (LGPL)
[Operating System]  POSIX :: Linux
[Programming Language]  C++
[Topic]  Games/Entertainment, Multimedia :: Graphics, Multimedia :: Graphics :: 3D Rendering, Multimedia :: Sound/Audio :: Players, Software Development :: Libraries

Dependencies: [change]
libjpeg (recommended)
libpng (recommended)
libtiff (optional)
Libungif (optional)
[download links]

 
Project admins: [change]
» Aloysius Indryanto (Owner)

» Rating: 8.35/10.00 (Rank N/A)
» Vitality: 0.24% (Rank 914)
» Popularity: 1.34% (Rank 4141)

project statsdownload stats
(click to enlarge graphs)
   Record hits: 20,928
   URL hits: 6,454
   Subscribers: 24

Other projects from the same categories:
aubio
Clker.com WordPress plugin
DUMB
SWT component for OpenSceneGraph
rubyzip

Users who subscribed to this project also subscribed to:
Quamachi
Box Backup
XINS
QCad
LINGOT Is Not a Guitar-Only Tuner


Add comment · Rate this project · Subscribe to new releases · Ignore this project · Email this project to a friend · Project record in XML

 Branches

Branch Version Last release License URLs
Default 0.6.9-1 10-Mar-2008 GNU Lesser General Public License (LGPL) Homepage Tar/BZ2 Changelog
Development 0.6.9-3 08-Jun-2008 GNU Lesser General Public License (LGPL) Homepage Tar/BZ2 Changelog

 Comments

[»] Hosting problem
by Aloysius Indryanto - Sep 21st 2004 21:17:37

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.

[reply] [top]


    [»] Re: Hosting problem
    by Asfand Yar Qazi - Jun 25th 2005 10:22:43


    > 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 ?!?!?!?!?!?!

    [reply] [top]


      [»] Re: Hosting problem
      by Aloysius Indryanto - Jul 5th 2005 23:36:32

      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.

      [reply] [top]


[»] Some download problem
by Aloysius Indryanto - May 9th 2004 19:59:38

Some people have said that there are download problems with the link. I am very sorry about this. For now I am still trying to find another (better and easier) place for hosting my project file. Or perhaps I should host it in sourceforge ?

[reply] [top]


    [»] Re: Some download problem
    by Aloysius Indryanto - May 15th 2004 22:44:35

    I have just change my hosting site to portland, hopefully there is no other download problem.

    [reply] [top]


    [»] Re: Some download problem
    by Aloysius Indryanto - Oct 3rd 2004 22:31:17

    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.

    [reply] [top]


[»] what's wrong with mesa?
by Michael Shigorin - Apr 12th 2004 11:17:10

I thought that if you needed software renderer, it was Mesa to go with. Why reimplement the wheel? (just curious)

--
Michael Shigorin mike SOMEWHERE AT altlinux PLUS DOT org

[reply] [top]


    [»] Re: what's wrong with mesa?
    by Aloysius Indryanto - Apr 12th 2004 22:37:19


    > Well, nothing wrong with MesaGL, however

    > isn't nice for programmers to know the real

    > behind 3D programming ? MesaGL source code is

    > very complicated. so it is hard to learn. Also

    > we need to know the GL standard to know how

    > MesaGL works.

    > Beside it will be nice if we can have a software

    > renderer that can run almost real time without

    > 3D hardware (at least in P4 where I develop that

    > project) ... :-)

    [reply] [top]


      [»] Re: what's wrong with mesa?
      by Michael Shigorin - Apr 12th 2004 23:28:25


      > however isn't nice for programmers to know the
      > real behind 3D programming ?

      Well I thought that's exactly what APIs are for: hiding the complicated details behind more or less juicy API :-) (used to like REXML 's one very much :)

      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.

      It's also about APIs and effort duplication -- if I was considering which library to link my 3D app with, would either stick with something standard and widely deployed (read -lGL ;-), or some more high-level abstraction layer. Preferably the one that lets the app scale if I decide I want shaders :)

      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"?

      --
      Michael Shigorin mike SOMEWHERE AT altlinux PLUS DOT org

      [reply] [top]


        [»] Re: what's wrong with mesa?
        by Aloysius Indryanto - Apr 16th 2004 00:12:05


        >-- or is it exactly about

        >studying "behind the scenes"?

        Well, that's correct.
        I like to experiment, that's why I want to study "behind the scenes", and I think it would better if I can share them with someone else.

        Or perhaps someone want to develop an OOP C++ wrapper for MesaGL or extend Mesa to a level so it can be say as game engine (complete with sound and other aspect of game engine) ? Well it will be very useful.

        Actually, I plan that in the future VortexGE will become a simple Game Engine (if necessary the 3D renderer will be reimplemented using GL). But for now I still want to study more about 3D programming, image & sound compression (using GPL/LGPL algorithm), how to create Game Editor, and of course more deep learning on Xlib, etc.

        [reply] [top]


          [»] Re: what's wrong with mesa?
          by Michael Shigorin - Apr 16th 2004 04:00:23


          > %-- or is it exactly about studying "behind the scenes"?
          > Well, that's correct.

          That's how I've took that. :)

          > or extend Mesa to a level so it can be say as game
          > engine (complete with sound and other
          > aspect of game engine) ? Well it will be
          > very useful.

          Well, looking through this and this shows more than a few known mature projects like libSDL, PLIB, Crystal Space, Allegro... So maybe it's worth rebrowsing categories where you've decided your project belongs to and pinging project communities -- the thing is, within one you're more likely to gain substantial practical experience.

          Maybe it wass supposed to be an FM editorial, but I've already seen at least one on effort duplication -- definitely not this one but you get the point.

          ...ah, found! It was "freshmeat's Stance on "Trivial" Software" indeed :-)

          --
          Michael Shigorin mike SOMEWHERE AT altlinux PLUS DOT org

          [reply] [top]


            [»] Re: what's wrong with mesa?
            by Aloysius Indryanto - Apr 16th 2004 19:31:01

            Well, thank you for your advice. When I want to publish / release a real 3D applications, I will choose the matured libraries (of course it is easier to use the existing one than to create it by your own).

            But, like I said, I like making experiment (eventhough my speciality is not in graphics software/development, but in Electronic Engineering majoring Electronics). So I just want to make this project as learning media for me or to anyone else who interested in. It may be like a "semi serious" hobby, perhaps... :-)

            When I have more times, who knows, may be I will combine my project with electronics (maybe create a USB connected device that can help someone wirh DSP, electronic, simulation, etc.?). But it will take much time. But for now I have no plan for this, since creating hardware will consumme much more time than creating software, I still can make it so for now.

            Anyway thank you for your response.

            [reply] [top]


        [»] Re: what's wrong with mesa?
        by Mike Sharov - Aug 2nd 2004 04:25:36


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

        [reply] [top]


          [»] Re: what's wrong with mesa?
          by Asfand Yar Qazi - Oct 10th 2004 09:52:00


          >

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

          [reply] [top]




© Copyright 2008 SourceForge, Inc., All Rights Reserved.
About freshmeat.net •  Privacy Statement •  Terms of Use •  Trademark Guidelines •  Advertise •  Contact Us • 
ThinkGeek •  Slashdot  •  Linux.com •  SourceForge.net  •  Jobs