glCapsViewer (and online database)

[phibermon]

Yes I can confirm it works, it returns "Microsoft Windows XP" on this system. No indication of 32/64bit but it's probably only worthwhile making the distinction for Vista and 7, there's going to be barely anyone on XP64 and server users will be a minority.

Thanks again for your time on this, such a database will be invaluable to so many people.

I've experimented with APITrace (commented on in my first responce) and it's quite in-depth, it might be a bit of a pain to parse the info (if it was a good idea)

--

Does anybody reading know of any other 'pass-through' tools that log the GL calls made by an application?

[Sascha Willems]

Thanks for your feedback. I'm glad it works, and it was actually not only XP64 that had the problems. Tried in a 32 Bit XP on an older machine and got the same error, so I guess it's best to leave WMI out of the app. And yes, I don't think it's important to know wether the report is from a 64 or 32-Bit machine as the OpenGL capabilities should be the same for the same driver.

And as for logging GL calls, have you tried GLDebugger. It became freeware some time ago and is a pretty in-depth debugger for OpenGL apps.

[Jimmy Valavanis]

Worked fine here, I've uploaded the results!

[vgo]

No OpenGL info is displayed when the program starts and when I click "Detect caps" I get access violation.

[Sascha Willems]

Do you have a driver with OpenGL support installed? A user over at DGL reported the same problem and it turned out he only had the default windows drivers for his card installed, and these don't include an OpenGL ICD. So make sure you have OpenGL driver installed. And if you have them installed could you tell me which OS you're running on and what graphics card you use?

And I'll try to implement hardware support detection for the next version so users without proper OpenGL support won't get crashes or AVs.

[WILL]

Personally, I'd parse all the data into proper fields and have each report it's own record. I'd try to parse specific data from XML into certain fields that would be best for doing queries, such as max texture size, OpenGL supported versions, etc...

Most of your Query work should be done in SQL not in PHP. Let the database do it's job and you'll be happier with the results. The trick is going to be parsing your XML data from the app into proper fields in your records.

I'd save as much data into fields of a record, but also keep a raw copy into a field as a chunk of text. This way you can write a script later on that can re-parse old saved reports in the DB and update to a new and improved database later on with even better statistics that are even more useful to developers than the previous version of your DB.

When I was heavy into web development a few years ago I cound the php.net and mysql.com sites' documentation infinitely useful as a reference. Also I'd recommend using phpmyadmin for developing your DB structure. It makes things so much easier than trying to write script that'll create a DB.

Yea, I plan to do statiscs, but e.g. "avg. texture size for hardware older than xxx years" would be really hard to implement. Cause the driver information doesn't include age or release data of the hardware, so I would gather a list of releasedates from the web by myself. But some simple stats (no. of cards per vendor etc.) will come soon.

But first on my list is searching the database (gotta read up on that stuff for PHP, only got very basic PHP skills). So that you will be able to e.g. search for a given extension and all graphics cards that support it are listed. Same with e.g. texture size, so you say "I need a list with all cards that support at least textures of 4096x4096 pixels" and the database will list them. I think that's a pretty important thing for developers and so I'll put priority on this as devs can then quickly check what hardware has what extension etc.

Though I'm still not sure about the database. As I mentioned the reports are XML and are uploaded to the "database" and the PHP scripts just iterate through them (PHP has DOM support, so you can easily get node information from XML). But since I don't really know that much about web development I'm kinda unsure about the load that a search would put on the server. I mean each search for an extension e.g. would make the search script go through all XMLs and check the extension nods for a string. But I think as long as the database doesn't include hundreds of reports that won't be a problem. And yes, I even tried with a real database (SQL), but putting something dynamic and extensible like an XML into a SQL database is nothing trivial, so I'm not sure if it's better to leave it like it currently is with the plain XMLs uploaded and searching through them via PHP.

[Sascha Willems]

Version 0.5 is here along with a real SQL-database
After a crash course in SQL (and PHP) druing the last days (and with some help from Horazont and Frase) I finally got a real SQL database up and running, with all the old reports migrated (so no need to reupload if you did already). So now the database is running atop of SQL, making it much faster and also allowing stuff that the old PHP-parsing-XML-thingy could never do. So for example you can now compare up to 8 reports to get a nice table with all values and the possibility to direclty compare supported extensions, along with a statsitics page listing the number of reports supporting a given extensions.

Though this is just the beginning as I can do a lot more with a SQL running in the background than what could've been done before.

Note that all links are the same, both win32 and linux-i386 versions have been updated, and the database is still here

[Sascha Willems]

Thanks to the help of damadmax (a user from the delphigl.com forums) I can now present a Mac OS X port of glCapsViewer! So with Mac OS X, Linux (i386) and Windows I got the most common operating systems covered and hopefully this tool along with it's database will become a valuable resource for all OpenGL developers out there.

The Mac OS X version is 0.6. It's just a minor fix that stops it from creating a temporary report file for upload and instead directly sends the stream to the server. This was necessary to make it work from a .dmg (which I was told is the preferred way of distributing Mac OS apps) and therefore I changed the version number for the Mac release.


Note that the database now has it's own subdomain, so be sure to use this if you want to access it or link to it : http://openglcaps.delphigl.de/
You can grab the Mac OS X version over here : http://www.saschawillems.de/?page_id=771


Note : I don't have a mac myself and therefore can't compile for it (thanks to Apples stupid policy of not distributing developer libs for it's OS free, at least not afaik). So I would be happy to get some feedback from Mac OS X users wether it actually works or if it's making problems. Though there are already Mac reports in the database so it should work I guess.

[WILL]

I can now present a Mac OS X port of glCapsViewer!

Excellent, I'll be glad to submit my iMac's hardware as well then! That's if it works.

[WILL]

It worked. Nice job! Works like a charm, except the App icon is a bit small and looks silly tiny on my system. lol

I submitted a report (and it seems I did so before while running WinXP in Parallels on this system too!) which worked just great. Kudos to whomever did the porting. Maybe they can take a look at one of my game projects I'm trying to port over to Mac just now.

Well if you got it going for Mac, the next logical step is iOS! You'd only need a single report from each device, unless you are trying for popularity of hardware.

Oh and don't forget to update your new URL in your downloads page! I noticed it wasn't changed yet.