It is, but so is Mesa, but should we have to distribute Mesa with all installations for our customers FreeBSD machines? No, so why should not Open Inventor, not be part of such a typical install?
You don't have to agree with me, I really don't care, the point is that our customers would probably love it. It would mean that if they hire some other company, all the new developers would need to know is OpenGL v3, which they would if they take the job. We have our own OO library set, which is supperior to Open Inventor, it's propertary. Our customers have access to the application code, but not the core libraries which is our trade secret; as it is shared between customers and makes them come back.
I would prefer if we would have an open standard, then both customers and employers would have a safer future. There is already indications that we will have to stall developent of our library, as customers should not depend on diversity of library version; a bugfix should apply and help all customers, not just the new.
I don't really know any more, I just do research in distributed systems security and availability, but this was a valid concern, and I think it still is.
The thing is, developers see Doom3, and think only in terms of small changes. I have not seen anything interesting in 3D perspective game in a looong time, the only one that comes to mind is the Soul Reaver line of games.
Better graphics doesn't make better games. The youth of today doesn't get that. I prefer IRL fistfighting, so I do that on my spare time. Because it's a challange, and exciting too.
Re:Why no comparison with D3D?
on
OpenGL 2.0 Released
·
· Score: 2, Interesting
I agree, but my point is that it should be part of the specification. Open Inventor support many of the thoings I want, but still, it's not part of the specification. That means that on the enterprise customers machines that run FreeBSD, Solaris and Windows there is no truly portable way to run things.
Windows doesn't do OpenGL the way it should, i.e. up to date, but that is no excuse for things not beeing in a OpenGL standard specification. If it was in the spec, more people would use OpenGL. Which is what we all want, right?
I have not done much work in D3D; I don't like many things in its design; but that doesn't matter as I talk about OpenGL on its own merits, not in relation to D3D. Which should put things in perspective.
No, you don't get it, OpenGL should do specs like CORBA; new version do new things. The latest offering adds support for components, before that CORBA was no more useful than plain RPC. The previous version are still the same, because different versions are solutions for different things.
If OpenGL v3 added a higher level API, which helps dealing with stuff that is trivial and plain annoying so we could focus on creating things, instead of how to create them, we would all benefit. I'm not saying, "throw away the current API", I'm saying, go with the flow.
Good, then maybe we will have some games that are fun to play. Sure, the last two offerings from id where nice looking, but for gods sake, where is the fun in any of their games?
Guess I'm an old fart, but I haven't had fun since Angband or maybe Lemmings; though the Jedi Knight games where quite entertaining, but that's because I grew up on the original films.
Hopefully this will lead to new directions in the gaming industry, trying new concepts etc.
Re:Why no comparison with D3D?
on
OpenGL 2.0 Released
·
· Score: 3, Insightful
Still, as a former OpenGL developer I must say that while OpenGL is nice it is far from perfect. The API is very C-centered, which is nice, if you develop in C; we however developed in other languages, which more suitable for enterprise apps where stability and floatingpoint correctes is AO.
I'm not fond of OOP, but it sure makes sense when you deal with visual objects, and OpenGL doesn't really feel OO. Dealing with OpenGL for Lisp or Python is easy, but sure as hell ain't pretty.
This is good. Though people will complain, they always do, about everything.
While I'm a pgsql myself, the more the merrier. As long as there are many differend dbms's we'll all be safe, because homogenicy is the root of all evil. This will hopefully help Sybase stay in buisness longer thanks to the increased popularity it will give them, which therefor is good for me as a pgsql user. Simply because improvements caused by competition and the lack of common ground for root exploits.
Now, if only MySQL would just die we would all be better off:)
I wonder if it will make it into FreeBSD 5.3, according to the schedule the Ports where frozen on the 3:rd of September; it would be nice if they regarded this a fix for the one in the Ports, otherwise I will use the latest stable XFree86 release.
As long as the S3 drivers suck, I could pick either and not really care; without better drivers my laptop mostly runs a VT100 console with a bit higher resolution thanks to vidcontrol.
In a traditional unix environment sudo is nifty, however, with FreeBSD we have had powerful ACLs for quite some time; enabled by default in 5.x, so no need for patches. With it you have better control, it's more dynamic and powerful. At first it may look complex, but you will develop understanding of them really fast, and it will be well worth it. Try it out.
The bsdtar is so much better than gtar I think it will replace gtar even in most Linux distributions. It automatically handles compresson (like gzip and bzip2).
My only beef with 5.X series is the fact that even though perl is out, it still is way too large; so I need to build my own releases for CD that doesn't have sendmail etc. No biggie but still a tad bit annoying.
Actually, DirectX is fully backwards compatible. It's probably driver problem causing this, because you normally need a new driver to match the DirectX increments; sucks, but that's what it takes. It's actually the buyers market, if people didn't spend money on top of the line graphics cards with new features then DirectX wouldn't need to be updated to accomodate those features.
I do think that better game programmers would write a more dynamic gfx engines that are pluggable with the new features instead of demanding them; so that they don't have to be emulated by DirectX either; on the other hand it would mean less optimized inner loops.
No, it's the gamedevelopers that does that for you by checking for if your card supports the features it needs to be playable. It's not MicroSoft's fault, by any extension, it is however silly that you are not allowed to check if it is playable according to _your_ standard; and it's the gamedevelopers you should blame. I guess it's easy to point at something big, like MS if you want someone to blame, people tend to do that.
Slashdot Mirror
It is, but so is Mesa, but should we have to distribute Mesa with all installations for our customers FreeBSD machines?
No, so why should not Open Inventor, not be part of such a typical install?
You don't have to agree with me, I really don't care, the point is that our customers would probably love it.
It would mean that if they hire some other company, all the new developers would need to know is OpenGL v3, which they would if they take the job.
We have our own OO library set, which is supperior to Open Inventor, it's propertary.
Our customers have access to the application code, but not the core libraries which is our trade secret; as it is shared between customers and makes them come back.
I would prefer if we would have an open standard, then both customers and employers would have a safer future.
There is already indications that we will have to stall developent of our library, as customers should not depend on diversity of library version; a bugfix should apply and help all customers, not just the new.
I don't really know any more, I just do research in distributed systems security and availability, but this was a valid concern, and I think it still is.
The problem is, it's all 3D shooters, basically.
The thing is, developers see Doom3, and think only in terms of small changes.
I have not seen anything interesting in 3D perspective game in a looong time, the only one that comes to mind is the Soul Reaver line of games.
Better graphics doesn't make better games. The youth of today doesn't get that.
I prefer IRL fistfighting, so I do that on my spare time. Because it's a challange, and exciting too.
I agree, but my point is that it should be part of the specification.
Open Inventor support many of the thoings I want, but still, it's not part of the specification. That means that on the enterprise customers machines that run FreeBSD, Solaris and Windows there is no truly portable way to run things.
Windows doesn't do OpenGL the way it should, i.e. up to date, but that is no excuse for things not beeing in a OpenGL standard specification.
If it was in the spec, more people would use OpenGL. Which is what we all want, right?
I have not done much work in D3D; I don't like many things in its design; but that doesn't matter as I talk about OpenGL on its own merits, not in relation to D3D. Which should put things in perspective.
No, you don't get it, OpenGL should do specs like CORBA; new version do new things. The latest offering adds support for components, before that CORBA was no more useful than plain RPC. The previous version are still the same, because different versions are solutions for different things.
If OpenGL v3 added a higher level API, which helps dealing with stuff that is trivial and plain annoying so we could focus on creating things, instead of how to create them, we would all benefit.
I'm not saying, "throw away the current API", I'm saying, go with the flow.
Good, then maybe we will have some games that are fun to play.
Sure, the last two offerings from id where nice looking, but for gods sake, where is the fun in any of their games?
Guess I'm an old fart, but I haven't had fun since Angband or maybe Lemmings; though the Jedi Knight games where quite entertaining, but that's because I grew up on the original films.
Hopefully this will lead to new directions in the gaming industry, trying new concepts etc.
Still, as a former OpenGL developer I must say that while OpenGL is nice it is far from perfect.
The API is very C-centered, which is nice, if you develop in C; we however developed in other languages, which more suitable for enterprise apps where stability and floatingpoint correctes is AO.
I'm not fond of OOP, but it sure makes sense when you deal with visual objects, and OpenGL doesn't really feel OO. Dealing with OpenGL for Lisp or Python is easy, but sure as hell ain't pretty.
This is good. Though people will complain, they always do, about everything.
:)
While I'm a pgsql myself, the more the merrier. As long as there are many differend dbms's we'll all be safe, because homogenicy is the root of all evil.
This will hopefully help Sybase stay in buisness longer thanks to the increased popularity it will give them, which therefor is good for me as a pgsql user.
Simply because improvements caused by competition and the lack of common ground for root exploits.
Now, if only MySQL would just die we would all be better off
I wonder if it will make it into FreeBSD 5.3, according to the schedule the Ports where frozen on the 3:rd of September; it would be nice if they regarded this a fix for the one in the Ports, otherwise I will use the latest stable XFree86 release.
As long as the S3 drivers suck, I could pick either and not really care; without better drivers my laptop mostly runs a VT100 console with a bit higher resolution thanks to vidcontrol.
In a traditional unix environment sudo is nifty, however, with FreeBSD we have had powerful ACLs for quite some time; enabled by default in 5.x, so no need for patches.
With it you have better control, it's more dynamic and powerful. At first it may look complex, but you will develop understanding of them really fast, and it will be well worth it.
Try it out.
Here is a short version of what I normally do.
You will need to customize the buildworld procedure to your liking, and that's about it.
The bsdtar is so much better than gtar I think it will replace gtar even in most Linux distributions.
It automatically handles compresson (like gzip and bzip2).
My only beef with 5.X series is the fact that even though perl is out, it still is way too large; so I need to build my own releases for CD that doesn't have sendmail etc.
No biggie but still a tad bit annoying.
Actually, DirectX is fully backwards compatible.
It's probably driver problem causing this, because you normally need a new driver to match the DirectX increments; sucks, but that's what it takes.
It's actually the buyers market, if people didn't spend money on top of the line graphics cards with new features then DirectX wouldn't need to be updated to accomodate those features.
I do think that better game programmers would write a more dynamic gfx engines that are pluggable with the new features instead of demanding them; so that they don't have to be emulated by DirectX either; on the other hand it would mean less optimized inner loops.
No, I use all this free time I got to play with myself... fast.
Ultra-Fast "Hello World" here I come...
No, it's the gamedevelopers that does that for you by checking for if your card supports the features it needs to be playable.
It's not MicroSoft's fault, by any extension, it is however silly that you are not allowed to check if it is playable according to _your_ standard; and it's the gamedevelopers you should blame.
I guess it's easy to point at something big, like MS if you want someone to blame, people tend to do that.