Jump to content
  • Advertisement

c2_0

Member
  • Content Count

    136
  • Joined

  • Last visited

Community Reputation

298 Neutral

About c2_0

  • Rank
    GDNet+
  1. 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.
  2. 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
  3. 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
  4. c2_0

    Instinct Training Sessions

    Al. Dave. Most appriciated.
  5. 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]
  6. c2_0

    Half way

    Cheers [smile]
  7. c2_0

    Force Fields

    Forcefield shields, nice! Reminds me of Another World, which was just re-released clicky
  8. c2_0

    Physical rant

    Ye, I came across similar information about pmaps, although they it's not quite clear from the official documentation. In any case, like Jesse said, I've learned [smile] We'll be building our all game objects from convex, or groups of convex shapes as suggested. The way the engine is set up at the momement, they have a one-to-one binding between actors and shapes, so for objects statically combined of multiple shapes we might have to do some trickery. I don't think we'll run in to any such issue though, since most our game objects should be convext shapes anyway. Suggestions and input always appriciated. Thanks [smile]
  9. c2_0

    Eww...

    Quote:Original post by Ravuya Repeat after me: ...typedef is my friend. Typedef makes things readable. I should endeavour to use typedef often. [smile] Concur
  10. c2_0

    Physical rant

    Today's been a most unproductive day. Unproductive in the sense of progress made, not work commited. Even more unsatisfactory [depressed] The better part of the day I spent trying to get mesh-mesh collisions going in Ageia PhysX; between our level and some arbitrary object. The thing just went mad with jittering, bouncing, and seemingly random behaviour. I assumed it was something to do with the way the engine sets up the physics system and objects (skin width, center of mass, inertia tensors, something like that). No luck tweaking values or setting flags. It all boils down to this. In PhysX, for mesh mesh collisions, you need to create pmaps for the meshes. pmaps only work properly on meshes that represent some sort of closed volume. As far as I can understand from the documentation, the process of generation applies raycasts to find extents of the volume, and further stores this in some sort of voxel structure for faster and more robust intersection tests. Now, our level naturally isn't a closed volume mesh, so ultimatly that screws up the pmap and any hope of arbitrary meshes colliding with the world [smile] To resolve this I suppose we could remodell the level with closed volume colission meshes, which in turn might make the character interaction less smooth (pluss our level designer will probably be jumping with joy [rolleyes]). Perhaps more realistically, we can restrict all world-interacting bodies to be of convex shapes, which should work fine without pmaps. None of this is too hard in itself, but working through someone else's wrapper (the engine we're using), hacking and slashing through their indirections, adding here and there, and never quite knowing if a problem stems from a bug in our code, their code, or in Ageia's PhysX itself, makes for a somewhat frustrating experience. May tomorrow be a better day [rolleyes]
  11. c2_0

    Half way

    You're right, it is a bit lacking. At the moment we have focused on getting the level up, the player in, etc. Next up is more texturing, effects, NPCs, and other gameplay elements. We're only 5 weeks in, started from scratch, and with only 10 weeks of total dev time for the competition, so we had to focus on getting functional aspects up at first. Thanks for your input.
  12. c2_0

    Half way

    Cheers :)
  13. c2_0

    Half way

    Competition is half way through, and we've just completed our first milestone... whoohoo! It's been an enjoyable 5 weeks so far, working long hours every day, and things are finally starting to come together. We now have something that more resembles a game, with a bulk of the character movement completed, an initial level up, animations, NPCs soon to come, as well as a bunch of ideas in the works. I haven't posted much about the actual game, so here are a couple of screenshots before I get back to work. Racing around a corner Magnetizing to the side of a building Posing :) We aim to make public some sort of playable demo at the end, so hopefully the coming 5 weeks will prove even more productive. Wish us luck [smile]
  14. c2_0

    Instinct Training Sessions

    Some pictures from the Instinct training sessions Hands on training with the engine. Close to the camera in the white shirt would be me [smile] A group picture of all Dare teams using the engine. Everyone mixed up in no particular order. Instinct crew are the 3 people in the center front.
  15. c2_0

    Untitled

    LoL, loved the "MAN" and "GOD" ones [rolleyes]
  • 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!