Is XOR Decryption in PlayBASIC as Fast as Assembly?

July 07, 2025

 

Logo

🔍 Is XOR Decryption in PlayBASIC as Fast as Assembly?

Every now and then, a forum question pops up that really catches my attention — and this one did just that. A PlayBASIC user recently asked:

> "Is using XOR decryption when loading media from memory in PlayBASIC as fast as doing it in assembly?"

At first, I was a little puzzled. Why? Because the function in question is written in assembly — it's already doing exactly what the user thought might be a separate optimization path. So, let's unpack what's really going on behind the scenes when you XOR encrypted media in memory using PlayBASIC.


🔐 XOR Media Loading: A Quick Recap

Years ago, PlayBASIC added support for loading media directly from memory. Earlier versions relied on external packer tools to encrypt and wrap media, but these days, you can load and decode encrypted content entirely from within your program.

The basic workflow is:

  1. 1. Load your file into memory.
  2. 2. Call the `XORMemory` function with a key.
  3. 3. The content is decrypted and ready to use.

You can use any XOR key you like. While XOR encryption is relatively simple and easily reversible, it’s still useful for basic protection against casual asset ripping.


🧠 What Happens Internally?

When you call `XORMemory`, PlayBASIC doesn’t interpret the data — it pushes the work down to the engine’s internal rendering system. Specifically, it uses the XOR ink mode inside the `Box` drawing function.

This function writes color data onto a surface by XOR’ing it with the existing pixels. Here’s what makes it cool: that surface isn’t necessarily a visible screen — it's just treated as raw memory.

To decrypt, the engine:

  • Creates a temporary 32-bit image buffer (must be 32-bit to handle raw data correctly).
  • Loads the encrypted file data into that buffer.
  • Applies the XOR key using the `Box` command in XOR mode.
  • Copies the result back to memory.
  • That’s it.


    💥 But Is It Fast?

    Yes. Very fast — because under the hood, this process is powered by raw MMX assembly.

    When the engine detects MMX support, it uses MMX instructions to process 64 bits (two 32-bit pixels) at a time:

  • Data is loaded into MMX registers.
  • XOR is performed at the hardware level.
  • Results are written back immediately.
  • Here’s the inner loop in plain terms:

  • Load two pixels from memory.
  • Load XOR key into a register.
  • XOR them.
  • Write them back.
  • Repeat in a tight loop.
  • We’re talking near cycle-per-pixel speeds here — hardware-level performance. If MMX isn't available, it gracefully falls back to optimized C code. Either way, you're getting a performance-optimized routine.


    🕰 Legacy Notes

    Older machines or systems using 16-bit display modes may encounter issues unless you force a 32-bit surface. That’s why the engine explicitly creates a 32-bit buffer in the decoding routine — it ensures consistent behavior across different environments.

    Also worth noting: drawing directly to the screen (especially in older systems where the screen buffer lives in VRAM) would be very slow due to the read/write overhead. But modern systems (e.g., Windows 10/11) emulate these surfaces in system memory, allowing direct blending without penalty.


    ✅ Final Thoughts

    So, to answer the original question:

    Yes — XOR decryption in PlayBASIC is as fast as it can be. It’s literally done in machine code.

    This is just one example of how PlayBASIC leans on low-level optimizations to make higher-level features accessible and fast. You get the convenience of a BASIC command, but the performance of assembly behind the scenes.


    Got more technical questions?

    Join the conversation on the forums, or check out the help files for more info about ink modes, memory banks, and low-level drawing operations.


    Tags:

    `#PlayBASIC` `#GameDev` `#Encryption` `#Assembly` `#MMX` `#XOR` `#RetroCoding` `#Performance`

    How Did Watching TV Get So Bad?

    July 01, 2025

     

    Logo

    How Did Watching TV Get So Bad?

    Once upon a time, watching TV was simple. You sat down, picked up the remote, flicked through the free-to-air channels — ABC, SBS, 7, 9, 10 — and found something to watch. If something wasn’t grabbing you, the "recall" button let you bounce between two shows during ad breaks. No lag, no loading. Just you, the remote, and the broadcast.

    The Golden Era of Digital Free-to-Air

    When digital TV first arrived in Australia, it came with a few growing pains — dropouts, unwatchable channels, and flaky reception — but eventually it settled. The benefit? More channels over the same networks. Digital broadcast was essentially a modernised version of the old analogue system: one-way communication, sent from a tower, received by your TV. No accounts. No buffering. No nonsense.

    Early digital TVs were little more than display panels with set-top box guts built in. Sure, they weren’t perfect, but many included useful features like program guides, reminders, and even simple recording tools. TV watching felt focused — direct, communal, and mostly frictionless.

    Then came the so-called "smart" TVs.

    Enter the App Era

    Today’s televisions are small computers. They boot up, they update, they crash, and they monitor your habits. Instead of simply broadcasting shows, they demand logins, bandwidth, and patience.

    What used to be a two-button process to swap between channels is now a fragmented mess of apps. Want to flip between two shows on different networks? Good luck. You’ll need to exit one app, wait for the interface to catch up, maybe even watch another set of ads before the other app lets you resume. There’s no “recall” anymore. There’s no flipping. Just loading, buffering, syncing, failing.

    Try casting content via a Google device, and you might spend more time troubleshooting than watching. Apps lose sync, freeze, or forget your place. And when they do work, you're locked into a provider’s ecosystem — their ads, their interface, their rules. Every interaction tracked, every pause or skip recorded.

    We’re Paying for Less

    On paper, we’ve never had more content. In practice, we’ve never had a worse user experience. And now we’re paying subscription fees, sitting through unskippable ads, and surrendering privacy for the privilege of watching a network that used to be — and technically still is — free.

    So, how did we get it so wrong?

    TV used to be simple. It used to just work. Now, it feels like work.

    Game Dev and the Rockstar Illusion

    June 23, 2025

     

    Logo

    🎮 Game Dev and the Rockstar Illusion

    At some point, many aspiring game developers ask the same question:

    "Should I pursue game development as a career?"

    It’s a fair question — and one I’ve heard dozens of times over the years. My usual answer goes something like this:

     Game development, for many of us, is the modern-day rockstar path. The huge potential upsides suspend people’s disbelief. Sheer optimism draws people into making life-changing career decisions on flimsy grounds.
    

    And I still stand by that.


    The Seductive Myth

    There’s a dream attached to game development that’s hard to shake.

    Make a hit indie game. Build a loyal community. Quit your day job. Maybe even go viral and rake in millions. We've all seen it happen. Stardew Valley. Undertale. Minecraft. Those stories are real — and they’re incredibly inspiring.

    But here’s the thing: they’re not the rule. They’re the outliers. The exceptions. The lottery wins.


    The Reality Check

    Making software is difficult.

    Making successful software? Even harder.

    Now try making a successful game in one of the most oversaturated creative markets on the planet.

    It’s not just about writing code or drawing sprites. It’s game design, storytelling, marketing, community building, testing, patching, supporting — usually with limited time, resources, or income. Even with passion and dedication, a great game can vanish in the noise of the marketplace.

    This isn’t meant to scare you off — but it is meant to snap the illusion. Because game development isn’t a shortcut to fame or fortune. It’s work. Deep, complex, and often unpredictable work.


    Why Do It Then?

    Because you love it. Because it fascinates you. Because making something interactive — something playable — is uniquely satisfying.

    For many of us, that’s reason enough. But the key is understanding that passion alone isn’t a business model. The most sustainable developers I know treat game dev like a long game. They build skills slowly. They wear many hats. They take breaks. They fail, adapt, and keep going.


    Career vs. Calling

    You can make a career in game development — but go in with your eyes open.

    Ask yourself:

  • Do I enjoy the process, not just the outcome?
  • Am I okay with uncertainty and iteration?
  • Can I build skills that work outside games too?
  • Am I doing this because I love it — or because I want to “make it”?
  • If you’re honest with yourself about those answers, you’ll save a lot of time and heartache.


    Final Thought

    Chasing the dream isn’t wrong — just don’t buy into the fantasy wholesale.

    Game development is an incredible field, but it’s not a guaranteed golden ticket.

    Build your foundation. Grow your skills. Be curious, be resilient — and enjoy the ride.