Unpopular Opinion #1: Teach Raw Pointers First

Being the administrator of a large programming Discord server, and the owner of a YouTube channel with a large audience of programming beginners, it is with some frequency that questions about the basics of programming are asked. In fact, it’s often the same questions. This is perfectly fine, after all, the ethos of One Lone Coder can be encapsulated in the phrase:

“There is no such thing as a stupid question”

An attitude which I wholly endorse, and encourage others to actively embrace because at least the asker is actually asking – a necessary step on the journey to acquire knowledge.

And so it was with admittedly brash vitriol that I lambasted several members of the community the other night, for which I can only apologise, as it was uncharacteristically impetuous of me, though I stand by my lambasting. Before we get there, please consider this code:

descriptor<utilises: a>
allocate : 23[a] 
<for 'all' in a> set [traits:on]?"numeric type"
    === literal_cast<set.trait>(12);

Now, tell me which modifications to the code will ensure that allocations remain aligned to 32 byte boundaries, in a contiguous fashion? C’mon it’s really simple!

If you know the answer, you’re lying. If you don’t know the answer, I’m not surprised. You haven’t encountered this language before, you know nothing of its semantics, structure, flow or algorithmic composition. You have just become the programmer you once were, when you first started.

So then, why when someone asks the innocent and innocuous “How do I declare a 2D array in C++?” is the immediate response:

std::shared_ptr<std::array<std::array<int, 500>, 500>>

Let’s just do a little reality check here. Firstly, the question itself implies the asker is not familiar with the language at a fundamentally basic level, so why should it be assumed that requiring the asker to first understand:

  • the standard template library
  • templates
  • object oriented programming
  • compile time memory descriptors
  • smart pointers
  • the concept of ownership

…is acceptable? The guy just wanted a 2D array!

This is a confrontation I often have with my fellow community. It’s great to be able to help people, it’s satisfying, and it makes you look great in front of others – and hey, it’s a chance to flex your skills and knowledge under the guise that in the long term, you are doing them a favour!

Well, sorry, you could not be any more wrong.

Not only is showing off in such a manner obnoxious, it labels you as being confusing in the eyes of the asker, and as a twit in the eyes of your peers. An array is fundamental, and if you are being asked how to create one, chances are the asker doesn’t really know anything about arrays. So don’t bog down your explanation in elitist, pedantic wafflery, just show them how to make an array!

// Ask for some memory
int *a = new int[500*500];

// Do something with it
a[y * 500 + x] = 6;

// Give it back
delete[] a;

Put aside the snobbery, and understand there is a beautiful elegance to this from the perspective of someone who is learning. Every single byte of source code in that snippet contributes to the most minimal form required to understand such an important concept.

  • A variable ‘a’ contains a memory address
  • That memory is requested, and the address put in ‘a’
  • The memory is indexed somehow, starting from its beginning
  • When finished, give the memory back

Surely, for such a basic question, understanding this sequence of events and their associated outputs is significantly more beneficial to the asker, than requiring them to concern themselves with ownership, templates and objects? But alas, empirically it would seem not because invariably the following argument is raised:

It’s better to teach people the correct way from the start, so they don’t form bad habits…

Oh be quiet! You’re embarrassing yourself and patronizing the asker. Firstly, there is no way you learned about arrays (or the fundamentals of programming) according to some “standard” first time around, so stop being a hypocrite. Secondly, you have assumed the asker is too dumb to understand the consequences of their code. And most importantly, thirdly, you have assumed the asker doesn’t have the capacity to adapt and change as they learn and gain experience – which clearly they do, as they are asking the questions in the first place!

Separating Axis Theorem Refinements and Expansion


In this video, javidx9 explores two techniques for collision detection and static resolution for convex polygons. While his collision detection using the Separating Axis Theorem is just as robust as his diagonals approach, his static resolution for SAT is slightly naïve. His implementation assumes the smallest possible displacement to resolve the collision is along the vector between the centers of the colliding polygon and the collided polygon, with a magnitude of the smallest displacement. This assumption is not always correct, and can lead to incorrect resolution with large overlaps. The correct resolution vector is along the normal of the axis with the smallest overlap.
This article will explore my implementation of Separating Axis Theorem detection and resolution.
This article assumes basic knowledge of two-dimensional vector math.

javidx9 explains two collision detection algorithms for convex polygons
separating / separated axis theorem

The video above explains the Separating Axis Theorem quite well, I suggest you watch it if my explanation seems a bit muddled.

The Separating Axis Theorem states that two convex polygons overlap only if the projection of one polygon onto the every axis of another polygon overlaps with the projection of the latter onto the same axis.


My implementation relies on several objects:

vector2 {
    float x, y
    float length => square_root(x * x + y * y)
    float dot(vector2 other) => x * other.x + y * other.y;
    vector2 normalized => this / length
    vector2 normal => (y, -x).normalized
 polygon {
    vector2 location;
    point[] points;
    side[] sides;

    projection project(vector2 axis){
        float min = axis.dot(points[0]);
        float max = min;

        for(int i = 1; i < points.length; i++){
            float dot = axis.dot(points[i])
            if     (dot < min) min = dot;
            else if(dot > max) max = dot; 

        return new projection(min, max);
side {
    vector2 start, end;
    vector2 normal => (end - start).normal;  
 projection {
    float min, max;
    bool overlap(projection other) => 
        max > other.min &&
        min < other.max;
    float overlap(projection other) =>
        minimum(max, other.max) - 
        maximum(min, other.min);

With these, writing Separating Axis Theorem collision detection is quite simple:

bool SAT(polygon a, polygon b){
    // smallest overlap
    float overlap = float.MaxValue;
    // axis along which the smallest overlap occurred
    vector2 oaxis = new vector2()

    // pointers to each polygon so they can be swapped
    polygon sa = a;
    polygon sb = b;

    // the same operations must be done on each shape
    for(int shape = 0; shape < 2; shape++){
        if(shape == 1)
            swap(sa, sb);

        vector2[] axes = new vector2[sa.sides.length);
        for(int i = 0; i < axes.length; i++)
            axes[i] = sa.sides[i].normal;

        for(int i = 0; i < axes.length; i++){
            vector2 axis = axes[i];
            projection pa = sa.project(axis);
            projection pb = sb.project(axis);

                // no collision, no resolution
                return false; 
                float o = pa.overlap(pb);
                if(o < overlap){
                    overlap = o;
                    oaxis = axis;
    // if the smallest penetration normal
    //     points into shape b,
    //     flip it
    if((b.location - a.location).dot(oaxis) < 0)
        oaxis *= -1;

    // now oaxis is the axis along which
    //     the smallest penetration occurred
    // the resolution vector is that axis normal
    //     multiplied by the smallest 
    //     penetration amount
    vector2 resolution = oaxis * overlap;
    // translate the colliding shape to resolve the collision
    a.location -= resolution;

    // no collision because of static resolution
    return false;

The only meaningful difference between javidx9’s approach and mine is how the resolution vector is found.


javidx9, Convex Polygon Collisions #1 (video) published 2019-02-02 retrieved 2020-09-26
Wikipedia, Hyperplane Separation Theorem (article) retrieved 2020-09-26
Wikipedia, Euclidean Vector (article) retrieved 2020-09-26


discord: Fyre#0465
email: horace5413@gmail.com with “olc” in the subject line

Programming and The Art of War

A few days ago on the Discord, there was a question asked about whether you could teach programming through the medium of ‘philosophical text’. An example was how Sun Tzu’s classic, The Art of War, is used to teach business practices.

This got me thinking… Can The Art of War be applied to programming and software development in general… Turns out that, with a little bit of twisting and wild interpretation, that it can! I shared a few on the Discord server, but thought I’d give the idea a more permanent presence here on the blog.

Continue reading “Programming and The Art of War”

Javidx9 Top 5’s

It would seem people are quite curious about things I like, so I thought it would be useful to have a page that I can point such individuals towards. Here are my Top 5 “things” in various categories.

Top 5 Films

  • Hackers
  • The Andromeda Strain (1969)
  • Batman Trilogy (Nolan)
  • Inside Out
  • John Wick

Top 5 Foods

  • Chilli Con Carne
  • Pulpo a la Gallega
  • Char Siu with Green Pepper and Blackbeans
  • Walkers Chicken and Thyme Sensations
  • Pistachio Nuts

Top 5 Programming Languages

  • C++
  • Lua
  • Java
  • BBC Basic
  • VHDL

Top 5 TV Series

  • The West Wing
  • The X-Files
  • Lost
  • The Orville
  • The Sopranos

Top 5 Tracks

  • La Gazza Ladra – Rosinni
  • Nightrain – Guns N’ Roses
  • Contact – Daft Punk
  • The Haunt of Roulette Dares – The Mars Volta
  • You To Me Are Everything – The Real Thing

Top 5 Albums

  • Frances The Mute – The Mars Volta
  • The Wall – Pink Floyd
  • Appetite For Destruction – Guns N’ Roses
  • Deloused In The Comatorium – The Mars Volta
  • Mechanical Animals – Marilyn Manson

Top 5 Star Trek Captains

  • Janeway
  • Picard
  • Lorca
  • Kirk
  • Pike

Top 10 Games

  • The Witness
    Deservedly titled “the best game I have ever played”. What a wonderful experience from start to finish (and yes I 100% it, even the damn boat and time trial). It is a lesson in game design. If you think its just line puzzles, you are very very wrong, and it gives you those “oooh I get it now, I wasn’t expecting that!” moments every couple of hours. Do not spoil this game, it is best enjoyed not knowing anything about it, and just enjoying the ride. A true masterpiece.
  • Final Fantasy VII
    Admittedly, there is a heap of nostalgia bundled into this, but wow was this an eye opener. RPGs up until this point were good but despite its aged looks today, this was really immersive, and grown up, and fun, and surprising, and tactical, and explorational. A rock solid adventure, creating mountains of lore, that’s really addictive to play.
  • Super Metroid
    Often touted as the pinnacle of game design demonstrated in a single title, and deservedly so. I don’t like shooters, I don’t care for shooty platformers either, but this game plays so well, its like playing a musical instrument when it comes together. Packed with replay value, a genuine demand for gameplay skill, and a variety of ways through the game, means its a game I play several times a year.
  • Super Mario Brothers 3
    It’s Super Mario Brothers 3 – what else needs to be said?
  • Uncharted 2
    So Uncharted 1 was good, but a bit generic. This sequel was genre redefining. It’s like a roller coaster all the time, the world collapsing and changing around you whilst you explore and navigate is captivating. The story and acting is top notch, and its the first time I’ve ever felt that a game is a genuine interactive movie. Really gripping and fluid gameplay all the time just makes this extremely fun to play, and can be enjoyed by spectators too.
  • Crash Bandicoot
    What really needs saying? It’s Crash Bandicoot! At the time, absolutely mind blowing visuals and gameplay which still hold up to this day. Classic Naughty Dog stuff, being very simple and accessible, but requiring lots of practice to master.
  • Fez
    An absolute gem. Look pass it’s indy credentials and its controversial developer and what you discover is a real masterpiece. Its geeky, the puzzles are hard and its a game with so much beneath the surface its easy to think its a different game entirely. The fact it has distinct “new game” playthroughs, and it took me ages to find all the cubes (except the final one, I had to google that) really impressed me.
  • Batman: Arkham City
    I like Batman. I like exploration games, and I like games with loads of things to find. This was a superbly immersive and engaging game. Fun fact, I’ve found all the Riddler trophies in all the Arkham games.
  • Command & Conquer: Red Alert
    A perfect blend of story and gameplay depth made this a far better sequel to its predecessor. The cinematics, the music, and the variety kept me coming back for more. Also exchanging strategies with friends as currency.
  • The Incredible Machine
    At the time it was genre defining. Solve puzzles by building various mechanical contraptions, and had a sandbox mode you could simply build in. Very addictive, highly educational and totally silly nonsense. Perfect.

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:


Author: Justin Richards

How to attribute/credit/cite the olc::PixelGameEngine

Hello! Firstly a big thank you, the fact that you are reading this means you actually care about doing the right thing, and want to acknowledge the software you have used from other developers.

The olc::PixelGameEngine is open source and is released under the OLC-3 licence. This means you can use it freely, even for commercial projects. However, the licence requires that appropriate attribution is required.

Releasing Software in Executable Binary Form

Your olc::PixelGameEngine application needs to display to the user the following message:

Copyright 2018 – 2020 OneLoneCoder.com

Most people prefer to do this by either:

  • Keeping the application in window mode, and not changing the text displayed in the window’s title bar. By default, olc::PixelGameEngine applications are out-of-the-box compliant.
  • A splash screen along the lines of “Made using olc::PixelGameEngine” and including the above notice.
  • Full attribution in a “Credits” or “Licences” menu available without special requirements of the user (such as completing the game for example)

Releasing Software in Source Code Form

If your project is distributed via source code, and you use either part, or all of the olc::PixelGameEngine, the full text of the OLC-3 licence needs to be included in the source code distribution. By default, an unchanged olcPixelGameEngine.h file will satisfy the licence requirements. If you maintain an external catalogue of licences, you should include OLC-3 in that too.

Releasing Derivative Works

Since the olc::PixelGameEngine is open source, you are allowed to modify it. This could be in the form of adding additional features, wrapping it into an alternative framework, cloning the features, or using parts of the code. In this instance, the full OLC-3 licence text needs to be included, and if your derivative work is in binary form, it must display to the user the above copyright notice.

Citation in Academic Works

If you use olc::PixelGameEngine for school, research, academic pursuit, you can reference/cite it properly in the following way:

olc::PixelGameEngine, v2.05, OneLoneCoder.com, 2020

The version number and year are of course flexible and should be changed as required.

Referencing in Digital Media

If you write blogs, make videos, create content and want to reference the olc::PixelGameEngine,, or indeed the OneLoneCoder website or javidx9 youtube channel, then the correct links are:




Finally, again a big thank you for taking this seriously. Software development is a hard and time consuming task, in the hope that it makes someone else’s software easier and quicker to produce. It is important that the hard work of others is given the credit it deserves – javidx9.