Branches
Releases
|
Version
|
Focus
|
Date
|
|
0.6.9-1
|
Minor feature enhancements |
10-Mar-2008 02:30 |
|
0.6.8-1
|
Minor feature enhancements |
17-Mar-2007 06:18 |
|
0.6.7-1
|
N/A |
01-Jan-2007 06:46 |
|
0.6.6-1
|
Minor feature enhancements |
10-May-2006 17:12 |
|
0.6.4-7
|
Code cleanup |
09-Jan-2006 03:28 |
|
0.6.3-4
|
N/A |
04-Nov-2005 07:46 |
|
0.6.1-5
|
N/A |
15-May-2005 07:10 |
|
0.5.5-7
|
N/A |
31-Dec-2004 10:48 |
|
0.5.4-9
|
Minor feature enhancements |
01-Oct-2004 08:52 |
|
0.5.4-1
|
Minor feature enhancements |
21-Aug-2004 07:38 |
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]
|
