Endurion

Just few tips, a triangle has 3 vertices a square has 4 at least (you may need more).

Find where you declare vertices,

 

You will need a switch to check if you are in square mode or triangle mode, and to a way to change that switch at runtime. (By switch I mean a Bool variable, True, False)

There is no square mode.

 

A square is simply a list of two triangles instead of 1. The simplest way would be to add the 3 vertices of the second triangle to your vertex array , change the "3*" in the CreateVertexBuffer call to "6*" and change the "1" in the DrawPrimitive call to "2".

Get that working first, don't bother with the other primitive types yet.

Bitmap images do have a padding. Every row of pixel data must be padded to a full multiple of 32 bit.<br /><br />So for your example, with 305 pixels, 305 * 3 (24bit) = 915 bytes per row. The next full multiple is at 916, so you have to read one extra padding byte.

Also, you need to disambiguate between keyboard input as in gamepad keys, or actual text entry. It is not advisable to use for text entry, but as gamepad replacement it's perfectly fine. DirectInput is the only API that gets you access to every input device under one hood.

To the OP: Are you calling input->Frame() somewhere?

I think the main problem comes from calling glutSwapBuffers two times.

Do a full redraw every time, with one glClear at the top and one glutSwapBuffers at the end. Only draw a brick, if it is not set to 0. Now when the ball is inside the brick rect (as your check seems to do), the brick is cleared and on the next redraw it is simply not drawn.

In other words, make it so:

// brick/ball collision
if ( ( x >= 3.0f )
&&   ( x <= 5.0f )
&&   ( y >= 3.5f )
&&   ( y <= 4.0f ) )
{
  bricks[3][5] = 0;
}

// brick/ball draw code
if ( bricks[3][5] ) != 0 )
{
  // draw the brick
}

The problem I fear is that bitmaps do use padding (4 bytes per line), so that probably won't work.

Just 'cause I'm curious, are you saying every bitmap format aligns each line of pixels to 4 bytes?
Or that, regardless of the length of a line, there are 4 empty bytes at the end of each one?

And is the first bit or the last bit of a 16-bit 555 bitmap pixel the ignored bit?

Not every bitmap format, only the Windows BMP format AFAIK.

Every line of pixels is padded to a full multiple of four bytes. The padding bytes are added at the end of a line. 16-bit bitmaps are always stored as 5-5-5, xRRRRRGGGGGBBBBB, unless the color masks in the header say otherwise. For simplicity sake the color masks in the sample hex dump are set to 0, then xRRRRRGGGGGBBBBB is the default.

The problem is that most paint programs do not cater to 16 bit 5-5-5 (or 5-6-5 ) color depth.

Here, try this, it's a hex dump of 16bit bitmap header for a 57x57 image. Since you seem to do Linux/Unix I think you can use one of the shell tools to convert it to binary. The problem I fear is that bitmaps do use padding (4 bytes per line), so that probably won't work.

42 4D 0A 1A 00 00 00 00  00 00 36 00 00 00 28 00
00 00 39 00 00 00 39 00  00 00 01 00 10 00 00 00
00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00
00 00 00 00

The file contains two dwords with width and height, and then the plain image data (2 bytes per pixel).

If you don't have a program that can work with that kind of data, the simplest way would be to write a programm to append/remove a image header of a format than can store that data.

I'd suggest BMP or TGA, both allow the pixel data in exactly that format.

To detail ptrrfs answer even more, load the image once, and set the color key on that image once. The color key is then a property of that SDL_Image.

Stolen from StackOverflow:

Better than using SetWindowText to replace the full text:
You can add text by setting the beginning and end of the selection to the end of the text in the control (EM_SETSEL), then replacing the (empty) selection with your new text (EM_REPLACESEL).

Scrolling to the bottom can be done with EM_SCROLLCARET after the caret (the selection) is at the end of the text. There are other ways, but if you're doing it immediately after adding text, this is probably the easiest.

Also a hint: You can return a value to C via yield and pass a parameter in via resume. This may come in handy for the Wait function.

As a game player I'd prefer to have Alt-Enter in, this is IMHO quasi standard; whereas F4 feels like the odd one out.

What's so bad about having both?

I don't want to sound harsh, but seriously, use std::list. Your code is leaking all over.
No, your compiler is surely not buggy. You don't call destructors directly.

Have you used the debugger and checked where it crashes?


The crash comes probably from that loop. Think about it, you're reaching the last element, so sentinel = sentinel->next; is setting sentinel to NULL.
And then you try to access sentinel->prev. Null pointer access!

sentinel = list;
   cout << sentinel->data->x << "*" << endl;
   while (sentinel != NULL)
   {
	    sentinel = sentinel->next;
	    delete sentinel->prev;
   }

For that you don't need a panel. Just create a dialog, attach a menu and the rest of the client area can be WM_PAINTed to.

If you do need a child control, RegisterClass a new window type and CreateWindow it with WS_CHILD set into your parent.

Unfortunately you don't mention the language and/or framework, so I assume Windows.Forms with C#?

You find the selected items in ListView.SelectedItems.

If you want to store a reference to your own objects in a ListView you can use the .Tag member of the ListViewItem.

Do you also resize the main window and change your main window styles to have no border when switching to full screen?