Jump to content

  • Log In with Google      Sign In   
  • Create Account


Member Since 11 Nov 2006
Offline Last Active May 23 2016 11:47 PM

#5286820 Multi thread deadlock issue with a recursive mutex. Need ideas.

Posted by on 14 April 2016 - 12:24 AM


An update on this topic, our bugs were found and fixed. However this thread was me looking in the wrong direction. The deadlock happening was a side-effect of the real bug and not the source of my issues. The bug was coming from a system was acting erratically and sending way too many messages over the network and our code could not keep up and they would stack up. Overtime, having a ton of very small memory blocks for each message would fragment the memory and then various systems would fail. The deadlock was the most common effect but we also had thread initialization failing and sometimes a straight up memory allocation failure (malloc of a big chunk returns NULL and that pointer was then used).

So, you have memory allocation failures, and most of them do not crash your program immediately? And then you're stuck dealing with other bugs that look impossible? Let me guess, you have catch (exception) or, even worse, catch (...) everywhere, with maybe a log saying "unknown exception" if your programmers are slightly less lazy than the people who just leave the catch empty?


malloc does not throw exceptions. It simply returns NULL. On some systems, there is no built-in catch for NULL dereferences, and NULL+offsetof(SomeStruct, someMember) might reasonably point to memory used by the main thread's stack, some global variable, allocation records, or even the OS itself; any of which could have very unpredictable consequences. It's entirely possible no C++ exception was ever thrown and no OS exception/signal/etc was ever triggered, and memory was silently corrupted.

@OP: I assume you corrected these side-effects by checking the address returned by malloc, and probably corrected the system that was acting up. But you should still do something about the heap fragmentation. If one system sending too many messages causes a heap fragmentation, what happens when several systems start having to send that many messages just to handle their workloads? It might be something you can put off for awhile, but you may find yourself needing to resolve the fragmentation issue in the future, I'd treat this like an early warning.

#5286198 What is the most organised way to create a class/file structure for a game?

Posted by on 10 April 2016 - 04:05 PM

Do rendering in its own class. It's not the window's responsibility to render. And rendering can occur without a window at all.

#5286111 Question about health bars

Posted by on 10 April 2016 - 04:25 AM

It's fine that you're a fan, but to a beginner this is just highly confusing. Please try to keep things as simple as possible in this forum.

You're right, of course. I just know that the OP was having issues with domain modeling in a previous post, so I figured I'd share a relevant trick WRT to domain modeling here.


You(null;) seem to have already solved your problem but I still have some doubts about this issue ( being a beginner myself ).


When I experienced this problem of object references, I created a GameObject class which was the parent of all game objects. The game object class had no default constructor but one constructor which takes a string argument. The GameObject class also consisted of a std::map from string to GameObject. So, in the constructor the object created was added to the map with the string argument as its id. The GameObject class also consisted of a static method 'get' which returned a object given its id.


I don't know whether my approach is correct, so I'm not recommending it to anyone but instead asking for expert review since after this discussion I'm doubtful about my approach. Please review!


The problem in this method seems to be about downcasting to the real type of object( Since I'm using C++ not Java ). Since I never felt the need of downcasting ( I put all the usual methods in GameObject class itself ) I didn't ponder more over this issue. But now I'm looking for correcting my approach.

There's nothing wrong with having a lookup table (std::map) of all game objects. In fact, in some designs, it may be necessary. In time you'll probably learn of a better way to do this, or ways to avoid it. But if it's working fine right now, and it's making your life easier to have it, there's not really any good reason to try and eliminate it. One way you could make this better is to have integer IDs instead of strings, it will make lookup much faster because it requires only one comparison per entry.

It should be rare for downcasting to be necessary if virtual functions are provided for most cases in the base class. It's unlikely you'll run into a situation where downcasting can be avoided by eliminating the lookup table, either.

#5286098 Question about health bars

Posted by on 10 April 2016 - 02:10 AM

you should make two healthbar instances - one for player 1, one for player 2.
each only needs to worry about its own player. So, in the appropriate spot in code


where Player::getHealthPercentage() is essentially just { return (health * 100) / maxhealth; }

or the healthbar class can store a reference to its player and get this information itself.
or you can create a class to specifically calculate the ratio of two integers as a percentage, IE:

class PercentageOf
int #
int &denom;

PercentageOf(int &_num, int &_denom){ num = _num; denom = _denom; }

operator int() const { return (num * 100) / denom; }

I'm a fan of classes like that, because it allows one complex class to perform logic using another complex class's members without any knowledge of that class at all. But making them and using them is a little awkward, so maybe not the best choice for a beginner.

#5285742 Companions as Combat Mechanism (Mechanic Idea)

Posted by on 08 April 2016 - 01:52 AM

Sounds like a game I'd play if it were free.
But not a game I'd pay for after playing a demo. Maybe it was just for the purposes of explanation, but as Servant said, your characters as you described them are boring, predictable, shallow. The silent protagonist is almost a given, especially in the action/puzzle genre. But why does the fire user have to have a vibrant personality? Or a woman for that matter? Why does the strong guy have to be stupid? One of the smartest guys I've ever met (smarter than me, for sure) was a body builder, could probably lift a trick. Some of the dumbest guys I know are weaklings.
Real people rarely fit so well into these naive archetypes. Why bother making other characters so important to gameplay, if you're not even going to bother making them seem genuine?

#5285731 Healthbar structure for a game?

Posted by on 08 April 2016 - 12:48 AM

visual components should be separate from game logic. They only need to be updated once, before rendering, while game objects may be updated several times during a single frame's logic. Mixing visual components with game logic at best leads to needlessly cluttered code, and more likely will lead to many unnecessary updates of the visual components. Store health with the player, have health logic with the player class (if there isnt a more appropriate one), but keep all logic and data specific to the healthbar (not needed for game logic) separate.

#5285385 Stage 2, learning game programming C++.

Posted by on 05 April 2016 - 09:55 PM

I would start with SFML, make yourself a simple 2D game, and work from there. I remember when I first started learning to make games, I decided I would be working with DirectX and the Win32 API directly, and wound up wasting a lot of time just getting things to render properly; it deferred my learning of basic game development techniques considerably. SFML will save you a lot of time, you can learn that other stuff later when you already know how to make a game.

#5284925 Polymorphic uninvolved parenting?

Posted by on 03 April 2016 - 04:07 PM

Since I found out I'm terrible at making sprite animations, I thought - for now at least - of leaving out the possibility to view the inside of the inn where one might contemplate the NPCs having a drink or eating a meal, and the view of the town, where one might see... something interesting and relevant that didn't cross my mind so far.

You could go the route of a text adventure game (plus GUI). Or if you can do pixel art but struggle with animation, maybe just don't make animations and have the game in first person POV (like in old school dungeon crawlers). NPCs (goblins, travelers, the emperor's spies, etc) can just appear in the player's view. Or if you can draw by hand, you can just scan a drawing of the player's static view (inside of the inn), some NPCs, clean them up a little bit, then render them together in a final scene. Back before I got a handle on pixel art (disclaimer: I still pretty much suck) I did this and it turned out somewhat okay looking.

Making these threads is useful for me to think about things, but it turns out this is leading me to a confusion about what I'm doing, but at the same helping me find the cause of the confusion. I made another thread before this one that also lead me to confusion (and I realize now it's not all that different from this one). It's no one else's fault but mine, really.

In this specific case, it seems like you're trying to implement an abstraction over all objects, without knowing how to do so.
You might want to read up on virtual functions, that's the simplest way in C++ to provide an abstraction as would be required by a UI.

#5284825 Polymorphic uninvolved parenting?

Posted by on 02 April 2016 - 11:52 PM

since you are implementing a UI system, all UI elements should simply have Draw()/Paint()/Render()/Display() function which each subclass implements; whether its plain text, sprites, or a container of other elements, there is no need to have a different function name when the intention is the same - in each case, you are just trying to display the element for the user.

#5284570 Naming conventions, software documentation and version control

Posted by on 01 April 2016 - 12:04 AM

Pascal is where I personally attribute the CamelCaseForm of identifiers, and many of the associated capitalization/spelling quirks that go along with it. I'm sure someone with a beardier neck than myself will arrive shortly to correct me about how it goes back even further.

This is a topic of much dispute, believe it or not. My money's on the practice originating in PARC, since all early programming languages in which CamelCase was common either originated within PARC or from its former employees.

#5284437 Help making jumping mechanism in java

Posted by on 31 March 2016 - 01:49 AM

position(new) = position(old) + (velocity * time)
velocity(new) = velocity(old) - (gravity * time)

this works for movement on both ground and in the air

so when the player first holds jump, set velocity to {0, -speed[, 0[, 0]]}
this gives the player velocity of speed in an upward direction
at each frame, use those two formulas above
the upward velocity of the player will reduce by gravity every frame
this will move the player up the screen each frame
eventually, the velocity will reach zero (or become positive) and this marks that the player has reached the peak of their jump
then the player will get velocity in the downward direction, his position will change to be lower, and eventually will hit the ground.

probably you will need to apply this velocity to the player's current velocity across the ground, to let the player move in both directions while jumping

#5284295 C++ RPG books and tutorials

Posted by on 30 March 2016 - 11:04 AM

It seems to be recurring advice from the three of you not to pay for tutorials, and I can understand why at the rate things become outdated.

It may arise that there are no good quality free tutorials on some new subject, but someone has written a book about it. If you're in a hurry to get new knowledge, it might be smarter to buy a book on the subject in that case. But that's a pretty rare situation.

#5284168 C++ RPG books and tutorials

Posted by on 29 March 2016 - 10:38 PM

pretty much any book using SDL is going to use the SDL 1.x interface, which is quite different than the newer SDL 2.0 interface you should probably be using.
If you want to learn how to program with SDL, I strongly recommend Lazyfoo's tutorials: http://lazyfoo.net/tutorials/SDL/index.php
If you want to learn how to program in C++, I strongly recommend just writing programs in C++. Most books on C++ are outdated and many books on C++ gloss over important parts of the language. Use free tutorials to increase your knowledge, at least then you're not paying for bad or outdated information. When you do need highly specific information, ask here or on other programming sites - programmers who know the answer will gladly answer your question.
I'm owner of about 50 different programming books, most of which were bought prior to 2011. Not even the ones on programming Android games are relevant any more. They look nice on my book shelf though.

#5283992 Is death to intense for kid players (<13 years old)

Posted by on 28 March 2016 - 10:45 PM

Ori and the Blind Forest comes to mind as a game that deals with death in the plot but is still suitable for children (I bought this for my nephews; age 9 and 12, last christmas)

#5283990 Making my game code cleaner/easier to work with

Posted by on 28 March 2016 - 10:19 PM

It wouldn’t hurt to make your code readable. Use whitespace and several other coding practices to improve readability.

While I find evenly indented literals to be easier to read, I find that indenting identifiers away from their type makes code less readable. Especially when it comes to working with code written by others (unfamiliar), having type and identifier visibly near each other makes it easier to follow. Your use of systems hungarian notation eliminates such issues by putting data type in the identifier itself, but since the OP is not using systems hungarian, I would advocate against this.