Jump to content
  • Advertisement

DaBono

Member
  • Content Count

    550
  • Joined

  • Last visited

Community Reputation

1500 Excellent

About DaBono

  • Rank
    Advanced Member

Personal Information

  • Role
    Programmer
  • Interests
    Programming

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. Well, in short I would deem nothing 'unhackable'. Most people would have considered OpenSSL to be safe, and the Heartbleed-bug showed that in certain cases this was unsafe as well. A cynical answer would therefore be: nothing is unhackable.   The other part of this is that everything that will be decrypted on your user's client side will be accessible to him/her. So, by asking for something unhackable, who is not allowed to have the information? Is it your user that cannot see the information? Or is it just the data as it is in transit?   In the encryption debate, I think it is important to strike a balance between 'unhackability' and 'impact if hacked'. If the consequences of an intercepted message would be that one player would know the location of another, and would be cheating, it would probably be more efficient to implement a good banning system, instead of trying to create a really secure system. 
  12. DaBono

    Some help starting Java

    If you have an Android-device (phone or tablet), I found it quite satifying to create my own Android game. Although mobile development may not be the first thing that comes to mind for making an FPS, it does help you learn Java and have something to show for it quite quickly. The Android developer pages (http://developer.android.com/training/index.html) contain loads of good documentation and tutorials.   From there, you have picked up enough programming skills and knowledge to transition to a more FPS-minded environment or even C++/Unity/etc...
  • 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!