• Announcements

    • khawk

      Download the Game Design and Indie Game Marketing Freebook   07/19/17

      GameDev.net and CRC Press have teamed up to bring a free ebook of content curated from top titles published by CRC Press. The freebook, Practices of Game Design & Indie Game Marketing, includes chapters from The Art of Game Design: A Book of Lenses, A Practical Guide to Indie Game Marketing, and An Architectural Approach to Level Design. The GameDev.net FreeBook is relevant to game designers, developers, and those interested in learning more about the challenges in game development. We know game development can be a tough discipline and business, so we picked several chapters from CRC Press titles that we thought would be of interest to you, the GameDev.net audience, in your journey to design, develop, and market your next game. The free ebook is available through CRC Press by clicking here. The Curated Books The Art of Game Design: A Book of Lenses, Second Edition, by Jesse Schell Presents 100+ sets of questions, or different lenses, for viewing a game’s design, encompassing diverse fields such as psychology, architecture, music, film, software engineering, theme park design, mathematics, anthropology, and more. Written by one of the world's top game designers, this book describes the deepest and most fundamental principles of game design, demonstrating how tactics used in board, card, and athletic games also work in video games. It provides practical instruction on creating world-class games that will be played again and again. View it here. A Practical Guide to Indie Game Marketing, by Joel Dreskin Marketing is an essential but too frequently overlooked or minimized component of the release plan for indie games. A Practical Guide to Indie Game Marketing provides you with the tools needed to build visibility and sell your indie games. With special focus on those developers with small budgets and limited staff and resources, this book is packed with tangible recommendations and techniques that you can put to use immediately. As a seasoned professional of the indie game arena, author Joel Dreskin gives you insight into practical, real-world experiences of marketing numerous successful games and also provides stories of the failures. View it here. An Architectural Approach to Level Design This is one of the first books to integrate architectural and spatial design theory with the field of level design. The book presents architectural techniques and theories for level designers to use in their own work. It connects architecture and level design in different ways that address the practical elements of how designers construct space and the experiential elements of how and why humans interact with this space. Throughout the text, readers learn skills for spatial layout, evoking emotion through gamespaces, and creating better levels through architectural theory. View it here. Learn more and download the ebook by clicking here. Did you know? GameDev.net and CRC Press also recently teamed up to bring GDNet+ Members up to a 20% discount on all CRC Press books. Learn more about this and other benefits here.

Excors

Members
  • 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. 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. 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. 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. 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]