Jump to content

  • Log In with Google      Sign In   
  • Create Account

nfries88

Member Since 11 Nov 2006
Offline Last Active Today, 08:02 PM

#5287479 HINSTANCE & HWND Corrupted when passed around functions

Posted by nfries88 on 18 April 2016 - 10:32 AM

I agree with fastcall22, there's no point to having the members of WinEventArgs being references, they are POD value types and you gain no benefit to pass by reference. I would keep them const, as these values should not be changed in processing.

Yes, because your EDelegate takes the IEventArgs by value, it performs a copy construction of IEventArgs from your WinEventArgs - the WinEventArgs data is lost here. This IEventArgs copy is then passed by reference to the function wrapped by EDelegate.

making IEventArgs non-copyable, as fastcall demonstrated, is the simplest way to prevent this mistake from recurring.




#5287286 Thinking of switching from a monolithic structure to a Client-Server structure

Posted by nfries88 on 17 April 2016 - 03:40 AM

The downside is that you have to program for packets

 Not necessarily. Yes, you'll have to design around the idea that the game manager is a service, that the user's view of the game cannot simply reach inside the game manager to get information or make changes, and that the two sets of logic will have to communicate in a highly decoupled manner; but that's actually preferable anyway. :)




#5287285 HINSTANCE & HWND Corrupted when passed around functions

Posted by nfries88 on 17 April 2016 - 03:30 AM

how is hinstance declared? Since wParam is not used by the function where the error is occurring, and hwnd appears to be valid, I think hinstance is the issue here.

also, while WPARAM is defined as a UINT_PTR, wParam should actually be treated as an integer for many messages.




#5287283 c++ should nested switch statements be avoided?

Posted by nfries88 on 17 April 2016 - 03:12 AM

The only time I recall having good reason to use a nested switch statement is in handling user input, where it's common practice to make pretty liberal use of them. This usually looks similar to the example prevented by frob, and is done for the same reason he described. Of course there are ways to prevent them in even that case, but it usually serves no purpose to do so.




#5287279 Multiple bullets?

Posted by nfries88 on 17 April 2016 - 02:43 AM

As previously stated, the simplest way to handle multiple bullets is to store them all in an ArrayList, and remove them when they collide with something or leave the screen.

Although Gian-Retro's advice is the optimal practice, it requires a bit of experience to implement properly, and might not apply as well to your case as it did to his. I would just use ArrayList unless you notice a performance issue. :)




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

Posted by nfries88 on 14 April 2016 - 11:26 PM

 

 

 

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.

Sure, that's possible, but I still think that it's relatively unlikely to have memory corruption de-referencing null pointers from failed malloc calls, instead of segmentation faults, compared to the chance this code is throwing and catching bad_alloc exceptions. The code above is clearly C++. I would guess new is being used, even with malloc mentioned earlier.

I've never worked on a program that corrupted memory through an offset null pointer. I have worked on code where memory usage would spike up and cause allocation failures, because it was filled with try/catch statements.

 

It's pretty common for C++ projects to interface with C libraries, a great many of which perform internal allocation and deallocation, some of which might not check for failed allocation before access. It's not unheard of for C++ programmers to use malloc for buffers, this is actually my own practice. The new operator can be overloaded, an overloaded new might not throw std::bad_alloc. It is possible to disable exceptions in C++. It is possible that this is a non-conforming C++ implementation with no exceptions - some C++ implementations intended for embedded applications lack RTTI and exceptions, along with a large number of other C++ features; possibly some lack the new operator altogether, and malloc is the only way to allocate. The implementation of malloc might be non-conforming, or a custom allocator might be used. There's any number of reasons why an allocation might not throw which are perfectly reasonable.  I understand that sloppy exception handling is all-too common, but not handling exceptions at all is even more common (I'm guilty of this), so it just seems odd to me to assume that's why the source of this bug was never caught. Also, I need to point out that on systems with NULL pointer protection, dereferencing memory near 0 does not generate a C++ exception, it generates a fatal signal - which few people know how to recover from - or an SEH exception on Windows, the typical handling of which is to quietly close the program. That is the first thing that indicated to me that something else was the problem.

 




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

Posted by nfries88 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 nfries88 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 nfries88 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 nfries88 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

healthbar1->setValue(player1->getHealthPercentage());
healthbar2->setValue(player2->getHealthPercentage());

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;

public:
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 nfries88 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 nfries88 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 nfries88 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 nfries88 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 nfries88 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.






PARTNERS