After a month of stagnation on my Tower Defense game, I implemented some cool stuff yesterday and today. Mainly a makeshift main menu and flashy animated text messages popping up.

Just a moment ago I started a Sourceforge.net project for it. Pretty neat! I appreciate that Sourceforge supports bazaar version control, and I do not yet know if I will discontinue the launchpad branch or keep it updated. Keeping it updated would be no big deal if I only bothered to write a proper ‘bzr push’ alias for both Sourceforge and Launchpad.

There is a source release of version 0.4 available. Binary releases for Windows will pop up soon (I am pretty sure I know how to do it properly!)[Update: Windows version available]. Please note that the game is not balanced at all and not near complete. Consider it alpha-stage.  However, it allows for an initial impression and I would be grateful for any feedback! A more rounded-up release is planned for next week

Python is a programming language that I learnt somewhat recently (something like 2, 3 years ago) and that I like very much. It is simple, to the point, and has several functional-like constructs that I am already familiar with. But Python is slow compared to other programming languages. But it was unclear to me just how slow Python was compared to other languages. It just felt slow.

So I have decided to investigate by comparing the implementation of a simple, compute-bound problem, the eight queens puzzle generalized to any board dimensions. This puzzle is most easily solved using, as Dijkstra did, a depth-first backtracking program, using bitmaps to test rapidly whether or not a square is free of attack¹. I implemented the same program in C++, Python, and Bash, and got help from friends for the C# and Java versions². I then compared the resulting speeds.

The eight queens puzzle consist in finding a way to place 8 queens on a 8×8 chessboard so that none of the queen checks another queen. By “checking”, we mean that if the other queen was of the opposing camp, you could capture it if it were your turn to play. So this means that no queen is on the same row, column, or diagonal as another queen. Using a real chessboard and pawns in lieu of queens, you can easily find a solution in a few seconds. Now, to make things more interesting, we might be interested in enumerating all solutions (and, for the time being, neglecting to check if a solution is a rotated or mirrored version of another solution).

The basic algorithm to solve the Eight queens puzzle is a relatively simple recursive algorithm. First, we place a queen somewhere on the first row and we mark the row it occupies as menaced. We also do so with the column and two diagonals. We then try to place a second queen somewhere on the second row, on a square that is menace-free, and mark the row, column, and diagonals of the new queen as menaced. And we proceed in the same fashion for other queens. But suppose that at the th stage, we cannot find a menace-free square, preventing us from placing the th queen. If the situation arises, we give up for the th queen and backtrack to the th queen. We try a new (and never tried before) location for the th queen and we go forth trying to place the th queen. If may happen that we go all the way back to the th queen because there are no other solutions for the th queen, which asks for the th queen to be moved, which can also result in a dead-end; and so forth all the way down to the th queen.

Because the algorithm proceeds depth-first and can rear back quite a bit in looking for new solutions, it is called a backtracking algorithm. Backtracking algorithms are key to many artificial intelligence systems like, well, chess programs.

So I wrote the program for the queens puzzle for a board in C quite sometime ago (circa 1995), then I ported to C++ recently (2006). And just for kicks, I decided to port it to different languages, with help from friends for Java and C# (of which I know about zilch). The C++ versions consist in a generic version that accepts the board size as a command-line argument and in a constant-propagated version where the board size is determined at compile-time. The Python versions, as there are two of them also, differ on how python-esque they are. The first variant is a rather literal translation of the C++ program. The second uses pythonesque idioms such as sets rather than bitmaps and turns out to be quite a bit faster—about 40% faster in fact. The Bash version is necessarily rather bash-esque as Bash does not offer anything much more sophisticated than arrays in terms of data structures.

All implementations were compiled with all optimizations enabled (-O3, inlining, interprocedural optimizations, etc.). For C++, I used g++ 4.2.4, for C#, gmcs 1.2.6.0, for Java, gcj 4.2.4, Python 2.6.2, and, finally, Bash 3.2.39—all latest versions for Ubuntu 8.04 LTS, which doesn’t means that they’re the really latest versions.

So I ran all seven implementations with boards sizes ranging from 1 to 15 on a AMD64 4000+ CPU (the numbers are arbitrary; I wanted to get good data but also limit the CPU time spent as the time increases factorially in board size!). At first, the results are not very informative:

Results, Time, Linear Scale

As expected, all times shoot up quite fast, with, unsurprisingly, BASH shooting up faster, followed by the two Python implementations. At this scale, Java, C#, C++, C++-fixed (the constant-propagated version) all seems to be more or less similar. To remove the factorial growth (as even with a log plot the data remains rather unclear), I scaled all performances relative to the C++ version. The C++ version is therefore 1.0 regardless of actual run-time; for board size , the time needed by Bash, for example, was divided by the time needed by C++ for board size . We now get:

Speed Ratio, Linear Scale

We can use a log-scale for the axis to better separate the similar results:

Speed Ratio, Log Scale

We see three very strange things. The first is Bash shooting up wildly. The second is that C# relative time goes down with the increasing board size. The third is that before , the results are fluctuating. The first is easily explained: Bash is incredibly slow. About 10,000 times as slow as the optimized compiled C++ version. It is so slow that the two last data points are estimated as it would have taken an extra week, or so, to get them. The second anomaly needs a bit more analysis. Looking at the raw timing data, we can see that the C# version seems to be needing an extra 7ms regardless of board size. I do not know where that comes from, as the timings do not time things such as program load and initialization, but only the solving of the puzzle itself. It may well be the JIT that takes a while to figure out that the recursive function is expensive and the run-time compilation takes 7ms? Anyway, would we remove this mysterious extra 7ms, the odd behaviour of the C# implementation would vanish. The third anomaly is easily explained by the granularity of the timer and the operating system; up to puzzle size of 8, the times are much less than 100 μs for most implementations. Suffice to move the mouse and generate a couple of interrupts to throw timing off considerably.

Removing the small board sizes yields:

Speed Ratios, Log Scale, Without Outliers

which shows that the respective implementations are well behaved (except for C# and its most probably JIT-related extra 7ms).

So we see that Bash is about 10,000 times slower than the optimized C++ version. The constant-propagated version is only a bit (~5%) faster than the generic C++ version. The Java version takes about 1.5× the time of the C++ version, which is way better than I expected—don’t forget that this is a native-code version of the Java program, it doesn’t run on the JVM. The C# version is twice as slow as the C++ version, which is somewhat disappointing but not terribly so. The Python versions are 120× (for the more pythonesque version) and 200× slower. That’s unacceptably slow, especially that the Python programs aren’t particularly fancy nor complex. We do see that using pythonesque idioms yields a nice performance improvement—40%—but that’s still nowhere useful.

*
* *

So what does this tell us? For one thing, that Bash is slow. But that Bash is slow even when it doesn’t use any external command should not come as a surprise. From what I understand from Bash, data structures are limited to strings and arrays. Lists and strings are the same. Basically, a list is merely a string with items separated by the IFS character(s), which causes all array-like accesses to lists to be performed in linear time as each time the string is reinterpreted given the current IFS. So even though a construct such as ${x[i]} looks like random-access, it is not. As for explicitly constructed arrays (as opposed to lists), there seems to be a real random-access capability, but it’s still very slow. I do not think that bash uses something like a virtual machine and an internal tokenizer to speed up script interpretation. Maybe that’d be something to put on the to-do list for Bash 5? In any case, I also learnt that Bash is a lot more generic than I thought.

The other thing is that Python is not a programming language for compute-bound problems. This makes me question how far projects such as Pygame (which aims at developing a cromulent gaming framework for Python) can go. While all of the graphics and sound processing can be off-loaded to third party libraries written in C or assembly language and interacting with the platform-specific drivers, the central problem of driving the game itself remains complete. How do you provide strong non-player characters/opponents when everything is 100× slower than the equivalent C or C++ program? What about strategy games? How can you build a MMORPG with a Python engine? Is a MMORPG I/O or compute bound? Could you write a championship-grade chess engine in Python?

My guess is that you just can’t.

And that’s quite sad because I like Python as a programming language. I used it in a number of (I/O-bound) mini-projects and I was each time delighted with the ease of coding compared to C or C++ (for those specific tasks). It pains me that Python is just too slow to be of any use whatsoever in scientific/high-performance computing. I wish for Python 4 to have a new virtual machine and interpreter to bring Python back with Java and C#, performance-wise. Better yet, why not have a true native compiler like gcj for Python?

*
* *

I am fully aware that the queens on a board puzzle is a toy problem of sorts. But its extreme simplicity and its somewhat universal backtracking structure makes it an especially adequate toy problem. If a language can’t handle such a simple problem very well, how can we expect it to be able to scale to much more complex problems like, say, a championship-level chess engine?

*
* *

The raw data (do not forget that the two last timings for Bash are estimated). All times are in seconds.

The More Pythonesque version:

#!/usr/bin/python -O
# -*- coding: utf-8 -*-

import sys
import time

########################################
##
##   (c) 2009 Steven Pigeon (pythonesque version)
##

diag45=set()
diag135=set()
cols=set()
solutions=0

########################################
##
## Marks occupancy
##
def mark(k,j):
    global cols, diag45, diag135
    cols.add(j);
    diag135.add(j+k)
    diag45.add(32+j-k)

########################################
##
## unmarks occupancy
##
def unmark(k,j):
    global cols, diag45, diag135
    cols.remove(j);
    diag135.remove(j+k)
    diag45.remove(32+j-k)

########################################
##
## Tests if a square is menaced
##
def test(k,j):
    global cols, diag45, diag135
    return not((j in cols) or \
        ((j+k) in diag135) or \
        ((32+j-k) in diag45))

########################################
##
## Backtracking solver
##
def solve( niv, dx ):
    global solutions, nodes
    if niv > 0 :
        for i in xrange(0,dx):
            if test(niv,i) == True:
                mark ( niv, i )
                solve( niv-1, dx)
                unmark ( niv, i )
    else:
        for i in xrange(0,dx):
            if (test(0,i) == True):
                solutions += 1

########################################
##
## usage message
##
def usage( progname ):
    print "usage: ", progname, " <size>"
    print "size must be 1..32"

########################################
##
## c/c++-style main function
##
def main():
    if len(sys.argv) < 2:
        usage(sys.argv[0])
    else:
        try:
            size = int(sys.argv[1])
        except:
            usage(sys.argv[0])
            return

        if (size <= 32) & (size>0):

            start = time.time()
            solve(size-1,size)
            elapsed = time.time()-start

            print "%s %0.6f" % (solutions,elapsed)

        else:
            usage(sys.argv[0])
#
if __name__ == "__main__":
    main()

The other versions can be found here in super_reines.zip. The Bash and C++ versions are somewhat Linux-specific.

² Frédéric Marceau translated the program from C++ to C#. François-Denis Gonthier translated from C++ to Java.

*
* *

So I added a third Python version to the archive. I also benchmarked it. It is quite a bit faster than the original one, and even than the ‘pythonesque’ version. For example:

$ super-reines.py 12
14200 15.966019
$ super-reines-2.py 12
14200 9.478235
$ super-reines-3.py 12
14200 6.845071

So a more ‘functional’ version performs about 2.3× faster than a direct translation from C++. For the same problem size, however, the C++ (fixed) version takes 0.069s… Roughly 100× faster than the 3rd version.

Speed Ratios, Log Scale, Without Outliers, with 3rd Python version

MicroWar 2.0rc3 Pierre-Alain Dorange | MadDog Production 음악: Louis Jullien, Justin D. Davis

매년 바뀌는 PC 시장과 싸우는 인베이더 스타일 게임. (via MOONGIFT)

Colaboração: Ricardo Takemura

Para quem gosta de Python e jogos, existe um framework para desenvolvimento
de jogos em Python chamado Pygame (http://www.pygame.org/news.html).

O jogo mais famoso feito por esta plataforma é o [Frets On Fire
http://fretsonfire.sourceforge.net/].

Fonte: Dicas-L

Here’s a simple example of a game screen written in Python and Pygame.

import pygame

from pygame.locals import *

def main():
    # I'm initializing the game's screen.
    pygame.display.init()

    # I set the width and the height of the screen.
    screen = pygame.display.set_mode((300, 200))

    # I'm setting the title of the game's screen.
    pygame.display.set_caption("The game's title")

    # I want to hide the mouse when It over the game's screen.
    pygame.mouse.set_visible(0)

    running = True
    while running:
        for event in pygame.event.get():
            if event.type == QUIT:
                running = False

if __name__ == "__main__":
    main()

Cheers

Got a quick chunk of time to play around with this again.  The minimap is now working properly, and that memory fix I talked about is now in.  The tileset may also have been tweaked, I’m not sure on that one.  Grab it here!

Olá pessoal,

continuando a série de posts sobre desenvolvimento de jogos, hoje vou falar sobre a instalação do Python + pygame e quais ferramentas utilizar.

Instalando o Python + pygame

Os usuários do Windows, devem baixar o instalador do Python em http://www.python.org/download e executá-lo. Eu aconselho a versão 2.6.3. Depois devem baixar o instalador do pygame em http://www.pygame.org/download.shtml correspondente a versão do Python escolhido anteriormente. O processo é bem simples, não passa de um NNF (Next-Next-Finish).

Para os usuários do Ubuntu, basta executar no shell o comando:

sudo apt-get install python-pygame

Qual editor ou IDE utilizar?

Várias opções estão listadas no site do PythonBrasil.

Eu aconselho utilizar um editor de texto simples com suporte a syntax highlight, ao invés de uma IDE pesada e cheia de recursos que, creio, não iremos precisar. Usuários do Windows podem utilizar o ótimo Notepad++ ou um similar. No Linux, o Gedit, o Kate ou até mesmo o Vim são muito bem-vindos. Eu, pessoalmente, vou utilizar o E-TextEditor que é um editor extremamente poderoso baseado no TextMate. Originalmente desenvolvido para o Windows, o E-TextEditor possui o código-fonte disponível no Github para quem quiser se aventurar, como eu, a compilá-lo no Linux.

Nosso primeiro programa com o pygame

Salve o código a seguir em um arquivo chamado jogo.py.

# importa as bibliotecas necessarias
import sys, pygame

# inicia o pygame
pygame.init()

# define o tamanho da tela
screen_size = (400, 300)

# define as cores utilizadas
white = (255, 255, 255)
black = (0, 0, 0)

# cria a tela com o tamanho especificado e seta o titulo da mesma
screen = pygame.display.set_mode(screen_size)
pygame.display.set_caption("Primeiro Programa")

# obtem uma fonte de tamanho 30. Nesse caso, usa a default do sistema
font = pygame.font.Font(None, 30)

# renderiza um texto.
# o segundo parametro especifica se deve utilizar antialias
# o terceiro e o quarto sao a cor do texto e a cor do fundo
text = font.render("Primeiro programa com pygame!", True, white, black)

# obtem o quadrante do texto, ou seja, a area do mesmo
text_rect = text.get_rect()

# posiciona a area do texto no centro da tela
text_rect.centerx = screen.get_rect().centerx
text_rect.centery = screen.get_rect().centery

# desenha o texto na tela
screen.blit(text, text_rect)

# atualiza a tela exibindo o texto
pygame.display.update()

while True:
  # itera no pool de eventos capturados
  for event in pygame.event.get():
    # se a janela for fechada, finaliza o programa
    if event.type == pygame.QUIT:
      sys.exit()

Depois basta executar na linha de comando:

python jogo.py

O resultado é esse:

Enfim, finalmente começamos a colocar a mão na massa. Creio que o exemplo é bem simples e claro, por isso não irei entrar em detalhes agora.

No próximo post, iremos discutir as principais técnicas de Game Loop e criar a estrutura básica de nosso jogo.

Yet again, it’s been a while since I wrote here. I apologize for being so irregular – but at least I’m considerbly better at regular microblogging. Social Media rocks!

So, my current software project is a Tower Defense-game. It’s actually my project for the Gymnaisum (Swedish) course PA1201 (the purpose of which is to do a major project). The scope of the course is 100 hours of dedicated school-time (ending in spring), so this is a serious project.  I have already spent countless of hours on it, and the current version can be found here (revision 35 at the time of writing).

I’d love all sorts of feedback. Unfortunately, it’s slightly messy to get it to work right now. First off you need the version control system Bazaar to fetch the game from launchpad (by typing “bzr branch lp:~baxemyr/+junk/towerdefense” in a command line), and then you need python and pygame installed to play the game.

Besides, it is barely worth the trouble right now due to the small amount of content — even though the game itself is shaping upnicely! Nonetheless, feedback is warmly appreciated (user interface design, feature requests and anything else you can think of)!

I’m planning for a proper demo release later this year, to maximize feedback reception before it’s too late. Hopefully with compiled windows executables etc so that you won’t need to install anything!

Rather recently I learned about a handy little program called Valgrind. I get to use it to debug some C++ code that works with dynamic memory to fix any leaks that occurred. As it turns out, this program can do a lot more.

Something I’ve noticed for a while now is that Graff takes up a pretty significant amount of memory–around 40 megabytes of RAM. I never really thought about it too hard until now, but I discovered that with the command:

valgrind --tool=massif python Start.py
...
ms_print massif.out.** > output

it takes snapshots of Graff’s memory usage. The first time running this and opening up “output” gives this result:

So currently I get ~43MB usage of the heap (or in python terms, plain memory) by just opening up the program and running around. Later in that output file, I notice a lot of calls to “SDL_CreateRGBSurface (in /usr/lib/libSDL-1.2.so.0.11.2)” seem to be eating up the most memory percentage-wise.

Doing some digging, I find out pygame converts images into a .RAW format for fast blitting–unfortunately, the file size is pretty hefty. Looking through my code, I notice that within Entity.py, when an entity is initialized, it loads up a file called “tiles.png” to pull the entity’s picture out of that and use it. After that, that loaded image is just kept there, permanently until the program quits. Tiles.png is only 42.3KB, though, which seems a little weird.

I decide to see just how many times entity loads up this image and stores it away forever. It turns out that this file is being loaded around 200 times, and is then saved as a member variable “self.sheet”. Since we don’t need it anymore once the entity’s image is ripped out of that sprite sheet, I decide to add one extra line to my code:

delete self.sheet

, after the entity’s image is set. What does that memory chart look like now?

15.64 MB is now used. By adding one extra line of code to delete an unused part of the code, I cut memory usage by 2/3!

Tinkering around some more, I find the pygame init routines take up a total of about 5MB, which means the code portion that I wrote takes up about 10MB of RAM. Perhaps now I’ll start paying attention to where memory ends up in Graff.

In my last post about this map-making process, I seemed to have left off at the part where the image itself is generated in its own separate program. Converting this image into a matrix for use in Graff was relatively straightforward. Pygame’s surfarray module allows one to access a surface (the screen) and treat it as a matrix of color values. From there I pulled out the color, used a dict datatype to convert that color into a tile type, and then write that into a matrix for use with the Graff; that wasn’t much of a problem.

However, one glitch I’ve noticed is that often the map would have some holes in it–it seemed like the algorithm would skip over a tile, perhaps because it couldn’t find a properly-fitting tile, so sometimes you get things that looked like this:

As it turns out, that was the case. I simply did not make enough tiles to cover each possible combination. After thinking that I’d have to make a mind-boggling number of additions to the 6×6 tile pieces I already have, I edited the code so that if the tile it needed could not be found, it should spit out that key combination and then I’d see where that would take me. Altogether, only about 30 “impossible” combinations of tiles ever seemed to come up, so I just added those extra ones onto the tileset.

After doing that, the results are much cleaner. Some glitches still remain (mainly I missed a few combinations, it seems), and I’ll probably adapt this to work with a smaller scale (say 3×3 instead of 6×6) or make changes to it to develop other areas, but I think I’ve just about exhausted the usefulness of posting about this process.

Oh, there is also the problem of the map not always being one complete piece. I still haven’t decided in what way I’ll solve that one yet, but there are some more interesting questions about Graff that I think I need to find an answer to first.

Right off the bat, let me be clear, we’re talking Python the programming language here, not Python the snake.  While not impossible, it is highly unlikely you’ll see me talking about playing with a snake.

So, I’m gonna get python installed and check out some comparisons between pygame and pyglet.  They are a couple of libraries intended to provide some of the constructs needed for game development.  I’ve used pygame before, but that was a couple of years ago.  I want to make sure that it is still a viable choice of api before I jump back into using it.

After I get them installed, I’m gonna try to put together a few simple games with it.  Python is not my language of choice by any means (C# has that title), but I do like it quite a bit.

The plan is to make the choice and have the chosen platform installed within the next 2 days or so.  And from there, I’ll get down to the business of deciding what little game(s) I’m gonna make and get some posting done on my progress.

dasclient early alpha screenshot

Originally uploaded by dasp0rk

Just a little look at what I have going on the client so far. The widgets are part of a UI library that I have updated and developed for years called clad. I have only used it for my own projects, but it’s pretty nice if I do say so myself. The life/mana/stamina bars are all custom widgets derived from the base widgets of clad and fully functional (even the text entry!). The four blue squares are the beginnings of re-programmable hotkeys/aliases. I have no plan to support the mouse with the client. I don’t see any reason to personally as re-mappable keys could surely do just as good a job, and the code required to do very complicated operations is much lighter. More updates to come if this can hold my interest.

Release here!

This’ll probably be the last update for a few weeks. Trying to go back to Python after spending a few weeks of working with C++ feels so..different. I might switch this project over to C++ if I get equated well enough with it, or maybe I’ll just start working on a C++ project instead and keep this around too. Busy busy busy. Either way, more activity will come in December or so.

The only glitch I’ve noticed with this release is the minimap is a little screwy. I know why it doesn’t work, but if I hold off on this until I fix it, it’ll be even longer before this post comes up.

CHANGES:
   Added a (barebones) title screen.
   Custom keybindings via title screen.
   Added “Key” py file and an ini file for manual editing if need be.
   Digging function cleaned up somewhat.
   Integrated new map generator.
      A fully glitch-free version is finished, I just need to update it.
   Changed scrolling/grass behaviors for more natural movement.
   Automatic screenshots placed in the Screenshots directory. Use the SCROLL LOCK key.

Additionally on that page under Misc, I’ve added in a dialog.py / dialog.txt file to show how my dialogue system will hopefully work. Run it through the terminal

I’m thinking about picking up an old project again. For a while I was enjoying playing MUDs. I often wondered why there had never really been a hybrid MUD out there. Something not graphical really, but with just a GUI. I have already made some headway on a client that will work on any platform that has the ability to use python and pygame. The client can even be packaged with all the dependencies needed to play it.

The server portion of the game is the hard part. I have had a little luck with NakedMud, and also modifying the last and most up to date version of Circle.

The type of game I really want to make would be similar to classic Everquest. I had a lot of fun with that game and think it could be captured in this way.

More to come.

Seid Ihr zum ersten mal hier, dann startet Ihr am besten mit Part 1.

Moin moin und willkommen zum dritten Part dieses Tutorials. In den ersten beiden Parts haben wir die Pygame-Segel gesetzt, nun geht es etwas schneller voran. Diesmal erobern wir mit unserem Tutorial-Kutter das OpenGL-Meer. Am Ende dieses Parts wird endlich etwas zu sehen sein, und zwar: Ein Viereck!

Damit wir die OpenGL-Schnittstelle nutzen können, importieren wir die PyOpenGL-Module. GL stellt einerseits OpenGL-Funktionen bereit, die mit gl beginnen (Beispiel: glVertex()) und andererseits Konstanten, die mit GL_ beginnen (Beispiel: GL_QUADS).
Mit GLU (GL Utility Library) werden weitere hilfreiche Funktionen und Konstanten nach dem gleichen Präfixmuster importiert (Beispiele: gluScaleImage, GLU_FILL).

from OpenGL.GL import *
from OpenGL.GLU import *

Als nächstes definieren wir eine Funktion namens reshape(), die jedesmal aufgerufen werden soll, wenn das Fenster neu angezeigt wird, oder die Fenstergröße verändert wird.
glViewport legt dabei ein Rechteck fest, in dessen Bereich wir unsere Vierecke zeichnen wollen. Es erstreckt sich von unten links (0,0) bis oben rechts (width,height, also 800,600).
Die Zeilen 3-6 beschäftigen sich mit Matrizen. Dazu mehr im nächsten Part.

def reshape((width,height)):
    glViewport(0, 0, width, height)
    glMatrixMode(GL_PROJECTION)
    glLoadIdentity()
    gluPerspective(60, 1.0*width/height, 0.1, 1000.0)
    glMatrixMode(GL_MODELVIEW)

Nun definieren wir eine init() Funktion, die zu Beginn des Programms aufgerufen wird und einige Eigenschaften unserer OpenGL-Umgebung festlegt. glClearColor legt eine weiße Hintergrundfarbe fest und erwartet dabei 4 Parameter: Rot-, Grün- und Blau-Anteil sowie den Alphawert.
Außerdem wird hier unsere reshape()-Funktion zum ersten mal aufgerufen.

def init():
    glClearColor(1.0, 1.0, 1.0, 1.0)
    reshape(screen)

Später im Tutorial fügen wir hier noch weitere OpenGL-Funktionen hinzu. Gleich gehts ans Zeichnen, aber zunächst ein wenig OpenGL-Vokabular:

Primitive
Primitives sind geometrische Grundformen, wie zum Beispiel Punkte, Linien oder Polygone. Diese lassen sich zusammensetzen und ergeben dann komplexere geometrische Formen.

Vertex
Ein Vertex (Plural: Vertices) ist ein Eckpunkt eines Primitives, dessen Position mit Koordinaten festgelegt wird. In OpenGL können mindestens zwei Koordinaten (X,Y) und maximal drei Koordinaten (X,Y,Z,W) angegeben werden, wobei X,Y und Z die 3D-Koordinaten sind. W findet hier zunächst keine Beachtung. Bei 2D-Darstellungen ist die Z-Koordinate immer 0.

Polygon
Ein Polygon ist eine aus mindestens drei Vertices bestehendes Vieleck. Das einfachste Polygon ist das Dreieck

Gentlemen, take your Bleistifts, das Malen kann beginnen. Zunächst definieren wir eine draw-Funktion. In dieser wird zunächst der Bildschirm geleert und mit der oben definierten Hintergrundfarbe (weiß) gefüllt.

def draw():
    glClear(GL_COLOR_BUFFER_BIT|GL_DEPTH_BUFFER_BIT)
    ...

Die draw-Funktion geht noch weiter. In OpenGL gibt es eine “virtuelle Kamera”, die aufnimmt, was später am Bildschirm zu sehen ist. Mit gluLookAt können wir Position und Ausrichtung (orientation) dieser Kamera bestimmen. Die ersten drei Parameter (0, 0, 6) bestimmen die Koordinaten der Position, also 6 Einheiten die Z-Achse entlang (Richtung Betrachter). Wir gehen mit der Kamera also im Prinzip 6 “Schritte” zurück, damit wir etwas sehen.

Die nächsten drei Parameter (0, 0, -100) bestimmen die Koordinaten eines Punktes, auf den die Kamera gerichtet sein soll. In unserem Fall ein negativer Wert auf der Z-Achse (in den Bildschirm hinein). Die letzten drei Parameter (0, 1, 0) bestimmen, wo oben ist. Hier also die Y-Achse gerade nach oben.
Die Funktion glLoadIdentity() wird aufgerufen, um die Einheitsmatrix (identity matrix) zu laden. Somit wird bestimmt, dass die nachfolgende Funktion vom Ursprung des Koordinatensystems (0,0,0) ausgehen soll.

    ...
    glLoadIdentity()
    gluLookAt(0, 0, 6, 0, 0, -100, 0, 1 ,0)
    ...

Jetzt zeichnen wir die ersten Primitives. Innerhalb von glBegin(GL_QUADS) und glEnd() bestimmen wir die Vertices unseres Vierecks (Quads). glBegin erwartet als Parameter den Typen des Primitives. Zum Beispiel GL_POLYGON für Polygone oder GL_QUADS für Vierecke. Es existiert eine sehr gute vollständige Liste der Primitive-Typen (inkl. Erläuterungen) im Wiki der Delphi-OpenGL-Community.

Als Nächstes bestimmen wir blau (0.0, 0.0, 1.0) als Füllfarbe. Anschließend werden nacheinander die vier Vertices des ersten Vierecks bestimmt. glVertex2f erwartet dabei die X,Y Koordinaten eines Vertex als Parameter.

Später werden wir sehen, dass es effektivere Möglichkeiten gibt, Primitives zu zeichnen. Zum Beispiel Vertex-Arrays. Aber zu Beginn ist es so in Ordnung. Wir wollen ja nur ein Viereck darstellen.

    ...
    glBegin(GL_QUADS)
    glColor(0, 0, 1.0)
    glVertex2f(-2, 2)  # oben links
    glVertex2f(2, 2)   # oben rechts
    glVertex2f(2, -1)  # unten rechts
    glVertex2f(-2, -1) # unten links
    glEnd()   

    pygame.display.flip()

pygame.display.flip() bewirkt einen OpenGL Buffer Swap. Dazu später mehr, wenn es zu Bewegtbildern kommt. Zunächst genügt die Erklärung, dass diese Funktion den Bildschirminhalt aktualisiert.

An dieser Stelle ein kleiner Einschub zum Thema OpenGL-Syntax. Der Funktionsname glVertex2f sieht ja schon etwas eigenartig aus. Die Erklärung ist allerdings recht simpel. Das angehängte 2f bedeutet, dass die Funktion 2 Parameter (X,Y Koordinaten) des OpenGL-Datentyps float erwartet. Es gibt von vielen OpenGL Funktionen verschiedene Versionen (zum Beispiel glVertex3f, glVertex4i, …).

Nun rufen wir die draw-Funktion innerhalb unseres main loops auf. Das bewirkt, dass das Bild mit jedem Schleifendurchlauf einmal aktualisiert wird. Das macht bisher noch nicht soviel Sinn, aber wenn später Bewegung ins Spiel kommt, ist es unverzichtbar.

def main():
    init()
    maxfps = 100
    clock = pygame.time.Clock()
    while True:
        clock.tick(maxfps)
        draw()
        get_event()

if __name__ == "__main__":
    main()

So sieht unser Ergebnis aus, wenn wir das Programm ausführen:

Tutorial Part 3 - Ergebnis

Der vollständige Quellcode zum dritten Tutorial-Part (ausgelagert)

Well, here’s some lafootgiri I’ve been upto.
I had been trying out some pygame and I made this image. It’s actually a screenshot of an animation that my code generates.

The number of lines actually keep reducing, and the density of the mesh keeps going down.

I showed Chaitu this code, and he suggested me to write code for an interesting problem, that was in H C Verma.

Three motorists, are travelling at a constant speed, each one moving towards the guy on his right.

I wrote code that takes any value of n as input and shows the motorists moving.
I’m having fun!
Pygame Rocks!

Seid Ihr zum ersten mal hier, dann startet Ihr am besten mit Part 1.

Ziel von Part 2 ist das simple Anzeigen eines Pygame-Fensters und die Möglichkeit dieses wieder zu schließen.

Zunächst importieren wir das Pygame-Paket und alle seine Untermodule (z.B. pygame.display, pygame.sound, …), sowie die exit-Funktion aus dem sys-Modul.

import pygame
from sys import exit

Hier wird die Auflösung des Fensters in einem Tupel als Variable screen gespeichert:

screen = (800,600)

In folgender Zeile werden alle Untermodule von pygame initialisiert:

pygame.init()

Die Funktion im folgenden Code-Abschnitt erstellt eine Pygame-Oberfläche und erwartet drei Parameter, von denen die letzten beiden optional sind. Der erste Parameter bestimmt die Auflösung (Variable screen). Im zweiten (optionalen) Parameter legen wir Flags fest, die bestimmen, dass eine OpenGL-Oberfläche erstellt werden soll, die einen doppelten Puffer nutzt. Es gibt noch weitere Flags, die zunächst nicht wichtig sind. Der dritte (optionale) Parameter ist die Farbtiefe in Bit.
Die Funktion pygame.display.set_mode gibt ein Oberflächen-Objekt (surface object) zurück, das wir in der Variable surface speichern.

surface = pygame.display.set_mode(screen, pygame.OPENGL|pygame.DOUBLEBUF, 16)

Als nächstes geben wir dem Pygame-Fenster einen Namen, der in der Titelleiste des Fensters erscheint.

pygame.display.set_caption("Hallo Welt!")

Innerhalb der Funktion get_input() werden Events erkannt und bearbeitet. Ein Event kann ein Tastenanschlag auf der Tastatur sein, oder in unserem Beispiel das Klicken auf den Schließen-Button des Fensters.

def get_event():
    for event in pygame.event.get():
        if event.type == pygame.QUIT:
            exit()

Nun benötigen wir den main loop, damit das Fenster sichtbar bleibt. Hier wartet das Programm auf Events. Der Codeabschnitt clock.tick(maxfps) sorgt dafür, dass Frames per Second (FPS) begrenzt werden. Das ist deshalb sinnvoll, um die CPU-Auslastung gering zu halten. Andernfalls würde die Schleife so schnell es geht durchlaufen werden. Später bringen wir hier weitere Dinge unter.

def main():
    maxfps = 100
    clock = pygame.time.Clock()
    while True:
        clock.tick(maxfps)
        get_event()

if __name__ == "__main__":
    main()

Führt man das Programm aus, erscheint ein schwarzes Fenster mit dem Titel “Hallo Welt!”, das quasi danach schreit, gleich wieder geschlossen zu werden Aber keine Angst, im nächsten Part wird es mehr zu sehen geben!

Hier noch einmal der komplette Quellcode aus Part 2 des Tutorials:

import pygame
from sys import exit

screen = (800,600)

pygame.init()
surface = pygame.display.set_mode(screen, pygame.OPENGL|pygame.DOUBLEBUF, 16)
pygame.display.set_caption("Hallo Welt!")

def get_event():
    for event in pygame.event.get():
        if event.type == pygame.QUIT:
            exit()

def main():
    maxfps = 100
    clock = pygame.time.Clock()
    while True:
        clock.tick(maxfps)
        get_event()

if __name__ == "__main__":
    main()

An dieser Stelle startet mein Tutorial zu OpenGL in Pygame. Das Ziel dieses Tutorials ist ein in Python 2.6 geschriebenes Programm, das ein 3D-Objekts darstellt, das sich mit Hilfe eines Gamepads bewegen lässt. Das Hauptaugenmerk liegt dabei auf OpenGL.

Wenn Ihr folgen wollt, solltet ihr bereits Python-Kenntnisse besitzen. Pygame-Kenntnisse sind nicht unbedingt Voraussetzung aber hilfreich, da ich nicht so ausführlich darauf eingehe. OpenGL ist für mich neu und ich versuche beim Schreiben des Tutorials selbst dazuzulernen und setze dementsprechend keine OpenGL-Kenntnisse voraus.

Zunächst ein paar Worte zu OpenGL, PyOpenGL und Pygame:

OpenGL (Open Graphics Library) ist eine Schnittstelle (API) zur Entwicklung von 2D- und 3D-Grafik. Derzeit befindet sich OpenGL in einer Umbruchsphase. Das heißt, viele Befehle aus der mittlerweile 17 Jahre alten API werden ausgemistet, sodass zukünftig weitaus perfomantere Techniken genutzt werden, um anderen APIs – wie zum Beispiel DirectX – wieder Konkurrenz machen zu können. In diesem Tutorial werden allerdings die klassischen Programmiertechniken zum Einsatz kommen, da der Einstieg in die 3D-Programmierung damit in meinen Augen wesentlich verständlicher ist.

PyOpenGL ist ein plattformunabhängiges Python-Binding zu OpenGL. Es ist wie eine Hülle (Wrapper) um OpenGL zu verstehen, die Befehle unter Python zur Verfügung stellt. Version in diesem Tutorial: PyOpenGL 3.0.0 (unterstützt OpenGL 1.1 bis 3.0): http://pyopengl.sourceforge.net

PyGame ist eine Sammlung von Modulen, die vor allem der Spieleentwicklung dienen. Es sind zum Beispiel Module zur Steuerung von Grafik und Sound enthalten, sowie Module zum Abfragen von Eingabegeräte wie Maus, Tastatur oder Gamepad. Version in diesen Tutorial: Pygame 1.8.1: http://www.pygame.org

Pygame stellt also quasi das Grundgerüst unseres Programms dar. Deshalb gehe ich in Part 2 überwiegend auf Pygame ein und lege den Grundstein für das weitere Vorgehen. Später folgen dann die 3D-Animationen in OpenGL.

Ovu igricu sam napravio za natjecanje na DoubleBuffer forumu.
Priča:
U zemlji gdje ništa nije besplatno, pa ni zrak, vi morate ubiti The Mother of Chaos, iliti Majku Kaosa i tako prekinuti njenu tiraniju.

Upute:
Za igranje: Pokrenite “main.exe”
Za kontrole: Pogledajte “readme.txt”

Pygame Stranica
Download Stranica

I’ve spent about 3-4 hours today familiarizing myself to pygame. I wrote a prototype for a wario clone, pario.
Right now, my character can move around ( to the left and to the right ), and he can jump. I never thought game development would be so fun ( yet, difficult ).

I have big plans for my pario

Ovako izgleda kod za našu igru, gdje igrač kontrolira metak, i uništava kutije.
[tab] je jedan pritisak na tiku “Tab”!

import pygame
from pygame.locals import *
import sys

fps = pygame.time.Clock()
pygame.init()
ekran = pygame.display.set_mode((800,600))
pygame.display.set_caption("CroProgrammer Rocks!")
pygame.key.set_repeat(500,30)
kutije = pygame.sprite.Group()
kutije.add(Kutija(10,20))
kutije.add(Kutija(300,20))
kutije.add(Kutija(20,100))
metci = pygame.sprite.Group()
metak = Metak(700,300,kutije)
metci.add(metak)
while True:
[tab]ekran.fill((0,0,255))
[tab]for event in pygame.event.get():
[tab][tab]if event.type==QUIT:
[tab][tab][tab]sys.exit(0)
[tab][tab]elif event.type==KEYDOWN:
[tab][tab][tab]if event.key==K_w:
[tab][tab][tab][tab]metak.micanje(0,-2)
[tab][tab][tab]elif event.key==K_s:
[tab][tab][tab][tab]metak.micanje(0,2)
[tab][tab][tab]elif event.key==K_a:
[tab][tab][tab][tab]metak.micanje(2,0)
[tab][tab][tab]elif event.key==K_d:
[tab][tab][tab][tab]metak.micanje(-2,0)
[tab]metci.draw(screen)
[tab]metci.update()
[tab]kutije.draw(screen)
[tab]kutije.update()
[tab][tab]fps.tick(30)
pygame.display.update()


Got some feedback on how the player movement worked and so I decided to switch it to the original idea I had–when the player gets too close to the bounds of the screen, then the screen recenters itself on the player, as opposed to re-centering every single time the player moves. Likewise the grass is now drawn so that it looks “attached” to the tile, instead of before where the grass appeared to just float under the screen like an odd parallax effect (see image; night sky is what the grass looked like if anyone hasnt tried out this thing).

Also, I’ve worked in the map generator into the game itself. It looks a bit weird, to be sure:

But I feel like currently that’s due to tileset issues and not necessarily the code. Don’t mind the odd looking minimap, still have a few kinks to work out.

Also, now I’ve got a way to output screenshots (properly labelled to boot) into a ’screenshots’ directory when you press the printscreen key. Saves time when I’m on Windows, thats for sure.