@traumatic: I was in a bit of a rush last week so let's backtrack a bit. I agree that natively PB should continue to support dx on windows, for 2D at least. I don't know what the overhead considerations are or how well dx is actually supported on non-nv/ati cards. I think it's safe to assume that most/all cards will support 2d-dx pretty well. I also think this thread, like many others on this topic, tend to confuse several issues (and I'm as guilty as others)...
- 2D/3D: The requirements are often different but as 3D hw becomes increasingly std then more use is being made of it for (psuedo) 2D ops. Prime current example is the whole OS X interface and supporting libs. Applications such as video processing (esp live) are making greater use of 3D hw (traditionally these would be considered 2D apps). OpenML and OpenES are specifications aimed at supporting 2D, multimedia and embedded devices in much the same way as OpenGL is aimed at supporting 3D devices - ALL in a effort to avoid single manufacturer tie-in.
- Single/Cross-Platform: The evidence is already clear that users are moving to non-windows platforms. Maybe not as quickly as some would hope but there is a definate trend that will only increase. In certain sectors, eg, film/ad production, it is probably rare to see Windows machines. DX has never aimed to be x-platform. WineX will always lag behind win-dx and will never be a first choice for native Linux apps.
- Proprietary: MS are never going to let other developers implement their own version of dx or ever put users/dev concerns above marketing concerns. There has already been many upsets each and every time dx gets "upgraded" and now they are even replacing dx itself! I can envisage a situation where old dx eventually gets "emulated" on new style libs. Of course if people passively support proprietary solutions then they only have themselves to blame for placing themselves completely at the mercy of a single unscrupulous company.
- Programming Issues: Maybe it's just me but I hate investing inordinate amounts of time learning a plethora of techniques to achieve what should be relatively simple. It started with the abstraction of hw, for good reasons, but has continued unabated into practically every aspect of Windows programming. I'm talking about "you have to use C++", "you have to use COM", "you have to use XYZ library/classses", etc, etc. The WinTel union has conspired for years to get everyone buying more "powerful" hw/sw that is actually MORE difficult to make best use of. I could write pages on how this leads to an obscene waste of peoples time but suffice it to say that the entry cost (not just in time) has purposefully been increased to rule out small developers and especially one-man bands. On a more practical point, the knowledge I gained regarding opengl (in half the time I spent on dx) allows me to scope out non-MS/Intel solutions for a fraction of the *entry* cost to MS-based solutions. Specifically where OpenGL is concerned, the spec is what I call fairly "flat", ie, "to achieve X call XYZ function" - no need for specific compilers, libs, classes, etc. The usual anti-ogl argument re extensions no longer stands since there are free opensource libs that handle them seemlessly, not that using them has ever been difficult anyway.
- Open/Closed Source: MS = Closed. In addition to points made above MS solutions will always be "closed", even in the general sense and even if/when they actually make source available for scrunity by selected third parties. MS itself will always be able to better others by utilising undocumented features in their OS's and libs. Open source libs/specs at least allow you to compete on a level playing field and for this reason, if no other, everyone should support the likes of Opengl and others.
Regarding me proving OpenGL is better, I hope the above clarifies that there is more to this whole debate than just performance. I've been tech-watching the 3D area for a number of years now waiting for hw 3D to become as standard as "coloured graphics" now are. For the young-un's, there was a time when if you wanted more than two colours you had to put coloured plastic film on your screen, sad I know. Traumatic's demo's are great and I love to see non-accelerated hw being pushed to the max, esp just to prove just how powerful even "old" computers still are. But if I was to start using coloured plastic film these days you'd quite rightly call me insane. Likewise when 3D hw is standard you will shift and distort polygon's rather than pixels... and if you follow the above arguments then you will do it using the like's of OpenGL rather than DX.
Fred:Time to switch to OpenGL as the native GFX source of PB
I'm currently working on a 3D "walkthrough" game (think DOOM without the blood and guts).
Actually, working on is a bit strong. I am learning what I can about the 3D arena. I may write a raycaster to do 3D in 2D if I can't quickly understand how 3D engines and etc work. I can manage the raycasting approach.
Actually, working on is a bit strong. I am learning what I can about the 3D arena. I may write a raycaster to do 3D in 2D if I can't quickly understand how 3D engines and etc work. I can manage the raycasting approach.
@}--`--,-- A rose by any other name ..
Hey dmoc,
thanks for the reply, you made some really good points there.
I never wanted to argue about what's being better or the best, if that
exists at all. All I can say is what I already said.
Having programmed both APIs I like DX so much more, it's just more
well-thought and all - but hey, that's just me.
thanks for the reply, you made some really good points there.
I never wanted to argue about what's being better or the best, if that
exists at all. All I can say is what I already said.
Having programmed both APIs I like DX so much more, it's just more
well-thought and all - but hey, that's just me.
Good programmers don't comment their code. It was hard to write, should be hard to read.
Well at least you tried both. We can only hope that others take the time and make an independent choice for themselves. I get the feeling some people don't get the the "Open" bit of "OpenGL" :P But as much as I'm not a fan-boy for MS neither am I an evangelist for other OS's. Time will tell - I'm happy with that.Having programmed both APIs I like DX so much more
So .. DX for windows all the way! 
Why wrap commands around somthing that already accessable now?
The only problems of having opengl nativly in pb is that some commands use doubles there is a lib to solve that and a include for the constants
With those I can do anything that any other program using opengl can do
and recently ive been working with nehe's tutorials and everything works.
I have done lessons 1-10 so far and no alternitives other than a work around I have to do with with window handling (opening and events)
The only problems of having opengl nativly in pb is that some commands use doubles there is a lib to solve that and a include for the constants
With those I can do anything that any other program using opengl can do
and recently ive been working with nehe's tutorials and everything works.
I have done lessons 1-10 so far and no alternitives other than a work around I have to do with with window handling (opening and events)
~Dreglor
-
Truth_Seeker
- Enthusiast
- Posts: 145
- Joined: Tue Mar 01, 2005 8:41 pm
- Location: Near a Computer
As far as I know Ogre (the really nice graphics engine/lib) supports both DirectX and OpenGL so you have a choice, correct? I think Fred has made a good decision on using Ogre so that it gives the users of PB the option of what we want instead of him creating his own wrapper around OpenGL or DirectX.
Thanks
Truth Seeker
Truth Seeker
I agree. But I only stand by my previous statement because, by default (before user installs anything) the OpenGL implimentation in Windows Vista is (or will) be very slow. If your game is the first the user installs on windows (providing we get native OpenGL support for pb/win), they should notice the slow speeds.
Now, unless there are drivers we can distro with our pb/win-opengl app .... ?
Now, unless there are drivers we can distro with our pb/win-opengl app .... ?