This is the complete Title / Intro from our 1995 Amiga game called Thesius XII. Sadly the game was never 100% finished, but even so, back around 2000 / 2001 we released an 'as is' version with three levels, but it's missing lots of the final polish from the game.
Thesius XII is yet another side scrolling shoot'em up game from those days, loosely inspired by such classics as R-Type & SilkWorm (was a big fan of that) and many other shooter of that time really. The game was designed for stock Amiga 500 running 7mhz 68000cpu, 512K Memory and Original Chip Set. The intro might look pretty plain today, but I remember it being fairly challenging to get the running at speed on the stock hardware.
If you into a bit of nostalgia, you can download Thesius XII from our site.
This is a clip of the Intro / Options Screen from our 1995 Amiga game called Thesius XII. The game was designed to be fairly flexible, so the user could enable or disable some of the key features during play. For such things as the explosion particle count, parallax effects, sound and even some tweaks for homing missiles.
The Homing missiles are probably my favourite section of code in the entire game. I remember a lot of work into them at the time, and looking back they seems to work fairly well.
Thesius XII Level 01 Terminal (Amiga Game)
This clip is from Level #1 Terminal from our 1995 Amiga game called Thesius XII. The terminal was meant to give the player a briefing about the up coming level as if there was some type of short to the game..but it's a shoot'em up... so... overkill... erm yeah... :)
In retrospect, there's a lot more stuff going on it here than I remember, from dynamic palette and resolution splitting, through to wire frame vectors to chunky image scaling. If you look closely (even in the video), you'll notice the screen is in both low and high resolution. The top section is in 32 colour low res (everything above the terminal window), with palette splits on every scan line through the video window. The terminal window at the bottom is in hires 16 colour. There's copper resolution switches on every scanline.. This makes the text in the terminal look a lot cleaner, but places a lot of extra drag from gfx hardware. Making it one of the hardest parts to write at the time..
Thesius XII - High Score Entry
This is a clip of the High Score entry screen from our 1995 Amiga game called Thesius XII. Looking back on it, this is perhaps my favourite piece of music in the game, even visually I'm fairly happy with it.
G2D: Bringing OpenGL to PlayBASIC for Enhanced Rendering
G2D is a promising alternative rendering library for PlayBASIC, offering an OpenGL-based solution for graphics rendering. While PlayBASIC traditionally uses DirectX and software rendering, G2D leverages the power of the OpenGL API to provide a more efficient and flexible rendering option. Although G2D is still in its early stages, the library has already shown significant potential in terms of compatibility and performance.
What is G2D?
At its core, G2D is a minimal rendering library built to work with PlayBASIC, a beginner-friendly programming language for game development. It replaces PlayBASIC’s default rendering system with OpenGL, offering a faster, more modern alternative for developers seeking improved graphical performance.
Currently, G2D supports a basic set of commands, including primitives like lines, shapes, and images. These commands work similarly to their PlayBASIC counterparts, but all rendering happens on the OpenGL canvas, ensuring faster performance in windowed modes.
It’s important to note that G2D is currently only compatible with PlayBASIC’s windowed modes, as it directly attaches the OpenGL viewport to the PlayBASIC window. To hide the default DirectX screen, you can use the `ScreenLayout` command to position it outside the window.
Building Basic Image Support
One of the first features G2D developers focused on was integrating basic image commands. The goal was to maintain compatibility with PlayBASIC’s internal image management system (AFX) while utilizing OpenGL for rendering. When an image is loaded into G2D, it’s first imported into PlayBASIC’s internal image slot and then converted into a texture that OpenGL can use. This dual approach allows developers to continue using PlayBASIC’s native sprite and collision functions while benefiting from the performance gains of OpenGL.
Expanding Core Primitives
In the early stages, G2D developers concentrated on expanding the core primitive commands for more complex scenes. One challenge was making sprites compatible with OpenGL’s efficient rendering pipeline. OpenGL, like Direct3D, performs best when rendering many polygons from a single texture to reduce overhead, but PlayBASIC’s sprites are handled differently.
To solve this, G2D developers experimented with ways to efficiently render sprites while preserving PlayBASIC’s collision and vector-based interactions. One solution was creating a dedicated GL sprite layer that caches texture states, reducing texture swaps between polygons. This approach mitigates performance issues when sprites constantly switch textures.
For maps, G2D introduced the `g2dDrawMap` function, which allows PlayBASIC maps to be rendered using OpenGL textures. This function takes parameters like texture index and map layout, enabling seamless integration with PlayBASIC’s map system while utilizing OpenGL for faster rendering.
Optimizing Sprite Rendering with `g2dDrawAllSprites`
After implementing basic image support, the G2D team moved on to optimizing sprite rendering. The `g2dDrawAllSprites` function was introduced to handle large numbers of sprites efficiently. It takes advantage of OpenGL’s ability to batch multiple sprite draw calls into a single operation, improving performance even with a high volume of sprites.
In early tests, the `g2dDrawAllSprites` function was able to render 1000 anti-aliased sprites at 27 frames per second on a standard test machine without optimization. While impressive, G2D developers acknowledged the need for further optimizations to improve rendering speed.
Dealing with Sprite Issues and Legacy Commands
During development, the G2D team encountered challenges with legacy PlayBASIC sprite commands, particularly functions like `GetSpriteRect()` and `SpriteInRegion()`, which are critical for determining sprite visibility and bounding boxes in the OpenGL viewport. These functions were causing crashes and unexpected behavior, so the G2D team worked to fix them.
The fixes involved rewriting portions of the code to ensure that the OpenGL-based wrapper functions interacted correctly with PlayBASIC’s internal sprite system. While some legacy functions, like sprite clipping, may still not work as expected, these issues are being addressed in ongoing updates.
Introducing `g2dDrawOrderedSprite` for Scene Sorting
To further optimize G2D, the team introduced the `g2dDrawOrderedSprite` function, which allows sprites to be sorted by depth values. This ensures that objects closer to the camera are rendered in front of objects that are farther away—essential for creating 2D scenes with proper layering and depth.
The `g2dDrawOrderedSprite` function works similarly to PlayBASIC’s `DrawOrderedSprite` command, but with the added advantage of OpenGL’s GPU acceleration. This enhancement allows G2D to handle complex scenes more efficiently by offloading rendering to the GPU.
Future Plans and Challenges
Although G2D has made impressive strides, many features and improvements are still in the works. Future updates will focus on adding interfaces for more advanced features like maps, shapes, and fonts. The G2D team is also working to resolve performance issues related to texture sizes, particularly for fonts, which may cause problems if the texture exceeds the size limits of older graphics cards.
For font rendering, the team plans to convert text into meshes and render them onto the OpenGL surface. While feasible, this approach requires attention to texture sizes, especially for large characters. As G2D continues to evolve, the goal is to make font rendering more flexible and optimized for a wide range of hardware configurations.
Conclusion
G2D is an exciting new rendering library for PlayBASIC that harnesses the power of OpenGL for faster and more efficient graphics rendering. Although still in the early stages, G2D already provides a solid foundation for developers looking to enhance the graphical performance of their PlayBASIC projects. With ongoing improvements and optimizations, G2D promises to be a valuable tool for PlayBASIC developers, offering more flexibility and control over rendering while maintaining compatibility with PlayBASIC’s internal systems.
As G2D evolves, it has the potential to become a go-to solution for developers looking to push the limits of PlayBASIC and OpenGL, making it an exciting development to follow for anyone interested in 2D game programming with PlayBASIC.
About the Author:
Kevin Picone is the creator of PlayBASIC, a beginner-friendly programming language for creating 2D games, and the lead developer of the G2D particle library. With years of experience in both game development and programming tools, Kevin is passionate about making powerful game creation tools accessible to everyone, from beginner to advanced developers.