Slashdot videos: Now with more Slashdot!

View

Discuss

Share

We've improved Slashdot's video section; now you can view our video interviews, product close-ups and site visits with all the usual Slashdot options to comment, share, etc. No more walled garden! It's a work in progress -- we hope you'll check it out (Learn more about the recent updates).

jones_supa writes "OpenGL debugging has always lagged behind DirectX, mainly because of the excellent DX graphics debugging tools shipping with Visual Studio and GL being left with APITrace. Valve's Linux initiatives are making game companies to think about OpenGL, and the video game company wants to create a good open source OpenGL debugger to improve the ecosystem. AMD and Nvidia have already expressed interest in helping them out. Valve has been developing VOGL mostly on Ubuntu-based distributions under Qt Creator. The software currently supports tracing OpenGL 1.0 through 3.3 (core and compatibility), and is expected to eventually support OpenGL 4.x. Many more details on VOGL can be found at Valve's Rich Geldreich's blog."
This looks much nicer than BuGLe. Valve is using Mercurial for version control and they plan to throw it up on bitbucket under an unspecified open source license soon. It works with clang and gcc, but debugging with gcc is currently very slow (hopefully something that can be fixed once the source is available and the gcc hackers can see what's going on). The tracer's internal binary log format can be converted into JSON for use with other tools as well.

They're building out a comfortable development environment for steam machines. Which is great. When proper well documented tool are available, developers are less likely to shun a platform. If there exists a some GPU memory profiling software (not that a team couldn't competently create their own system) and keyword completion for OpenGL calls then I might consider switching over to Ubuntu for development myself.

This is, of course, throwing aside all DX vs OpenGL arguments based on feature support (which I'm not really familiar with at this time).

OpenGL's documentation is poorly written where it's needed most and most of the examples you find online are really old, targeted at hardware that was successfully phased out several years ago.

Huge problem with books, too. Most OpenGL books are still about the old fixed-function, immediate-mode pipeline, and if they introduce "modern OpenGL" at all, it's somewhere later in the book as an advanced feature. Partly this is because many of them serve sort of double-duty, as intro-to-graphics and intro-to-OpenGL textbooks, and immediate mode with fixed-function pipeline actually is easier to use pedagogically if your goal is to introduce people to graphics and the OpenGL code is just an example, not intended for production. But retained mode and shaders is not an "advanced feature" anymore from a coding perspective, just the way things are done.

This is even true in new editions of textbooks, because publishers are lazy and often don't really update the textbook. Therefore a (c) 2012 book might still be >85% full of early-2000s content, depending on the book. The only two OpenGL books I know of, besides giant reference tomes, that take a "modern OpenGL" approach through-and-through, are the sixth edition of Interactive Computer Graphics [amazon.com] (which is actually revised), and Learning Modern 3D Graphics Programming [arcsynthesis.org], a work-in-progress textbook that's been slowly appearing online over the past two years (sections I-IV are now complete, V and VI still being written).

I've had to design a piece of code for students to use as a framework for OpenGL programming. It took me something like two days to drill down to the correct, modern way of doing things in OpenGL, including going through multiple online tutorials on the subject. Most used archaic implementations and didn't bother to explain anything they were doing. And that's just to render a box on screen!

I also do DirectX programming and the difference is like night and day. The OpenGL official docs are acceptable, but

Ah yeah, the SEO-style Web 3.0 URLs, where you guess which part is actually significant.:) On Amazon, the/dp/00000000 part is the real URL, and the/Seo-Friendly-Title-Inserted-Here/ part is SEO-bait garbage that's completely ignored from a technical perspective. So you can leave it out if you want, and http://www.amazon.com/dp/1782167021/ [amazon.com] works. But including only the SEO-bait part of the URL doesn't work, because it doesn't successfully locate resources.

Learning Modern 3D Graphics Programming [arcsynthesis.org], a work-in-progress textbook that's been slowly appearing online over the past two years (sections I-IV are now complete, V and VI still being written).

Actually that tutorial tends to swipe all the OpenGL stuff behind a framework and talks about graphics programming in generic terms. Otherwise it's still very high-quality and useful.

My personal favorite is Anton Gerdelan's OpenGL Tutorials [antongerdelan.net]. I find more practical OpenGL recipes from that one. Good also for the basic stuff to get shaders and textures going.

In general I have found OpenGL programming incredibly complex. Same seems to apply for DirectX. They are cool APIs but the learning curve is high. On the

Once people get it right that steamworks is the part that is DRM and steam is a distribution service and a store... I mean. There are some games that have no DRM at all and after you download them you can use them for whatever. But nooo, a distribution service requiring you to log in is DRM (never mind that GOG also requires you to log in for first download, and they get praised as DRM-free)./rant

Interesting. I might actually have a look at steam again. previously it always required you to install the steam client to download a game. If that isn't required anymore then I might actually use them again.

So steam has somewhere to put the games it downloads for you. This really isn't that complicated. Game producers determine the DRM. If the producer chooses none then Steam downloads the files to the steam directory and keeps them up to date for you if you log in and launches the game for you if you log in. OR you can move the files wherever you want and log in or not and the game works just fine. Don't let reality get in the way of your anti-DRM narrative though.

I wonder... How can you agree with a new TOS if you never open the steam client. The way I see it is: if you don't accept the TOS, you lose access to their services (store and distribution, login servers, etc) which results in games with DRM failing to load since they wouldn't verify since you are not logged in (if you are, then you accepted the TOS, right?). Thus, in the case of a game without DRM, they would provide Store and Distribution services. I doubt (IANAL, should check with one) they had the (lega

The steam client isn't just a download manager though. It is a messenger, includes functionality to scan your system and includes a store interface as well as a pile of other crap. If it was just another download manager it would be irritating but partly acceptable. Instead it is an unstable, intrusive pile of shit that they have jammed so much into that it is offensive.

The "nooo" didn't give it away? I need to work on writing better. Yes, exactly. Anybody who thought like that would probably be an ass. In my (and your) view, at least. Which is why I find it completely okay. A minor... inconvenience, if you may, for access to the rest of the services each provide.

It's difficult as a regular Steam user to get that distinction right, though, because the interface is completely non-transparent about which games have DRM and which don't. You cannot filter the list of available games by "DRM-free only" and choose to vote with your dollars for those. And the majority of games do have DRM (either third-party or Steamworks), so buying blindly is unlikely to get you a DRM-free title. That's a difference with GOG, because there you can know what you're buying is DRM-free.

There are some third-party sites that are attempting to compile the consumer information [pcgamingwiki.com] that Steam doesn't want to give you, but it's a bit hit-or-miss, and most Steam users don't know about such lists.

Valve could probably improve Steam in that way... I don't think, however, most Steam users are the type to care much about that. And those that DO care probably will enjoy the experience from other stores like GOG and Humble bundle (I don't think they are selling games with DRM in their store, although the occasional bundles does have DRM, and they are clearly labeled as such). Of course, there is the matter that some people may not care because they don't know, and it'd be nice if Steam mentioned/allowed f

The store page actually does tell you whether they have third party DRM and if so what they use. One example I know of is if you check BioShock (the first one) the store page says it has SecuROM. Though it's true that they don't appear to list whether it has their own DRM and as far as I know there's no way to filter by DRM.

I fail to see how I'm perpetuating "the confusion". Please enlighten me how explaining that Steam is a distribution platform that offers both games with and without DRM causes confusion. Furthermore, explain to me how are you tied to Valve any more than you are tied to say your CD or that CD-Key you mustn't lose if you want to reinstall your game (in the case of games with DRM), or GOG for re-download (in the case of DRM-free games), which you don't need at all unless you failed to back up the installer?

The difference with GOG is that with Steam games -- even those that don't use Steamworks -- you need to use Steam AND have a working Internet connection to install the game, so you are not truly separated from Valve's ecosystem. With GOG, you can download all the games you own, back them up to a portable hard drive, and then you can play all the games regardless of your Internet connectivity or GOG's continued existence, even if you change or wipe your computer. With Steam, you can only play these "DRM-free

I wonder how open Steam would be to improvement on that front. Steam could certainly improve (for a certain measure of improving, anyway) when it comes to DRM-free games. Something as simple as allowing you to browse the store for DRM-free games would be an improvement. Providing an installer or perhaps making the backup feature not requiring an internet connection when dealing with DRM-free games would be nice too (like GOG.com's installer!). OTOH I also understand what kind of service Steam is offering vs

I actually wonder why GOG doesn't improve their downloader app into a full Steam competitor, which automatically downloads, installs and keeps your games up to date. It wouldn't imply adding DRM -- you could still download the stand-alone.exe installers, and the GOG client could have a "save as.exe" button. Because as it stands, I have to keep making this trade-off between properly DRM-free games (GOG, and Humble Store for that matter, which is also nice in that it supports Linux) and the convenience of h

Reasons like this are why Vavle's push is good for the entire Linux community and not just gamers. I see a lot of naysaying about SteamOS, but what really speaks to me is the number of gears that are beginning to turn.

This. In my opinion FOSS works best when there is some real commercial interest behind it. They can throw a bunch of properly paid engineers on the problem instead of some weekend hobby coders. We should get quite robust results.

Reasons like this are why Vavle's push is good for the entire Linux community and not just gamers. I see a lot of naysaying about SteamOS, but what really speaks to me is the number of gears that are beginning to turn.

Well, it's because Valve sees the competition, and they see where they have an open field. Linux is one of them - the app stores it has are few and far between. Valve and Steam are huge names among the computing community.

And while Windows and OS X have their own app stores that compete with S

How about also building a decent general purpose debugger? GDB is a pile of shit, so folks resort to just stuffing their program full of printfs() and examining the output. I'd pay good money for a state of the art debugger that works on Linux.

"Valve's Linux initiatives are making game companies to think about OpenGL,"

Unless Valve is makingcompanies, this "to" should be omitted. Either that, or "making" could be switched to "forcing". Yeah, kinda OCD, I know, but we need to save the English language from the Internet!:|