Jump to content
  • Advertisement

c2_0

Member
  • Content Count

    136
  • Joined

  • Last visited

Community Reputation

298 Neutral

About c2_0

  • Rank
    GDNet+
  1. Adding to the issue of synchronization. Be aware there might be implicit hardware synchronizations when writing (and reading) to the same cache line from different threads. I.e. any non-shared cache level will have to re-fetch to see the other thread's writes.
  2. c2_0

    A Case for Trivial Setters and Getters

    I used to be of the mind that using trivial getters and setters is simply redundant typing. I've later come to see some advantages to writing them, in particular for library code. In addition to those you mentioned (code insertion, debugging, profiling, tracing, etc): Platform independent code Getters and setters provide an interface to your object which can be kept consistent across multiple platforms. There might for example be platforms where your object only acts as a proxy and doesn't hold some piece of data itself. Versioning You can refactor or for other reasons change your implementations while preserving backwards compatibility and behavior. The bottom line is it can make your code more future proof. This is probably only a valid argument for a small fraction of code written, but worth mentioning.
  3. c2_0

    Developing a Graphics Driver II

    Sounds like you've landed yourself a very interesting job there :) I have a couple of questions. 1) Could you give some examples of the kind of mistreatment an application might give the driver? I.e., what sort of best practices can you give that might not be immediatly obvious (and perhaps specific to the NVIDIA driver). 2) In D3D10 the Begin/End Scene API is (finally) removed. I'm curious if this was ever any help to the D3D9 driver (there are some restrictions imposed in D3D9 for what must be done outside or inside Begin/End Scene), and how that effects the D3D10 driver (if at all)? 3) I understand you might not be at liberty to speak on this, but do you know much about how the driver internally handles D3D9 state blocks? For instance, I assume alot of D3D states are compiled into the same GPU registers or register blocks. If a complete set of states for a GPU register is set in a state block, will the driver then store the GPU register rather than the individual states? If so, is there any way to find out which states one should group together to get maximum benefit from this? I would assume that grouping together states that are in D3D10 part of the same state object should be likely to work optimally on D3D10 hardware while running under D3D9. Cheers, Christian
  4. Quote:Original post by snk_kid Quote:Original post by c2_0 ... and focusing on the language being academically "correct" A programming language that is "academically correct" would look nothing like Java what ever that is suppose to mean besides. You're right, bad wording. What I meant was, they seem to focus more on the ideology of the language than the practicalities of using it.
  5. Quote:Original post by ApochPiQ By contrast, I spent two years trying (off and on) to pick up Java. Now, to be fair, I haven't done any UI work for a while now in Java, so I may be behind the times - but I do know that as of last time I checked (would have been 2004) there was no Java UI library that wasn't a steaming pile of feces. There certainly wasn't anything that could touch WinForms for rapid development. I learned WinForms in a matter of minutes, just tinkering around; I once spent three days trying to get a Java program's UI to do what I wanted, and ended up quitting due to the overwhelming urge to shoot myself in the head. As for IntelliJ ... more subjectivity [smile] I'd rather be castrated with a rusty spoon. Twice. LOL and seconded. As for contributing to the discussion, I think one of Java's main mistakes from the start was binding the language to the platform, and focusing on the language being academically "correct", where .Net and C# have a much more market and productivity oriented view. The mere fact that you need special tools in Java IDEs to lessen the need for verbose typing is a testament to the flaws of the language already at the syntax level. Generics (just syntactic sugar) and versioning (functions default to virtual and don't require explicit override) are two other elements where Java has flaws and .Net have got them "right" so to speak. Again, this is personal oppinion, but alot of things seem to make more sense in .Net.
  6. c2_0

    Dare finished

    Last week, Dare to be Digital 2006 finished. In the end, we didn't win anything, but I'm pleased with the outcome anyway. It's been a tremendous experience, alot of hard work, and alot of fun :) Here's a video showreel of the game. The video itself has a few flaws in it, but keep in mind it was put together at 3am in the morning before our presentations :P Now it's off and out into the real world to get a job. I've had one interview and one offer so far. I have a couple more interviews scheduled for next week, so hopefully they will go equally well. Maybe the last to see of Glitch in a while
  7. Re-reading the original post, that's probably more likely than my suggestion. I was thrown off by "closer and further away" that I associated with perspective [rolleyes]
  8. c2_0

    plz help

    You can check out the Articles section There's one under Data Structures about linked lists, clicky, that might be helpful. It's using C++ 'new' and 'delete', but plain datastructures for the list elements, and no templates.
  9. c2_0

    Battleship game in Visual C++

    That's a very open ended question.. It sounds like what you're looking for is a tutorial on C or C++ programming, not the specifics of Visual C++ or how to make battleships. You should check out the articles section, search the net a little bit (I'm sure someone here will recommend some good sources), and perhaps have a look at some books (check out the books section). When you know the basics of the language, you can post back about specifics of the problem you're tackling.
  10. c2_0

    A rendering dilemma

    Also, if you're limited by high pixel shader costs, and this is why you'd want to be rendering front to back, you can do a depth only (/depth + ambient) pass first. This will fill the depth buffer and allow depth tests to discard potentially expensive pixels before their shaders are invoked. If you have high overdraw, or you're already doing multiple passes (say 1 per light for instance), the hierarchical early depth culling can reject regions of pixels per cycle as well, which should help if you're fill rate limited.
  11. c2_0

    Instinct Training Sessions

    Al. Dave. Most appriciated.
  12. c2_0

    Physical rant

    Thanks for the suggestion. They do support a special case for height map meshes, but that wouldn't work for our level. After rethinking things, being constrained to convex shapes for dynamic objects interacting with the world isn't really an issue for this prototype. I added this to the engine's physics plugin the other day, and just the default all our rigid bodies to be cooked as convex meshes. As long as we keep that in mind, it works just fine [smile]
  13. c2_0

    Half way

    Cheers [smile]
  14. c2_0

    Force Fields

    Forcefield shields, nice! Reminds me of Another World, which was just re-released clicky
  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

GameDev.net is your game development community. Create an account for your GameDev Portfolio and participate in the largest developer community in the games industry.

Sign me up!