Jump to content
  • Advertisement


  • Content Count

  • Joined

  • Last visited

Community Reputation

2145 Excellent


About Zakwayda

  • Rank

Personal Information

  • Interests

Recent Profile Visitors

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

  1. You're correct that aspect ratio can be an issue regardless of what approach you take. Aspect ratio and window resolution are to a certain extent orthogonal issues. As you said, using a fixed aspect ratio for the game content could result in stretching/distortion, which I think would be undesirable under most circumstances. So even with the downsampling approach you mentioned, you'd still need a way to handle that. With your e.g. 4kx4k approach, the simplest option might be to clip off the sides or top/bottom of the rendered image as appropriate based on the window aspect ratio (since you're already ok with showing less of the world under certain circumstances, it seems like this would be acceptable). Is there any particular reason you think the quality is or would be poor when downsampling from e.g. 1920x1080 to 1360x768, as you mentioned? I'm not questioning it - I'm just curious as to whether you've tried it, and if so, what sort of negative effects you're seeing. Maybe the downsampling approach is desirable for reasons I'm not thinking of, but it seems like it could have some cost in terms of texture memory and rendering effort. An alternative would be to use art appropriate for the largest resolution you want to target, and then render directly to the selected resolution while letting mipmaps handle the downscaling. That could still result in a lot of wasted texture memory though. A further refinement would be to load art based on the selected resolution (similar to how platforms like iOS and Android provide ways of selecting differently-sized images based on screen size). Also, you may already have thought about this, but showing less of the world on lower resolutions isn't the only option. You could just allow everything to scale with the resolution instead (although as mentioned before you'd still have to deal with differences in aspect ratio).
  2. Just to avoid confusion, are you referring to the 'OpenGL header already included' error? I ask because that appears to be a build-time error rather than a run-time error.
  3. As has been said, there are likely to be portability issues no matter what precautions you take, not only between platforms, but even between and within development environments (as Gnollrunner pointed out). You're probably already aware, but for what it's worth there are alternate approaches and third-party solutions that are insensitive to environmental factors like layout, endianness, and representation of primitive types, can handle complex types such as standard library containers, and can serialize to and from human-readable formats such as JSON. If you intend to stick with your current approach though, there may be some things you could do to protect yourself a bit. One option would be to store serializable data in a single POD object, rather than trying to serialize portions of a more complex object. You could then use std::is_trivially_copyable to check for obvious oversights. This wouldn't protect against serializing raw pointers, but might catch other errors.
  4. I'll admit I still don't understand how the quadrant method reduces the amount of work to be done But it may just be me. In any case, I would, as you said, see how a straightforward implementation performs before worrying too much about optimization. If performance is an issue though, there should be ways to address it. Some ideas off the top of my head: - Amortize the cost of searches by spreading them over multiple updates. Obviously the player might move while the search is executing, but if the search runs fast enough (say, in under a second), the error might be acceptable. - Similarly (and with the same caveat regarding player position), run searches on separate threads (admittedly this could be nontrivial). - You may already be doing this, but if you're using a general ray casting system (e.g. associated with a physics system like Unity's), use an optimized domain-specific algorithm instead, like 2D-DDA or Bresenham. - If rounding the player/agent position to the nearest cell is acceptable, and if all or most obstacles are static, you could precompute line-of-sight information and store it as part of the map data. That might seem like an impractical amount of data, but given that it would be (conceptually) a triangular 2-d array and that you can use one bit per entry, it might be manageable. For example, some quick math (don't hold me to this result) gives me about 600 bytes for a 100x100 grid, which isn't bad. This would of course make your line-of-sight tests trivial. There are also other interesting approaches involving e.g. navigation meshes and visibility regions, but they're admittedly nontrivial and would be a significant departure from your current grid-based approach.
  5. I hesitate to answer because I fear I may be missing some nuance or other (and I didn't fully understand the part about quadrants). But, it seems like Dijkstra (equivalent to A* with a constant heuristic of zero) would work, or BFS if weights are uniform. These algorithms allow you to find an optimal node that satisfies a predicate, as opposed to finding a single specified node. Here the predicate would be, "is there a line of sight from this node to the player?".
  6. If the code is the same as in the first post, that means you're still using 'pitch * pitch', and you should fix that first. If you've already fixed that, then the code has in fact changed, in which case reposting it in its current form would be helpful.
  7. Can you post your updated code? (That is, the same block that was included in your initial post.) I'm not entirely clear on what the behavior is at this point. You said the minimap doesn't render completely without the memset, but what happens with the memset? If it's convenient to do so, posting some screenshots showing exactly what's happening with the minimap might be helpful.
  8. If you're curious, there may be ways of examining the layout. Maybe there's something available in your development environment. Or, you could examine the output files in a hex editor, or compute and log the differences between the addresses of each member of interest and 'saveStart' (as e.g. char *'s). By comparing results in debug and release, you might be able to identify where and why things are going wrong. It seems like it could be interesting and perhaps informative to figure that out, but as has been mentioned, this approach has various caveats associated with it, so it might be worth at least considering alternative approaches.
  9. Zakwayda

    "Nice" tweakable S-function

    Although I'm not positive, it looks like the function in the accepted answer here: https://math.stackexchange.com/questions/121720/ease-in-out-function/121755 Might have the properties you're looking for.
  10. @rjhwinner03: Unless I'm mistaken, it looks like you're assigning each pixel a value anyway, so it might be worth considering whether you even need the memset to begin with.
  11. Zakwayda

    c++ use map with struct

    I was asking about the word 'Idenety', not the prefix.
  12. Zakwayda

    c++ use map with struct

    I see. Regarding the testing, if it seems like it's working, I'm wondering if it's just circumstantial (e.g. maybe you're just testing it with one user identity). If you're not sure about that, you could post your test code for us to take a look at. As for the topics under discussion (arrays, etc.), I think getting more comfortable with those would be helpful. The function you're trying to implement is, I think, a reasonable test bed for that, as it touches on a number of relevant issues, such as pointers, arrays, memory management, and ownership semantics. Although eventually using something like std::vector would probably be preferable, implementing it 'manually' might be a good starting point.
  13. Zakwayda

    c++ use map with struct

    Like Zipster said, there may be other considerations at play here. As far as the code itself goes though, a couple questions. First, does it compile? Second, have you tested it, and does it produce the desired results? Something you might consider is setting aside the DLL issue for now and just focusing on implementing this in isolation, maybe even in a self-contained single-file terminal or command-line app. That way you could post your code in its entirety for others to look at. What you have there appears to be the same thing you had before, just expressed differently. As such, it still likely doesn't do what you want. Although I mentioned std::vector earlier, you might benefit from implementing this without such tools first in order to better understand the underlying concepts. How familiar are you with topics such as arrays, pointers, and manual memory management?
  14. Zakwayda

    c++ use map with struct

    I'm still curious as to what 'Idenety' means, but perhaps it's not important. I haven't done much with Windows in a while, so I'm not going to comment on the DLL aspect of things. There may of course be additional considerations related to that. Your original implementation doesn't do what you want (as you probably know by now). All it does (as pcmaster pointed out) is write the name-ID pairs to the same UserIdentity instance repeatedly. If the map is empty, the UserIdentity instance will be unaltered. If the map contains one entry, you may get the desired results (more or less), but only circumstantially. If the map has more than one entry, only the last one will be recorded. 'UserIdentity *' could also be treated as an array. You're not treating it as one though, and you'd need knowledge of its size to write to it safely. 'UserIdentity **_UserIdentity' might be appropriate if you wanted the function to be responsible for creating the array. Typically though, in that case you'd just create the array locally and return it, I would think (although in both cases you'd probably need to convey the size of the array to the user somehow). Lastly, barring other considerations (again, I'm not addressing the DLL issue here), it's common to use RAII containers such as std::vector for things like this to alleviate the burden of manual memory management (and to avoid the kinds of bugs that can come with it). I think the most straightforward implementation of a function like this would create a std::vector instance locally, populate it, and return it. Again though, perhaps there are other considerations at play. Edit: Minor correction.
  15. Zakwayda

    c++ use map with struct

    I'll just ask a couple more questions to try to clarity things further. - What does the name 'TIdenetyClass' mean? Is it a 'T' prefix plus the word 'Idenety'? If so, what does 'T' mean, and what does 'Idenety' mean? (Note that I'm not questioning your naming conventions or anything. I'm just trying to better understand what the names mean.) - I still don't understand the implementation of get_all_users(). An instance of UserIdentity only stores a single name-ID pair. How are you expecting to store multiple such pairs in a single instance?
  • Advertisement

Important Information

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

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!