Davide Pasca

OVERSWEEP is a carrier-interceptor combat flight game, written in C++20 with a native Vulkan renderer. I am the sole developer. It is a playable vertical slice with authored operations, free flight, guided tutorials, and deterministic demos, in development for a commercial release on Steam.

The project draws on the flight dynamics, guidance, autopilot, and avionics work I did on XPSVR. The implementation is largely new, but that earlier experience informs what to simulate, how to present it, and where detail helps the player.

Engineering decisions

• One simulation, several ways to fly. Missions, tutorials, free flight, and demos share a fixed-step simulation. The same underlying aircraft and systems support manual play, instruction, and repeatable verification.
• Avionics driven by simulation state. A typed data bus feeds the HUD, tactical displays, and mechanical instruments. The renderer presents the aircraft’s state rather than inventing a separate version of it.
• Reproducible visual checks. Tick-addressed replay, fixed-clock captures, and image comparisons make rendering changes reviewable from the same flight state.

My work on the project

• Native SDL3/Vulkan renderer: lighting and shadows, HDR, atmospheric effects, terrain, and ocean rendering
• Real-world terrain processing from elevation, bathymetry, and land-cover data, with bounded streaming of regional scenery
• Flight model, automatic wing sweep, manoeuvre devices, landing gear, and pilot G response
• Cockpit integration, camera and pilot presentation, live avionics, and flight instruments
• Weapon guidance, seekers, launch envelopes, and guns
• Operations, flight instruction, runway landing, and carrier-recovery systems
• Audio, development tools, deterministic replay, visual verification, and desktop packaging

Development workflow

OVERSWEEP is the heaviest user of Little Control Room, which I built to coordinate coding agents, worktrees, runtimes, and review across projects. I direct the architecture and product, use agents throughout implementation, and review the result through tests, captures, and hands-on flying.

The difficult part is choosing the right scope and knowing when something is correct. Flight simulation can absorb almost unlimited detail; keeping the game approachable takes judgment about what to model, what to simplify, and how it feels in motion.

AskMei.ai is a modern AI assistant built on the ChatNext3 platform. It combines multi-model LLM routing, live web search, image generation, memory, file and vision support, and a friendly skeuomorphic interface into a single web/PWA experience.

The system is designed as a multi-instance platform: the same codebase can ship different branded assistants with their own prompts, visual identity, model choices, pricing, rewards, and deployment settings.

AskMei was developed with modern AI coding tools as part of the everyday engineering workflow, including implementation, review, visual iteration, and release work.

My work on the project

I designed and implemented the product, front-end, backend, AI orchestration, deployment, and monetization systems. Major areas include:

• Multi-model assistant architecture with a backend preparation agent, model routing, tool orchestration, and a user-facing response model
• Tool system for live web search, link scraping, image generation, calendar and memory retrieval, user context, and HTML artifact generation
• Editable memory system with compact summaries, detailed YAML memory, user import/export, and background consolidation
• File, image, and PDF handling so the assistant can reason over uploaded content
• Skeuomorphic visual design, including the “Spring Canopy” desk interface and themed assistant presentation
• Credits, subscriptions, power packs, daily rewards, and optional ad-based credit earning
• Multi-instance configuration for branded deployments such as AskMei and other specialized assistants
• PWA support and Capacitor groundwork for iOS and Android packaging
• Production deployment, observability, authentication, and payment integration

What I learned

• How to separate model preparation, tool use, and final response generation without overloading a single assistant prompt
• How to balance quality, latency, and cost through model routing and selective tool use
• How much control users need around memory for an assistant to feel useful rather than intrusive
• How visual identity changes the perceived warmth and usability of an AI product
• How to build an AI assistant as an adaptable product platform rather than as a single fixed chatbot

Little Control Room is a terminal-first control center for my AI-heavy development workflow. It keeps work across many repositories, agent sessions, TODOs, diffs, and project runtimes in one place. It is now the main tool I use to develop and coordinate my other projects, including AskMei.ai, Fractal Strike, and RogueLLM. Its heaviest user is OVERSWEEP, where many concurrent worktrees, agent sessions, and runtimes run against one codebase at once.

One of my main lessons from using AI agents is to use them to build better tools for the way we work. Personal tools remove very specific friction and keep more of the workflow under my control when a vendor changes direction. LCR therefore works with Codex, Claude Code, and OpenCode rather than being designed around a single provider or harness.

Through the Model Context Protocol (MCP), LCR gives different agents a common interface to the same projects, worktrees, TODOs, sessions, browsers, and runtimes. That shared environment lets them discover what is already happening, coordinate resources, and hand work to one another, so the agent can change without taking the workflow with it.

Creating LCAgent, an experimental coding agent native to LCR, is an important next step. It is both research into where the model ends and the harness begins, and a practical move toward independence. It does not remove reliance on external models, but moves that reliance down a layer: from one complete coding-agent product to replaceable LLMs behind tools and policies I control.

That exposes the less visible challenges of agent engineering: choosing and compacting context without losing important state, resuming reliably, managing security through permissions and command vetting, preventing common destructive actions, and keeping enough trace and verification evidence to understand what happened.

My work on the project

I am the sole developer. The main areas of work include:

• Go-based TUI for monitoring and navigating many projects without losing sight of active agent work
• Embedded Codex, Claude Code, and OpenCode sessions, with provider-neutral project and session workflows
• TODO, Git diff, commit, worktree, conflict-resolution, and managed-runtime tools kept close to the agent sessions
• Artifact-first project and session discovery, using local state rather than requiring a central cloud service
• Boss Chat, a higher-level view for project inventory, session recall, and confirmable control proposals
• LCAgent’s provider-flexible loop, durable thread state, context compaction, permission and approval policies, command guardrails, verification traces, and repeatable evaluations
• Local and API-backed inference across multiple agent tools, model providers, and OpenAI-compatible endpoints

What I learned

• Building tools for my own workflow creates compounding leverage and reduces dependence on any one vendor’s product decisions
• Provider and harness independence has to be designed into the architecture; it is difficult to add after everything assumes one agent
• Much of an agent’s intelligence comes from the model, but reliability comes from the surrounding work on context, compaction, permissions, recovery, and verification
• Security is most useful when its guarantees are explicit and narrow: vet commands, require approval where appropriate, block known dangerous actions, and remain honest about what is not sandboxed

Fractal Strike is a mech combat game built with Phaser, TypeScript, Vite, Capacitor, and Electron. It targets web, mobile, and desktop, with arcade survival gameplay, adaptive controls, store-ready screenshots, and a sci-fi campaign structure.

This was an AI-first production: code, art direction, terrain and story assets, copy, localization checks, QA scripts, store capture pipelines, and release tooling were developed through iterative AI-assisted workflows under my direction.

My work on the project

I developed the project end to end. Major tasks include:

• Core top-down mech combat gameplay, weapons, pickups, enemy waves, boss phases, HUD, and pause/settings flows
• Campaign structure with briefings, debriefings, mission progression, and localized UI/content
• Phaser game architecture with TypeScript, Vite, deterministic build steps, and sprite prebuild pipelines
• AI-assisted visual asset generation for story thumbnails, terrain, UI art, icons, achievement art, and promotional assets
• Automated screenshot capture for App Store, Google Play, Steam, and publisher handoff workflows
• Cross-platform builds through Capacitor for mobile and Electron for desktop
• Store publishing support, metadata generation, fastlane integration, and release checklists
• Autoplay and localization QA tools to catch gameplay regressions and translated UI overflow

What I learned

• AI-assisted production works best when paired with tight verification loops, deterministic capture scripts, and clear acceptance criteria
• Game feel still depends on traditional craft: readability, pacing, feedback, collision tuning, and control response
• Store assets and release automation can become first-class parts of the development pipeline instead of last-minute chores
• Small games are now a practical laboratory for AI-driven art, code, QA, and product workflows

RogueLLM is an experimental roguelike that combines traditional dungeon crawling with LLM-generated worlds. The player can request almost any setting, from a one-word theme to a detailed premise, and the system generates locations, enemies, items, and narrative flavor around that theme.

The current gameplay focuses on exploration, combat, equipment, and inventory management, with generated world descriptions and events providing the texture around the mechanics.

My work on the project

I built the prototype and have continued updating it as an AI-gameplay experiment. Major tasks include:

• Python web application for launching and playing generated roguelike sessions
• LLM-driven world generation for settings, locations, enemies, items, and descriptions
• Combat, inventory, equipment, health, attack, XP, and location-state systems
• Theme input flow that can turn short prompts or longer setting descriptions into playable worlds
• Search-provider support for enriching generated game descriptions when useful
• Seeded development worlds for repeatable local testing and smoke checks
• Browser UI for map navigation, character status, inventory, and event log display

What I learned

• LLMs are strongest in games when they provide variety and flavor while deterministic systems protect playability
• Generated content needs caching, validation, and repeatable seeds to stay debuggable
• Even simple mechanics feel richer when the generated theme changes the player’s expectations
• AI games need a careful boundary between improvisational text and stable game-state rules

This section summarizes the AI and machine-learning work that connects several of the newer projects listed above.

• Financial market forecasting using artificial neural networks
• Vehicle navigation, pathfinding, obstacle avoidance, and autopilot logic
• Custom C++ neural network implementation for inference and training
• Neural networks with PyTorch, Python, and C++/LibTorch
• Genetic algorithms, neuro-evolution, and REINFORCE-ES
• LLM applications with model routing, tool orchestration, memory, search, and agentic workflows
• AI-assisted production pipelines for games, tools, screenshots, localization checks, and release assets

Professional Journey

Below are the highlights of my involvement in AI and machine learning at various stages of my career.

1) Simulation and AI

My journey in machine learning started in 2017, when I began designing autopilot logic for the plane and missile airframes in my experimental flight simulator XPSVR.

Simulation is a key component of machine learning because it forms the basis for training at a much faster pace and a much reduced cost, especially when dealing with extremely expensive or dangerous tasks such as flight and weapon delivery.

2) Algorithmic Trading and Neural Networks

In 2018 I started applying ML to financial market forecasting for the ENZO Trading System.

By early 2023, my focus shifted toward artificial neural networks, tackling increasingly complex tasks from autonomous driving experiments to sophisticated time-series prediction models deployed in live trading.

3) LLM-Based Assistants and Agents

Since late 2023, my AI work has increasingly focused on LLM systems: model routing, tool use, memory, search, image generation, and agentic workflows.

That work is now represented most clearly by AskMei.ai, a production AI assistant and multi-instance platform, and by Little Control Room, a terminal-first AI development tool for coordinating Codex, OpenCode, Claude Code, and an experimental native agent called LCAgent.

4) AI-Assisted Games and Production Workflows

I also use AI as a production multiplier for games and interactive projects. Fractal Strike is an example of an AI-first game production workflow, while RogueLLM explores LLM-generated worlds and game content inside a deterministic roguelike structure.

Insights Gained

Building systems from simple cases was essential in grasping the core concepts involved.

In time-series prediction, Evolution Strategies (ES) proved effective, particularly with limited computational resources. While backpropagation is generally more efficient and likely a better long-term solution, the evolutionary approach provided a practical balance between exploration and exploitation. This balance is crucial in chaotic environments like financial markets, where the potential for useful predictions is debatable and top-tier research often remains undisclosed due to its financial significance.

In my opinion, time-series prediction can be especially challenging for backpropagation because of the chaotic nature of the task and the loss function, which must be carefully designed to avoid local minima and overfitting.

This research also highlighted the profound effects of training data, network architecture, hyperparameters, and loss function design. Crafting a loss function is particularly nuanced in trading, where there is no universal truth: many suitable outcomes exist, some more realistic than others, when it comes to training a model.

Technically, I honed my skills in using PyTorch both in Python and C++ (LibTorch), focusing on minimizing CPU-GPU data transfers, which is crucial for CPU-executed evolutionary strategies.

A key optimization was increasing tensor dimensionality, reducing the number of batches needed for each generation’s processing. Neuro-evolution’s explorative nature demands evaluating numerous models, a process that can be computationally intensive without efficient parallelization.

The more recent LLM work reinforced a different lesson: reliability comes less from a single clever prompt and more from architecture. Clear tool schemas, bounded agent loops, model tiering, memory hygiene, verification, and user control all matter.

A complete trading system for cryptocurrencies. See www.enzobot.com.

My work on the project

I developed most of the front-end and trading models in C++. Some of the major tasks are:

• Realized machine-learning driven trading algorithms and indicators
• Live trading on Bybit and Binance exchanges via REST and WebSocket APIs
• Backtesting infrastructure
  • Simulation of exchange orders, including HFT (sub-minute) data
  • Reporting of P&L, Calmar ratio, Sharpe ratio, Monte Carlo validation, etc.
• Risk management (see video Levels of risk management. Our approach summarized.)
• Live profit calculation and reporting
• TCP/IP client-server infrastructure to distribute trading signals to customers
• IPC protocol based on BSD sockets
• UI based on Dear ImGui
• Chart and indicators rendering in OpenGL

What I learned

• Challenges of building consistently profitable strategies
• Practical machine-learning application and techniques to reduce curve fitting
• REST API connectivity and crypto exchange protocols
• Risk and portfolio management techniques
• Leverage trading and short selling
• Usage of Dear ImGui for a complex project
• Reliance on multiprocessing for fault-tolerance

An image viewer capable of building composites of a stack of images with transparent regions. Source code at github.com/gugenstudio/xComp

This tool was built to visualize region updates of a render on top of previous renders, in real-time. Images found in a chosen folder to scan for, are quickly composited with alpha blending in a stack. OpenColorIO transformations are optionally added to the composite image, which can be saved out as a PNG.

My work on the project

I was the sole developer on this project. The main tasks were:

• Setting up a multi-platform UI infrastructure with Dear ImGui and GLFW
• Implementation and use of OpenEXR and OpenColorIO
• Image compositing with alpha blending and resampling
• UI to manage EXR layers and masks

What I learned

• Build and usage of OpenEXR and OpenColorIO

An experimental flight simulator built to mimic the F-35 Lighting II jet fighter. The project targeted VR for full-immersion.

Avionics display includes the famous 2-screen touch display of the F-35 and its windowing system that allows to configure the panels and to maximize and minimize various elements.

Rendering is performed with the OYK Game’s rendering engine which I originally wrote for mobile games, and that I later expanded for PC GPUs and OpenGL 4.5.

See more details on the XPSVR’s blog.

The flight dynamics, guidance, and avionics knowledge from this project is what OVERSWEEP is built on today.

My work on the project

I was the sole developer on this project. The main tasks were:

• Writing the game engine based on OpenGL and OpenAL
• Physically Based shaders, IBL and CSM (Cascaded Shadow Maps)
• Underlying rigid-body physics engine
• Flight model for the airplane and missiles
• Autopilot for the airplane and the weapons
• VR support for Oculus
• Custom image compression and geometry LOD for the terrain
• GUI system, customized to simulate the F-35 look and feel
• Advanced avionics such as TSD (Tactical Situation Display) with moving cursor and DAS (Digital Aperture System), the see-through system
• Floating HUD simulating Head Mounted Display

What I learned

• Building a simple FDM (Flight Dynamics Model)
• Weapon systems and guidance (Missile Launch Envelope, Proportional Navigation, etc.)
• Building a basic autopilot to maintain orientation and altitude
• Building avionic displays
• The F-35 user interface
• Use of CSM for large terrains

An arcade flight combat game with more than 1M downloads.

Fractal Combat X (successor of Fractal Combat), is an arcade flight combat game for mobile phones that has reached a wide distribution across multiple markets around the world.

It’s built with an in-house game engine which I developed in C++ on top of OpenGL ES. The game features a continuous terrain LOD capable of showing high detail at a very far distance with no perceptible far clipping.

See the joint technical presentation with Intel at GDC 2015, “Getting There First: OpenGL ES 3.1 and Intel Extensions in Fractal Combat X”

My work on the project

I was the sole developer on this project except for the Android platform. The main tasks were:

• Writing the underlying game engine
• Terrain LOD system with run-time light baking
• Implementation of OpenGL ES 3.1 tessellation, when available
• Dynamic skyline, with stratosphere and sun glare effects
• Dynamic destruction model for any 3D object
• Shadow mapping and IBL suitable for mobile
• VR support for Oculus GearVR, Google Cardboard or similar
• Custom image texture and audio compression
• Fractal terrain generation for certain stages
• 3D audio based on OpenAL
• GUI system, HUD

What I learned

• Terrain LOD and light baking on low-spec mobile systems
• OpenGL ES optimization for various mobile targets
• Use of in-app purchase and advertisement API calls
• Implementation of fun game controls for arcade flight combat games
• VR techniques for playability and to improve comfort for the player

The Final Freeway games have reached over 1M downloads across multiple markets.

Final Freeway is an arcade racing game I first released for iOS in 2010, later followed by an Android version and Final Freeway 2R. I still maintain and extend the original game; the screenshot above is from the recent Paris Sonnet stage.

It runs on an in-house C++ engine built on OpenGL ES. Its sprite-scaled road and roadside scenery deliberately recall the arcade racers of the 1980s and early 1990s, but that style also grew from a very practical decision about what one person could finish.

From a Java applet to Final Freeway

The project’s oldest ancestor is JavaKazRace, a small browser applet I wrote around 2000–2001 while I was between jobs and living in Huntington Beach, California. It already contained the central idea: an OutRun-like road rendered with old-school sprite scaling. A later C++ port became the technical starting point for Final Freeway nearly a decade later.

Most of JavaKazRace’s scenery began as 640×480 photographs I took along the Pacific Coast Highway with a Ricoh RDC-300Z, one of the early consumer digital cameras. I roughly clipped buildings, palm trees, people, and other details out of those photos. The same resourceful approach carried into Final Freeway: some vehicles began as small model cars photographed from the angles needed for their sprites.

This was more than a way to make programmer art cheaply. Choosing 2D avoided the model formats, materials, textures, geometry, and tooling that a 3D production would have required. The retro appearance turned those constraints into a coherent visual identity. It remains a useful game-development lesson: build with what you have, make the first version reachable, and leave room to add more after it ships.

My work on the project

I was the sole developer of the original iOS game; the Android platform work involved another developer. My main work included:

• Building the Java prototype, then porting and evolving its ideas into a C++ mobile game engine
• Writing and tuning the road model for a strong sense of speed and responsive play
• Creating a simple text stage format so new courses and roadside scenery could be assembled quickly
• Developing the photo-and-model sprite workflow and preparing much of the original artwork
• Building the OpenAL-based 3D audio and GUI systems
• Adapting the engine to early iOS devices and supporting the game through many later platform generations

What I learned

• Scope is part of game design: a deliberately small 2D pipeline can be the difference between an experiment and a shipped game
• Technical and artistic constraints can become the product’s identity rather than merely limiting it
• A modest prototype can compound in value when its strongest ideas survive later ports, products, and platforms
• Data-driven stages make content iteration practical for a very small team
• Early iOS and Android NDK development, OpenGL ES optimization, mobile publishing, promotion, and advertisement APIs

RibTools is an experimental open-source implementation of the basic Pixar’s RenderMan REYES rendering architecture. The parser is able to parse simple RenderMan rib scene and shaders which run on a custom VM. Rendering of the micropolygons is performed via SIMD CPU instructions.

Parallelism is implemented at all levels:

• Instruction level (adaptive N-way SIMD)
• Many-core hardware (multi-threading)
• Network-distributed rendering (custom protocol over TCP/IP)

See more details on: Implementing an experimental RenderMan compliant REYES renderer

My work on the project

I was the sole developer on this project. The main tasks were:

• Writing the rib scene parser
• RenderMan shader parser and compiler
• Implementation of a custom shader VM with SIMD opcodes
• Implementation of a REYES-style micropolygon renderer
• Flexible SIMD functions to write N-way parallel code
• Display and debugging infrastructure with OpenGL and GLUT
• Server-client code for distributed rendering

What I learned

• REYES-style micropolygon rendering
• Writing a shader compiler and VM
• Writing N-way vector and thread parallelism
• Basics of implementation of network-distributed rendering
• Use of CMake for multiplatform builds

While employed at Square Enix, Japan, I led the development of a next generation 3D engine capable of optimizing production rendering scenes and reproducing them in real-time with Direct3D and many-core hardware.

The development was built around production-rendering graphics assets for the cut scenes of the Final Fantasy XIII. Those cut scenes were originally meant to be played only as movie clips. Our job was that of playing back those same scenes in a real-time 3D engine, regardless of the complexity of the original assets.

The engine supported very high resolution geometry and multi-gigabyte textures as well as per-vertex animation. I wrote rendering and compression technology capable of reducing computing and storage for the target hardware. Rendering was performed with Direct3D 10. Compression used lossy approaches based on DCT, Wavelets and Zero-tree encoding.

My work on the project

I was the lead engineer on the runtime portion of the project. My main tasks were:

• Researching and developing new technology to handle massive production-rendering assets in real-time
• Writing the runtime rendering engine in Direct3D
• Writing custom GPGPU-friendly CODECs for texture and 3D geometry compression and streaming
• Working with hardware manufacturers to optimize graphics drivers

What I learned

• Multiprocessor and advanced SIMD architectures
• Maximizing performance around graphics drivers
• Managing and optimizing large 3D assets for production rendering
• Geometry compression techniques
• Workflow and assets for production rendering
• Team and project management

While employed at Arika, Japan, I worked on “Tetris: The Grand Master Ace”, a launch title for Xbox 360 in Japan.

My involvement was mostly as a system programmer, taking care of the Xbox 360 platform including, rendering engine, network programming, audio engine. At the time we were working on an extra tight schedule to match the Xbox 360 release.

My work on the project

I was the senior engineer on the project. My main tasks were:

• Writing the game engine in DirectX for the Xbox 360 (graphics, audio I/O)
• PC version of the game engine for Development
• Display and particle effects
• Network code for multiplayer: lobby, VDU packets
• Created a low-level reliable-protocol on top of VDP
• Analyze and solve publishing requirements for the Live store

What I learned

• Xbox 360 platform
• Network multiplayer code with lobby system and UDP/VDP packets

A real-time demo that uses Spherical Harmonics (SH) to quickly apply Image Based Lighting (IBL) for diffuse and ambient lighting.

The user can paint on a virtual cube map to freely apply lighting without the limitation of classical light sources.

The SH coefficients for the IBL are calculated on the CPU at every frame. The rendering is performed in OpenGL with a shader that calculates lighting of each vertex based on those SH coefficients.

This technique is based on the famous paper: “An Efficient Representation for Irradiance Environment Maps” by Ravi Ramamoorthi and Pat Hanrahan. I’ve since used Spherical Harmonics for diffused lighting or ambient lighting in every 3D engine that I wrote.

My work on the project

I was the sole developer on this project. The main tasks were:

• Implementation of the Spherical Harmonics coefficients on the CPU at every frame
• Shader that generates colors based on the SH coefficients
• A basic UI with an on-screen console and painting of the cube maps
• A system to record and replay events, for the demo mode

What I learned

• Application of Spherical Harmonics for lighting

While employed at SquareSoft, USA, I worked on the Windows port of the Final Fantasy VIII PlayStation game.

My main job was that of creating an abstraction layer between the PSX code and SquareSoft’s graphics library, which was based on DirectX. This drastically reduced porting time, as most code continued to compile as it did on the PlayStation.

Some code still needed fixing, in a few cases due to memory access bugs that did not appear on the original platform, due to lack of an MMU unit in the first PlayStation.

My work on the project

• Writing the abstraction layer that simulated PlayStation APIs and hardware on PC
• Alternative software rendering path for special effect, normally not possible via DirectX
• Adapt rendering code for the wild variety of graphics accelerators of the era
• Develop techniques to improve rendering quality with original (low res) assets

What I learned

• I built a deeper understanding of the PlayStation hardware
• Game code of Japanese RPG games
• Work in a mixed Japanese/international environment

In 1997 I started working on the PSEmu Pro, the first PlayStation emulator.

PSEmu Pro was possibly also the most consequential of the PSX emulators, due to its DLL plugin system that simplified the creation of more modern emulators, such as ePSXe.

Subsequent emulators could focus development on a subset of the hardware, while relying on existing plugins made for the PSEmu Pro, to support other key portions of the hardware such the GPU and the GTE.

My initial involvement was writing the GPU (Graphics Processing Unit) rendering emulation in software rendering. I eventually joined the other two original developers (Duddie and Tratax), with the Kazzuya nickname, forming the final core team.

Once in the team, I worked on anything necessary, most notably the GTE (Geometry Transformation Engine), and MDEC (Macroblock Decoder) emulation. Constantly balancing between performance and accuracy.

This was a non-commercial effort, done for the sake of the challenge itself. I worked on this in my spare time, coordinating the effort online via IRC (Internet Relay Chat).

My work on the project

• GPU software rendering emulation
• GTE emulation, used for 3D math
• MDEC emulation, used for video MJPEG-like decoding
• Gamepad controller plugin

What I learned

• Details about the PlayStation hardware
• Working with a fully-remote team
• Optimization techniques for fixed-point math operations
• Optimization techniques for video decoding

In 1997 I worked on the PC port (Windows and MS-DOS) of the now famous Oddworld Abe’s: Oddysee.

The game was originally written for the Sony PlayStation, which at the time had specialized hardware capabilities unavailable to consumer PCs, requiring creative solutions to achieve the same results with just a CPU. Although the game didn’t use 3D graphics, it ran on a 640x240 resolution and 16-bit color. The PC version was required to run at 640x480 with the same color resolution, with no hardware acceleration, using CPUs of the caliber of a Pentium 120.

My approach was to continue to use a 640x240 base resolution, but upscaling it with a cheap but effective smoothing filter that was fast enough for the target CPUs.

I also wrote an MDEC (Macroblock Decoder) simulator, to playback the movie assets in the original PlayStation format. The clips were essential to the narration of the game and were sometimes mixed with the live animation.

Video decoding had specialized hardware on the PSX, but had to be done with the CPU on PC, requiring some special optimizations to maintain the necessary frame rate to decode the 320x240 video clips and upscale them to 640x480.

My work on the project

• Wrote a rasterizer capable of rendering the PlayStation graphics primitives with a CPU on PC
• MDEC simulation capable of playing native MJPEG PlayStation videos on PC
• Various tasks to adapt and port the original code

What I learned

• In-depth PlayStation’s GPU calls
• Optimization techniques for 16-bit color rendering on SVGA resolution
• MDEC CODEC definition and implementation

In 1995 I worked on the PC port (MS-DOS) of Battle Arena Toshinden, a 3D fighting game and early PlayStation title.

For this port, we never received the full source code, so, much of the logic had to be written from scratch. My job was mostly writing the rendering engine, which had to run on regular Intel 486 and Pentium CPUs. I also wrote logic for the camera movement and some LAN network code (no Internet play yet !).

This was my first real job in the game industry, after a few years programming desktop software and developing 3D tech demos in my spare time (see RTMZ below).

A demo of the game is currently playable online at oldgames.sk !

My work on the project

• Wrote a software rasterizer for the 3D characters and environment
• Basic UI for options and main screen
• Logic for camera and controls

What I learned

• First steps into actual game development, albeit from a technical perspective

RTMZ (previously RTMX) is a tech demo that I developed in the mid 90s.

The goal for the demo was that of showing off the real-time 3D rendering capabilities that I accumulated in years of personal R&D, as a teenager with a passion for computer graphics and games. Thankfully, this landed my first job in the game industry. Nothing sells like a cool demo.

In 2022 I released the old source code on GitHub for historical purposes.

The demo is written mostly in ‘C’ (C++ still had major performance issues at the time), and it ran on MS-DOS with VGA and SVGA resolutions on a 256 colors palette.

Major features are:

• Gouraud shading
• Texture mapping
• Basic lighting and material properties
• Z-Buffer (optional)
• Cool menu interface

My work on the project

• I wrote a rasterizer with subpixel accuracy
• Implemented a materials system, within the limitations of 256 colors
• Wrote readers for OBJ, 3D Studio and Videoscape 3D formats
• Implemented a cool 3D UI and record+playback system for demo purposes

What I learned

• This was the testbed for my early 3D rendering
• Portions of my 3D library mimicked OpenGL calls, which at the time was not available on PC

In 1993 I worked on the Mac (“Macintosh” at the time) edition of Easy-CD Pro, the first CD burning software for the Mac.

Although by that time I had been developing in ‘C’ on the Mac for a while, this was the first commercial product with a relatively wide reach that I worked on.

This was also my first experience working with the English language with a native speaker, when the programmer for the ISO image engine (originally built on a Sun workstation !) came to Rome to help us integrate his engine into the product.

My work on the project

• I wrote the user interface, including a tree-view of the filesystem
• Implemented conversion of file names from Mac long format to ISO 9660
• Integrated the ISO image engine
• Various optimizations (file sorting. etc.)

What I learned

• CD burning software and formats
• Working in the context of an international team