Projects / VortexGE / Comments

Comments for VortexGE

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.

02 Aug 2004 04:25 msharov

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.

15 May 2004 22:44 blue_wind_25

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

09 May 2004 19:59 blue_wind_25

Some download problem
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 ?

16 Apr 2004 19:31 blue_wind_25

Re: what's wrong with mesa?
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.

16 Apr 2004 04:00 gvy

Re: what's wrong with mesa?

> %-- 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 (http://freshmeat.net/browse/110/?orderby=&filter=809) and this (http://freshmeat.net/browse/110/?orderby=&filter=809%2C80) shows more than a few known mature projects like libSDL (http://freshmeat.net/projects/plib/), PLIB (http://freshmeat.net/projects/plib/), Crystal Space, Allegro (http://freshmeat.net/projects/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 (http://freshmeat.net/articles/view/774/) but you get the point.

...ah, found! It was "freshmeat's Stance on "Trivial" Software (http://freshmeat.net/articles/view/198/)" indeed :-)

Screenshot

Project Spotlight

ReciJournal

An open, cross-platform journaling program.

Screenshot

Project Spotlight

Veusz

A scientific plotting package.