Paul Robertson

Paul Robertson

I was a lecturer in Games Programming at Abertay University. With teaching focusing on the fundamentals of games programming and graphics programming. Currently a senior games programmer in industry.

Location Scotland

Activity

  • You are correct. The example code is in Python 2.x. There was a plan to link with a python based games library in the future, which at the time did not have a python 3.x build.

    For python 3, print should be print("hello world")
    and raw_input(), is input()

  • Everything language has it's pros and cons. Python is highly readable, extendable and portable. One of the reasons it was chosen as the example language for the course is it readability.

    The major language used for games is C++ but all the concepts covered are applicable to that and many other languages.

  • Hi Sophia, thanks for pointing out the error in the captions. I will get that updated.

    Thank you David, excellent explanation!

  • It's best to break it down into two steps, first calculate the new velocity
    new velocity = old velocity + ((direction * acceleration) * delta time)
    Then move using that velocity (updating the position based on the velocity)
    move(velocity * delta time)

  • @JanRamsli Correct, you could use different colours as transparency however it will be a little complex to manage. For @SophiaRiches example, you could use a colour very close to magenta, off by a single colour value, it would look like magenta, but not be made transparent as it wouldn't be an exact match.

  • Partially transparency allows for more complex game objects, such as glass, fog and clouds. Objects than have colour but are not completely solid or transparent.
    Alpha is a value that states how transparent a colour is. Ranging from completely transparent, to completely solid.
    https://en.wikipedia.org/wiki/RGBA_color_space

  • If we were not using delta time, then yes we would have to handle PAL/NTSC differently as they have different frame rates. Delta time calculates the amount of time between frames and if we use that to update the game elements we can ignore the frame rate differences.

  • In single buffering, it is a single piece of shared memory. We write the sprites (background, characters etc) to it, building the scene. The monitor reads directly from it. The monitor doesn't know if we have finished writing to the memory space or not. It just reads the memory and displays what is there.
    Double buffer resolves this issue by using two chunks...