Advertisement Jump to content
  • Advertisement


  • Content Count

  • Joined

  • Last visited

Community Reputation

342 Neutral

About Clash

  • Rank
  1. Clash

    Software testing

    Shannon, could you elaborate some more on why you don't think unit testing is wortwhile? I've been writing automated unit tests for close to two years and I can't stand it when I have to work in code that doesn't allow me the luxury. It's just so... unsafe. The primary benefit I see to unit tests is that, because they are so focused, you have a much better idea of what went wrong during a feature addition\change or refactoring when a test fails.
  2. Clash

    Software testing

    You should google "Acceptance Testing," as it sounds like that more specifically describes what you're going to be doing. I've found that developers will naturally gravitate towards testing practices that are useful. If you're writing code, check out "unit tests" and "automated testing." There's lots of stuff in the Xp literature about it under Test-Driven Development.
  3. I apologize if this has already been mentioned, but I haven't read over the whole thread or managed to find the wiki that someone mentioned. I'm curious about the fixation with compile-time static typing. Have you guys considered the benefits of having implicitly typed variables like in some scripting languages? I've been exploring with some alternatives to C++ (Ruby, Python) and have found that, by writing code test-first, I actually end up with more readable code than in C++. The type of checking that the compiler would normally do for me in a statically typed system gets done in the test suites. Losing the type information at compile-time doesn't seem to impact readability negatively. In fact, I'd say, I end up with code that seems to be more readable. Of course, I haven't pushed this technique to its limits yet, but it's managed to hold up well while doing some tool development. What say you?
  4. Clash

    Automated Testing

    Woah! You need to check out CxxTest. It's by far the best C++ unit testing framework. I modified my copy of it slightly so that the output is parsable by visual studio. If you run your app as a post-build step, .NET will catch the output and display errors in your task list just as it does normal compiler errors. I use it for all my game development unit testing needs!
  5. I don't have much to add to this, but the idea of cataloguing these types of patterns is very interesting. I'm curious to see where this type of work leads.
  6. The problem is that windows somehow automatically scrolls the children of a listbox. The way that it does it doesn't seem to work with how I'm adding children controls to the listbox. I'm curious what I'm missing about how windows works.
  7. Clash

    void * help

    bool a = (bool*)m_data; is the same as bool a = (m_data != 0); In other words, you're casting void* to bool* and then setting a bool to it. Unless that is a null pointer, your value is going to be true. And true is usually 1, which is not what m_data was. What you really want is bool a = *reinterpret_cast<bool*>(m_data); Also, don't do this. Use polymorphism to achieve whatever you're trying to do. Void* is almost always evil. Good luck.
  8. I've subclassed a variable owner draw listbox. I programmatically add a bunch of controls (edit, combo, and buttons) as children of the listbox. I position the controls only one time - right after they are created as children. They only scroll properly when a single scroll occurs (i.e. clicking on the "scroll up or down" button). If the user tries to drag the thumb or use the mousewheel the children controls move to some really large y position (and it keeps growing everytime you track the scrollbar). So my question boils down to, how do you add a child control to a listbox and have it respond to all types of scrolling properly?
  9. Clash

    Questions about memory management

    I completely agree with Aldacron. However, I think it's important to make a distinction between Memory Management and Memory Tracking. A memory manager will do things like reduce fragmentation in the heap to optimize performance. A memory tracker will do things like alert you if you have memory leaks. A memory manager is usually *not* necessary for a PC game. A memory tracker, however, can be a big help. If you're using Visual Studio to develop your game, the simplest thing you can do is use the CRT memory tracking features. You can have the CRT dump all outstanding memory leaks with file and line number when your application terminates. If you want to get your allocations tracked with file and line numbers, I recommend overloading global new. You can change it so that it delegates to the CRT operator new and passes file and line information. If you use a macro such as MyNew that expands to the new call you can get this all for free. Check out crtdbg.h and you can see the signature of the function. If you have really hard to find memory leaks, such as things that aren't being allocated by your calls to new, _CrtSetAllocHook allows you to inject a callback before each and every memory operation. You can use the dbghelp library functions such as StackWalk64 to generate a stack trace of every single memory allocation, reallocation, and free in your application. This can also be used to gather interesting metrics about memory usage. CRT debug info: DbgHelp info: And a quick aside: if you try to use StackWalk64 check out the RtlCaptureContext function on the MSDN. GetThreadContext will not work to get your Thread Context. Best of luck.
  10. Hey man! Shoot me an e-mail some time and lemme know what you're up to! Onto the topic... Quote:The testRemove actually assumes that for remove to succeed the value needs to exist.This is the crux of the problem. In order to write remove we need to add something to the list. In order to add something to the list we need to verify that add works. This duality between add and remove is the issue I'm having trouble with. I want to have a test that only tests one thing, but it seems I can't have a remove test only test remove. It either assumes add works or tests both. An interesting thing I've realized is that if you can somehow build a list without going through the "add" interface (i.e. a mock list) you could write remove without add. That assumes that there is a simple way to present whatever first half of the duality is needed in an ulterior way. If the situation wasn't lists, but rather a series of game objects in the world doing some sort of integration test... it gets more complicated. I'm curious what sort of approach people have taken to this issue.
  11. Now that I've been knee deep in TDD for a while I've come to notice a recurring pattern that is a bit disturbing. I run into problems when there are prerequisites to a method being called. For instance: testing the removal of an entity from a list. First that entity needs to be in the list, which implies that adding an entity needs to be tested first. So, do you have two tests: testAddEntity and testRemoveEntity even though testRemoveEntity adds and removes? Or do you just write one test: testAddAndRemoveEntity? Now you have a test that does more than one thing, which I've found is worth avoiding. I would lead myself to think that this kind of stuff should go in the suite's setUp method, but you still need to test the add functionality BEFORE you put it in setUp. Do you test it, and then move it into setUp? Do you just put the asserts in setUp right away? Or do you manually add an entity at the beginning of testRemoveEntity? (note that this example is sort of contrived, but it should get the point across) Anyone have any wisdom to shed on this?
  12. Shannon's thread on testing singletons got me thinking about the difference between unit tests and integration tests. I recently wrote three low-level systems: a subsystem loader, a subsystem factory, and a task scheduler. - The loader reads subsystem names and key\value settings from a stream. - The factory is populated with all the available subsystems and knows how to create them. - The scheduler simply executes a series of Task interfaces in sequence. Now, each of these systems are Unit Tested in isolation. But, there needs to be some code which orchestrates the integration of these systems. My question is, how would one go about writing that integration test? My approach was along the same path as the individual unit tests: I created a fourth object called which took a text stream as input and invoked the various functions on those three subsystems as appropriate. In order to test that everything was invoked correctly, I created a few mock subsystems to get pushed through the logic. I like the way it turned out: I have three isolated unit tests and one integration test -- all automated (and developed Test First). The only issue I have with this is that the integration test is very tightly coupled to a lot of details. It seems inevitable in a way, but I wonder if there is a better way to go about it. I could see this sort of technique start to be come very involved when the underlying systems are more complex.
  13. Clash

    What is a game engine supposed to be?

    Traditionally these sorts of things are called Frameworks. We just happen to call it an Engine because it's cooler. Go figure.
  14. Interesting. This behavior seems to be the case on both the .NET2003 and Intel 8.0 compilers. It looks like you only get extra vtable pointers when you do multiple inheritance though (as opposed to multiple single-inheritances). I wonder if this is standard C++ behavior or implementation dependent.
  15. Quote:hmm, too bad the author only makes some vague statements about flat hierarchies and components (and the interesting links are dead), so i don't really have an idea what his design looks like.I didn't bring this up because we were talking about decorators, but for building game objects you should prefer to use composition instead of inheritance. And generally speaking, if composition can solve the problem it should be prefered over inheritance. Anywho, the idea is basically this: The bits and pieces of functionality you want to give to different game entities gets packaged up into reusable components. Each game entity, when created, has any number of these components created and attached to it. The components, of a single entity, can communicate with eachother using broadcasted messages. Components can then be configured to trigger specific behavior when a specific message is received. There is a really good article on this in the new Game Programming Gems. Quote:decorators: iGameCharacter,iMonster<-GC_MonDeco - decorate the gamecharacter and monster inteface iEndBoss<-EBDeco - decorate the EndBoss interface onlyIf IMonster extends IGameCharacter, then there is no need to have a decorator explicitly for both. If the behavior that is being added can be done with an IGameCharacter, then the decorator shouldn't have any knowledge of an IMonster. If you added a new game character, and wanted to decorate it, it wouldn't make much sense based on the name... even though the logic would make sense. Quote:...those bitchy vtable data induces some bloat, namely 4 bytes per intefaces.I'm pretty sure that each concrete type only has 1 vtable pointer per instance. The more virtual functions you have, the larger the vtable will be, but you don't have multiple vtable pointers. Unless maybe you use virtual inheritance? I never do.. so I dunno. Quote:@Clash, btw. i had no intention to sound rude, you made a reasonable point.No worries. We'are all friends here :)
  • Advertisement

Important Information

By using, you agree to our community Guidelines, Terms of Use, and Privacy Policy. 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!