Jump to content

  • Log In with Google      Sign In   
  • Create Account


Member Since 30 Aug 2012
Offline Last Active Oct 18 2013 01:09 PM

#5084746 Advice for 2D game structure

Posted by BLM768 on 10 August 2013 - 01:05 PM

I'm not sure whether you're using OpenGL or DirectX, but in either case, you might be able to take advantage of instancing.


Here's a good article on OpenGL instancing:


#5081363 Revew my pong clone: game and code!

Posted by BLM768 on 28 July 2013 - 11:55 PM

This code's not bad for a first project; it's organized reasonably well and is pretty easy to read. As far as structure goes, you'd need only a few tweaks to make it more solid:
The functions that manipulate the ball and paddles could be moved into the classes as methods, like so:

class Paddle
	int x, y;
	int width, height;
	BITMAP *paddleSprite;

	void moveUp() {
		if(y < 0)
			y = 0;

	void moveDown() { /* ... */ }
	void draw() { /* ... */ }

Then instead of calling moveup(paddle1), you would call paddle1.moveUp().
You could also take advantage of the similarities between the paddles and the ball. They are both game entities with coordinates, width, height, and an image, so you can pull those similarities into a base class:

class Entity
	int x, y;
	int width, height;
	BITMAP* sprite;

	void draw()
		blit(sprite, buffer, 0, 0, x, y, width, height);

//Has all the fields from Entity plus whatever we add here:
class Paddle: Entity {
	//moveUp(), moveDown, etc.

class Star: Entity {
	void rotate() { /* ... */ }

	//etc., etc.

I can think of a few more things you might want to tweak, but I'll leave you with that for now because it's getting late, and this post will probably take a little while to "digest" if you're not already familiar with methods and inheritance.

#5078298 Problem with game design implementing VBO and VAO

Posted by BLM768 on 16 July 2013 - 04:55 PM

The problem is that when you draw the contents of the VAO, the currently active shader will be used for everything that the VAO contains. In general, when I'm drawing a mesh, I use one VBO for each of the vertex attributes (position, normal, etc.), but I split the face index data into several VBOs, with one VBO per material. I iterate over the face-index VBOs, setting the correct material/shader for each before drawing it.

#5078285 Jumping - What did I do wrong?

Posted by BLM768 on 16 July 2013 - 04:14 PM

Here's a hint: when the player presses a button, inAir is set to true, but what are the values of rising and falling?

#5027130 Convert between coordinate spaces

Posted by BLM768 on 30 January 2013 - 03:48 AM

Aha! I think I've got it. When you subtract 30 from the roll value, you're doing it in the conversion from model space to view space, so the second object's position will change by 30 degrees in view space, not in world space. Try splitting it into two transformations: one to rotate its position vector 30 degrees in world space, followed by the (-pitch, -roll, -yaw) transformation to get it into view space. You might have to swap the order of those two transformations because Cocos3D seems to perform matrix operations in the inverse order (at least from what I've seen your code do, but I'm not completely sure because I've never messed with it).

#5026665 Convert between coordinate spaces

Posted by BLM768 on 29 January 2013 - 12:23 AM

Yeah, that's what I initially thought but it looks like it goes the other way around. Not sure why... I don't think that is the issue here, since you can see on the first image that the I have the correct order. Otherwise you'd see both objects in the same ( -distance) position, just rotated differently.

That's quite odd. It seems as though the changing device rotation alters the objects' rotation, but the position is only affected by the first rotation value and then stays fixed. Weird...


Is the origin of each object (without any transformation) at the center of the rectangle, or is it at some other point?

#5026293 Convert between coordinate spaces

Posted by BLM768 on 28 January 2013 - 12:55 AM

I'm not too familiar with Cocos3D, but if I'm reading your code correctly, it looks like you're performing the rotation and then moving the objects in world space. The problem is that you're performing those two operations in the wrong order. In general, you want the most "local" transformations to be applied first; for example, if an object is rotating around its own axis, you'll perform that rotation first, then translate it to its position in the world. However, if it's rotating around the camera, you'll want to translate it before rotating. Every translation/rotation is applied in the camera's space, not in the space of the object that received the last transformation.


To visualize: using simple matrix transformations, if you put an object in front of yourself and translate it "up" (+Y), it will always move toward your "up", not toward its "top" side (unless it's already right-side-up). If you rotate it, it will always move as if it's orbiting around your head. If you want an object to be rotating around its own axis but staying in one location, you need to put it "inside" your head, rotate it there, and move it out to its final position; otherwise, it will move around your head as it rotates. A little unintuitive, but the math works out nicely.

#5013604 May I know what a patch (mesh) is?

Posted by BLM768 on 23 December 2012 - 02:05 AM

I would like to see OpenGL to grow more mature because OpenGL can be programmed on the android mobile phones while DirectX can't.


I'm not aware of any major areas in which OpenGL is less "mature" than DirectX is. It's certainly less comprehensive because it only deals with graphics and not input, etc., but that doesn't make it any less powerful for graphics; you just need to use other libraries, such as SDL, alongside it. In the area it handles, which is just graphics, it's very mature and powerful as long as you're using a recent enough version.


Personally, I always use OpenGL for my projects because I hate being tied to one platform, and OpenGL has more comprehensive language bindings. With OpenGL, SDL, and optionally OpenAL, you should be able to write just about any type of game/simulation in a very cross-platform manner using just about any programming language.

#5013361 May I know what a patch (mesh) is?

Posted by BLM768 on 22 December 2012 - 02:24 AM

I don't have much experience with this particular topic, and my experience is mainly in OpenGL rather than DirectX, so my answer might not be completely correct, but here is what I understand:


At least in OpenGL, a "patch" is basically like a triangle, but it has a user-defined number of vertices. Patches can only be used as the input for a tessellation shader, which breaks them down into triangles in a user-programmable manner. The main advantage is that patches allow you to take advantage of GPU tessellation, which can be a useful tool for some effects (especially subdivision surfaces) that would traditionally require re-generating the mesh on the CPU and pushing it to the GPU each frame. Unfortunately, patches and tessellation shaders are only available in recent versions of OpenGL (4.0, I think).


From the minimal research I've done on DirectX patches, they are fairly similar to OpenGL patches, but I'm not sure what all of the differences are. In some versions of DirectX, it appears that the number of vertices in a patch is more tightly restricted than in OpenGL 4, but the most recent versions are probably more flexible.

#4975045 Problem with mapping a reflection texture

Posted by BLM768 on 30 August 2012 - 11:26 PM

To properly obtain the coordinates, I think that you need to multiply the vertex coordinates by the projection matrix and then divide the x/y values by -z.
However, I'd recommend considering using the stencil buffer to mask out the non-mirror areas, render the reflection, then render the unreflected scene. It's a bit more complex than that, but that's the general idea. The advantage to this method is that you don't need an additional texture, and the stencil test prevents some of the unnecessary fragment processing from happening.