Advertisement Jump to content
  • Advertisement

JasonBlochowiak

Member
  • Content Count

    534
  • Joined

  • Last visited

Community Reputation

601 Good

About JasonBlochowiak

  • Rank
    Advanced Member
  1. JasonBlochowiak

    D3D and multi threads

    I'd recommend doing only file open/read/close on the secondary thread, and leave all the d3d calls in the primary thread. Depending on how you've got things set up, keep in mind that d3d might be doing things like creating mip-maps and format conversions. If you use .dds files with pre-created mip-maps in the final format (like DXT compressed), there will be a whole lot of work that won't have to happen after you load the texture. Also, depending on your usage patterns, some people suggest pre-creating the d3d resource (in this case your texture) at application start-up, and then keeping a pool of them around. When you actually get your texture bits in memory from your other thread, you can just lock/copy the data into the existing resource. Before doing that, though, try the .dds route.
  2. You can have multiple parts that are all in the same mesh, and then just turn parts on or off. Whether that's a performance win depends on what your engine's overhead is per mesh.
  3. JasonBlochowiak

    Rays V. Physics

    You could use something like a swept sphere test, where the radius of the sphere represents a reasonable amount of ballistic arc for a segment. Depending on circumstances, you could do a few swept sphere segments to accomodate a larger arc. Then, if you got a hit within a given segment, you could do the piecewise linear ray testing that's been mentioned.
  4. JasonBlochowiak

    Programming Portfolios - How much is too much?

    I usually skim through the code, looking for good or bad habits. If I see something of particular interest, I may pay more attention to it, but that's usually not all that necessary. Having a few different things is usually better than just one thing, but if it's a choice between one good thing or three meh things, go for the one good thing.
  5. JasonBlochowiak

    projective texture mapping with multiple instances

    I didn't mean using multitexturing to render all the indicators at once, I simply meant rendering a bunch of quads - one per indicator.
  6. Quote:Original post by James Sutherland Oh, absolutely. We certainly used plenty of inheritance in our component-based system. Similar components inherited interfaces and behaviour from each other quite a lot. What we didn't have was a single big inheritance tree that every type of entity was part of. Essentially, you have a number of smaller, flatter trees from which you pick components to plug together, rather than a single big tree. I'm not interested in advocacy, and I certainly wouldn't suggest that this is The One True Way for building your game entities. All I really can say is that it worked pretty well for us. Interesting. I'm actually using a single inheritance tree for every entity, but using non-generic components to build the behavior of each of those entities.
  7. JasonBlochowiak

    Need some pixel shader (HLSL) help

    Here's an abstract. And a reference to GAXEL here. As I remember it, some of the video decode still had to happen CPU side, but quite a lot of the raw number crunching got moved to GPU. I thought there was more information out there, but I seem to not be finding it at the moment - sorry.
  8. JasonBlochowiak

    Constants in header files

    Quote:Original post by Decoda On a related note for some reason I find the use of ALL_UPPERCASE for constants a bit old school. I notice that the Maya API uses a k prefix for all it's constants which I like the look of but at the same times seems a little odd as constant doesn't start with a k eg. const float kShipSize = 2.0f; Constant starts with a k if you're speaking German. Don't know if that's the origin, but given the number of scientific articles written in German, it's at least a possibility. Btw, my personal style matches the way Maya does constants.
  9. JasonBlochowiak

    collada

    Quote:Original post by Spoonbender I recently had to use Collada for a project. I ran into two problems: #1: Most Collada exporters seem to be more or less buggy #2: As said above, the format is *huge*. Too huge, in some cases. We had a lot of problems with the exporter seemingly randomly changing the representation of various data. Sometimes it decided to use a vector, sometimes a matrix. For no particular reason, even. That meant our Collada importer broke every time we exported a new model (or exported the same model again), because *now* the exporters just felt like exporting things differently. I'm currently using Collada as an intermediate format, and I plan to stick to it (and I've written Max and Maya exporters in the past). #2 really is the biggest drawback. Different methods of construction can cause the exported data to look quite different, and different DCC packages can cause this as well. My approach has been to make what (valid) content the artists produce actually work with my DOM-based importer, and increase the robustness of the importer as time goes by. Something of a pain, but if making games was easy, everybody would do it. :)
  10. JasonBlochowiak

    Mixing Physics + Scenegraph

    I've not seen a physics solution that doesn't allow for attaching things together somehow. Any reason that a system for parent/child relationships shouldn't be implemented by attaching them together physics-side, and let the physics solution deal with it? Any controlled scene graph nodes would then be able to just get their world-space transform from the physics sim, and you're done. Additionally, things like breakable constraints just automagically work in this scenario.
  11. JasonBlochowiak

    How to implement lighting...

    What's best really depends on the specifics of the scene. Is the geometry static, mostly static, or dynamic? Are the lights static or moving? With that said, I'd recommend maintaining object/light pairing by inserting the light into the topmost fitting node. When adding a light, you then traverse down to all child nodes, adding the light to the objects in the nodes. When adding an object (or chunk of geometry or whatever), you accumulate lights as you drill down to the node that you end up putting the object into. Or, you could leave a pointer to objects contained in the current node and all child nodes, which would make updating lights faster at the cost of a bit more storage and maintainance on object movement, etc.
  12. JasonBlochowiak

    In game mesh customization..how?

    Morph targets are also used - sometimes in an initial "baking" step, and sometimes at render time, depending on the usage. Texture blending is another applicable technique.
  13. This smells more than a bit of golden hammer. Components are a useful tool, but relying on them entirely seems like overkill, especially for base items (like location) that almost all of your entities are going to have seems silly. Inheritance, when used well, is a A Good Thing, and not some inherently evil thing to avoid.
  14. JasonBlochowiak

    Need some pixel shader (HLSL) help

    I'm a bit confused about your perception of "needing more than 8 bits of precision." The source texture and destination texture may be 8 bit, but the ALU ops that are doing the math are higher precision, as are the constant registers for the pixel shader. Unless I'm missing your intent, what you're talking about it totally do-able in a pixel shader, even early revisions. I think there's a sample out there that does DCT type stuff on GPU, but I don't remember exactly.
  15. JasonBlochowiak

    Normal mapping doesn't work on flat surfaces?

    I do all my lighting in world space - it's easier to write orthogonal shader code that way, it seems. If you're doing scaling (uniform or not), you'd still presumably need to re-normalize after transform, which does preclude some tricks (like encoding ambient occlusion in the normals' lengths).
  • 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!