Jump to content
  • Advertisement


  • Content Count

  • Joined

  • Last visited

Community Reputation

7 Neutral

1 Follower

About DerekB

  • Rank

Personal Information

  • Role
  • Interests

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. DerekB

    Shaders managing

    All of that information could be included in your material definitions. Uniform data can be defined by the materials, for varying data the material definition can tell your engine what data the shader requires, where to bind it, and possibly how to generate it. If you have a particular requirement in mind and can't see how it would work ask about it specifically, talking through an example might be beneficial to grasping the idea.
  2. DerekB

    Shaders managing

    Your current approach of encoding shader name and texture name into the material name you use in Max is reasonable, but it is very limited. I'd suggest a good iteration would be to move to a scheme where the material name in Max maps to a material definition that fills all your requirements. E.g. you might have your runtime materials defined in a structured format like JSON: [ { "name": "Gravel", "vertexshader": "rigid", "fragmentshader": "normalmapped", "diffusemap": "gravel_d.png", "normalmap": "gravel_n.png", "ambientmap": "gravel_ao.png" }, { "name": "Orc", "vertexshader": "skinned", "fragmentshader": "normalmapped", "diffusemap": "orc_d.png", "normalmap": "orc_n.png", "ambientmap": "orc_ao.png" } ] Then in Max you just use the material names on your meshes and you can simply look up the corresponding runtime material when loading the .obj/.mtl files. This approach will scale pretty well for, you can readily extend it to specify vertex attribute requirements and so on. I'd hold off on creating your own format for models/meshes until you've got a clear idea of what your requirements are. If you keep loading obj files, you'll probably end up doing quite a bit of processing on the data post-load, possibly triangulating quads, probably generating tangent basis space vectors for normal mapping, definitely laying out data in GPU buffers and so on. At some point moving that post processing into an offline tool which outputs your own data format will make good sense and what you need to do will be obvious.
  3. You could use FMOD Studio, drop the sounds into simple events and tweak the instrument volumes to suit. Integrating FMOD into your game is pretty simple and if/when your audio requirements become more ambitious you'll have a good basis for expansion. WWise is another good option, I'm not familiar with it but I'm sure it would be easy to do a similar thing there. (Full disclosure: I work at Firelight, the makers of FMOD.)
  4. I don't think this is an improvement - indices in QuadData is redundant (all quads have the same indices), and storing pointers to QuadData in the vector is going to lead to fussy allocations and thrash the poor caches when copying vertex data.
  5. DerekB

    Calculating Vertex Normals

    You may have had some flipped face normals in your input, and fixing that may have made the result of your lighting more plausible, but if you continue to average your summed normals rather than normalising them as JoeJ is suggesting then you are still not getting the correct results. Honestly it's really worth your while to get your head around the concepts JoeJ talked about, unit normals and normalisation are kind of a big deal. Everything you do in 3D graphics will be easier and make more sense if you can understand fundamental linear algebra.
  6. DerekB

    Effect: Black Hole Background

    Really nice work. Now I just want you to put the black sphere in (or make it bigger if that's already there?), the little black dot in the middle is heavily aliased and letting your effect down imo.
  7. You need to invert the matrix you're building in order to transform p1, p2 & p3 from model space to world space.
  8. DerekB

    Drawing a buffer to client window in winapi.

    Sorry to hit and run, I'm literally about to run out the door, but you can check out some code I have which does exactly this here: https://github.com/GeneralLeeInept/vgfw/blob/master/vgfw.h
  9. Check out Brian Bucklew's use of an ECS in Caves Of Qud, he solved exactly the probem you're describing with his approach and has done a couple of presentations about it.
  10. DerekB

    std::thread question

    The thread t1 is not a thread of execution, to "start it" you have to create a thread of execution and assign it to t1: std::thread t1; t1 = std::thread(someFn);
  11. You don't say where you are are getting the exception? This line in Terrain::draw is wrong, I don't know if it would cause your exception, but it's definitely going to run off the end of your mSubMesh collection: pDeviceContext->IASetVertexBuffers(0, mSubMesh.size(), &mSubMesh[a].VertexBuffer, &stride, &offset); Edit: actually it's more wrong than I first thought, your SubMesh type has multiple members, that call will bind mSubMesh[a].VertexBuffer and then attempt to bind everything in memory following the vertex buffer as vertex buffers.
  12. It's difficult to offer any help with such a general and sprawling topic. The best way to learn, and get help, is to have a concrete question or goal. You mentioned that you are doing a C++ course and as you're interested in using Visual Studio I'm going to guess that you have easy access to a desktop PC, so I'd suggest you focus first on creating a desktop C++ Hello World application. It's easiest if you aim for a windows console application first.
  13. DerekB

    Iometric depth sorting (C++, SFML)

    I would assign a sorting ID to each tile in the map and at preprocessing or loading determine the map space sorting coordinate for each sorting ID, then when you want to render a set of tiles you can just sort on sorting coordinate. The sorting coordinate would be the map space Y co-ordinate of the tile which corresponds to the lowest screen space Y co-ordinate when rendering (visually that's the bottom edge of the tile on screen). Background tiles could all get a special sentinel ID and sorting co-ordinate which always sorts to the end of the list, multi-tile sprites like your trees would have the same ID for each tile so the whole lot sort together. Dynamic sprites like the player sort correctly based on their current sorting co-ordinate. The assignment of sorting IDs to tiles would best be done automatically, given the information of which tiles are background tiles, which tiles are members of sets like your carved up trees, etc, it should be possible to develop an algorithm that assigns appropriate sorting IDs. I think the trouble here is that OPs situation involves an unbounded number of tree layers and no fixed ordering for the player layer.
  14. DerekB

    Iometric depth sorting (C++, SFML)

    I feel like your current approach should be viable, if you sort using the baseline of the sprites by y co-ordinate (with y increasing from top of the screen to the bottom). Edit: I just reread your post and caught the bit about breaking the sprites up into tiles. That's fine but you're going to need to use the same sort order for all of the tiles which compose each sprite and use the baseline of the bottom tiles as the sort key.
  15. Glad you figured it out, I only just had a chance to check back and was about to reply that your image barrier looks okay, but I guess you know that now:)
  • 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!