Jump to content
  • Advertisement


  • Content Count

  • Joined

  • Last visited

Community Reputation

1500 Excellent

About DaBono

  • Rank
    Advanced Member

Personal Information

  • Role
  • Interests

Recent Profile Visitors

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

  1. What does 'not working' mean in your context? If you have a mutex around writing the variable, but not reading, the only change you made in synchronization is that no multiple writers can write to the variable. However, it is still possible for a reader to read the variable halfway through the write operation. If that variable is not an atomic type (e.g. a struct or other compound), your read operation may very well happen halfway that write. Surrounding your read with a lock/unlock would solve that problem, since you now guarantee that no two threads may be in the parts surrounded by lock/unlock simultaneously.
  2. One line before the compiler error happens, the code created an item of type T. In your case, that is an InventoryItem *, which is unintialized by default. It is just a pointer and has no object associated with it. Your code actually assumes that it contains a valid object and dereferences the pointer that points into nothingness, hence the error. You should either use: static bool decode(const Node& node, InventoryItem*& inventoryItem) { inventoryItem = new InventoryItem(); inventoryItem->name = node["name"].as<std::string>(); // .. etc .. } or consider not using the pointers.
  3. Are the original _mouseX and _mouseY int's? They should be casted to 64-bit numbers before you are able to correctly shift them 32 bits.
  4. Also, check that the C-functions you use pop everything they push temporarily and the amount of return values you return matches the amount you pushed.
  5. Yes, although in my experience the most significant benefit is sorting not on texture per se, but on texture size. (So rendering all 256x256, then all 512x512). In principle, the fewer state changes, the better.    That said, I guess there is some worst case scenario where you cause lots of overdraw. Experiments for your particular case may be necessary.
  6. DaBono

    Graphs tool for a thesis (needing an suggestion)

    GraphViz is the most obvious candidate to me. An online tool for this exists as well.   Edit: Oops, interpreted 'graph' as the wrong type of graph. Stupid me...
  7. The things you list are not functions, they are the calling conventions, common parameter names and types of WinMain.   So yes, I guess they are used in DirectX 11.2 apps. But why do you ask?
  8. DaBono

    How unreliable is UDP?

    In my experience, packet loss does not happen too often. When it does, it seems to happen in bursts. Reordering seems to be much more frequent.   However, most important is that it can happen. For a simple game state this is not an issue (simply drop the old state and interpolate), but you really need to be prepared issues with game events (e.g. chat messages, kill events). Most net-libs (DirectPlay, ENet, RakNet) implement a way to mark packets as 'reliable and ordered', thereby ensuring that packets arrive and are sent to the application in the correct order.
  9. I would say it really depends on what you'd define as 'roll through'. From the few I looked at, I think many candidates would have their answers be marked as incorrect. They're quite full of small gotchas, instead of really testing someone's programming skills. (But hey, that may just be my disappointment speaking  )   That said, I'd be much more interested in why the candidate gave that answer. If a candidate knows what a reference, copy constructor, initialization list, etc. is, but just overlooked some small issue, I'd still would want to hire them. Example: one of the tests checks if you know what happens if a local functor has the same name as a function and you call f(..). I don't care: anyone who programs something like that will be close to be fired on the spot or at least have a good talking to...    So as a test, I don't think these are particularly good. As a starting point for a technical discussion, they're quite nice.
  10. Did you try to run your app using an actual Android-device? Did it work that way?   Also, LogCat can show you a trace where the crash occurred. You could use that to pinpoint any errors. If you use Eclipse (ADT Bundle), you can open it using Window -> Show view -> Other -> Android -> LogCat.
  11. DaBono

    You Don't Need to Hide Your Source Code

    I think the main flaw in the logic in this article is that it presumes that a complete game is the only revenue source, and therefore releasing the game engine code is harmless.   In my opinion, this would only be true for the 'game logic' of a specific game. People would still need the resources to play the game. However, companies like Epic (the ones from Unreal) make huge amounts of money by licensing their game engine. Open-sourcing that would mean lots of revenue missed that would not go towards new engine development.   Side note, I feel quite some opinions in this article are (mis)represented as facts. 
  • 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!