Graphics Overview
OpenBOR uses a software-composited graphics system designed primarily for sprite-based games. Images, background layers, entities, text, primitive shapes, and scripted subscreens are collected into a drawing queue, ordered by layer, rendered into a 32-bit logical screen, and finally presented by the platform video backend.
This arrangement separates game graphics from the physical display. Creators define the logical resolution and visual composition of a project, while OpenBOR handles window sizing, fullscreen scaling, aspect ratio, filtering, and final presentation.
The basic pipeline is:
Source images and generated graphics
|
v
Load, trim, and cache assets
|
v
Build the sprite drawing queue
|
v
Sort by layer and sort ID
|
v
Compose into the 32-bit logical screen
|
v
Optional software scaling or filtering
|
v
Present through SDL or OpenGL backend
Source Graphics
Regular OpenBOR graphics use PNG images. Character frames and most other sprites normally use non-interlaced indexed PNG files. Indexed images allow palette replacement and efficient storage while the finished display is rendered in full color.
True-color PNG images are also supported for backgrounds and background layers.
| Graphic type | Recommended format | Notes |
|---|---|---|
| Character and entity sprites | Indexed PNG | Supports palettes, remaps, and automatic transparent-border trimming. |
| Icons, fonts, and interface sprites | Indexed PNG | Drawn through the same sprite system as other graphic elements. |
| Backgrounds and stage layers | Indexed or true-color PNG | Indexed backgrounds may provide the module palette. True-color backgrounds are loaded through the 32-bit image path. |
| Animated cutscenes | Animated GIF | Played through the cutscene system. GIF is not a general-purpose sprite format. |
Transparent borders surrounding a sprite are trimmed when the image is loaded. OpenBOR preserves the original alignment by recording the trimmed offset, so creators do not normally need to crop every frame manually.
Previously loaded sprites are cached and may share encoded image data when the same source image is used with different offsets.
True-Color Sprites
OpenBOR is intentionally designed to render individual sprites using indexed color. This compact representation is one reason its software-driven graphics pipeline can withstand immense sprite loads without frame-rate loss. Indexed sprites also provide efficient palette replacement, remapping, tinting, and color-channel manipulation.
When RGB color is required, OpenBOR can produce a true-color image by compositing a meta-sprite from three indexed sprites:
- Red channel.
- Green channel.
- Blue channel.
Each component is drawn at the same position using the corresponding channel drawmethod. OpenBOR composites the red, green, and blue components into the final true-color image during normal rendering.
Note: OpenBOR's software renderer is an artifact of an earlier console portability policy that has since been discontinued. Hardware-accelerated rendering and direct RGBA sprite support are currently in development.
Graphics Pipeline
Asset Loading
OpenBOR decodes source images and converts them into an internal bitmap, sprite, or screen representation.
Sprites are trimmed and encoded for repeated drawing. Background images remain screen-like rectangular buffers. Indexed graphics retain palette information needed for palette replacement and other color effects.
Drawing Queue
Game objects do not normally draw themselves directly to the physical display. Instead, OpenBOR submits drawing entries to the sprite queue.
Queue entries may include:
- Sprites and animation frames.
- Background layers.
- Subscreens.
- Text glyphs.
- Dots.
- Lines.
- Boxes.
The queue supports up to 5000 entries. Text is also composed from sprites, so every displayed character contributes to the queue total. Entries submitted after the limit is reached are not drawn.
Layer Sorting
Each queued item has a drawing layer, internally represented by its queue Z value. Items with lower values are drawn first, while items with higher values are drawn later and therefore appear in front.
When two items have the same layer, OpenBOR uses a secondary sort ID to determine their order.
Lower layer
|
| Background scenery
| Stage objects
| Entities and effects
| HUD and interface
v
Higher layer
This provides object-level Z ordering suitable for a game world with foreground and background depth.
Tip: Use explicit layer adjustments for effects that must reliably appear in front of or behind another object. Submission order alone should not be treated as a substitute for layer control.
Software Composition
Once sorted, the queue is rendered into OpenBOR's logical screen. The main logical screen is a 32-bit software buffer with the width and height selected by the module.
Draw effects, palette conversion, blending, transformations, clipping, and subscreen composition occur during this stage.
Final Presentation
After composition, OpenBOR passes the finished logical screen to the platform video backend. The backend may perform color conversion, software filtering, texture upload, display scaling, brightness adjustment, and final presentation.
SDL and OpenGL are presentation backends. Core sprite composition remains software based.
This distinction is important:
- Increasing the logical resolution provides more space and potential detail to the game.
- Increasing the window or output size enlarges the finished image without changing the game's logical coordinate system.
- Display filtering changes how the enlarged image appears but does not add new source detail.
Draw Effects
Drawmethod is the common collection of properties OpenBOR uses to alter an item while drawing it. Entities, animation frames, stage layers, scripted sprites, and subscreens can expose some or all of these properties.
| Effect group | Capabilities |
|---|---|
| Palette and color set | Replace an indexed sprite's palette or select one of the model's available color sets. |
| Blend | Apply transparency and supported blend modes, including alpha, negative alpha, overlay, hard light, dodge, and average blending. |
| Tint and channels | Tint an image, reduce individual red, green, or blue channels, or fill visible pixels with a specified color. |
| Orientation | Flip an image horizontally or vertically. |
| Scale | Resize an image independently along its horizontal and vertical axes. |
| Rotation | Rotate an image around its drawing center. |
| Shift | Skew the image horizontally. |
| Clipping | Restrict drawing to a rectangular area. |
| Repetition | Repeat supported layers or screens with configurable spacing. |
| Water and plane transformation | Apply sine-wave distortion, shear, and perspective-like scaling effects. |
Drawmethod effects are evaluated by the software renderer. Transforming a large image or full-screen buffer is consequently more expensive than transforming a small sprite.
Not every drawing item supports every property in the same way. Some effects also select different drawing paths and may not combine meaningfully with every other effect.
For property-level documentation and script access, see Drawmethod.
Alpha Masks
Alpha masks provide pixel-level control over blending. Instead of applying one transparency value uniformly across an entire sprite or screen, a mask determines the blending treatment of individual pixels.
This enables effects such as:
- Soft or irregular transparency.
- Dissolves and materialization effects.
- Selective reflections and highlights.
- Layered lighting and shadow masks.
- Complex silhouettes and partial reveals.
- Localized blending across sprites, backgrounds, or subscreens.
Combined with drawmethods, color channels, and subscreen composition, alpha masks provide many effects ordinarily associated with a shader-driven graphics pipeline.
Subscreens
OpenBOR includes the ability to allocate self-contained 32-bit drawing surfaces called subscreens.
Creators may assemble sprites, text, primitive shapes, captured queue layers, and other generated graphics independently, then insert the completed surface into the main drawing queue as a single item.
This makes subscreens useful for picture-in-picture displays, mirrors, custom interfaces, cached compositions, localized effects, cutscenes, perspective transformations, and other advanced rendering techniques. See Subscreens for allocation, direct drawing, queue capture, composition, drawmethod effects, lifecycle management, and examples.
Resolution
OpenBOR distinguishes the module's logical resolution from the final display resolution.
Logical Resolution
The video setting in data/video.txt selects the width and height of the logical screen.
OpenBOR provides the following compatibility presets:
| Mode | Logical resolution |
|---|---|
| 0 | 320 × 240 |
| 1 | 480 × 272 |
| 2 | 640 × 480 |
| 3 | 720 × 480 |
| 4 | 800 × 480 |
| 5 | 800 × 600 |
| 6 | 960 × 540 |
Example:
video 6
Custom logical resolutions use a width and height separated by a lowercase x:
video 1280x720
Preset resolutions are compatibility conveniences rather than graphical capability tiers. Custom dimensions allow projects to target widescreen, portrait, low-resolution pixel art, or other layouts.
Note: Use widths divisible by four. OpenBOR's screen allocator aligns screen widths downward to a multiple of four.
No single practical maximum resolution applies to every platform. Available memory, CPU performance, display backend texture limits, optional filter requirements, and target hardware all affect the usable size. Extremely large logical resolutions should therefore be tested on every supported platform.
Display Resolution
Window and fullscreen settings determine how the logical screen is presented. OpenBOR can enlarge or reduce the finished frame independently of the module's internal coordinates.
Display options include:
- Windowed or fullscreen output.
- Adjustable window scaling.
- Preserved aspect ratio or stretching to the available display.
- Nearest-neighbor or linear presentation scaling, depending on backend and selected settings.
- Optional 2× software filters, including simple scaling, bilinear filtering, AdvanceMAME, scanlines, television simulation, and dot-matrix effects.
- SDL or OpenGL presentation where supported.
Preserving aspect ratio may produce unused borders when the logical and physical displays have different shapes. Stretching fills the display but may distort the image.
Tip: Select logical resolution according to the project's artwork, camera, interface, and target hardware. Use final display scaling to fit different monitors instead of rebuilding the game around every possible desktop resolution.
Performance Considerations
Graphics cost generally increases with the number of pixels processed, the number of queued items, and the complexity of effects applied to them.
For efficient rendering:
- Choose a logical resolution appropriate for the artwork.
- Reuse subscreens rather than repeatedly allocating them.
- Keep temporary subscreens close to the required dimensions.
- Avoid applying full-screen transformations when a smaller affected region is sufficient.
- Remember that text consumes sprite queue entries.
- Use explicit drawing layers instead of relying on incidental queue order.
- Test blending, rotation, water effects, and multiple subscreens on lower-powered target devices.
- Treat software filters and output scaling as presentation features rather than substitutes for suitable source artwork.