Beer and Programming: 2

Beer:

20131002_205031
20131003_205928
20131004_202003
20131005_193830

Idjit! – Dugges Ale- & Porterbryggeri AB: I generally love stouts and especially imperial stouts, but Idjit just didn’t grab me. It was incredibly thick (at points almost feeling chunky) and just had too heavy of a taste. It felt like they tried to make the imperial stouts to end imperial stouts but just went too far. Not really worth picking up.
Punkin Ale – Dogfish Head Brewery: Dogfish Head always puts out one of my favorite pumpkin beers, and this year is no exception. As far as pumpkin beers go, it’s on the lighter end with the pumpkin flavor not overwhelming you, but instead being a nice accompaniment to the brown beer. I think I still like the Elysian’s: The Great Pumpkin better, but that’s just because it matches the styles I tend to like more. Good for a pumpkin style beer.
Flipside Red IPA – Sierra Nevada Brewing Co.: Reds are my favorite beer type, so seeing a Red IPA was intriguing to me as I’d never known that was a thing. At first taste, it definitely reminds you of a solid red, but then you notice a bitterness to it from the IPA part afterward. It’s definitely a decent beer, but I think in the end I’d rather have a red or an IPA, I don’t think they need to be combined. Good for a red IPA; something to try once, but not a regular beer.
Narwhal Imperial Stout – Sierra Nevada Brewing Co.: I can’t speak highly enough of Narwhal. It’s one of my favorite Imperial Stouts, if not my absolute favorite. It’s thick, but not especially so like the Idjit. It has hints of coffee, but isn’t overpowering. And lastly, it’s fucking delicious. I love it so much, I’ve picked up two four packs to put in my beer cabinet to save for later when I can’t get it anymore. Pick up this beer if you see it, you won’t regret it.

Programming:

I haven’t done much, if any programming at home this week, so I thought I’d talk a bit about some stuff I’ve already worked on in my engine. One of the first things I worked on was a memory manager, since C++ is not terribly good at tracking memory and letting you know when you’ve leaked it. Memory management is one of the hardest things for people to learn when using C++ if they’ve come from a managed language before and for good reason; it’s not something you learn via learning the language, but instead you learn by messing it up so many damn times that you get into a rhythm when programming new things. On windows, there is a very easy way to see when you leak memory when exiting the program (and potentially during, if you want to do snapshots).

As a primer for how Windows handles memory leak detection, you can read MSDN’s page about it, which has fairly good samples. The short of it is, you can include this code, and it’ll automatically spit out stuff at the close of the program to tell you which bytes are leaking.

// top of file
#define _CRTDBG_MAP_ALLOC
#include <stdlib.h>
#include <crtdbg.h>
// entry point into the application
int WINAPI WinMain(__in HINSTANCE hInstance, __in_opt HINSTANCE hPrevInstance, __in LPSTR lpCmdLine, __in int nShowCmd)
{
#if defined(_DEBUG) && defined(WIN32)
	_CrtSetDbgFlag(_CRTDBG_ALLOC_MEM_DF | _CRTDBG_LEAK_CHECK_DF);
#endif

If you were to do an: int* int_ptr = new int;
That will spit stuff out like:

Detected memory leaks!
Dumping objects ->
{570} normal block at 0x00E26948, 4 bytes long.
Data: < > CD CD CD CD
Object dump complete.

Unfortunately, this isn’t terribly helpful! It might be if the data were a string, but when the data is an object, the output is relatively worthless. If you get lucky, the leak will occur at the same time every time, and if that is the case, you can put breakpoints on the creation of the data (the 570 in this example means it was the 570’th memory allocation).

So where do we go from here? A memory manager is the next step. We want to be able to both track our allocations better, and optimize how memory is created at run-time so we don’t have lots of little allocations slowing us down. There are two real ways to go about doing this; you can either overload the new operator or create an insertion point into which all memory is allocated and track it that way. The former is easier, but a bit messier, and the latter is something you probably want to do in the long run. I’ve done both before and in this instance I decided to go the easier route by overloading new and delete.

You can track all uses of new by doing:

inline void* operator new(size_t size, const char* file, const int line)
{
	void* ptr = malloc(size);
	MemoryManager::GetMemoryManager()->AddAllocation(ptr, size, file, line);
	return ptr;
}
inline void operator delete(void* ptr, const char*, const int) throw()
{
	MemoryManager::GetMemoryManager()->RemoveAllocation(ptr);
	free(ptr);
}

#ifdef ENABLE_MEMORY_MANAGER
	#define DBG_NEW new(__FILE__, __LINE__)
#else
	#define DBG_NEW new
#endif // ENABLE_MEMORY_MANAGER

You have to not just overload those functions, but all of the different types of new/delete (including the ones you created by redefining new as DBG_NEW). You can see all of them here. I’ve had some odd problems with code that overloads new, but doesn’t include the throw() part in the functions (even when I have no exceptions turned on), so it may take some fanangling before they work, but they should be good.

For the internals of the AddAllocation and RemoveAllocation functions, they’re pretty simple. They’re just a map of the pointer to the data that was allocated (size, filename, and line number).

struct MemoryAllocation
{
	MemoryAllocation() : _size(0), _filename("default"), _line_number(0) { }
	MemoryAllocation(const unsigned int size, const char* filename, const int line_number)
		: _size(size), _filename(filename), _line_number(line_number)
	{
		// do nothing
	}
	unsigned int _size;
	const char* _filename;
	int _line_number;
};

void MemoryManager::AddAllocation(const void* ptr, const unsigned int size, const char* file, const int line)
{
	_allocations[ptr] = MemoryAllocation(size, file, line);
}

void MemoryManager::RemoveAllocation(const void* ptr)
{
	_allocations.erase(ptr);
}

Record all of that information and you’re good to go! The example we had above with the integer being allocated (but not deleted) now looks like this when we spit the information out on close of the application:

c:programmingsideprojectsourcemain.cpp(48): Memory Leak at 0x00E26948 size: 4 bytes

This is MUCH more useful. This still doesn’t get us all the way to complete usefulness, however. What if you have a function like:

int* CreateInt()
{
	return new int;
}

That line and file will always be the same and never return what is actually important, the original caller! So how do you find out the important information? You get the callstack and keep that around in addition to the other information. I haven’t done that yet, as it’s platform specific (and in some cases a pain in the ass), but Google is your friend. It’s next on my list if I need to make any additions to my memory manager. This will allow you to see where all allocations are created from.

So how does this break down and why did I say it was the lazy way to go? Good questions! First, it breaks down when you have things like different libraries or third party dlls that will allocate/deallocate memory. It depends on how they’re created, but generally speaking you shouldn’t expect third party code to ever allow you to track these kind of allocations. In addition to that, because you’re overriding new, that means that other people are able to override new as well (including your coworkers or friends)! This means that if you compile with code that’s not yours and it does bad things, it could completely negate what you’re trying to do. It’s the lazy way to go because it works if everything you work with uses new. As a counter example, the standard library, like std::vector, will not allocate via new, so you can never see memory stats via that method of memory allocation. C++ is really hard to track all memory allocated in a program. Be wary of static allocations as well.

In the end, this is a very easy way for C++ applications to track memory allocations, but not expend too much time to write a true memory allocator like the Bitsquid engine.

Please give me ideas and/or comments about this post as I’d like Beer and Programming to become a weekly post. It takes a lot of work for me to do, but I enjoy it so far, so I’m going to continue it until I either run out of ideas or people stop caring about my posts.

Beer and Programming: 1

Beer and Programming: 1

I’ve been lamenting the fact that I don’t regularly update this blog, and I think the best way for me to fix that is to post about the things that I’m actively doing. I love all different kinds of beer, and I learn as much as possible about programming, so why not combine the two into a weekly roundup? I can talk about the different beer that I’ve had during the week and the different programs I’ve worked on as a professional and a hobbyist.

This week, let’s start off with the beer. First off, I tried out the Epic Imperial: Red Ale.

20130929_183938_h6wjfbbzag

It was exactly what you’d expect from an Imperial Red. It was a Red, with a bit of a kick to it. I think I need to come up with some sort of rating system for beer, so I’m going to say there’s the 3 ratings of:

    * Amazing and you should pick up regardless of what else you see
    * Good for its type or good for a different type of beer
    * Not really worth picking up.

Epic Imperial Red Ale leans toward the amazing and you should pick up, but not quite getting there. It’s a solid beer that is done really well, but not exceptional.

The second beer I tried out was the Elysian: The Great Pumpkin.

20130929_200157_cgw1ph2e6m

I love pumpkin beers, and this is no exception. I’d tried their stout pumpkin and been underwhelmed, but this one was quite good. The Great Pumpkin was solid without being overwhelming. If you can pick it up, I’d say it manages to come in the bottom of “Amaazing and you should pick it up”. If you don’t like pumpkin, you should stay away, but otherwise, it’s pretty damn good.

On to programming. I’ve been trying to learn OpenGL lately and have been having a hard time finding tutorials that are focused more toward people that know how to program, but don’t know how to program graphics. It’s surprisingly hard to do so. Right now, I’m using rastertek.com‘s and arcsynthesis‘s examples. Neither of which is particularly good for how to structure a game’s graphics engine, but they each teach OpenGL in their own way that helps out a little. I wish I could find an OpenGL for game programmer’s website, but, alas, I have been unable to do so.

Work on the engine has been going well, however, as I’ve been understanding more and more as of late. I enjoy the knowledge even if I sometimes hate how hard and different it is from my everyday, normal programming. As of now, I have a triangle rendering, but soon hope to have textures or generic polygons.

Beer and Programming: 2