Weird decisions you have taken during game programming

u/Dream of Omnimaga October 24, 2016, 04:34:30 PM

Yeah I can't read people code, same for very old code I wrote >.<

Also when I optimized in the past, I often broke my code beyond any possibility of repairing. This sucked when I forgot to backup.

u/p2 October 24, 2016, 05:21:20 PM

Thats why I always put lots of comments in my code.
I also always add a section at the bottom of my main file where I put a list of all my thoughts and stuff I want to change later.
Also using this as some kind of changelog for myself so when reading it agian, I remember what I did and why ^^
Maybe doing something similar can help you

u/Yuki October 24, 2016, 06:55:37 PM

Quote from: DJ Omnimaga on September 26, 2016, 07:30:47 AM
This isn't programming-related, but still RPg-related: In one of my custom-made choose-your-own-adventure comic gamebooks, there is a status aliment called Flower of Defecation and a magic spell called Defecation

"(Very stupid status)"

At least you were assuming it.

Quote from: DJ Omnimaga on October 24, 2016, 04:34:30 PM
Also when I optimized in the past, I often broke my code beyond any possibility of repairing. This sucked when I forgot to backup.

This is one of the reasons why version control software such as Git is very useful nowadays.

u/Scipi October 24, 2016, 07:09:53 PM

It wasn't for a serious program, but i had some really weird C code written for the old code golf competitions.

Back in the Game Of Life one, I decided I would write my entry for the GBA. Normally in the GoL, you'd have to implement a swap buffer. The front buffer would hold the previous GoL state while the program used it to build the next state in the back buffer. Then at the end of the frame, the buffers would be flipped and the new front buffer copied to the screen. This all ends up being a good chunk of code. And for Code Golf, that's obviously bad.

However, the GBA has a screen mode which splits video memory into two segments. On any one frame, one segment would be used for drawing the next frame while the other segment is displayed... Sound familiar? So in my GoL entry, I [ab]used video memory to serve as my GoL buffer. I read directly from pixels on the screen for my previous GoL state and read directly to the video backbuffer to generate my next state. Than I simply swap the buffers to increment the GoL sim and to display all in one.

Another weird thing I did was in a previous Code Golf where you had to read your own source file. As part of the program, I needed a concise way to check if I hit the end of the file. Normally, you'd do a comparrison against EOF like so:

Code Select

i = getc(f);
while(i != EOF){
  //...
  i = getc(f);
}

This is waaay too verbose, though. For starters you have to duplicate i = getc(f);!
You can cut it down if you remember that in C, assignments have an implicit return value (so you can do things like a = b = c)
This turned the code into:

Code Select

while((i = getc(f)) != EOF)
//...

Pretty good, right? But still not enough. Precedence rules make it so you have to waste two characters on parenthesis. I also wanted to get rid of the EOF comparison wholesale.
In the C standard, EOF is always -1. So by that, you can always add one to get 0, which is the value for false in C. Unfortunately, because we're changing every character that gets read, we have to revert it when we want to use it.

Code Select

while(i = getc(f)+1) a[i-1]++;

However, this is still an extra 4 characters. I wanted to cut that down even further. It just so happens that -1 is 0xFFFFFFFF. Or all 1's in binary. So all I really needed to do was flip all bits and if the value was -1, it'll become 0. Fortunately, C has a bitwise operator for that: ~. So my final code became:

Code Select

while(i=~getc(f))a[~i]++;