Coordinate System

Getting Started ›› Basics ››
Parent Previous Next


Coordinate System


The library's screen origin (0,0) is the bottom-left corner, with Y increasing upward — the opposite of what many graphics libraries and image formats use, where (0,0) sits at the top-left and Y increases downward.
This is the first thing to internalize before writing any drawing code, since every coordinate you pass to every function in the library — TftPixel(), EpdBmpFromCode(), shape functions, everything — is expressed in this convention.


This isn't an arbitrary choice - it's a deliberate design decision made for three concrete reasons:


    1. It matches the standard Windows BMP format's own row order. BMP files store their pixel rows bottom-up internally, so an image converted straight from a BMP source needs no row-order recalculation or rotation to print correctly — what's stored first in the file is the bottom of the image on screen, with no translation step in between.
    1. It keeps ordinary screen math in unsigned arithmetic. A Y-increases-upward, all-non-negative coordinate system means most drawing code never needs signed coordinate types at all — the added complexity of SWord/SDword types and careful widening only shows up where it's genuinely unavoidable (rotation math being the clearest example elsewhere in this library), not scattered throughout ordinary, everyday drawing calls.
    1. It keeps screen Y-coordinates aligned directly with 0-based array and buffer indexing. Row 0 in a buffer is the bottom row on screen, row 1 is the row above it, and so on — no inversion step is needed anywhere to translate between "which row is this in memory" and "where does this appear on screen."

One practical consequence worth knowing early: since this is the library's own foundational convention, it's also why the image and font tools (PositronPixelFoundry.exe, SdCardWriteRGB565.exe, Ttf_Bdf_Flash.exe) and the format the  produce store data the same bottom-up way — see BMP Compression File Structure for the file-format-level details, if you're working with compressed images directly rather than just calling EpdBmpFromCode().

Created with the Personal Edition of HelpNDoc: Experience a User-Friendly Interface with HelpNDoc's Documentation Tool