Building a Wolf 3D-Style Engine in PlayBASIC with Affine-Textured Polygons

March 31, 2025

 

Building a Wolf 3D-Style Engine in PlayBASIC with Affine-Textured Polygons

The idea behind this project was simple: Could I recreate a Wolfenstein 3D-style engine in PlayBASIC while maintaining good perspective but using affine texture-mapped polygons instead of traditional raycasting?

Floors and Ceilings: Subdivision for Perspective

Classic Wolfenstein 3D engines rely on raycasting, but I wanted to explore using polygons. This introduced two key challenges: rendering walls and handling floors/ceilings. I tackled floors first by subdividing floor tiles near the camera, ensuring that closer surfaces were represented with a denser set of polygons. This approach worked well, maintaining an accurate perspective without excessive computational overhead.

Walls: Adaptive Subdivision

I applied the same technique to walls, subdividing them based on their distance from the camera. Surfaces closer to the viewer were represented with more polygons, while those farther away used fewer. This adaptive approach preserved scene perspective while optimizing performance.

Ensuring Proper Polygon Order

A major challenge with polygon-based rendering is ensuring proper drawing order. Since walls, floors, and ceilings are drawn as independent polygons, z-fighting (incorrect layering of polygons) can be an issue. To address this, I implemented a two-pass rendering system:

  1. 1. First, floors and ceilings are drawn.
  2. 2. Then, walls are rendered on top.

This method prevents z-popping artifacts commonly seen in painters’ algorithms and produces a visually appealing scene.

Enhancing the Classic Wolf 3D Look: Adding Light Mapping

To push beyond the classic Wolfenstein 3D aesthetic, I added a light mapping pass. Implementing this in PlayBASIC required rendering the scene twice—essentially brute force—but the cost was only around a 20% performance hit. The visual improvement, however, was well worth it.

The process involved:

  1. 1. Drawing the texture-mapped scene.
  2. 2. Overlaying a Gouraud-shaded version of each triangle, where each pixel’s color was alpha-blended with the background.

This resulted in a real-time light-mapped scene with a Doom-like atmosphere, enhancing immersion and depth.

Pushing Further: 3D Polygonal Characters Instead of Sprites

A long-standing idea I wanted to explore was replacing traditional 2D sprites with 3D polygon-based characters. This concept originated from my work on a rendering engine called "Reality" for Amiga computers back in 1995, which aimed to integrate both sprites and 3D objects within a scene.

Implementing 3D Objects

To bring this concept into PlayBASIC’s Wolf 3D engine, I needed a way to load and render 3D models. I chose the DirectX ASCII format due to its simplicity. The loader extracted three key components:

  • Vertex data (point locations)
  • UV data (texture mapping coordinates)
  • Face data (which vertices form polygons)

    • Fortunately, I had already written a PlayBASIC loader for this format years ago. With minor modifications, I incorporated it into the project and built a simple object library for dynamic 3D models within the scene.

    Sorting and Rendering 3D Objects

    Rendering 3D models in a PlayBASIC-based engine required an efficient way to order polygons. Rather than manually sorting faces, I leveraged PlayBASIC’s built-in 2D camera system. Each face was assigned an average depth value (Z-depth), and the engine used the camera’s sorting system to manage rendering order. This approach avoided the need for a costly manual sort, maintaining decent perspective despite the lack of true z-buffering.

    The final result was impressive: a Wolfenstein 3D-inspired environment with fully textured, light-mapped walls and floors—now featuring real 3D characters and objects.

    Future Optimizations: Reducing Overdraw with a Portal System

    One of the biggest challenges in 3D rendering is overdraw—when objects outside the visible scene are still processed and rendered. While the engine is fast enough to handle this, unnecessary rendering wastes performance.

    To optimize, I am experimenting with a portal-based rendering system. This system:

  • Connects open areas (portals) within the game world.
  • Checks which portals are visible from the camera’s current position.
  • Recursively determines visibility, ensuring only necessary polygons are processed.

    • This technique should significantly improve rendering efficiency without sacrificing visual fidelity. However, that’s a topic for a future update!

    Get the PlayBASIC Source Code

    You can download the full PlayBASIC source code for this project from our forums. Stay tuned for more updates as I refine the engine and explore new rendering techniques!

  • Yet Another Wolfenstein 3D Demo (Texture Mapped Floors & Ceiling)



    • 🔗

    G2D: Bringing OpenGL to PlayBASIC for Enhanced Rendering

    November 15, 2015

     

    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.

    Links:

  • G2D - 2D OpenGL library for PlayBASIC (WIP / BLOG / SCRATCH PAD)
  • PlayBASIC,com

    • 🔗

    Syntax Highlighting PlayBASIC Code Example

    August 03, 2012

     

    Vector Library

    This is simple library of 2d vector functions. Bellow is the example.

    PB PlayBASIC Code: 
    	//  Use a typed array to hold all the vectors we'll be using
	Dim vectors(100) as vector2d
	for lp =0 to getArrayElements(vectors())
		vectors(lp)= new vector2D
	next


	//  declare some pointers of type vector
	// for use in the examples
	Dim N as vector2d pointer
	Dim V1 as vector2d pointer
	Dim V2 as vector2d pointer
	Dim OldPoint as vector2D pointer

	//  Get pointers to some pre--alloated
	//  vectors in our cache array
	n = Vectors(0).vector2d
	V1 = Vectors(1).vector2d
	V2 = Vectors(2).vector2d


	Dim CurrentPoint as vector2D pointer
	CurrentPOint = Vectors(3).vector2d

	Dim OldPoint as vector2D pointer
	OldPOint = Vectors(4).vector2d

	Dim Lerp1 as vector2D pointer
	Lerp1 = Vectors(10).vector2d

	Dim Lerp2 as vector2D pointer
	Lerp2 = Vectors(11).vector2d


	SetVector2d lerp1, 500,100
	SetPolar2d lerp2, Rnd(36),rndrange(10,100)
	Addvectors2d Lerp2, Lerp2, Lerp1



	// Set up this vector
	Setvector2d OldPOint,Mousex(),MouseY()
	Flushmouse

	// -----------------------------------------
	Do
	// -----------------------------------------

		CLS


		// Set up this vecor
		Setvector2d CurrentPoint,Mousex(),MouseY()


		circlec OldPoint.X,OldPoint.Y, 50,true, $00ff00

		circle CurrentPoint.X,CurrentPOint.Y, 50,true


		// Subtract target from current  N = Old - Current
		Subvectors2d(N , oldPoint,CurrentPoint)

		ypos= 50

		text 10,Ypos, "Delta:"+StrVector2d$(N)

		//  Get the length of this delta vector
		Dist#=GetVectorLenght2D(N)

		// normalize N = and store it back in N
		GetVectorNormal2D(N , N)

		text 10,Ypos+30, "Normalized:"+StrVector2d$(N)


		//  Scale Normal by Dist#
		Multvector2d(N , N, Dist#)

		text 10,Ypos+60, "Scaled Normalized:"+StrVector2d$(N)

		//  Add origin (current point) back on.
		Addvectors2d(N , N, CurrentPoint)

		text 10,Ypos+90, "Result:"+StrVector2d$(N)


		//  Scale it  so we can draw line between them
		line CurrentPOint.x,CurrentPOint.y,n.x,n.y

		if Mousebutton()=1
				CopyVector2d OldPoint,CurrentPOint
		endif


		//  test lerp
		Linec Lerp1.x,Lerp1.y,Lerp2.x,Lerp2.y, $ff00ff

		//
		LerpFrame		=mod(LerpFrame+1,100)
		LerpScale#		=LerpFrame/100.0

		LerpVector2d N,Lerp1,Lerp2,LerpScale#

		Circlec n.x , n.y, 5, true ,$ff00ff


		//  Curve Lerp vector to the one between
		LerpVector2d V1,Lerp1,Lerp2,LerpScale#
		LerpVector2d V2,CurrentPoint,OldPoint,LerpScale#
		LerpVector2d V1,V2,V1,LerpScale#
		Circlec v1.x , v1.y, 5, true ,$ff00ff

		LerpVector2d V1,Lerp1,Oldpoint,LerpScale#
		LerpVector2d V2,lerp2,CurrentPoint,LerpScale#
		LerpVector2d V1,V2,V1,LerpScale#
		Circlec v1.x , v1.y, 5, true ,$ff00ff

		Sync

loop  Spacekey()


    🔗