errcw

Members
  • Content count

    30
  • Joined

  • Last visited

Community Reputation

169 Neutral

About errcw

  • Rank
    Member

Personal Information

  1. I'm happy to announce that Tacticolor, my real-time strategy game for Xbox LIVE Indie Games, is now open source. All the assets and code are available from the linked Mercurial repository. The code is decidedly not a shining example of exemplary design and implementation but nevertheless there are pieces that are not outright terrible, perhaps even good. Of note are the lockstep networking bits for online multiplayer and the AI. I hope it proves interesting and useful for the community. Enjoy!
  2. Crashing The Video Card

    Your hardware is fine. A TDR means something caused the hardware to stop responding past some timeout point. Except for exposing a hardware bug (exceedingly rare), you're really only going to encounter this problem when you have a shader or compute program that runs for too long. "Too long" is typically ~2 seconds.
  3. A few thoughts: - Sponsor is misspelled "sponser" consistently throughout the site. - Sign up is incorrectly joined as "Signup". - And various other grammatical and spelling errors. - On Chrome (and other WebKit browsers?) the last line of each post runs in to the footer. - Having the game description text centered makes it very hard to read.
  4. freeware sprites

    Danc, from Lost Garden, has a variety of excellent free sprite sets: Danc's Miraculously Flexible Game Prototyping Tiles Free game graphics: Tyrian ships and tiles More free game graphics Also take a look at his prototyping challenges for yet more excellent art work.
  5. can I overload return types?

    As noted above, overloading the return type of a function is generally not allowed in most scenarios in programming languages. I just wanted to point out that, in object-oriented programming, some languages support covariant return types. Useful, but unfortunately not the functionality you're looking for!
  6. One notable omission I see from the workshop timeline is a discussion of the content pipeline. Unless, that is, you planned to file it under Week 10. I'd like to see the content pipeline in the schedule because handling and processing a variety of content is one of XNA's strong points. Extending the content pipeline gives you an immense amount of freedom to preprocess or otherwise mangle content. That said, I've found it to be one of the trickier aspects to get right. I'm lucky enough to work with XNA professionally and my (admittedly anecdotal) experience has been that understanding the pipeline consumed a lot of my ramp-up time.
  7. First, it needs to be said that the IE javascript engine is an awful relic. The WebKit (SquirrelFish), Gecko (SpiderMonkey) and Chrome (V8) javascript engines are vastly more performant. So no matter what you do your performance in IE will be degraded compared to most every other browser in existence. As for resolving your performance problem, I would strongly suggest using a javascript library like jQuery (my preferred choice), Prototype or MooTools. For one, you are (mostly) guaranteed cross-platform compatibility that is extraordinarily difficult to achieve using pure DOM manipulation. Moreover, and more importantly, these frameworks are likely to be tuned for optimal performance, in that they will use the best method available to do what you want.
  8. Scheme Help

    So, uh, I'm pretty sure the policy here is no homework solutions. I'll solve the problem in Haskell, then, and leave the extrapolation to Scheme up to you. (Heh, which conveniently solves the problem of not being familiar enough with Scheme to help you directly.) multimap fs xs = map (foldr (.) id fs) xs The key here is composing the list of functions (using foldr) into a single function which is then mapped on to the list. I realize that this must be rather opaque if you're not fluent in Haskell so let me know if I can explain the concept further for you :) (It's an exercise for the reader to construct the appropriate type for the function. The best I could do is multimap :: [a -> a] -> [a] -> [a] but that severely limits your ability to transform the list. One of the cases where a dynamically typed language like Scheme really wins, I suppose.)
  9. C# in industry

    I've worked on a few commercial games in C#. I did a (brief, thankfully) contract stint working on the Fisher Price Digital Arts and Crafts Studio and the client was written in C# with Managed Direct X. I used C# on the .NET Compact Framework to develop a game for a mobile device. I've coded in C# for an ASP.NET site. Of course the plural of anecdote is not data, but I'm trying to illustrate that C# has at least some degree of industry penetration.
  10. Continuing with the theme of manipulating numbers: write a function that counts from 1 to MAX but only prints numbers whose digits do not repeat. For example, part of the output would contain 8, 9, 10, 12 (11 is invalid) then later 98, 102, 103 (99, 100, 101 are invalid). Borrowed from Cedric; the linked post has a lengthy and interesting discussion of potential solutions.
  11. Sure, it's possible, but also a ton of work. The nouveau driver people have a set of Nvidia hardware documents available that you can sift through. You can find the (undocumented) register specs there. Moreover, the nouveau drivers themselves will be highly illustrative. You'll very quickly discover, though, that getting anything done is never as simple as setting a few registers; there's no direct mapping from high-level graphics APIs to hardware commands. (I remember when I worked for ATI (...back when it was ATI) the initialization code for even the lightweight mobile-device chips was thousands of lines.) You're also fighting against a severe lack of documentation and knowledge. (Then again, at ATI our register specs were dubiously documented so I guess that's about on par, heh.) That said, if you decided to potentially tackle the task, good luck. Writing drivers was, for me, always a ton of fun.
  12. In response to your original question, unfortunately I don't think equations of the form a cos(x) + bx + c = 0 have analytical solutions. I tried solving it myself and got nowhere. Moreover, I fed the equation into Maple and it failed; that's a pretty solid indication there is no solution to be had.
  13. Batching in a 2D renderer

    Quote:Original post by Zipster If you're going to be batching the vertices each frame, then you might as well just batch the indices at the same time and make sure to offset them by the appropriate amount. Otherwise, not only would you generate redundant data like you mentioned, but if the geometry was internally indexed (and it sounds like it is) you would need to manually expand the indexed vertices into the buffer, which is probably a lot slower than just writing the indices in the first place. You're right; it may be significantly slower to perform the expansion that it is to adjust the indices. That said, it's probably worthwhile to profile both solutions and make a decision based on real data. Quote:Original post by Zipster One solution is to use rigid skinning... Thanks for the idea. I'm left to wonder, though, if the overhead of setting up rigid skinning every frame might actually outweigh the overhead of performing the transformations on the CPU. Moreover, I'm concerned that it might significantly limit my maximum batch size. Again, I think it makes sense to profile each option. No sense speculating when I can get cold, hard data. :) Quote:Original post by dmatter Could you not just use a draw call per chunk? This would solve all your problems including indexing would it not? It would, but it would also eliminate any benefit to be had from batching. As I understand it (from Batch, Batch, Batch) the CPU is limited to submitting N batches (i.e., draw calls) per frame. If I want thousands of polygons (or any number > N) rendered each frame I need to implement batching of some form.
  14. I have been struggling for the past several days to come to grips with batching in my 2D renderer. I am uncertain how to best handle two scenarios, both of which I have outlined below. First, some background: My renderer sorts geometry into batches based on render state and render layer. It discards all its data every frame; that is, every frame you must specify the geometry to be drawn. (This behaviour is intended to (1) simplify the API so that addGeom/removeGeom is never necessary and (2) avoid the problems of geometry signaling the renderer its data needs to change.) It only renders indexed primitives. (Polygons, the dominant type of geometry, are triangulated using indices.) Indexed Geometry Say we have a chunk of geometry with vertices 0..n indexed with, naturally, values from 0..n. As soon as we batch two chunks of geometry into a single large vertex buffer the second set of indices is no longer valid (e.g., index 0 will not point to the correct vertex). My current solution is to preprocess each set of indices by adding the appropriate base. (Or, alternatively, when I query the geometry for its indices I indicate the base value for vertex zero.) I am concerned, however, that this is terribly inefficient. I could forgo indexed geometry but that would force me to generate reams of redundant data for triangulated polygons. How should I handle indexed geometry? Transformed Geometry Most geometry is in constant motion and must be transformed every frame. As soon as we batch multiple chunks of geometry (i.e., by putting them in a single vertex buffer), however, we lose the ability to transform each chunk individually. My current solution is to perform the transformation on the CPU, transforming each vertex appropriately before it is copied into the vertex buffer. Is this sane? Or is there a way to leverage the ability of the GPU to handle the transforms without defeating the batching? In both scenarios I cite a concern for potential efficiency; please don't misconstrue my questions as premature optimization. Rather, I am worried my algorithms are fundamentally broken and that there is a superior approach to batching that I have overlooked. I look forward to getting some perspective! :) Thanks, Eric
  15. Untitled1.class

    Quote:Original post by HopeDagger Java is pretty much the educational-sector staple in the University In fact, Java is currently being phased out as a first-year language at Waterloo. The 2007-2008 academic year will be the last for CS 125, 133, and 134. Quote:Professor Prabhakar Ragde The courses recommended for CS majors and interested non-majors (CS 135/136, CS 145) will use Scheme, then C. The courses recommended for others (CS 115/116) will use Scheme, then Python. And while I thoroughly agree the Java+Slick is an awesome choice, don't expect the first-years to come equipped with any knowledge of Java. Yay for random UW knowledge.