Tribute to Future Crew

I was in the middle of implementing some sub-systems into the Xona System 8 engine:

 

I happened to notice my subscribers was at 360. My original plan for my YouTube channel was to release games that related to the number of subscribers at interesting numbers (such as 100, 250, 500, 1000). I was already at 170 when I had this idea, and 250 came and went before I prepared. Should I let 360 pass as well?  How about a quick demo relating to 360°?

I had recently watched Future Crew‘s Second Reality.  It has a rotozooming effect (rotation and zooming) of a really cool image drawn by the artist, Pixel. Therefore, I made a quick bi-linear texture-mapping rotation demo in tribute to Future Crew:

 

Inaccuracies

VGA Mode 13h (and Mode-X) resolution is 320×200, fitted to a 4:3 aspect ratio screen, meaning it had 5:6 sized pixels (taller than wider). I don’t respect that here. My apologies to Pixel (a 20% distortion is not appropriate).

You need quite high resolutions to showcase a 320×200 non-square 6:5 pixel ratio image perfectly. 1600×1200 is the minimum. Given that my demo is running in 1920×1080, I could have shown most of the image, but my engine, and my demos, and my tribute to Future Crew, are all based on the low-resolution VGA mode.

 

CPU vs GPU

My demo uses the GPU. I am not calculating each pixel individually, nor am I using assembly language. But, I did “invent” bilinear texture mapping several years before Second Reality: I programmed the Mode 7 graphics of F-Zero in GW-BASIC, and it only took 30 minutes to render a single frame. I could watch and count the pixels begin drawn one-by-one.

 

Resolution

Second Reality drops to a lower resolution (160×100, from the original 320×200) to enable full-screen frame-rate (less pixel updates), which is 70 Hz for VGA. Using Mode-X you can write to 2 pixels at once, and also you can double the repeat scan from 2 to 4 (VGA 320×200 has 400 actual scan lines, double scan is the default per scanline). At the time, in 1993, most video cards couldn’t even handle a full 64,000 byte copy into video memory in 1/70th of a second. So you just could not achieve such frame rates! It was a big deal to see full-framerate animations.

 

Memory Cache

Later demos (1994) shows an improved speed of rotozooming, full-screen, at near frame-rate on fast video cards, in full 320×200 resolution (HeartQuake comes to mind). Such demos led me to understand memory cache, and why texturing the whole screen a full line at a time is not an efficient use of reading memory — as the bilinear scan of the source texels goes all over memory, especially when rotated. It is far better to texture 8×8 sections… more complex code, more instructions, but much faster! Given CPU speeds today, this is crucial for writing performance critical code.

 

Assembly Language

I had been chasing after assembly language since I was 7, when I first programmed on my TI-99/4A. I knew the real power in this machine, and my later Tandy 1000 SX, was extracted via assembly language, and BASIC was just not up to the challenge. My first Mode-7 demo took 30 minutes to render a single frame. I needed assembly.

But I didn’t have it.

Enter Second Reality.

 

Second Reality Impact

Second Reality was my introduction to the demoscene. However, this introduction was not what you may think. I didn’t know of software cracking, graphics demos, or the demoscene. I was merely shown Second Reality… with the ridiculous explanation that there was an “assembly language” competition, and some Finnish kids decided to show off their assembly language skills, and showed up with Second Reality — a full-fledged multi-media demo that showcases a dozen effects simply not possible on a 486, most at the full frame rate (70 Hz), in Dolby surround sound (which isn’t even possible on the Gravis Ultrasound hardware they were using). My jaw dropped both watching the demo and wondering how they blew away their competition.

 

Reality

I later learned this was the demoscene. Second Reality was entered into a “demo party” or “demo compo” called “Assembly ’93” (a pun on “assembly language” and “assembly of people”). It was not an “assembly language competition”, it was a graphics demo competition, where mostly everyone had programmed similar effects, to music, in their own multi-media presentations. Even after learning this, I was still amazed. It still seemed impossible. Their presentation was well beyond what other demos showcased. And I knew I needed to get my hands on assembly language…

 

Game Engine

Xona System 8 is the name of a new game engine / game development framework that I am building in C# on top of the XNA / MonoGame framework.

Its purpose is primarily for building new games quickly — it is both a game engine in its own right, and also a game development framework, where games can be developed quickly.  Part of my goal is also to allow releasing older XNA games for release onto PC and other consoles — with the updated requirements of today’s games (resolutions, framerates, online services, etc.)

The below video shows its very beginnings.  Currently it showcases the distinction between the game and the engine, with clearly defined ownership: engine running the graphics, rendering, font manager, and update layer vs. the game simply requested such resources with minimal API access.

 

First Showcase

Engine:

• Low resolution / pixel-zoom screen (I am Retro! “Retro Re-invisioned“)
• Graphics rendering sub-system
• Extensive font library (the fonts you see are my own)
• Font render & animation framework
• Texture / Sprite creation

Game Demo:

• Sprite requests
• Integration into the engine
• No level details handled
• simple engine API calls

 

Driving Force

I have made several engines over the past couple of years (well I have all my life, since I was 7 — but in the past 2.5 years, I’ve made several in MonoGame), as you can see in my other videos.  Some created in less than 48-hours in game jams, and some are side passion projects.  Many are recreations of technology I invented long ago — which I built in hand-optimized assembly & machine language, Turbo Pascal, GW-BASIC, and TI BASIC (yes that’s a 50,000x speed difference — from 1 frame per 30 minutes for a half-screen F-Zero style texture mapper in Tandy graphics to 30 frames per second in assembly in VGA, pre-GPU).

Platforming Engine

Side-Scrolling Shmup Engine

Arena Shmup Engine

Voxel Engine

Pseudo 3D Scanline Road Engine

3D Ray Casting Engine

Equation Rendering Engine

3D Polygon Engine

 

Barrier to Entry

It is time to break down the barriers to entry that prevent these engine demos from becoming full, feature-rich, implemented, playable, and releasable games.

It is time to collaborate all of the work into a single engine system – a game dev system – that allows the extra “fluff” of a game to be handled elegantly by a core engine, a system of sub-systems, that are all protected from the user (the game maker), and remove it from distracting efforts of focusing on the game.

Its purpose is to provide a framework from within which to make prototypes — such as simple weekend game jams, or quick ideas that can be tested and tried, without rewriting an engine from scratch (or borrowing code from a prior engine).

 

Quick Development – Prototyping

While it is great to witness the core code from my 2D Side-Scroll Shmup Engine be reused almost verbatim in my 3D Voxel Engine (animation system just works, along with sprite scaling, with simple Vector2D changed into Vector3D) — along with the code from my 2D Arena Engine used verbatim in my 3D Ray Cast Engine (this still amazes me just how similar the 3D game is to the 2D game; I totally get it, Carmack).  What would be better is if the engine provided this code, the framework, to the games that want it.

I am going back to my roots as a TI BASIC, GW-BASIC, and Turbo Pascal developer where either the language was simple enough (BASIC dialects) or the language was powerful enough (Turbo Pascal units) to allow an extremely quick foundation upon which you could build.  I feel anyone who has not written code in the original BASIC interpreters that accompanied home computers — where you could write an entire game in a screenful of code (like I did with Tetris, including saving high scores) — is missing how simple & quick programming can (and should) be.  In structured languages you can build utility units to help out, as I did with Turbo Pascal, but for some reason this seems harder today.

No more.

The goal is a working graphics test from Visual Studio “File -> New -> Project” in 5 minutes flat, a full game in 1 hour, and a polished demo in a weekend.  No more barriers.

 

Programming Concepts

I am keeping the following concepts in mind:

• “Fight code entropy” – John Carmack
• “You never, ever, open the (encapsulated) box.” – Chris “Kiwidog” Hargrove
• MVP – minimal viable product.  What do I need today?
• The First Pixel – Motion is more important than perfection.