Blitting part 4

After an absurd amount of extremely frustrating exceptions and bugs, I’ve finally gotten software blitting working perfectly (I hope) on my chess project. As of right now every time I run the program it creates a png for me to use. The images can be of arbitrary size, and can blit to an arbitrary part of the other image. Anyway, here’s one of the PNG’s:

full board

Notice, no borders.

There’s no doubt that it looks quite janky. Since I’m using a sub-optimal (from a perfect image quality POV), nearest-pixel algorithm, I decided to pre-downscale my images. I was lazy, and instead of creating a small program to do this for me, I instead just resized the images in Microsoft Paint, which ruined all my alpha values (transparency). As a result, to get this image I set pure white to transparent (similar to green-screening), and we have what you see before you.

Nevertheless I’m quite proud of myself, mostly on the programming side, since these images can easily be replaced with higher quality images.

Posted in Uncategorized | Leave a comment

Software Blitting Part 3

If we have a typical PNG of size, say, 100×100, then we can easily refer to a specific pixel as 44, 02, if we want the forty fourth pixel from the right, on the second line. Unfortunately it’s not quite that simple, since the raw pixel data is linear, so pixel 44,02, is actually just pixel #244. A visual representation might make this easier.

Imagine a very simple image consisting of four pixels:

fourPixels

Of course, I have added the black lines.

The way this image is stored in memory is like this:

greenPixel redPixel yellowPixel pinkPixel

So if we want to access the pink pixel, we can’t simply go for the pixel at 2, 2, we need to specify the #4 pixel. All this seems quite simple, but it makes blitting one image to another a bit harder.

Continue reading

Posted in Programming, Uncategorized | Tagged , , , | Leave a comment

Software Blitting part 2

Computer graphics are made up of pixels, and pixels are made up of colour channels, specifically Red, Green, and Blue (and Alpha, but we’re not worried about that). You combine all three of those channels to form the colour that you want. As it turns out, if you have a gradation of 0-255 for each of these channels, you can create colours of small enough granularity that the human eye cannot tell the difference between the two most like each other. Since it takes a computer 8 bytes to store 256 values, and we need one byte for each colour channel, we have each of our pixels requiring 24 bits of information, giving us 24 bit colour, giving us over 16.7 million colours.

But we have a bit of a problem. Raw pixel data can be quite large. Consider this, and image at 1920×1080, or 1080p, contains 1920*1080 pixels, or over 2 million pixels. If each pixel takes 3 bytes of information, that image takes 47.46 MB’s of space on the user’s hard drive. And yet, if you find an image of this size on your hard drive odds are that it does not take up anywhere near that amount of space. This is due to compression. There are many types of compression algorithms (such as JPEG, DXT, PNG, GIFF, etc), and therefore formats, but I was dealing simply with PNG. What compression does is take the raw image data, and reduce the data required to store that image. You then need a program to read the PNG (or other format) image file, and decompress the file.

Continue reading

Posted in Programming | Tagged , , , | Leave a comment

Software Blitting Part 1

About a week ago my trusty Microsoft Ergonomic Keyboard broke, and I was forced to use my laptops native keyboard. I somehow managed to be productive during this time, but today my new keyboard came in the mail. So I decided to take it out for a spin, and get to work on a problem that’s starting to irritate me to no end.

My workflow to create the pictures that you see here consists of the following:
1) Run Program
2) Hit ‘Print Screen’ key
3) Open Microsoft Paint
4) CTRL+V the entire screen into Paint
5) Crop out everything but the running window.
6) Upload PNG to WordPress

Uncropped2

Uncropped image.

Continue reading

Posted in Programming | Tagged , | Leave a comment

Chess 3030

As a brief refresher, the entire purpose of Chess 60 was to reduce the benefit of opening preparation to effectively zero. Top level players, and frankly even >2000 ELO players (fairly highly rated) have played so many games and remembered so many openings, that the game begins much later than move one. For the best players in the world, it begins much, much later than move one. Since that’s not particularly fun to me, I created a version that would hit the sweet spot between Fischer Random Chess, (chess 960) and classical chess. Unfortunately, as it turn out, Chess 60 is really Chess 30, which leaves me with two problems. The first being that Chess 60 is a stupid name, which can easily be solved by calling it something else, like Chess 30.

More seriously, my concern is that, with only thirty starting positions it leaves the door quite open to players memorizing openings again. They may not memorize openings for all thirty positions, but there is a clear advantage to memorizing openings for a few positions, and hoping that you get to play those positions in tournament. Even with the original sixty positions there was a small part of that, and it makes for a very unfortunate meta-game, where the outcome of a game is determined in large part due to luck, if one of the players prepared for the position more than the other did.

My solution to this is probably going to be much more controversial than my original proposal, but frankly I feel it is much more exciting.

Continue reading

Posted in Chess, Chess 900, Game Design | Tagged , | Leave a comment

Chess 60, an incorrect name

It occurred to me that I had improperly counted the amount of possible starting combinations of the so-called “Chess 60”. I had overlooked that there are two knights, and so many of the positions will simply be repeats of another, but with Knight A and Knight B flipping positions. So is it true that we can simply halve the amount of positions, and start calling the game Chess 30? Perhaps not.

Here we have a chess board, set up with the classical chess starting position.

chessBoard

The classic chess starting position

Continue reading

Posted in Chess, Chess 60, Game Design | Tagged , , | Leave a comment

Testing programming syntax

I’ve struggled when posting programming posts, since WordPress has always improperly formatted them. This is quite unfortunate, since poor formatting can ruin the readability of a post. Luckily, when researching CGI extensions for WordPress (which hopefully allows me to run c++ on WordPress) I stumbled upon a post that claimed I could have proper syntax for programming with just a few lines added into the post. So here goes:


void SetUpSprite(Sprite* sprite, std::string textureName)
{
GLuint VBO;
GLfloat vertices[]={
// Positions // Texture Coords
0.0f, 1.0f, 0.0f, 1.0f,
1.0f, 0.0f, 1.0f, 0.0f,
0.0f, 0.0f, 0.0f, 0.0f,

0.0f, 1.0f, 0.0f, 1.0f,
1.0f, 1.0f, 1.0f, 1.0f,
1.0f, 0.0f, 1.0f, 0.0f
};

glGenVertexArrays(1, &sprite->quadVAO);
glGenBuffers(1, &VBO);

glBindBuffer(GL_ARRAY_BUFFER, VBO);
glBufferData(GL_ARRAY_BUFFER, sizeof(vertices), vertices, GL_STATIC_DRAW);

glBindVertexArray(sprite->quadVAO);
//send position and Tex as one vec4
glEnableVertexAttribArray(0);
glVertexAttribPointer(0, 4, GL_FLOAT, GL_FALSE, 4*sizeof(GLfloat), (GLvoid*)0);

glBindVertexArray(0); //unbind VAO
glBindBuffer(GL_ARRAY_BUFFER, 0); //Unbind VBO

//Load texture and store texture ID.
sprite->texture=LoadTexture("\\"+textureName);
}

The above is some graphics code I had in my game. Seems to look pretty good to me.

Edit: However that last line is a nightmare. It’s supposed to look like this:

sprite->texture=LoadTexture(“\\”+textureName);

Let me try that again


sprite->texture=LoadTexture("\\"+textureName);

Weirdly it now works. This is an odd bug, but I still feel that this is a useful feature.

Posted in Uncategorized | Leave a comment