Excors

Member
  • Content count

    274
  • Joined

  • Last visited

Community Reputation

715 Good

About Excors

  • Rank
    Member
  1. [quote name='PrestoChung' timestamp='1301135851' post='4790631']I wonder what kind of range needs to be accounted for?[/quote] The queryable values are [url=http://feedback.wildfiregames.com/report/opengl/feature/GL_MAX_ELEMENTS_VERTICES]GL_MAX_ELEMENTS_VERTICES[/url], [url=http://feedback.wildfiregames.com/report/opengl/feature/GL_MAX_ELEMENTS_INDICES]GL_MAX_ELEMENTS_INDICES[/url] - they vary from about 1024 to about 2 billion. But per [url=http://www.opengl.org/discussion_boards/ubbthreads.php?ubb=showflat&Number=125297#Post125297]this explanation[/url] they're really only relevant for glDrawRangeElements (not glDrawElements) in old-fashioned systems that aren't using VBOs where the drivers copy the given range of vertex data into a bounded buffer, so it's probably best to ignore those values.
  2. The game's had a new alpha release so there's a lot more users reporting data now (something like 500 over the past few days) and [url=http://feedback.wildfiregames.com/report/opengl/]the data[/url] ought to be more comprehensive and hopefully more useful now. [quote name='rick_appleton' timestamp='1298626534' post='4778832']I'd also see the value in what driver versions support what extensions, so I'm wondering if you've got a specific reason for merging driver version together?[/quote] The driver versions are still all reported, like on [url=http://feedback.wildfiregames.com/report/opengl/device/Intel%20965/963%20Graphics%20Media%20Accelerator]this page[/url] - they're just merged into a single column to save space when the other data is identical.
  3. It should be possible, but it's not advisable. The OpenGL 2.0 spec says: [quote]Buffer objects created by binding an unused name to ARRAY_BUFFER and to ELEMENT_ARRAY_BUFFER are formally equivalent, but the GL may make different choices about storage implementation based on the initial binding. In some cases performance will be optimized by storing indices and array data in separate buffer objects, and by creating those buffer objects with the corresponding binding points.[/quote]
  4. Yeah, the giant table was getting a bit unmanageable . I've redesigned the interface now so you can view the devices supporting a given extension, or the range of implementation-dependent values for a given feature, or the features supported by a given device, which is hopefully a more helpful presentation.
  5. What version of Firefox? It works for me in 3.6, and [url=http://caniuse.com/#feat=transforms2d]apparently[/url] it should work in 3.5 too. (I'm not good at designing an interface that looks okay in modern browsers, so I don't really want to make it harder for myself by supporting much older ones too )
  6. For [url=http://wildfiregames.com/0ad/]0 A.D.[/url] I was interested in what kind of hardware is common among players, and what gives acceptable performance in the game, so I've set up a system where the game can report various details back to a server. (It's disabled by default and opt-in - there's a button on the main menu screen which enables the automatic sending of anonymous feedback while the game is running). A large part of that information is OpenGL extensions and implementation limits, and I'm thinking it would be useful for others if we published that information, so I wanted to check for input before finishing the work on this. The game currently seems to have something like 10K downloads per month of the alpha releases, so I expect this could collect a lot of data. A fairly large proportion of users are on Linux so we can get data for those drivers too. (Some are on OS X, but not many, since we're lacking good packaging support there). The game runs on fairly low-end hardware (GeForce 4 should be okay, Intel 965 might be bearable, etc) so hopefully it'll get relatively broad data. The current data is [url=http://feedback.wildfiregames.com/report/opengl/]like this[/url]. (This comes from users of the SVN version, and there's some gaps and bugs since the code's still being worked on, and the report UI isn't great). In particular it's got the basic device-identifier strings, driver version numbers (only on Windows), list of GL extensions, and the values from various glGet* calls. It should include all the implementation-dependent state from GL 1.3 (unless I missed any), plus all the ARB extensions included up to GL 2.0, plus a few other extensions. (The exact details are [url=http://trac.wildfiregames.com/browser/ps/trunk/source/ps/GameSetup/HWDetect.cpp?rev=8937#L192]here[/url]). Rows that are identical except for driver version are merged together, but otherwise nothing is discarded, since it seems useful to know the limits of not-the-most-recent drivers. The full data is downloadable as JSON from that page. The other GL databases I've seen so far are typically limited in size, or scope (not many data fields, no Linux, etc), or are no longer online, and they rarely make the data downloadable, so I'm hoping this can provide something new and useful. Would people really be interested in it? If so, is there more data you'd find useful (e.g. implementation limits for other extensions), or any particular dangers to watch out for when doing this?
  7. [web] Custom HTML Tags

    The 'custom tags' won't work at all in IE - it parses each tag into an empty element (one named "FOO", one named "/FOO"). If you write <script>document.createElement('foo')</script> then IE will start parsing <foo> into an element with content, but that's totally evil. Other browsers parse the tags kind of like <span> or <div>, but they all do it slightly differently (e.g. Firefox 2 doesn't let you put block elements inside custom tags, but that was fixed in Firefox 3). (DTDs are irrelevant - browsers ignore them entirely. You might trick the validator into saying your document is okay, but that's a waste of time.) For your own sanity, don't use custom tags [smile] Quote:If you include any tag that is not covered by one of these standards in your document, then the document is not valid HTML anymore—this may mean that the browser displaying your document may do anything with it.The HTML 5 draft does cover unknown tags, and requires them to be parsed identically to <span> (via the "Any other start tag" steps). Mozilla, Apple and Opera have indicated that implementing the HTML 5 parsing algorithm is a long-term goal, so hopefully they will converge on that behaviour. (No idea what Microsoft plans to do, though.)
  8. That seems a slightly unusual way to loop over all the matches in a string. It would be more common to write while (<>){ while (/<!--(.[^-]*)/g){ print $2."\n"; } } (using the /g flag to make it match the next occurrence each time through the loop). If this is meant to actually be extracting HTML comments, then you'd want something more like /<!--(.*?)-->/ because it's perfectly valid for comments to contain individual dashes. (The .*? in that regexp is the same as before - it means it will match as few characters as possible before finding the -->, instead of as many as possible, which will matter if there are two or more comments on the line.)
  9. Your example works for me. Quote:How does CSS determine 'precedence' of classes upon an element when two+ classes are assigned to it?The CSS spec has the details, particularly in the section about cascading order and specificity. The order in the class="..." has no effect - if all else is equal, it will prefer the styles from the last-defined declaration.
  10. BrowsrCamp usually works in a few seconds, which is very nice.
  11. (That <htmL> shouldn't be there.) Opera gives the same output as Firefox, so the difference seems likely to be buggy behaviour in IE. You can force the footer to be below the floating menus by adding .Footer { clear: both; } which makes it look about the same as in IE. And then you just need to fiddle with the margins until the spacing is correct (since IE (at least IE6) seems to do that differently too).
  12. [web] IE7 and CSS

    Sorry, I meant (but didn't correctly say) "something that looks like a doctype (including being in about the right position within the document for it to look enough like a doctype)" and "a document whose entire content is <!DOCTYPEHTML><b<i>Hello world", like here ("rendering mode: CSS1Compat" in every browser I tested) - Opera 9 and IE6 go back to BackCompat mode if you put non-trivial content (non-whitespace text, tags) before it, and IE6 (unlike Opera) also does if you put a comment or <??> in front (though I think IE7 fixes the latter case?). Firefox 3 stays in CSS1Compat despite arbitrary plain text (not containing any tags) before the doctype, but only if the whole doctype stays within the first 1024 bytes of the document. So I agree with what you say - it matters that the doctype is at the beginning of the document.
  13. [web] Replacing tables with layers

    This IE bug? It only affects quirks mode, so it shouldn't be a problem when you've got a proper doctype in the right place.
  14. There's some very experimental work on a portable standardised built-in OpenGL ES interface in web browsers, specifically in Opera (example) and Firefox (code, with a 0.1 release probably happening quite soon), with a note here saying "A future version of this specification will probably define a 3d context (probably based on the OpenGL ES API)". But that'll probably be something like a year or two away before it's properly released (and then IE still won't support it) - at the moment you can't do much other than 2D (or slow 3D-faked-in-2D (blatant self-promotion)). But depending on how exciting you want life to be, and whether you don't mind being limited to Firefox + non-standard extension in the near future, you could probably do something useful with FF's 3D canvas.
  15. [web] IE7 and CSS

    Standards/quirks mode depends on the presence of something that looks like a doctype, and not on anything else in the page - a document containing <!DOCTYPEHTML><b<i>Hello world will always be rendered in standards mode in current browsers. But I intended "validity" in terms of "making a DOM which conforms to the requirements of the DTD", as opposed to the more basic "well-formed" (i.e. no syntax errors, because an XML parser must choke on any such error and refuse to show you anything except an error message, like here) - if you don't even get well-formedness right, despite trying to use XHTML, there are more fundamental problems to sort out than mere DTD-validness. But anyway, using the validator is a sensible idea just because it'll point out things like the <link> being in the wrong place, even if browsers don't actually care about well-formedness or validity since approximately zero pages get it right - they just reverse-engineer IE's bugs so it looks alright no matter what you write [smile]