In this PlayBASIC development update, we take a deep dive into the latest polygon subdivision experiments inside the PS3D software rendering engine. This tech demo showcases adaptive quad subdivision, near-plane clipping improvements, affine texture mapping, filtered triangles, and transparent rendering running entirely in software.
The new subdivision system dynamically increases polygon detail based on camera distance and face orientation, dramatically improving image quality for close-up geometry without requiring full perspective-correct texture mapping. Instead of relying purely on traditional affine textured triangles, PS3D subdivides quads into smaller faces to better approximate perspective, reducing the heavy distortion commonly seen near the camera.
This video also explores:
Adaptive polygon subdivision in a software renderer
Quad vs triangle clipping behavior
Near Z-plane clipping and projection artifacts
Backface culling and object-level visibility rejection
Transparent alpha blended rendering
Triangle fan generation after clipping
Performance tradeoffs between image quality and rendering speed
Screen-space clipping limitations
Software 3D rendering techniques in PlayBASIC
Retro-style rendering pipelines and engine experimentation
The demo scene renders thousands of transparent objects while visualizing subdivision levels and clipping behavior in real time. The green wireframe overlays reveal how faces are broken down and processed internally by the renderer.
PS3D remains a fully software-driven 3D engine written in PlayBASIC, focused on experimentation with classic rendering techniques, optimization strategies, and retro-inspired graphics programming.
🔍 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.
