Announcing The Inaugural OLC Relay Race 2020

On 20th June 2020, the One Lone Coder community will host its first ever coding relay race.

Edit [14th June 2020]: There have been some minor changes to the way in which teams will be set up.

A relay race, you say?

Yes. Teams of between three and six coders will be given a coding task and an hour each to work towards completing the task. The first team to meet the challenge criteria will be crowned the winners and awarded a special role and colour on the Discord server.

Okay, so how’s this going to work?

Officially register by DMing your interest to @SaladinAkara. Then, on the 20th June, log in to the OLC Discord server for 5pm BST, where teams will be drawn at random. At 5:30pm BST details of the task will be announced. We’ll give you 30 minutes to chat with your team and come up with a plan before the race officially begins at 6pm.

Discord’s live streaming means we can all see the code progress for each team and allow referees to ensure that there’s no cheating.

Each member of the team must code for an hour, before passing their code on to the next member of their team. This will go on until either the task is complete, or the time limit of 6 hours is completed.

Can I join?

Yes! The relay race is open to all, regardless of experience. At One Lone Coder we encourage making code fun, and this is just a new way of doing that. A bit of friendly competition could also help you take your code skills to the next level.

Are there any limitations or restrictions?

In the interest of fairness, all entrants should use the OLC Pixel Game Engine to develop their solution to the challenge.

To help refereeing, all solutions should use a public git repository – this makes life easier not only for sharing code, but for making sure all competitors only use the hour given to them.

Sounds great. Sign me up!

Now you know how it’s going to work, here are the full list of rules:

  1. Teams must be between 3 and six people.
  2. Entrants must be registered by the end of Friday 19th June 2020 by sending a DM to @SaladinAkara on the Discord server.
  3. Teams will be drawn at random an hour before the race begins.
  4. Teams must declare the order of participants 15 minutes before the race starts. Changes to order will only be permitted in exceptional circumstances.
  5. Should a team member need to drop out for IRL reasons, they can be replaced. If a team drops below 3 members they will be disqualified.
  6. The task of the race will be announced 30 minutes before the race officially starts. This gives you time to discuss a plan with your team and set up a git repository for your code.
  7. The active coder must stream their code on Discord
  8. Only the team member whose turn it is may code. Other team members may watch and discuss with each other (including with the currently active member) but should not continue coding additional features in the background. This includes providing code to the currently active member.
  9. Handovers must occur within 5 minutes of the scheduled hour and will be verified by commit timestamps
  10. If all members of a team have completed their hour and the task hasn’t been completed, then they can continue from the first member again, continuing with the order defined before the race.
  11. The first team to complete the task will be the winner.
  12. If no team has completed the task by the 6-hour time limit, the winner will be the team who has completed the most criteria from the task.
  13. The race will be monitored by referees, and their decision is final.

We look foward to seeing you on 20th June!

The olcPixelGameEngine for Retro Platforms Part I

I’m very found of the Atari 8-bit machines and the Atari ST. When I saw the PixelGameEngine (PGE for the rest of this text) i thought why not port it? I started to look at the Atari ST. Using my own 520 STM as a the target machine.

I soon realised that a regular port wouldn’t cut it. My first attempt was to remove a lot of stuff just to get it to compile. The first PGE binary needed a 4 MB machine. Not even close for my 512kB target machine. In the test program all graphics routines is written from scratch and that is because of the bit plane situation, more on that below.

Before we dig deeper let’s look at the hardware.

The Atari ST

The Atari ST is made to be cheap it has almost no custom chips. For the original machines you can look at it as a 68000 processor connected to a 32k frame buffer.

  • Motorola 68000 processor running at 8 MHz
  • 520kB to a maximum of 4MB of RAM
  • TOS operating system
  • A YM2149 sound chip
  • MK68901 MFP
  • Built in midi
Atari TOS

Graphics capabilities

The ST always (almost) has 32kb of screen memory. In the following graphics modes:

  • 320 x 200 pixels, 16 colors
  • 640 x 200 pixels, 4 colors
  • 640 x 400 pixels, monochrome

For graphics and games the first mode is the most useful.

The screen memory is organised in bitplanes which are interleaved. It looks like this i word (16bits) of bit 0, one word of bit 1, one word of bit 2 and finally one word of bit 3. Then we start over. This makes it harder to set individual pixels. It’s also harder to copy graphics that is not a multiple of 16 pixels. To get around this you pre shift your graphics to save time.To complicate things more you can only set the screen adress on even 256 bytes. This is because the LSB of the screen adress is missing in hardware. This makes scrolling a lot harder. You basically have to copy all your graphics data. This eats up all your processor time for one frame at least.

The Atari 8-bit

The Atari 8-bit machines is the opposite to the Atari ST. It has a lot of different graphics modes. The Hardware:

  • MOS 6502 processor running at 1.77 MHz (PAL)
  • ANTIC and GITA custom graphics chips
  • POKEY custom chip for sound, keyboard, paddles and serial communication
  • Maximum of 128 kB of RAM (newer mods with more memory exists)

As for graphics capabilities you have up to 17 different graphics modes to choose from. But it does not end there. You also have something called the display list which means you can mix and match your graphics modes as you see fit. This is a very powerful feature. There is also hardware scrolling support and the possibility to add interrupts in the display list. This means that you can have interrupts happening on a specific line for example to change the palette or scrolling.

Test programs

We end the first part by looking at my test programs I’ll also link the code att the end of this post.

Atari 8-bit

A smal test in 40×23 pixels

Uses ANTIC modes 2,7 and 8. Then writes random numbers to the screen as fast as possible.

Atari ST

Atari ST version here called the SimpleGameEngine.

Program is written in C++ and uses gcc 8.3 for cross compilation.

The Atari ST version is here called the simpleGameEngine. I’ve decided to change the names to PGE68000 and PGE6502 to be consistent.

The code

Atari ST version: https://github.com/dataochljud/simpleGameEngine

Atari 8-bit version: https://pastebin.com/zCUkZeWe

Final note on the code the GitHub version may differ slightly from the running code in the video.

Final words

My tests have shown that it is possible to make the PGE for both the Atari ST and Atari 8-bit. It should also be possible to port to the C64 and Amiga.

In the next part

In the next part we will take a closer look on the Atari ST version of the PGE68000.

PGE Driver – upcoming olc::PixelGameEngine game

PGE Driver is an arcade style racing / death-match game where the aim is to win – by any means necessary! With nitro boost and heavy machine guns at your disposal, along side pre-race upgrades such as engine power, tyres, and armour – the choice really is yours… Win by being the fastest, or the deadliest, it’s your call.


What started as merely a theme to accompany an exercise in code discipline, ended up blowing out to a fully featured game which so far has spawned 3 olcPGEX extensions for sprite handling, camera tracking, and sprite animation. Not to mention a fully customisable menu system with panel transitions and overlays.

The cars in this game are fun to drive and easy to do burnouts in, which shows off the PGEv2.xx’s ability to render many 10’s of thousands of decals on the screen at any given time and still maintain a satisfactory frame rate. By the end of a race there might be 40,000 or so skid decals on the track! This was not possible until PGE v2.0 so well done Javidx9, you’ve made the PGE a viable game engine for those of us who like the simplicity, but still need some power under the hood 😉



A playable demo is not available as of time of writing, however you can check out a short demo clip of a couple of levels and vehicles to see how the game is progressing so far…

If you are interested in the extensions of mine that were used to create this game you can check them out in the contributions folder in the github here:

https://github.com/OneLoneCoder/olcPixelGameEngine/tree/master/Contributions

Author: Justin Richards

Casting Bit Magic

Pt. 1 Binary Representation and Endianness

Introduction

This article began as an explanation of the “fast inverse square root algorithm” found in the source code of Quake 3 by id Software. While working on the article and receiving feedback I realized that I would better split the article in a small series about binary representation and the floating point type. We will begin at the basics of bit representation and ending the series with some nice bit trickery with the floating point format. The goal of the article is that beginner level programmers can understand the lower level workings of their machine. I do sincerely hope I have included enough material that also the more experienced programmer will enjoy the content. So here is the first entry!

Continue reading “Casting Bit Magic”