
🔍 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. Load your file into memory.
- 2. Call the `XORMemory` function with a key.
- 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`




