Browsed by
Category: Programming

Your first game

Your first game

Comments 0 Comment

Time for me to shake my fist and tell you darn kids to get off my lawn. Lets set the wayback machine to the 1980’s…

Ralph Koster shares the first video game he ever wrote as well as a great flashback to what almost everyone that wanted to learn to program did back in the 80’s and 90’s. We typed in long programs by hand from books we got at the library and computer magazines. We taught ourselves BASIC and smatterings of assembly. If you were really cool, you even tried to sell your games: which was done by copying them to a floppy, printing a dot-matrix label for it, and trying to sell it in a ziplock baggie.

I started by fiddling around with the programs I typed in to see if I could change them or make them do different things.

My very first video ‘game’ on my TSR-80 consisted of a bunch of black and white dots that would fall down from the top of the screen, and you moved your dot ‘ship’ back and forth to avoid them as the enemies rained down. They came down one at a time. Ridiculously slowly. But it was probably my very first ‘game’.

My second, more ‘real’ game was a castle adventure game. You were the sole heir of a long-lost uncle and had to search his castle to find the deed within 24 hours. It was a text adventure at its heart, but there was opening graphics. I even wrote my own graphics editor with which I drew those opening screens. I believe I still have the graph paper I used.

Anyway, for anyone who learned to program in the 80’s, Koster’s video will tug some familiar heartstrings. For you younger kids, this is how it was done back in the day…

LD_PRELOAD and stealing function calls

LD_PRELOAD and stealing function calls

Comments 0 Comment

There is a clever little trick that one can use for a variety of purposes on Linux. It involves overriding or hijacking function calls. It’s called LD_PRELOAD.

Lets say you create a file called unrandom.c that includes an implementation of the rand() function. It matches the function rand() in standard C.

unrandom.c:
1
2
3
int rand(){
    return 42; //the most random number in the universe
}

We’ll compile it into a shared library.

gcc -shared -fPIC unrandom.c -o unrandom.so

Now… just run a program (my_program) that uses random numbers like this, and you’ll find that the rand function only generates 42.

LD_PRELOAD=$PWD/unrandom.so ./my_program

This trick can be used in a variety of ways. A good write-up can be found here, and is worth a read:

Dynamic linker tricks: Using LD_PRELOAD to cheat, inject features and investigate programs

Vector graphics are back!

Vector graphics are back!

Comments 0 Comment

Remember the arcade game Asteroids or the vector-based Star Wars arcade game? How about the vector-graphics based Vectrix game console?

Say hello to LaserOS. It that allows you build really cool, high quality vector graphics dreams – on real laser projectors. You can build visual laser shows, visualizations, control and create musical compositions, and play some great old games.

Here’s a developer that re-created Asteroids with a high-quality laser system (bonus points for talking about the difficulty of the traveling salesman problem):

Here’s one reviewer giving LaserOS a go on his laser projector:

Kernel compiling and the PIC mode error

Kernel compiling and the PIC mode error

Comments 0 Comment

If you see this when compiling an Ubuntu or other kernel (my case was a Yocto kernel on an Ubuntu 17.04 distro)

...
CHK include/generated/uapi/linux/version.h
CHK include/generated/utsrelease.h
CC scripts/mod/empty.o
/usr/src/linux-4.4/scripts/mod/empty.c:1:0: error: code model kernel does not support PIC mode
/* empty file to figure out endianness / word size */

 

Then the issue is with your gcc installation. In gcc 6+ versions, PIE (position independent executables) is enabled by default. So in order to compile you need to disable it. Even gcc 5 has the issue. This is a known bug for gcc. Bug Link.

So far there is no official patch from gcc side, so the workaround is to patch the Makefile of kernel source.

If you are familiar with patching the source file use the codes from this link to create the patch file then try to compile.Patch File

Here’s the patch to add to your kernel Makefile to disable PIE compiling.

diff –git a/Makefile b/Makefile
index 5c18baa..e342473 100644
— a/Makefile
+++ b/Makefile
@@ -612,6 +612,12 @@ endif # $(dot-config)
# Defaults to vmlinux, but the arch makefile usually adds further targets
all: vmlinux

+# force no-pie for distro compilers that enable pie by default
+KBUILD_CFLAGS += $(call cc-option, -fno-pie)
+KBUILD_CFLAGS += $(call cc-option, -no-pie)
+KBUILD_AFLAGS += $(call cc-option, -fno-pie)
+KBUILD_CPPFLAGS += $(call cc-option, -fno-pie)

# The arch Makefile can set ARCH_{CPP,A,C}FLAGS to override the default
# values of the respective KBUILD_* variables
ARCH_CPPFLAGS :=

 

Auto generating game engines

Auto generating game engines

Comments 0 Comment

 

Game studios and enthusiasts may soon have a new tool at their disposal to speed up game development and experiment with different styles of play. Georgia Institute of Technology researchers have developed a new approach using an artificial intelligence to learn a complete game engine.

Their AI system watches less than two minutes of gameplay video and then builds its own model of how the game operates by studying the frames and making predictions of future events, such as what path a character will choose or how enemies might react.

Learn more here:
https://gvu.gatech.edu/ai-uses-less-two-minutes-videogame-footage-recreate-game-engine

 

YOLO!

YOLO!

Comments 0 Comment

YOLO is a real-time object detection system. On a Titan X it processes images at 40-90 FPS, and it has a pretty nifty demo reel too. 🙂

Gradient Descent using Flocking algorithms

Gradient Descent using Flocking algorithms

Comments 0 Comment

One of the key mathematical foundations of machine learning is using gradient descent to find maxima and minima in a multi-dimensional data set. Gradient descent is good, but getting the most out of it can sometimes leave you wringing your hands or doing a lot of painful mathematical investigation and analysis. Investigations that can quickly tax even a mathematics major.

Sergui Puscas shows us a different, more intuitive way to find maxima and minima by using swarming and flocking techniques. It’s a pretty fun read.

Tanya’s plan to avoid the fallacies of crunching and bad work habits

Tanya’s plan to avoid the fallacies of crunching and bad work habits

Comments 0 Comment

Tanya Short gave one of the best talks I’ve heard in a long time about the fallacies of crunching and bad work habits many people have. The video is now up for free at the GDCVault. Her talk starts at 6:00 :
http://gdcvault.com/play/1024174/Indie

Summary of her points:

When trying to hit deadlines, she starts out by observing that most of the time we think ‘getting X done’ is our highest priority. It’s not. It’s actually #3:

Your real priorities:

  1. Don’t burn out (i.e. don’t die)
  2. Always keep in mind you’re going to do another – and you should be excited to do the next one even better.
  3. Get it done

That sounds great, but it also sounds a bit idealistic. She says it is not easy, but lays out these points.

Step-by-step roadmap to not dying:

  1. Believe it is possible to hold those priorities in that order
    Many great studios work and ship games without crunch. It can be done, she does it. You just have to be disciplined.
  2. Stop working ‘all the time’. Set work hours.
    It is a fallacy to think working all the time is better. Especially in creative fields. Creative work and creative problem solving require a relaxed mind to do it. Time away from work helps us be more productive. So set work hours and stick to them.
  3. Prioritize your tasks and re-prioritize as often as needed.
    In order to hit your deadlines, you need to know what you’re working on RIGHT NOW is important, not just urgent. If you focus just on the ‘urgent’ emails/tasks/etc, then you’ll never get into the steady workflow that is what makes your work great.
  4. Estimate your tasks. Re-estimate when needed.
    When you finish your task, ask if it took the time you thought it would take. You should do that with every task. It helps you get better at estimating.
  5. Cut the scope before you bleed out.
    If you’re 3 weeks out and realize you won’t make it, don’t immediately think about working more/harder/longer. 3 or more 60 hour weeks is scientifically less productive than 3 or more weeks of 40 hour weeks. You are doing worse work. Even if you think you are a special exception. Why can she say that? A study was done on 100 people that claimed they needed less than 7 hours of sleep. Only 5 out of the 100 could actually do it.
  6. Don’t give up – iterate steps 1-5 again and again
    These steps (production) is a skill. Skills can be developed. Skill development requires practice. So congratulate yourself when you do it pretty well, forgive and be kind to yourself when you don’t treat yourself as you deserve.
    We are primates. Primates need to be taken care of in a way computers and games don’t, so don’t act like that towards yourself. It’s not about how many hours you spend because everyone is different.

Other quotables:
A few long nights won’t kill you, but a few long months might. Especially if combined with other health and life factors.

Burnout is the feeling of being dulled as layer after layer of exhaustion accumulates. Burnout is the void left behind where your career could have been.

Then she has a real Benedictine moment: The moment right now will never come again. Every one of us will die. No matter what we create, all we have is right now. Don’t use up that joy, love, and creative energy you have by burning yourself out.

Keep death always before your eyes.
—St. Benedict: The Rules: Chapter 4.47


She doesn’t cite the studies, but I found some:
http://lifehacker.com/working-over-40-hours-a-week-makes-you-less-productive-1725646811