Game Development Megathread

The Something Awful Forums > Discussion > Serious Hardware/Software Crap > The Cavern of COBOL > Game Development Megathread

«‹›622 »

Gary the Llama: Mar 16, 2007; SHIGERU MIYAMOTO IS MY ILLEGITIMATE FATHER!!!

I ran into an issue that's been plaguing me for a few days. Here's my render code, I'll post about the issue afterward.

code:

void Render()
{
   // Start rendering on the backbuffer.
   if (d3ddev->BeginScene())
   {
      d3ddev->ColorFill(backBuffer, NULL, D3DCOLOR_XRGB(0, 0, 0));
      sprite->Begin(D3DXSPRITE_ALPHABLEND);

      RECT srcRect;
      srcRect.left = 0;
      srcRect.right = 32;
      srcRect.top = 0;
      srcRect.bottom = 32;

      // MAX_PIECES is 256.
      for (int i = 0; i <= MAX_PIECES; i++)
      {
         D3DXMATRIX spriteMatrix;
	 D3DXMatrixIdentity(&spriteMatrix);
	 sprite->SetTransform(&spriteMatrix);
	 sprite->Draw(texture, &srcRect, NULL, &piece[i].pieceSprite.pos, D3DCOLOR_XRGB(255, 255, 255));
      }

      sprite->End();
      d3ddev->EndScene();
   }

   // Flip back buffer to the screen.
   d3ddev->Present(NULL, NULL, NULL, NULL);
}

So it loops through and renders my blocks falling from the top of the screen. (It's a Tetris clone.) Unfortunately, while one piece is dropping, I can see the next piece at 0,0 on the screen. That piece doesn't disappear until I reach the last piece, which then drops down the screen.

I've checked my code again and again, and I can't find anywhere where my piece's position is set to 0,0. And from what I can tell, it's nowhere in my render code, though I could be missing something.

Any ideas?

Here's a picture in case I'm not making myself clear:

Ninja Edit: While writing this up, I figured it out, but still need a nudge in the right direction. It's the for loop in my render code. I guess I need an array that stores only the objects that should be drawn to the screen, instead of all 256 objects like it's doing now. Any idea on a good way to implement it?

Super Edit: This sounds like a good place for an stl vector of Sprites, huh? Amazing how I just walked myself through the whole problem with this post. Thanks guys! :

Gary the Llama fucked around with this message at 02:57 on Aug 28, 2008

# ? Aug 28, 2008 02:52

Adbot: ADBOT LOVES YOU

# ? May 9, 2024 22:14

MasterSlowPoke: Oct 9, 2005; Our courage will pull us through

Either that, or you can have a boolean variable on your block objects that indicates whether it needs to be drawn or not.

# ? Aug 28, 2008 20:38

POKEMAN SAM: Jul 8, 2004

MasterSlowPoke posted:

Either that, or you can have a boolean variable on your block objects that indicates whether it needs to be drawn or not.

Or you can keep the 256 objects pre-allocated and use it like a pool. Keep track of an index to the first unused object in the pool. When you create a new item, put it at that index and increment the index. When you delete an item, swap it with the item at the top of the pool and decrement the index. (When you add a new item it'll write over the old one, you don't need to explicitly delete it.) Then, when you want to draw them all, just go through the pool from 0 to index and draw all of those.

# ? Aug 28, 2008 21:32

OneEightHundred: Feb 28, 2008; Soon, we will be unstoppable!

MasterSlowPoke posted:

Either that, or you can have a boolean variable on your block objects that indicates whether it needs to be drawn or not.

Better would be to use an enumeration or reference (i.e. to individual sprites, or to a block info table), so you can have different block appearances. :iamafag:

OneEightHundred fucked around with this message at 22:35 on Aug 28, 2008

# ? Aug 28, 2008 22:23

Gary the Llama: Mar 16, 2007; SHIGERU MIYAMOTO IS MY ILLEGITIMATE FATHER!!!

Ugg boots posted:

Or you can keep the 256 objects pre-allocated and use it like a pool. Keep track of an index to the first unused object in the pool. When you create a new item, put it at that index and increment the index. When you delete an item, swap it with the item at the top of the pool and decrement the index. (When you add a new item it'll write over the old one, you don't need to explicitly delete it.) Then, when you want to draw them all, just go through the pool from 0 to index and draw all of those.

Would you mind giving me a code example of pre-allocating objects in this manner good sir? :patriot:

# ? Aug 29, 2008 00:52

gibbed: Apr 10, 2006

for (int i = 0; i <= MAX_PIECES; i++)

Does 'pieces' have 257 elements? (I doubt it)

# ? Aug 29, 2008 02:07

Gary the Llama: Mar 16, 2007; SHIGERU MIYAMOTO IS MY ILLEGITIMATE FATHER!!!

gibbed posted:

for (int i = 0; i <= MAX_PIECES; i++)

Does 'pieces' have 257 elements? (I doubt it)

No, I'm just not paying attention. Besides, it needs to be dynamic so I'll be changing it soon enough.

# ? Aug 29, 2008 06:06

gibbed: Apr 10, 2006

Gary the Llama posted:

No, I'm just not paying attention. Besides, it needs to be dynamic so I'll be changing it soon enough.

That's probably where your extra block is coming from then, given that you are reading past the end of your array into unknown data.

# ? Aug 29, 2008 13:19

POKEMAN SAM: Jul 8, 2004

gibbed posted:

That's probably where your extra block is coming from then, given that you are reading past the end of your array into unknown data.

He already realized his extra block is coming from the 250 blocks in the array that aren't being used.

# ? Aug 29, 2008 16:35

nihilocrat: Jun 8, 2004; all the hep cats jam to "cat /dev/hda1 > /dev/audio"

Anyone else participating in pyweek?

edit: Oh hey, lots of python talk a few pages ago.

Pyglet seems to be the currently hip graphics lib for Python; I have to agree, it's higher-level than pygame and uses OpenGL for speed. Its sprite engine can very easily be integrated by pymunk: after you update your physics simulation, update the sprite position and rotation based on its related physics body pos + rot, and you're done.

Also, those with a particularly limited amount of time / attention should check out cocos2d: it's even more high level and has a bunch of snazzy builtin transition effects, along with timed actions (sprite.MoveTo((x,y), seconds) and a bultin interactive console. It's based on pyglet, so you can always drill down and use pyglet methods if you want.

nihilocrat fucked around with this message at 02:59 on Sep 4, 2008

# ? Sep 4, 2008 02:40

Sivart13: May 18, 2003; I have neglected to come up with a clever title

nihilocrat posted:

Anyone else participating in pyweek?

I probably will, but none of my stodgy friends want to do it with me.

Pyweek always generates some awesome entries, and with Pyglet continuing to gain traction maybe we'll see more and more things outside of the "low-res thing that can run fast in Pygame" space. I love their website so much better than Ludum Dare's awful blog wiki hybrid monster.

# ? Sep 4, 2008 02:45

nihilocrat: Jun 8, 2004; all the hep cats jam to "cat /dev/hda1 > /dev/audio"

Sivart13 posted:

stodgy friends

You might actually do better going it alone, especially if you opt to use Creative Commons / Public Domain artwork (Remastered Tyrian Graphics, etc.), just because you don't have to worry about actually coordinating anything with anyone else.

The only problem I have with the pyweek site is that their message board doesn't show who the OP of a thread is unless you actually open the thread.

# ? Sep 4, 2008 13:38

Sivart13: May 18, 2003; I have neglected to come up with a clever title

It's definitely easier to throw a lot of code at something by yourself, but I always find myself dropping off in motivation as soon as I hit a big bug or design issue. Being part of a team usually helps me soldier through that instead of running off to SA to waste time while the comp is still going.

# ? Sep 4, 2008 20:34

Pfhreak: Jan 30, 2004; Frog Blast The Vent Core!

Here's a stumper of a procedural question:

Let's say I have a texture, any texture, and I want it to have depth in my game. Nothing complicated, just a cardboard cutout-esque amount of depth. Think paper mario (actually, they were 2 d, think the background pieces in paper mario.)

The first way I thought of doing it would be to use the marching squares algorithm to create a perimeter, then tesellate that, then build the polys, but that seems overkill.

I'd imagine there has to be a way to do this with a shader, but my shader-fu is weak.

# ? Sep 6, 2008 06:01

MasterSlowPoke: Oct 9, 2005; Our courage will pull us through

What exactly do you mean by "have depth"?

# ? Sep 7, 2008 00:36

shodanjr_gr: Nov 20, 2007

What's a good place to get some free 3D assets?

I'm looking for a few "ground" (aka gravel/stone/etc) textures with their respective normal maps that tile well.

# ? Sep 7, 2008 03:18

MasterSlowPoke: Oct 9, 2005; Our courage will pull us through

For temporary textures or models, http://www.turbosquid.com/ has some free stuff that should get you by. Just select the category you want and sort by lowest price, and all the free stuff should come out. You'll need to make an account but that's painless.

# ? Sep 7, 2008 05:00

OneEightHundred: Feb 28, 2008; Soon, we will be unstoppable!

Pfhreak posted:

Here's a stumper of a procedural question:

Let's say I have a texture, any texture, and I want it to have depth in my game. Nothing complicated, just a cardboard cutout-esque amount of depth. Think paper mario (actually, they were 2 d, think the background pieces in paper mario.)

The first way I thought of doing it would be to use the marching squares algorithm to create a perimeter, then tesellate that, then build the polys, but that seems overkill.

I'd imagine there has to be a way to do this with a shader, but my shader-fu is weak.

You mean like relief mapping?

I haven't played Paper Mario so hopefully I'm understanding this.

# ? Sep 7, 2008 07:51

MasterSlowPoke: Oct 9, 2005; Our courage will pull us through

OneEightHundred posted:

You mean like relief mapping?

I haven't played Paper Mario so hopefully I'm understanding this.

Paper Mario's effects are purely billboarded sprites, as far as I know.

# ? Sep 7, 2008 08:21

shodanjr_gr: Nov 20, 2007

MasterSlowPoke posted:

Paper Mario's effects are purely billboarded sprites, as far as I know.

He may mean those background pieces that "look" 2D in 2D mode but actually have "depth" when you look at them in 3D mode. I dont see how those things are any different than normal objects. The only things that change are the camera position and the way clipping/collision detection is handled.

# ? Sep 7, 2008 08:34

Pfhreak: Jan 30, 2004; Frog Blast The Vent Core!

To clarify:

I know that a billboarded sprite has no depth, if you look at it side-on it disappears. Let's call that analogous to a sheet of paper.

What I want is to have it appear like a piece of cardboard. Like the texture was simply extruded to a certain depth. So, when you look at it side on, it still has a flat face with the texture, but also a 'side'.

The best way I can think of to do this is to use the output from marching squares to build a trianglestrip representing the side, then billboard the actual sprite on the top of that.

# ? Sep 7, 2008 18:20

Obsurveyor: Jan 10, 2003

Pfhreak posted:

I know that a billboarded sprite has no depth, if you look at it side-on it disappears. Let's call that analogous to a sheet of paper.

Technically, a billboarded sprite always faces the camera so you never see it edge on. If you want something with thickness that is not always rotated to face the camera, just use a thin rectangular solid with the texture on a single face.

# ? Sep 7, 2008 19:55

OneEightHundred: Feb 28, 2008; Soon, we will be unstoppable!

That's probably the only actual way to do it, though you could technically hack it with relief mapping and alpha test abuse. Just generating polygon strips would probably be faster though, relief mapping is SLOW.

# ? Sep 7, 2008 20:31

ZorbaTHut: May 5, 2005; wake me when the world is saved

Pfhreak posted:

To clarify:

I know that a billboarded sprite has no depth, if you look at it side-on it disappears. Let's call that analogous to a sheet of paper.

What I want is to have it appear like a piece of cardboard. Like the texture was simply extruded to a certain depth. So, when you look at it side on, it still has a flat face with the texture, but also a 'side'.

The best way I can think of to do this is to use the output from marching squares to build a trianglestrip representing the side, then billboard the actual sprite on the top of that.

You wouldn't really billboard the sprite on it, you'd just render a polygon with the sprite as a texture. That said, yes, this is the easiest way. However, do you want it to have a jagged edge, or a smooth edge? For example, if you have a 90/45/45 triangle, should the edge of it look like a stairstep or actually have a flat surface?

Because if you want a flat surface, you've got some nasty work ahead of you

# ? Sep 8, 2008 10:23

take boat: Jul 8, 2006; boat: TAKEN

I'm wrapping up a soul sucking year and a half long drain on my life, and am looking forward to using my new found time to maybe build a simple 2D sprite game (my first!).

I want ease of distribution, the speed to handle hundreds of animated sprites on screen, and ideally cross platform/free dev tools. But running the game on an Xbox would be cool too.

Here's what I'm considering:

Flash: playable online, cross platform, expensive and proprietary dev tools, slow (?)
Silverlight: playable online, chance to learn .NET, semi-cross platform, proprietary dev tools, no one has Silverlight installed, slow (?)
XNA: requires .NET to play, not cross platform, chance to learn C#, Windows only dev tools, can run games on Xbox (!), fast
Python/Pygame: difficult to distribute, cross platform, chance to get better at Python, medium speed (?)
Java: Cross platform, easy to distribute, chance to learn Scala or Clojure, fast

I'm leaning towards Java (w/ Clojure), but I'd love to get some input from more experienced game makers.

# ? Sep 8, 2008 11:48

POKEMAN SAM: Jul 8, 2004

take boat posted:

Here's what I'm considering:
Flash: playable online, cross platform, expensive and proprietary dev tools, slow (?)

Silverlight: playable online, chance to learn .NET, semi-cross platform, proprietary dev tools, no one has Silverlight installed, slow (?)

XNA: requires .NET to play, not cross platform, chance to learn C#, Windows only dev tools, can run games on Xbox (!), fast

Python/Pygame: difficult to distribute, cross platform, chance to get better at Python, medium speed (?)

Java: Cross platform, easy to distribute, chance to learn Scala or Clojure, fast

I'm leaning towards Java (w/ Clojure), but I'd love to get some input from more experienced game makers.

What kind of 'fast' do you mean? If it's development time then Pygame will be the fastest.

# ? Sep 8, 2008 21:56

t_rf: Nov 24, 2006

take boat posted:

I'm wrapping up a soul sucking year and a half long drain on my life, and am looking forward to using my new found time to maybe build a simple 2D sprite game (my first!).

I want ease of distribution, the speed to handle hundreds of animated sprites on screen, and ideally cross platform/free dev tools. But running the game on an Xbox would be cool too.

[/list]I'm leaning towards Java (w/ Clojure), but I'd love to get some input from more experienced game makers.

That's not quite enough information on what kind of speed you are looking for. Any of those can display hundreds of animated sprites at 30fps, and probably even 60 -- depending on screen resolution, bit-depth, and collision/AI complexity. I've used a lot of both Flash and Pygame. I used to be all about Pygame, now it's all Flash. Pygame is probably the slowest renderer because it doesn't have a fast scenegraph built-in like Flash, but if you add OpenGL to the mix it can get a lot faster. Flash on the other hand has a scenegraph that performs pretty well for straight-up bitmaps; the vectors and transformation effects can be looked at as additions to that. Perceptions of Flash slowness are almost entirely due to an overuse of vector rendering. There are also some great open source tools for Flash: I use and actively promote haXe where I can. I've never used Adobe's commercial tools on a project, though I know they have their benefits.

Also, I would warn you away from a focus on rendering. Having hundreds of things on screen, while technically interesting, tends to make the game design converge on a uniform, repetitive gameplay where you have a cloud of stuff that is either moving too randomly or too predictably to be fun. The most you can use massive amounts of sprites for is in particle effects, unless you have a very specific design in mind that needs high quantity.

What you should really worry about - if you are serious about making a game - is collision, state, and timing, in that order: those things constitute the core gameplay of most game genres. Answering problems like: How to make characters slide against walls instead of bouncing or stopping dead. Working out which frames of the player's attack anim cause an hit on the enemy, and how the enemy AI will perform its hitreact before returning to normal behavior. Transitioning from gameplay to an in-game cinematic, and back again, without completely breaking the gameplay. Those are the tough questions of game programming that have nothing to do with optimization.

The other thing to consider, besides the gameplay, is the asset pipeline. It should be as easy and seamless as possible to add new content, if you are doing a content-heavy game. Fortunately with 2d these problems are mostly organizational. In 3d-land it's easy to end up with conversion processes that fail "some" of the time.

For all those questions the language is mostly a matter of "which one will allow me to make the fewest errors?" If you can build off a game engine which answers some of the gnarly problems outlined above, life becomes much easier. (A lot of people make engines that do almost nothing to solve those problems, of course. Those engines are rendering, a pipeline, and a little bit of collision. Good enough for a demo, but a long way from a shippable game.)

# ? Sep 9, 2008 04:46

Hammertime: May 21, 2003; stop

I know this question will probably be frowned on, but I've read the thread start to finish ...

I'm getting back into 3D programming, I've had some good times with C# and XNA in the past, but I need to transition to C++ for my next project and I'm left with two choices, OpenGL and Direct3D. The transition to C++ is due to getting a 3x performance gain in performing my procedural generation math natively.

Which one should I use?

My main concern is core API structure. Performance is a slight concern if there's a big gap, the only intensive task I'll be doing is drawing large amounts of triangles (some shader effects, but nothing too fancy).

I've heard that OpenGL is cleaner, but then I've also heard it's a dieing beast. Decisions, decisions.

# ? Sep 10, 2008 09:39

tyrelhill: Jul 30, 2006

Hammertime posted:

I know this question will probably be frowned on, but I've read the thread start to finish ...

I'm getting back into 3D programming, I've had some good times with C# and XNA in the past, but I need to transition to C++ for my next project and I'm left with two choices, OpenGL and Direct3D. The transition to C++ is due to getting a 3x performance gain in performing my procedural generation math natively.

Which one should I use?

My main concern is core API structure. Performance is a slight concern if there's a big gap, the only intensive task I'll be doing is drawing large amounts of triangles (some shader effects, but nothing too fancy).

I've heard that OpenGL is cleaner, but then I've also heard it's a dieing beast. Decisions, decisions.

OpenGL is not a dying beast. It is probably stronger than ever. As for "getting back" go with DirectX. It has a full math library, surfaces, the FX framework, and plenty of other crap already done to get you warmed up for doing practically everything yourself with OpenGL.

# ? Sep 10, 2008 09:56

OneEightHundred: Feb 28, 2008; Soon, we will be unstoppable!

Hammertime posted:

Which one should I use?

My main concern is core API structure. Performance is a slight concern if there's a big gap, the only intensive task I'll be doing is drawing large amounts of triangles (some shader effects, but nothing too fancy).

I've heard that OpenGL is cleaner, but then I've also heard it's a dieing beast. Decisions, decisions.

OpenGL and D3D9 have almost identical feature sets. The main concerns at this point:
- Intel IGPs have no GLSL support yet
- If you're ever going to port to D3D10, you need to know how input layouts work
- Filtering/clamp are set on textures in OpenGL and set on sampler slots in D3D
- D3D10 draw calls are reasonably cheaper than OpenGL draw calls which are a lot cheaper than D3D9 draw calls
- GLSL compiled shaders need to be completely recompiled any time the application is restarted, D3D shaders can be cached and built offline
- Sampling in D3D9 is offset by half a texel, which is especially important with UI controls: (0,0) in D3D9 is between the four corners of a texture, (0,0) in D3D10 and OpenGL is a single corner texel
- D3DX has tons of useful toys, GLUT is pathetic
- D3D is useful on Xbox 360, OpenGL is useful on every other console

# ? Sep 10, 2008 19:48

captain_g: Aug 24, 2007

OneEightHundred posted:

- D3DX has tons of useful toys, GLUT is pathetic

I didn't know GLUT is part of OpenGl? Surely you mean GLU, which no one uses anyway.

# ? Sep 10, 2008 21:04

StickGuy: Dec 9, 2000; We are on an expedicion. Find the moon is our mission.

captain_g posted:

I didn't know GLUT is part of OpenGl? Surely you mean GLU, which no one uses anyway.

GLU is pretty handy actually. It's good for setting up some camera views and who wants to write stuff to tesselate polygons? Furthermore, I refer you to:
http://www.opengl.org/documentation/specs/
where they also list the GLUT specification.

# ? Sep 10, 2008 21:09

pianoSpleen: Jun 13, 2007; printf("Java is for programmers with no %socks", "c");

Pfhreak posted:

Here's a stumper of a procedural question:

Let's say I have a texture, any texture, and I want it to have depth in my game. Nothing complicated, just a cardboard cutout-esque amount of depth. Think paper mario (actually, they were 2 d, think the background pieces in paper mario.)

The first way I thought of doing it would be to use the marching squares algorithm to create a perimeter, then tesellate that, then build the polys, but that seems overkill.

I'd imagine there has to be a way to do this with a shader, but my shader-fu is weak.

You mean like the sky textures in Quake? Where you have a bunch of layers which have parallax?

That can be done quite simply by hacking up the relief mapping algorithm to only take as many samples as there are layers. Relief mapping's slowness comes primarily from the number of texture samples used, and I imagine for your application there would only be 3-4 layers needed (thus 3-4 samples). As a result, it'd probably run at an acceptable speed.

Then again, you'd probably get a bit more speed by simply drawing one quad per layer in the appropriate position and set a shader to discard any pixel whose depth isn't the correct value for that layer.

I'm still not 100% sure that's what you want, though. Can you think of another example?

# ? Sep 11, 2008 02:30

Bob Morales: Aug 18, 2006; ~~Just wear the fucking mask, Bob~~

I don't care how many people I probably infected with COVID-19 while refusing to wear a mask, my comfort is far more important than the health and safety of everyone around me!

I have a question about memory management. It was never covered in Lamothe's 'Game Programming in 21 Days' so I don't know anything about it.

I was browsing around at the Heretic source code, and similar to the Quake code it seems they have their own memory manager. (Looking back, a very similar Z_ZONE.C file is even in the Wolf3D source!)

It contains code like this:

code:

typedef struct
{
	int		size;		// total bytes malloced, including header
	memblock_t	blocklist;		// start / end cap for linked list
	memblock_t	*rover;
} memzone_t;

/*
========================
=
= Z_Init
=
========================
*/

void Z_Init (void)
{
	memblock_t	*block;
	int		size;

	MallocFailureOk = false;
	mainzone = (memzone_t *)I_ZoneBase (&size);
	mainzone->size = size;

// set the entire zone to one free block

	mainzone->blocklist.next = mainzone->blocklist.prev = block =
		(memblock_t *)( (byte *)mainzone + sizeof(memzone_t) );
	mainzone->blocklist.user = (void *)mainzone;
	mainzone->blocklist.tag = PU_STATIC;
	mainzone->rover = block;
	
	block->prev = block->next = &mainzone->blocklist;
	block->user = NULL;	// free block
	block->size = mainzone->size - sizeof(memzone_t);
}


/*
========================
=
= Z_Free
=
========================
*/

void Z_Free (void *ptr)
{
	memblock_t	*block, *other;
	
	block = (memblock_t *) ( (byte *)ptr - sizeof(memblock_t));
	if (block->id != ZONEID)
		I_Error ("Z_Free: freed a pointer without ZONEID");
		
	if (block->user > (void **)0x100)	// smaller values are not pointers
		*block->user = 0;		// clear the user's mark
	block->user = NULL;	// mark as free
	block->tag = 0;
	block->id = 0;
	
	other = block->prev;
	if (!other->user)
	{	// merge with previous free block
		other->size += block->size;
		other->next = block->next;
		other->next->prev = other;
		if (block == mainzone->rover)
			mainzone->rover = other;
		block = other;
	}
	
	other = block->next;
	if (!other->user)
	{	// merge the next free block onto the end
		block->size += other->size;
		block->next = other->next;
		block->next->prev = block;
		if (other == mainzone->rover)
			mainzone->rover = block;
	}
}

/*
========================
=
= Z_FreeMemory
=
========================
*/

int Z_FreeMemory (void)
{
	memblock_t	*block;
	int			free;
	
	free = 0;
	for (block = mainzone->blocklist.next ; block != &mainzone->blocklist 
	; block = block->next)
		if (!block->user || block->tag >= PU_PURGELEVEL)
			free += block->size;
	return free;
}

There's also a big fat Z_Malloc function as well. What's the exact reason for them doing this instead of using the stdlib free/malloc?

# ? Sep 11, 2008 20:49

newsomnuke: Feb 25, 2007

Bob Morales posted:

There's also a big fat Z_Malloc function as well. What's the exact reason for them doing this instead of using the stdlib free/malloc?

Speed. They'll still be using malloc & free (or a variant) somewhere to actually (de)allocate the memory, but they're potentially expensive functions, so you sometimes want to give them a helping hand in various ways, eg pre-allocating memory, making sure it doesn't get too fragmented, etc. Also, wrapping memory allocation like this makes it easier to find leaks, segfaults, etc.

Memory allocation in games doesn't get discussed nearly enough, but it's very important for writing robust programs, especially ones which can run for a long period of time and perform lots of allocations without the memory getting too segmented.

# ? Sep 11, 2008 22:03

more falafel please: Feb 26, 2005; forums poster

ultra-inquisitor posted:

Speed. They'll still be using malloc & free (or a variant) somewhere to actually (de)allocate the memory, but they're potentially expensive functions, so you sometimes want to give them a helping hand in various ways, eg pre-allocating memory, making sure it doesn't get too fragmented, etc. Also, wrapping memory allocation like this makes it easier to find leaks, segfaults, etc.

Memory allocation in games doesn't get discussed nearly enough, but it's very important for writing robust programs, especially ones which can run for a long period of time and perform lots of allocations without the memory getting too segmented.

It also allows them to know exactly how memory is getting allocated, essentially independently of the OS or hardware.

# ? Sep 11, 2008 22:34

OneEightHundred: Feb 28, 2008; Soon, we will be unstoppable!

Well, you also have to remember that Wolf3D and a lot of earlier games were largely written at times when stock allocators were horrible and games were using software renderers that used a lot of system memory.

Stock allocators are better than they were, memory debuggers are a lot better, some general-purpose custom allocators like dlmalloc perform excellent, etc.

A major reason behind it is error recovery, since they're written in C and consequently lack exception handling and destructors, so error recovery isn't able to clean up things on the stack automatically and handling complex deallocation situations is a lot more cumbersome. Using a custom memory manager means everything can be pool-tagged and just deallocated all at once if things go south.

# ? Sep 12, 2008 07:53

take boat: Jul 8, 2006; boat: TAKEN

t_rf posted:

[snip]

Wanted to say thanks for your advice, and I'm definitely going to try Flash out. I'm interested in having a hi-def resolution with a lot of sprites for the purposes of assembling complicated background scenery, not for anything gameplay related. In general I'm more excited about the background than on the gameplay, which as you point out isn't how you make a good game...but I guess we'll see how things go.

# ? Sep 13, 2008 01:47

IEatBabies: Sep 17, 2004

OneEightHundred posted:

- D3DX has tons of useful toys, GLUT is pathetic

There are also alternatives to GLUT. There is also SDL, sfml (never used), and, if you're strictly Windows, WGL.

captain_g posted:

I didn't know GLUT is part of OpenGl? Surely you mean GLU, which no one uses anyway.

GLUT is primarily just a platform-independent way of creating your window and handling I/O.
http://en.wikipedia.org/wiki/OpenGL_Utility_Toolkit

IEatBabies fucked around with this message at 21:53 on Sep 13, 2008

# ? Sep 13, 2008 21:46

Adbot: ADBOT LOVES YOU

# ? May 9, 2024 22:14

tyrelhill: Jul 30, 2006

Anyone know about a leak detector for COM objects, specifically DirectX objects in C/C++?

# ? Sep 14, 2008 02:08

The Something Awful Forums > Discussion > Serious Hardware/Software Crap > The Cavern of COBOL > Game Development Megathread

«‹›622 »