• Advertisement


  • Content count

  • Joined

  • Last visited

Community Reputation

3 Neutral

1 Follower

About DerekB

  • Rank

Personal Information

  • Interests
  1. 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.
  2. C++ 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);
  3. Quadtree/terrain frustum culling help

    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.
  4. Visual Studio 2017 Beginner

    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.
  5. 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.
  6. 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.
  7. 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:)
  8. An idea unsupported by any specific knowledge or experience, I'd be looking carefully at synchronisation, I wonder whether something is clobbering your shadow map before you're done with it?
  9. If I understand you correctly it sounds like you're interested in visual scripting or visual programming, you might find something interesting with a google search for those terms. Off the top of my head I can suggest GameMaker Studio or maybe UE4 with a focus on blueprints.
  10. I would go with the templated multiplication operator suggested by @GDnetplus, it's narrowly targeted to support only the operations you want to support, and it follows a pattern you'll find in the standard library which makes it unsurprising.
  11. Yeah, I wondered why the fascination with removing, then I thought maybe it's an occlusion culling pass after first adding everything in the frustum or something. (Personally I'd tackle that by using my occlusion cull to filter the first vector and add things that are not occluded to a new collection, but if @noodleBowl has a need to remove things from the vector then my advice is just do it and worry about performance if it's too slow.)
  12. To be honest I think you might be The best bet is to do the simplest thing that works. Put all of your renderables into a vector, when you're ready to draw them sort the vector. Radix sort is commonly used in this scenario. If you need to remove renderables which were previously added then just remove them from the vector. You might as well use the swap and erase trick to avoid lots of needless memory shuffling. Unless you are removing a lot of renderables from a large collection the linear search for the renderable to remove will probably not be an issue. You'll probably find that's good enough to ship.
  13. I'm working on the same thing right now, creating a low level API which I can build a higher level scene management framework on top of. I've wound up basically aping the Vulkan API as I didn't want to abstract away any of its expressive power and I believe I can implement it efficiently on top of OpenGL ES 2/3, dx12, metal and various console APIs. For platforms where I want to support switching the implementation at runtime I'm using a virtual interface and dynamic libraries, on platforms where there is only one implementation it's just statically linked directly. I don't anticipate the calls to the rendering API through a vtable being a performance concern.
  14. Yes you need to find the item you want to remove. If the vector is sorted you can use a binary search, otherwise you have to do a linear search. Swapping the item to the end before removing it will make removal faster but after that the items are unsorted and finding further items then requires a linear search. You could remove the item and move all the following items down to keep the array sorted which makes subsequent searching faster but remove is slower. You could simply mark items as removed and leave them where they are,then the array stays sorted but at the expense of keeping the additional items around. It's all trade offs and the most optimal solution depends on how many items you'll be working with, how often you need to add and remove items, etc.
  15. Where to start making a game in assembly.

    What you want to do is perfectly feasible. If I understand your intention correctly you want to use the SDL to develop a C framework for your snake game to run in? Something like: int main() { init(); while (!quit) { poll_input(); // Update input state update_game(); // Call your assembly entry point; assembly code updates the game state and renders to a bitmap present(); // Use SDL to display the bitmap } shutdown(); return 0; } If that's your approach then it's a sensible way to limit just your game state and logic to being developed in assembly. I'd recommend first just writing a single routine in assembler and working out how to assemble that and link it with an object file compiled from C, then work out the ABI so you know how to handle parameters and return values, and finally how to share data between the assembly and C parts. Once you have that plumbing in place you can iterate away on your game in assembly. I agree, I've done a couple of hobby games for the 8-bit Atari, it was the first computer I had and learned to program on and it's a lot of fun and very rewarding to develop for it using an adult's brain and modern dev tools.
  • Advertisement