| 1 |
6 |
Orka |
\documentclass[10pt,a4paper]{article}
|
| 2 |
|
|
\usepackage[latin1]{inputenc}
|
| 3 |
|
|
\usepackage{amsmath}
|
| 4 |
|
|
\usepackage{amsfonts}
|
| 5 |
|
|
\usepackage{amssymb}
|
| 6 |
|
|
\usepackage{hyperref}
|
| 7 |
|
|
|
| 8 |
|
|
\usepackage{graphicx}
|
| 9 |
|
|
\usepackage{listings}
|
| 10 |
|
|
|
| 11 |
7 |
maiden |
\usepackage[margin=3cm]{geometry}
|
| 12 |
|
|
|
| 13 |
6 |
Orka |
\author{Per Lenander, Anton Fosselius}
|
| 14 |
|
|
\title{ORSoC Graphics accelerator Specification}
|
| 15 |
|
|
\begin{document}
|
| 16 |
|
|
|
| 17 |
|
|
\maketitle
|
| 18 |
|
|
|
| 19 |
|
|
\begin{center}
|
| 20 |
|
|
\includegraphics[scale=1.0]{../pictures/OpenCores}
|
| 21 |
|
|
\end{center}
|
| 22 |
|
|
|
| 23 |
|
|
\begin{center}
|
| 24 |
|
|
\includegraphics[scale=0.50]{../pictures/wb_compatible}
|
| 25 |
|
|
\end{center}
|
| 26 |
|
|
|
| 27 |
|
|
\newpage
|
| 28 |
|
|
|
| 29 |
|
|
\section*{Revision history}
|
| 30 |
|
|
\begin{tabular}{|p{1cm}|p{2cm}|p{3cm}|p{7cm}|}
|
| 31 |
|
|
\hline \textbf{Rev.} & \textbf{Date} & \textbf{Author} & \textbf{Description} \\
|
| 32 |
|
|
\hline
|
| 33 |
7 |
maiden |
\hline 1.0 & 23/3/2012 & Per Lenander & Initial draft and basic functionality \\
|
| 34 |
|
|
\hline 2.0 & 4/6/2012 & Per Lenander & Advanced functionality (vector, 3D etc) \\
|
| 35 |
6 |
Orka |
\hline
|
| 36 |
|
|
\end{tabular}
|
| 37 |
|
|
\newpage
|
| 38 |
|
|
|
| 39 |
|
|
\tableofcontents
|
| 40 |
|
|
\newpage
|
| 41 |
|
|
|
| 42 |
|
|
\section{Introduction}
|
| 43 |
|
|
The ORSoC Graphics accelerator allows the user to do advanced vector rendering and 2D blitting to a memory area. The core supports operations such as drawing textures, lines, curves and filling rectangular and triangular areas with color.
|
| 44 |
|
|
|
| 45 |
|
|
This IP Core is designed to integrate with the OpenRISC processor through a Wishbone bus interface. The core itself has no means of displaying the information rendered, for this purpose it can work alongside a display component, such as the enhanced VGA/LCD IP core found on OpenCores.
|
| 46 |
|
|
|
| 47 |
|
|
\subsection{Features}
|
| 48 |
|
|
\begin{itemize}
|
| 49 |
|
|
\item 32-bit Wishbone bus interface
|
| 50 |
|
|
\item Integrates with enhanced VGA/LCD IP core
|
| 51 |
|
|
\item Support for 16 bit color depth
|
| 52 |
|
|
\item Support for variable resolution
|
| 53 |
|
|
\item Acceleration of line operations
|
| 54 |
|
|
\item Acceleration of rectangle and triangle rasterization
|
| 55 |
|
|
\item Acceleration of memory copy operations
|
| 56 |
|
|
\item Textures can be saved to video memory
|
| 57 |
|
|
\item Vector transformation and rasterization
|
| 58 |
|
|
\item Clipping/Scissoring
|
| 59 |
|
|
\item Alpha blending and colorkeying
|
| 60 |
|
|
\item Filled Bezier curves
|
| 61 |
|
|
\item Bitmap Fonts
|
| 62 |
|
|
\item Vector Fonts (ttf)
|
| 63 |
|
|
\item Interpolation of colors
|
| 64 |
|
|
\item UV-Mapping
|
| 65 |
|
|
\item Transformation (scaling and rotation)
|
| 66 |
7 |
maiden |
\item 3D model support (.obj model files built using 3rd degree polygons)
|
| 67 |
|
|
\item Z-Buffer (triangles drawn in depth order)
|
| 68 |
|
|
\item Requires around 10000 Slice LUTs (Xilinx ISE 13.4)
|
| 69 |
6 |
Orka |
\end{itemize}
|
| 70 |
|
|
|
| 71 |
|
|
\subsection{IP Core directory structure}
|
| 72 |
7 |
maiden |
A overview of the contents of the IP core source folder can be found in figure \ref{fig:directory}.
|
| 73 |
6 |
Orka |
|
| 74 |
|
|
\begin{figure}
|
| 75 |
|
|
\begin{center}
|
| 76 |
|
|
\includegraphics[scale=0.5]{../pictures/directory}
|
| 77 |
|
|
\caption{Directory structure of the ORSoC graphics accelerator.}
|
| 78 |
|
|
\label{fig:directory}
|
| 79 |
|
|
\end{center}
|
| 80 |
|
|
\end{figure}
|
| 81 |
|
|
|
| 82 |
|
|
\section{Architecture}
|
| 83 |
|
|
\subsection{Overview}
|
| 84 |
7 |
maiden |
A topology of how the ORGFX is connected to the VGA driver and the OpenRISC core is shown in figure \ref{fig:topology}. The ORGFX has three wishbone interfaces: one read/write port that is used to communicate with the host CPU. One read port that reads depth/texture/alpha blending information from the RAM and one write port to write pixel information to the RAM.
|
| 85 |
6 |
Orka |
|
| 86 |
|
|
\begin{figure}
|
| 87 |
|
|
\begin{center}
|
| 88 |
|
|
\includegraphics[scale=0.60]{../pictures/topology}
|
| 89 |
|
|
\caption{Overview of the ORPSoCv2's wishbone interconnection.}
|
| 90 |
|
|
\label{fig:topology}
|
| 91 |
|
|
\end{center}
|
| 92 |
|
|
\end{figure}
|
| 93 |
|
|
|
| 94 |
|
|
\subsection{Concepts}
|
| 95 |
|
|
This section describes a few basic terms used in this document.
|
| 96 |
|
|
|
| 97 |
7 |
maiden |
\textbf{Video memory} -- The ORGFX component writes pixels one by one to an external memory, usually a SDRAM or DDR RAM chip. The CPU should also have access to this memory space to be able to write pixels directly (the easiest way to load textures).
|
| 98 |
6 |
Orka |
|
| 99 |
|
|
\textbf{Render target} -- The render target, defined by the target base and size registers, describes the area to which all operations render pixels. It is possible to change the base address and size, enabling render-to-texture and double buffering.
|
| 100 |
|
|
|
| 101 |
7 |
maiden |
\textbf{Surface/Texture} -- Any memory area that can be rendered to, including the render target, is considered a surface. A surface is defined by it's base address and size. There are two main surfaces that the ORGFX device handles: the render target and the currently active texture. Swapping between different textures has to be done in software. The operation of setting the current render target or texture is referred to as \textit{binding}.
|
| 102 |
6 |
Orka |
|
| 103 |
|
|
\textbf{Source, Destination and Clip rectangles} -- There are three sets of rectangles that affect rendering, each described by two points. The first point sets the beginning of the rectangle, while the second point sets the pixel after the end of the rectangle. This way, a rectangle exactly filling the screen would be (0,0,640,480) at 640x480 resolution. See figure \ref{fig:SrcClipDest};
|
| 104 |
|
|
|
| 105 |
|
|
\textbf{Source rectangle} -- The source rectangle defines what pixels should be read from a texture during textured operations. The points are defined in the coordinates of the currently bound texture. This way sections of a texture can be drawn (good for tile maps or bitmap fonts).
|
| 106 |
|
|
|
| 107 |
|
|
\textbf{Destination rectangle} -- The destination rectangle defines where operations such as draw pixel and draw line will draw pixels, in the coordinates of the render target.
|
| 108 |
|
|
|
| 109 |
|
|
\textbf{Clip rectangle} -- The clip rectangle defines an area within the current render target which is valid to draw to. Any pixels outside this rectangle are discarded in the rasterization step. Pixels outside of the render target are automatically discarded.
|
| 110 |
|
|
|
| 111 |
7 |
maiden |
\textbf{Z-buffer} -- The depth or Z-buffer is a surface containing z coordinate information. This can be used to draw graphics primitives in depth-correct order.
|
| 112 |
|
|
|
| 113 |
6 |
Orka |
\begin{figure}
|
| 114 |
|
|
\begin{center}
|
| 115 |
|
|
\includegraphics[scale=0.50]{../pictures/SrcClipDest}
|
| 116 |
|
|
\caption{1. Texture, 2. Source, 3. Render target, 4. Clip, 5. Destination}
|
| 117 |
|
|
\label{fig:SrcClipDest}
|
| 118 |
|
|
\end{center}
|
| 119 |
|
|
\end{figure}
|
| 120 |
|
|
|
| 121 |
|
|
\subsection{Coordinate precision}
|
| 122 |
7 |
maiden |
The ORGFX core supports variable coordinate precision through two parameters, \textbf{point\_width} and \textbf{subpixel\_width}. Both parameters defaults to 16 bits width.
|
| 123 |
6 |
Orka |
|
| 124 |
|
|
Target size, clip and source rects are defined as \textbf{point\_width} bit integers. Destination points are defined as fixed point numbers, with \textbf{point\_width} bit integer precision and \textbf{subpixel\_width} fractional precision. Internally many calculations are done with fixed point logic.
|
| 125 |
|
|
|
| 126 |
|
|
\subsection{Instruction FIFO}
|
| 127 |
|
|
All wishbone writes sent to the slave interface will pass through an instruction fifo. If the device is in the busy state (when the pipeline is active) the instruction will be queued instead of being set immediately. This is important to take into account when reading from registers, since an operation that changes the register being read might be queued. To find out if the device is busy, poll the status register and check if the busy bit is high.
|
| 128 |
|
|
|
| 129 |
|
|
\subsection{Pipeline}
|
| 130 |
7 |
maiden |
The ORGFX core uses a pipelined architecture to speed up operation. An overview of the pipeline can be seen in figure \ref{fig:pipeline}. Each module in the pipeline communicates with acknowledge and write signals. A module will not assert write to the next module unless it receives an ack first (or if the module was previously in a ready state, in which case the downstream pipeline is empty). All ack and write signals are always exactly one clock tick long, to prevent triggering multiple instances of the same instruction.
|
| 131 |
6 |
Orka |
|
| 132 |
|
|
Each module in the pipeline may hold the upstream pipeline for several clock ticks. For example, the rasterizer will prevent incoming raster instructions until all the pixels for the current operation are generated. When the rasterizer is ready for new data, it will send an ack upstream.
|
| 133 |
|
|
|
| 134 |
|
|
% The pipeline begins with the \textbf{transformation processor}, it calculates transformations like rotations and scaling. There after the next step in the pipeline is the \textbf{vector processor}, if there is no vector operations to be done, this step is skipped. When the vector calculations is done (if needed) the next step is the \textbf{rasterizer}, its purpose is to convert points into pixels. When there are a request to write a rectangle, the \textbf{rasterizer} receives two points and outputs all the pixels between those points. The pixels generated by the \textbf{rasterizer} is recieved by the \textbf{fragment processor}. In the \textbf{fragment processor} the pixel gets a color either by a pre-set color or from a texture (via the \textbf{wishbone read} from the \textbf{memory}). The colored pixel is then sent to the \textbf{blender} which handles alpha blending. If alpha is enabled, the \textbf{blender} will read from the address in the \textbf{memory} where the pixel is going to be drawn. Then the new color is calculated based on the pixel color and the alpha value. The pixel is then passed on to the \textbf{renderer} which calculates the address in the memory where the pixel is going to be written. The pixel is then passed on to the \textbf{wishbone write} interface and finally to the render target in the \textbf{memory}.
|
| 135 |
|
|
|
| 136 |
|
|
\begin{figure}
|
| 137 |
|
|
\begin{center}
|
| 138 |
|
|
\includegraphics[scale=0.35]{../pictures/pipeline}
|
| 139 |
7 |
maiden |
\caption{Picture of the ORGFX pipeline}
|
| 140 |
6 |
Orka |
\label{fig:pipeline}
|
| 141 |
|
|
\end{center}
|
| 142 |
|
|
\end{figure}
|
| 143 |
|
|
|
| 144 |
|
|
\subsection{Description of core modules}
|
| 145 |
|
|
|
| 146 |
|
|
\subsubsection{Wishbone slave}
|
| 147 |
7 |
maiden |
The wishbone slave handles all communication from the main OpenRISC processor (or other master CPU). This component holds all the registers, and the instruction FIFO that sets them. This component can be in one of two states: \textit{busy} or \textit{wait}. It enters the busy state when a pipeline operation is initialized, and returns to the wait state when the operation is finished. Operations can be initialized by writing to the control register (see section \ref{sec:registers}).
|
| 148 |
6 |
Orka |
|
| 149 |
|
|
\subsubsection{Transformation processor}
|
| 150 |
|
|
The transformation processor handles rotations and scaling.
|
| 151 |
|
|
|
| 152 |
|
|
\subsubsection{Rasterizer}
|
| 153 |
|
|
This rasterizer generates pixel coordinates from points for several different operations.
|
| 154 |
|
|
|
| 155 |
|
|
\subsubsection{Clipper}
|
| 156 |
|
|
Discard generated pixel if clipping is enabled and pixel is out of bounds. Always discard pixels outside of the target area.
|
| 157 |
|
|
|
| 158 |
|
|
\subsubsection{Fragment processor}
|
| 159 |
|
|
The fragment processor adds color to the pixel generated by the rasterizer. If texturing is disabled, a color supplied from the color register is used. If texturing is enabled on the other hand, the u v coordinates supplied by the rasterizer are used to fetch a pixel from the active texture. If colorkeying is enabled and the fetched color matches the color key, the current pixel is discarded.
|
| 160 |
|
|
|
| 161 |
|
|
\subsubsection{Blender}
|
| 162 |
|
|
The blender module performs alpha blending if this is enabled. The module fetches the color of the pixel that the current operation will write to, and the mixes the value of the target color and the color from the fragment processor using the following algorithm:
|
| 163 |
|
|
|
| 164 |
|
|
\begin{quote}
|
| 165 |
|
|
$ alpha = alpha_{global} * alpha_{pixel} $
|
| 166 |
|
|
|
| 167 |
|
|
$ color_{out} = color_{in} * alpha + color_{target} * (1 - alpha) $
|
| 168 |
|
|
\end{quote}
|
| 169 |
|
|
|
| 170 |
|
|
Where alpha is a value between 0 (transparent) and 1 (opaque). If alpha blending is disabled the pixel is passed on unmodified. The alpha value can be interpolated over a triangle to create gradients. If this function is turned off (interpolation is disabled on triangle draws) then $alpha_{pixel}$ is set to 1.
|
| 171 |
|
|
|
| 172 |
|
|
\subsubsection{Wishbone arbiter}
|
| 173 |
|
|
Since two parts of the pipeline (fragment and blender) needs to access video memory, the arbiter makes certain only one of them can access the reader at once. The blender has the highest priority.
|
| 174 |
|
|
|
| 175 |
|
|
\subsubsection{Wishbone master read}
|
| 176 |
|
|
The wishbone reader handles all reads from video memory.
|
| 177 |
|
|
|
| 178 |
|
|
\subsubsection{Renderer}
|
| 179 |
|
|
The renderer calculates the memory address of the target pixel.
|
| 180 |
|
|
|
| 181 |
|
|
\subsubsection{Wishbone master write}
|
| 182 |
|
|
The wishbone master handles all writes to the video memory.
|
| 183 |
|
|
|
| 184 |
|
|
\section{IO Ports}
|
| 185 |
|
|
The Core has three wishbone interfaces:
|
| 186 |
|
|
|
| 187 |
|
|
\begin{itemize}
|
| 188 |
|
|
\item Wishbone slave -- connects to the data bus of the OpenRISC processor. In the case of ORPSoC, this bus is connected through an arbiter. Supports standard wishbone communications, not any burst modes.
|
| 189 |
|
|
\item Wishbone master read-only -- connects to a video memory port with read access. Used for fetching textures and during blending.
|
| 190 |
|
|
\item Wishbone master write-only -- connects to a video memory port with write access. Used for rendering pixels to the framebuffer.
|
| 191 |
|
|
\end{itemize}
|
| 192 |
|
|
|
| 193 |
|
|
There is an interrupt enabled that can be connected to the interrupt pins on the or1200 CPU (in the supplied orpsoc\_top it is connected to or1200\_pic\_ints[9]). For this interrupt to trigger, the correct bits in the control register has to be set.
|
| 194 |
|
|
|
| 195 |
|
|
\section{Registers}
|
| 196 |
7 |
maiden |
\label{sec:registers}
|
| 197 |
6 |
Orka |
\begin{tabular}{|l|l|l|l|l|}
|
| 198 |
|
|
\hline \textbf{Name} & \textbf{Addr} & \textbf{Width} & \textbf{Access} & \textbf{Description} \\
|
| 199 |
|
|
\hline
|
| 200 |
|
|
\hline CONTROL & 0x00 & 32 & RW & Control register \\
|
| 201 |
|
|
\hline STATUS & 0x04 & 32 & R & Status register \\
|
| 202 |
|
|
\hline ALPHA & 0x08 & 32 & RW & Global alpha register \\
|
| 203 |
|
|
\hline COLORKEY & 0x0c & 32 & RW & Colorkey register \\
|
| 204 |
|
|
|
| 205 |
|
|
\hline TARGET\_BASE & 0x10 & 32 & RW & Render target base \\
|
| 206 |
|
|
\hline TARGET\_SIZE\_X & 0x14 & 32 & RW & Render target width \\
|
| 207 |
|
|
\hline TARGET\_SIZE\_Y & 0x18 & 32 & RW & Render target height \\
|
| 208 |
|
|
|
| 209 |
|
|
\hline TEX0\_BASE & 0x1c & 32 & RW & Texture 0 base \\
|
| 210 |
|
|
\hline TEX0\_SIZE\_X & 0x20 & 32 & RW & Texture 0 width \\
|
| 211 |
|
|
\hline TEX0\_SIZE\_Y & 0x24 & 32 & RW & Texture 0 height \\
|
| 212 |
|
|
|
| 213 |
|
|
\hline SRC\_P0\_X & 0x28 & 32 & RW & Source pixel 0 x \\
|
| 214 |
|
|
\hline SRC\_P0\_Y & 0x2c & 32 & RW & Source pixel 0 y \\
|
| 215 |
|
|
\hline SRC\_P1\_X & 0x30 & 32 & RW & Source pixel 1 x \\
|
| 216 |
|
|
\hline SRC\_P1\_Y & 0x34 & 32 & RW & Source pixel 1 y \\
|
| 217 |
|
|
|
| 218 |
|
|
\hline DEST\_X & 0x38 & 32 & RW & Destination pixel x \\
|
| 219 |
|
|
\hline DEST\_Y & 0x3c & 32 & RW & Destination pixel y \\
|
| 220 |
|
|
\hline DEST\_Z & 0x40 & 32 & RW & Destination pixel z \\
|
| 221 |
|
|
|
| 222 |
|
|
\hline AA & 0x44 & 32 & RW & Transformation matrix coefficient\\
|
| 223 |
|
|
\hline AB & 0x48 & 32 & RW & Transformation matrix coefficient\\
|
| 224 |
|
|
\hline AC & 0x4c & 32 & RW & Transformation matrix coefficient\\
|
| 225 |
|
|
\hline TX & 0x50 & 32 & RW & Transformation matrix coefficient\\
|
| 226 |
|
|
\hline BA & 0x54 & 32 & RW & Transformation matrix coefficient\\
|
| 227 |
|
|
\hline BB & 0x58 & 32 & RW & Transformation matrix coefficient\\
|
| 228 |
|
|
\hline BC & 0x5c & 32 & RW & Transformation matrix coefficient\\
|
| 229 |
|
|
\hline TY & 0x60 & 32 & RW & Transformation matrix coefficient\\
|
| 230 |
|
|
\hline CA & 0x64 & 32 & RW & Transformation matrix coefficient\\
|
| 231 |
|
|
\hline CB & 0x68 & 32 & RW & Transformation matrix coefficient\\
|
| 232 |
|
|
\hline CC & 0x6c & 32 & RW & Transformation matrix coefficient\\
|
| 233 |
|
|
\hline TZ & 0x70 & 32 & RW & Transformation matrix coefficient\\
|
| 234 |
|
|
|
| 235 |
|
|
\hline CLIP\_P0\_X & 0x74 & 32 & RW & Clip pixel 0 x \\
|
| 236 |
|
|
\hline CLIP\_P0\_Y & 0x78 & 32 & RW & Clip pixel 0 y \\
|
| 237 |
|
|
\hline CLIP\_P1\_X & 0x7c & 32 & RW & Clip pixel 1 x \\
|
| 238 |
|
|
\hline CLIP\_P1\_Y & 0x80 & 32 & RW & Clip pixel 0 y \\
|
| 239 |
|
|
|
| 240 |
|
|
\hline COLOR0 & 0x84 & 32 & RW & Color 0 \\
|
| 241 |
|
|
\hline COLOR1 & 0x88 & 32 & RW & Color 1 \\
|
| 242 |
|
|
\hline COLOR2 & 0x8c & 32 & RW & Color 2 \\
|
| 243 |
|
|
|
| 244 |
|
|
\hline U0 & 0x90 & 32 & RW & Texture coordinate 0 \\
|
| 245 |
|
|
\hline V0 & 0x94 & 32 & RW & Texture coordinate 0 \\
|
| 246 |
|
|
\hline U1 & 0x98 & 32 & RW & Texture coordinate 1 \\
|
| 247 |
|
|
\hline V1 & 0x9c & 32 & RW & Texture coordinate 1 \\
|
| 248 |
|
|
\hline U2 & 0xa0 & 32 & RW & Texture coordinate 2 \\
|
| 249 |
|
|
\hline V2 & 0xa4 & 32 & RW & Texture coordinate 2 \\
|
| 250 |
|
|
|
| 251 |
|
|
\hline ZBUFFER\_BASE & 0xa8 & 32 & RW & Depth buffer base address \\
|
| 252 |
|
|
|
| 253 |
|
|
\hline
|
| 254 |
|
|
\end{tabular}
|
| 255 |
|
|
\\\\
|
| 256 |
|
|
Each register is described in detail in the following sections, with information about what the purpose of each bit in the register is. The default value provided for each register is set when the device receives a reset signal.
|
| 257 |
|
|
|
| 258 |
|
|
\subsection{Control Register (CONTROL)}
|
| 259 |
|
|
\begin{tabular}{|l|l|l|}
|
| 260 |
|
|
\hline \textbf{Bit \#} & \textbf{Access} & \textbf{Description} \\
|
| 261 |
|
|
\hline
|
| 262 |
|
|
\hline [31:20] & - & Reserved \\
|
| 263 |
|
|
\hline [19] & W & Transform point \\
|
| 264 |
|
|
\hline [18] & W & Forward point \\
|
| 265 |
|
|
\hline [17:16] & RW & Active point \\
|
| 266 |
|
|
\hline [15:14] & - & Reserved \\
|
| 267 |
|
|
\hline [13] & W & B\'{e}zier inside shape \\
|
| 268 |
|
|
\hline [12] & W & Interpolation \\
|
| 269 |
|
|
\hline [11] & W & Curve write \\
|
| 270 |
|
|
\hline [10] & W & Triangle write \\
|
| 271 |
|
|
\hline [9] & W & Line write \\
|
| 272 |
|
|
\hline [8] & W & Rect write \\
|
| 273 |
|
|
\hline [7] & - & Reserved \\
|
| 274 |
|
|
\hline [6] & RW & Z-buffer enable \\
|
| 275 |
|
|
\hline [5] & RW & Clipping enable \\
|
| 276 |
|
|
\hline [4] & RW & Colorkey enable \\
|
| 277 |
|
|
\hline [3] & RW & Blending enable \\
|
| 278 |
|
|
\hline [2] & RW & Texture0 enable \\
|
| 279 |
|
|
\hline [1:0] & RW & Color depth \\
|
| 280 |
|
|
\hline
|
| 281 |
|
|
\end{tabular}
|
| 282 |
|
|
\\\\
|
| 283 |
|
|
\textbf{Default value:} 0x00
|
| 284 |
|
|
|
| 285 |
|
|
Color depth is defined as follows:
|
| 286 |
|
|
|
| 287 |
|
|
\begin{tabular}{|l|l|}
|
| 288 |
|
|
\hline \textbf{Mode} & \textbf{Color depth}\\
|
| 289 |
|
|
\hline
|
| 290 |
|
|
\hline 00 & 8 bit \\
|
| 291 |
|
|
\hline 01 & 16 bit \\
|
| 292 |
|
|
\hline 10 & 24 bit (not supported) \\
|
| 293 |
|
|
\hline 11 & 32 bit \\
|
| 294 |
|
|
\hline
|
| 295 |
|
|
\end{tabular} \\
|
| 296 |
|
|
|
| 297 |
|
|
The active point is defined as follows:
|
| 298 |
|
|
|
| 299 |
|
|
\begin{tabular}{|l|l|}
|
| 300 |
|
|
\hline \textbf{Mode} & \textbf{Point id}\\
|
| 301 |
|
|
\hline
|
| 302 |
|
|
\hline 00 & p0 \\
|
| 303 |
|
|
\hline 01 & p1 \\
|
| 304 |
|
|
\hline 10 & p2 \\
|
| 305 |
7 |
maiden |
\hline 11 & - \\
|
| 306 |
6 |
Orka |
\hline
|
| 307 |
|
|
\end{tabular} \\
|
| 308 |
|
|
|
| 309 |
|
|
The operations \textbf{Forward point} and \textbf{Transform point} reads the current values of the active point and stores the x, y, z values in the correct register inside the device.
|
| 310 |
|
|
|
| 311 |
|
|
\subsection{Status Register (STATUS)}
|
| 312 |
|
|
\begin{tabular}{|l|l|l|}
|
| 313 |
|
|
\hline \textbf{Bit \#} & \textbf{Access} & \textbf{Description} \\
|
| 314 |
|
|
\hline
|
| 315 |
7 |
maiden |
\hline [31:16] & R & Current FIFO size \\
|
| 316 |
6 |
Orka |
\hline [15:1] & R & Reserved \\
|
| 317 |
|
|
\hline [0] & R & Busy pin (high when busy) \\
|
| 318 |
|
|
\hline
|
| 319 |
|
|
\end{tabular}
|
| 320 |
|
|
\\\\
|
| 321 |
|
|
\textbf{Default value:} --
|
| 322 |
|
|
|
| 323 |
|
|
\subsection{Alpha (ALPHA)}
|
| 324 |
|
|
\begin{tabular}{|l|l|l|}
|
| 325 |
|
|
\hline \textbf{Bit \#} & \textbf{Access} & \textbf{Description} \\
|
| 326 |
|
|
\hline
|
| 327 |
|
|
\hline [31:24] & RW & Point 0 alpha \\
|
| 328 |
|
|
\hline [23:16] & RW & Point 1 alpha \\
|
| 329 |
|
|
\hline [15:8] & RW & Point 2 alpha \\
|
| 330 |
|
|
\hline [7:0] & RW & Global alpha \\
|
| 331 |
|
|
\hline
|
| 332 |
|
|
\end{tabular}
|
| 333 |
|
|
\\\\
|
| 334 |
|
|
\textbf{Default value:} 0xffffffff
|
| 335 |
|
|
|
| 336 |
|
|
The global alpha value is used in all rendering when alpha blending is enabled. \textbf{0xff} is full opacity, while \textbf{0x00} is full transparency (nothing rendered). When interpolation of triangles is activated, the point alpha values are used to find an interpolated alpha value for each pixel. This value is then multiplied with the global alpha before being used for blending.
|
| 337 |
|
|
|
| 338 |
|
|
\subsection{Colorkey register (COLORKEY)}
|
| 339 |
|
|
\begin{tabular}{|l|l|l|}
|
| 340 |
|
|
\hline \textbf{Bit \#} & \textbf{Access} & \textbf{Description} \\
|
| 341 |
|
|
\hline
|
| 342 |
|
|
\hline [31:0] & RW & Colorkey \\
|
| 343 |
|
|
\hline
|
| 344 |
|
|
\end{tabular}
|
| 345 |
|
|
\\\\
|
| 346 |
|
|
\textbf{Default value:} 0x00
|
| 347 |
|
|
|
| 348 |
|
|
By setting a colorkey certain pixels in a texture can be discarded in the fragment stage, providing a hard transparency. Depending on the color depth, a mask is applied to the color. Using 8 bit color, only the 8 least significant bits in the colorkey will be compared with the texture color during the check. The colorkey enable bit in the control register must be set to enable this functionality.
|
| 349 |
|
|
|
| 350 |
|
|
|
| 351 |
|
|
\subsection{Target base address Register (TARGET\_BASE)}
|
| 352 |
|
|
\begin{tabular}{|l|l|l|}
|
| 353 |
|
|
\hline \textbf{Bit \#} & \textbf{Access} & \textbf{Description} \\
|
| 354 |
|
|
\hline
|
| 355 |
|
|
\hline [31:2] & RW & Video Memory Address \\
|
| 356 |
|
|
\hline [1:0] & - & Nothing \\
|
| 357 |
|
|
\hline
|
| 358 |
|
|
\end{tabular}
|
| 359 |
|
|
\\\\
|
| 360 |
|
|
\textbf{Default value:} 0x00
|
| 361 |
|
|
|
| 362 |
|
|
\subsection{Target size width Register (TARGET\_SIZE\_X)}
|
| 363 |
|
|
\begin{tabular}{|l|l|l|}
|
| 364 |
|
|
\hline \textbf{Bit \#} & \textbf{Access} & \textbf{Description} \\
|
| 365 |
|
|
\hline
|
| 366 |
|
|
\hline [31:0] & RW & Integer Width \\
|
| 367 |
|
|
\hline
|
| 368 |
|
|
\end{tabular}
|
| 369 |
|
|
\\\\
|
| 370 |
|
|
\textbf{Default value:} 0x00
|
| 371 |
|
|
|
| 372 |
|
|
\subsection{Target size y Register (TARGET\_SIZE\_Y)}
|
| 373 |
|
|
\begin{tabular}{|l|l|l|}
|
| 374 |
|
|
\hline \textbf{Bit \#} & \textbf{Access} & \textbf{Description} \\
|
| 375 |
|
|
\hline
|
| 376 |
|
|
\hline [31:0] & RW & Integer Height \\
|
| 377 |
|
|
\hline
|
| 378 |
|
|
\end{tabular}
|
| 379 |
|
|
\\\\
|
| 380 |
|
|
\textbf{Default value:} 0x00
|
| 381 |
|
|
|
| 382 |
|
|
\subsection{Texture 0 Base Register (TEX0\_BASE)}
|
| 383 |
|
|
\begin{tabular}{|l|l|l|}
|
| 384 |
|
|
\hline \textbf{Bit \#} & \textbf{Access} & \textbf{Description} \\
|
| 385 |
|
|
\hline
|
| 386 |
|
|
\hline [31:2] & RW & Video Memory Address \\
|
| 387 |
|
|
\hline [1:0] & - & Nothing \\
|
| 388 |
|
|
\hline
|
| 389 |
|
|
\end{tabular}
|
| 390 |
|
|
\\\\
|
| 391 |
|
|
\textbf{Default value:} 0x00
|
| 392 |
|
|
|
| 393 |
|
|
\subsection{Texture 0 size x Register (TEX0\_SIZE\_X)}
|
| 394 |
|
|
\begin{tabular}{|l|l|l|}
|
| 395 |
|
|
\hline \textbf{Bit \#} & \textbf{Access} & \textbf{Description} \\
|
| 396 |
|
|
\hline
|
| 397 |
|
|
\hline [31:0] & RW & Integer Width \\
|
| 398 |
|
|
\hline
|
| 399 |
|
|
\end{tabular}
|
| 400 |
|
|
\\\\
|
| 401 |
|
|
\textbf{Default value:} 0x00
|
| 402 |
|
|
|
| 403 |
|
|
\subsection{Texture 0 size y Register (TEX0\_SIZE\_Y)}
|
| 404 |
|
|
\begin{tabular}{|l|l|l|}
|
| 405 |
|
|
\hline \textbf{Bit \#} & \textbf{Access} & \textbf{Description} \\
|
| 406 |
|
|
\hline
|
| 407 |
|
|
\hline [31:0] & RW & Integer Height \\
|
| 408 |
|
|
\hline
|
| 409 |
|
|
\end{tabular}
|
| 410 |
|
|
\\\\
|
| 411 |
|
|
\textbf{Default value:} 0x00
|
| 412 |
|
|
|
| 413 |
|
|
\subsection{Source Pixel position 0 x Register (SRC\_P0\_X)}
|
| 414 |
|
|
\begin{tabular}{|l|l|l|}
|
| 415 |
|
|
\hline \textbf{Bit \#} & \textbf{Access} & \textbf{Description} \\
|
| 416 |
|
|
\hline
|
| 417 |
|
|
\hline [31:0] & RW & Integer x pos \\
|
| 418 |
|
|
\hline
|
| 419 |
|
|
\end{tabular}
|
| 420 |
|
|
\\\\
|
| 421 |
|
|
\textbf{Default value:} 0x00
|
| 422 |
|
|
|
| 423 |
|
|
The source pixels are used to define a specific area in a texture to draw.
|
| 424 |
|
|
|
| 425 |
|
|
\subsection{Source Pixel position 0 y Register (SRC\_P0\_Y)}
|
| 426 |
|
|
\begin{tabular}{|l|l|l|}
|
| 427 |
|
|
\hline \textbf{Bit \#} & \textbf{Access} & \textbf{Description} \\
|
| 428 |
|
|
\hline
|
| 429 |
|
|
\hline [31:0] & RW & Integer y pos \\
|
| 430 |
|
|
\hline
|
| 431 |
|
|
\end{tabular}
|
| 432 |
|
|
\\\\
|
| 433 |
|
|
\textbf{Default value:} 0x00
|
| 434 |
|
|
|
| 435 |
|
|
|
| 436 |
|
|
\subsection{Source Pixel position 1 Register (SRC\_P1\_X)}
|
| 437 |
|
|
\begin{tabular}{|l|l|l|}
|
| 438 |
|
|
\hline \textbf{Bit \#} & \textbf{Access} & \textbf{Description} \\
|
| 439 |
|
|
\hline
|
| 440 |
|
|
\hline [31:0] & RW & Integer x pos \\
|
| 441 |
|
|
\hline
|
| 442 |
|
|
\end{tabular}
|
| 443 |
|
|
\\\\
|
| 444 |
|
|
\textbf{Default value:} 0x00
|
| 445 |
|
|
|
| 446 |
|
|
\subsection{Source Pixel position 1 Register (SRC\_P1\_Y)}
|
| 447 |
|
|
\begin{tabular}{|l|l|l|}
|
| 448 |
|
|
\hline \textbf{Bit \#} & \textbf{Access} & \textbf{Description} \\
|
| 449 |
|
|
\hline
|
| 450 |
|
|
\hline [31:0] & RW & Integer y pos \\
|
| 451 |
|
|
\hline
|
| 452 |
|
|
\end{tabular}
|
| 453 |
|
|
\\\\
|
| 454 |
|
|
\textbf{Default value:} 0x00
|
| 455 |
|
|
|
| 456 |
|
|
\subsection{Destination Pixel position Register (DEST\_X)}
|
| 457 |
|
|
\begin{tabular}{|l|l|l|}
|
| 458 |
|
|
\hline \textbf{Bit \#} & \textbf{Access} & \textbf{Description} \\
|
| 459 |
|
|
\hline
|
| 460 |
|
|
\hline [31:16] & RW & Signed Integer part \\
|
| 461 |
|
|
\hline [15:0] & RW & Fractional part \\
|
| 462 |
|
|
\hline
|
| 463 |
|
|
\end{tabular}
|
| 464 |
|
|
\\\\
|
| 465 |
|
|
\textbf{Default value:} 0x00
|
| 466 |
|
|
|
| 467 |
|
|
The control register flag active point decides the destination register inside the device. Points are pushed to the device by setting the forward or transform bit in the control register.
|
| 468 |
|
|
|
| 469 |
|
|
\subsection{Destination Pixel position Register (DEST\_Y)}
|
| 470 |
|
|
\begin{tabular}{|l|l|l|}
|
| 471 |
|
|
\hline \textbf{Bit \#} & \textbf{Access} & \textbf{Description} \\
|
| 472 |
|
|
\hline
|
| 473 |
|
|
\hline [31:16] & RW & Signed Integer part \\
|
| 474 |
|
|
\hline [15:0] & RW & Fractional part \\
|
| 475 |
|
|
\hline
|
| 476 |
|
|
\end{tabular}
|
| 477 |
|
|
\\\\
|
| 478 |
|
|
\textbf{Default value:} 0x00
|
| 479 |
|
|
|
| 480 |
|
|
\subsection{Destination Pixel position Register (DEST\_Z)}
|
| 481 |
|
|
\begin{tabular}{|l|l|l|}
|
| 482 |
|
|
\hline \textbf{Bit \#} & \textbf{Access} & \textbf{Description} \\
|
| 483 |
|
|
\hline
|
| 484 |
|
|
\hline [31:16] & RW & Signed Integer part \\
|
| 485 |
|
|
\hline [15:0] & RW & Fractional part \\
|
| 486 |
|
|
\hline
|
| 487 |
|
|
\end{tabular}
|
| 488 |
|
|
\\\\
|
| 489 |
|
|
\textbf{Default value:} 0x00
|
| 490 |
|
|
|
| 491 |
|
|
\subsection{Matrix coefficient registers}
|
| 492 |
|
|
The matrix coefficients are defined in the following way:
|
| 493 |
|
|
|
| 494 |
|
|
$
|
| 495 |
|
|
M
|
| 496 |
|
|
=
|
| 497 |
|
|
\left[
|
| 498 |
|
|
\begin{array}{cccc}
|
| 499 |
|
|
AA & AB & AC & TX \\
|
| 500 |
|
|
BA & BB & BC & TY \\
|
| 501 |
|
|
CA & CB & CC & TZ \\
|
| 502 |
|
|
\end{array}
|
| 503 |
|
|
\right]
|
| 504 |
|
|
$
|
| 505 |
|
|
|
| 506 |
|
|
Each coefficient has a register, where the bits are defined as:
|
| 507 |
|
|
|
| 508 |
|
|
\begin{tabular}{|l|l|l|}
|
| 509 |
|
|
\hline \textbf{Bit \#} & \textbf{Access} & \textbf{Description} \\
|
| 510 |
|
|
\hline
|
| 511 |
|
|
\hline [31:16] & RW & Signed Integer part \\
|
| 512 |
|
|
\hline [15:0] & RW & Fractional part \\
|
| 513 |
|
|
\hline
|
| 514 |
|
|
\end{tabular}
|
| 515 |
|
|
|
| 516 |
|
|
The default matrix is set to no scaling, no rotation, no translation:
|
| 517 |
|
|
|
| 518 |
|
|
$
|
| 519 |
|
|
M_{default}
|
| 520 |
|
|
=
|
| 521 |
|
|
\left[
|
| 522 |
|
|
\begin{array}{cccc}
|
| 523 |
|
|
1 & 0 & 0 & 0 \\
|
| 524 |
|
|
|
| 525 |
|
|
|
| 526 |
|
|
\end{array}
|
| 527 |
|
|
\right]
|
| 528 |
|
|
$
|
| 529 |
|
|
|
| 530 |
|
|
\subsection{Clip Pixel position 0 x Register (CLIP\_P0\_X)}
|
| 531 |
|
|
\begin{tabular}{|l|l|l|}
|
| 532 |
|
|
\hline \textbf{Bit \#} & \textbf{Access} & \textbf{Description} \\
|
| 533 |
|
|
\hline
|
| 534 |
|
|
\hline [31:0] & RW & Integer x \\
|
| 535 |
|
|
\hline
|
| 536 |
|
|
\end{tabular}
|
| 537 |
|
|
\\\\
|
| 538 |
|
|
\textbf{Default value:} 0x00
|
| 539 |
|
|
|
| 540 |
|
|
\subsection{Clip Pixel position 0 y Register (CLIP\_P0\_Y)}
|
| 541 |
|
|
\begin{tabular}{|l|l|l|}
|
| 542 |
|
|
\hline \textbf{Bit \#} & \textbf{Access} & \textbf{Description} \\
|
| 543 |
|
|
\hline
|
| 544 |
|
|
\hline [31:0] & RW & Integer y \\
|
| 545 |
|
|
\hline
|
| 546 |
|
|
\end{tabular}
|
| 547 |
|
|
\\\\
|
| 548 |
|
|
\textbf{Default value:} 0x00
|
| 549 |
|
|
|
| 550 |
|
|
\subsection{Clip Pixel position 1 x Register (CLIP\_P1\_X)}
|
| 551 |
|
|
\begin{tabular}{|l|l|l|}
|
| 552 |
|
|
\hline \textbf{Bit \#} & \textbf{Access} & \textbf{Description} \\
|
| 553 |
|
|
\hline
|
| 554 |
|
|
\hline [31:0] & RW & Integer x \\
|
| 555 |
|
|
\hline
|
| 556 |
|
|
\end{tabular}
|
| 557 |
|
|
\\\\
|
| 558 |
|
|
\textbf{Default value:} 0x00
|
| 559 |
|
|
|
| 560 |
|
|
\subsection{Clip Pixel position 1 y Register (CLIP\_P1\_Y)}
|
| 561 |
|
|
\begin{tabular}{|l|l|l|}
|
| 562 |
|
|
\hline \textbf{Bit \#} & \textbf{Access} & \textbf{Description} \\
|
| 563 |
|
|
\hline
|
| 564 |
|
|
\hline [31:0] & RW & Integer y \\
|
| 565 |
|
|
\hline
|
| 566 |
|
|
\end{tabular}
|
| 567 |
|
|
\\\\
|
| 568 |
|
|
\textbf{Default value:} 0x00
|
| 569 |
|
|
|
| 570 |
|
|
\subsection{Color Registers (COLOR0-2)}
|
| 571 |
|
|
\begin{tabular}{|l|l|l|}
|
| 572 |
|
|
\hline \textbf{Bit \#} & \textbf{Access} & \textbf{Description} \\
|
| 573 |
|
|
\hline
|
| 574 |
|
|
\hline [31:0] & RW & Color bits \\
|
| 575 |
|
|
\hline
|
| 576 |
|
|
\end{tabular}
|
| 577 |
|
|
\\\\
|
| 578 |
|
|
\textbf{Default value:} 0x00
|
| 579 |
|
|
|
| 580 |
7 |
maiden |
There are several color modes available (set in \textit{control register}):
|
| 581 |
6 |
Orka |
|
| 582 |
|
|
\begin{tabular}{|l|l|l|}
|
| 583 |
|
|
\hline \textbf{Mode} & \textbf{Format} \\
|
| 584 |
|
|
\hline
|
| 585 |
|
|
\hline 32bpp & [31:24] is alpha channel. [23:16] is R, [15:8] is G and [7:0] is B \\
|
| 586 |
|
|
%\hline 24bpp & [31:24] is unused. [23:16] is R, [15:8] is G and [7:0] is B \\
|
| 587 |
|
|
\hline 16bpp & [15:11] is R, [10:5] is B and [4:0] is G\\
|
| 588 |
|
|
\hline 8bpp gray & [7:0] sets both R, G and B values \\
|
| 589 |
|
|
\hline 8bpp palette & [7:0] sets the color index in the palette \\
|
| 590 |
|
|
\hline
|
| 591 |
|
|
\end{tabular}
|
| 592 |
|
|
\\\\
|
| 593 |
|
|
|
| 594 |
7 |
maiden |
Currently only 16 bit color depth is fully supported.
|
| 595 |
|
|
|
| 596 |
|
|
\subsection{Texture coordinate Registers (U0-2 and V0-2)}
|
| 597 |
|
|
\begin{tabular}{|l|l|l|}
|
| 598 |
|
|
\hline \textbf{Bit \#} & \textbf{Access} & \textbf{Description} \\
|
| 599 |
|
|
\hline
|
| 600 |
|
|
\hline [31:0] & RW & Coordinate bits (integer) \\
|
| 601 |
|
|
\hline
|
| 602 |
|
|
\end{tabular}
|
| 603 |
|
|
\\\\
|
| 604 |
|
|
\textbf{Default value:} 0x00
|
| 605 |
|
|
|
| 606 |
|
|
\subsection{Depth buffer Register (ZBUFFER\_BASE)}
|
| 607 |
|
|
\begin{tabular}{|l|l|l|}
|
| 608 |
|
|
\hline \textbf{Bit \#} & \textbf{Access} & \textbf{Description} \\
|
| 609 |
|
|
\hline
|
| 610 |
|
|
\hline [31:2] & RW & 32-bit word base address \\
|
| 611 |
|
|
\hline [1:0] & - & Ignored \\
|
| 612 |
|
|
\hline
|
| 613 |
|
|
\end{tabular}
|
| 614 |
|
|
\\\\
|
| 615 |
|
|
\textbf{Default value:} 0x00
|
| 616 |
|
|
|
| 617 |
|
|
This register holds the base address of the depth buffer. The depth buffer operations uses TARGET\_SIZE\_X and TARGET\_SIZE\_Y for the size of the depth buffer (it is assumed that the render target and the depth buffer are of the same size.
|
| 618 |
|
|
|
| 619 |
6 |
Orka |
\section{Operation}
|
| 620 |
|
|
All hardware accelerated operations draw pixels to the currently active surface (defined by TADR\_REG and TSZE\_REG). These operations are all affected by clip\_p0 and clip\_p1. No pixels that fall outside the clipping rectangle will be rendered.
|
| 621 |
|
|
|
| 622 |
|
|
\subsection{Draw pixel}
|
| 623 |
7 |
maiden |
\textbf{Input needed:} dest\_p0, color0\\
|
| 624 |
|
|
ORGFX have no hardware-support for writing a single pixel to the video memory. However its possible to draw a line, rect or curve with the size of one pixel. The software API makes it possible to draw a pixel by writing directly to the memory (this is the most optimal way). Since the video memory can point to both the framebuffer and to textures, the same operation can be used to draw an arbitrary pixel to the screen and to load a texture into video memory.
|
| 625 |
6 |
Orka |
|
| 626 |
|
|
\subsection{Fill rect}
|
| 627 |
7 |
maiden |
\textbf{Input needed:} ctrl, dest\_p0, dest\_p1, color0, [src\_p0, src\_p1]\\
|
| 628 |
6 |
Orka |
Fill rect will fill the area of a rectangle created between the pixel dest\_p0 and dest\_p1 with color. If texturing is enabled, color will be taken from the active texture in the area between src\_p0 and src\_p1. This operation is hardware accelerated, and is activated by setting the Rect write bit in the control register.
|
| 629 |
|
|
|
| 630 |
|
|
\subsection{Line}
|
| 631 |
7 |
maiden |
\textbf{Input needed:} ctrl, dest\_p0, dest\_p1, color0\\
|
| 632 |
6 |
Orka |
Line will draw a line between the pixels dest\_p0 and dest\_p1 with color. This operation is hardware accelerated.
|
| 633 |
|
|
|
| 634 |
7 |
maiden |
\subsection{Triangle}
|
| 635 |
|
|
\textbf{Input needed:} ctrl, dest\_p0, dest\_p1, dest\_p2, color0, [color1, color2, u0, v0, u1, v1, u2, v2]\\
|
| 636 |
|
|
Draw the pixels in the triangle created by dest\_p0, dest\_p1 and dest\_p2. The triangle can be colored with either a flat color, a gradient or a texture. Gradient or textured coloring require the interpolation pin to be set in the control register.
|
| 637 |
6 |
Orka |
|
| 638 |
|
|
\subsection{Curve}
|
| 639 |
7 |
maiden |
\textbf{Input needed:} ctrl, dest\_p0, dest\_p1, dest\_p2, color0, [color1, color2, u0, v0, u1, v1, u2, v2]\\
|
| 640 |
|
|
Draws a filled quadratic B\'{e}zier curve with dest\_p0 as start, dest\_p1 as control point and dest\_p2 as end. For this operation to work, the interpolation pin must be set in the control register.
|
| 641 |
6 |
Orka |
|
| 642 |
|
|
\section{Clocks}
|
| 643 |
7 |
maiden |
The entire component uses the same clock domain.
|
| 644 |
6 |
Orka |
|
| 645 |
|
|
\section{Driver interface}
|
| 646 |
|
|
The ORSoC graphics accelerator offers three different APIs to code against, two for bare metal when coding directly against the processor, and a Linux kernel module. The extended bare metal interface is a wrapper around the basic bare metal API, and makes coding easier by reducing the number of calls. The drawback is lesser control over the graphics card.
|
| 647 |
|
|
|
| 648 |
|
|
\subsection{newlib}
|
| 649 |
|
|
The basic library is provided in \textbf{orgfx.h} and \textbf{orgfx.c}.
|
| 650 |
|
|
|
| 651 |
|
|
The bare metal library declares a structure that can hold surfaces (both framebuffers and textures). Many functions take a pointer to one of these structures.
|
| 652 |
|
|
\begin{lstlisting}
|
| 653 |
|
|
struct orgfx_surface
|
| 654 |
|
|
{
|
| 655 |
|
|
unsigned int addr;
|
| 656 |
|
|
unsigned int w;
|
| 657 |
|
|
unsigned int h;
|
| 658 |
|
|
};
|
| 659 |
|
|
\end{lstlisting}
|
| 660 |
|
|
|
| 661 |
|
|
\subsubsection{orgfx\_init}
|
| 662 |
|
|
\textbf{Description:} The orgfx\_init must be called first to get other oc\_gfx commands to work properly.
|
| 663 |
|
|
\begin{lstlisting}
|
| 664 |
|
|
void orgfx_init(unsigned int memoryArea);
|
| 665 |
|
|
\end{lstlisting}
|
| 666 |
|
|
|
| 667 |
|
|
\subsubsection{orgfx\_vga\_set\_videomode}
|
| 668 |
|
|
\textbf{Description:} Sets the video mode, width, height, bpp.
|
| 669 |
|
|
\begin{lstlisting}
|
| 670 |
|
|
void orgfx_set_videomode(unsigned int width,
|
| 671 |
|
|
unsigned int height,
|
| 672 |
|
|
unsigned char bpp);
|
| 673 |
|
|
\end{lstlisting}
|
| 674 |
|
|
|
| 675 |
|
|
\subsubsection{orgfx\_vga\_set\_vbara}
|
| 676 |
|
|
\textbf{Description:} Assign a memory address to "Video Base Address Register A".
|
| 677 |
|
|
\begin{lstlisting}
|
| 678 |
|
|
void orgfx_vga_set_vbara(unsigned int addr);
|
| 679 |
|
|
\end{lstlisting}
|
| 680 |
|
|
|
| 681 |
|
|
\subsubsection{orgfx\_vga\_set\_vbarb}
|
| 682 |
|
|
\textbf{Description:} Assign a memory address to "Video Base Address Register B".
|
| 683 |
|
|
\begin{lstlisting}
|
| 684 |
|
|
void orgfx_vga_set_vbarb(unsigned int addr);
|
| 685 |
|
|
\end{lstlisting}
|
| 686 |
|
|
|
| 687 |
|
|
\subsubsection{orgfx\_vga\_bank\_switch}
|
| 688 |
|
|
\textbf{Description:} Switches the framebuffer.
|
| 689 |
|
|
\begin{lstlisting}
|
| 690 |
|
|
void orgfx_vga_bank_switch();
|
| 691 |
|
|
\end{lstlisting}
|
| 692 |
|
|
|
| 693 |
|
|
\subsubsection{orgfx\_init\_surface}
|
| 694 |
|
|
\textbf{Description:} Initialize a surface and return a control structure for it. This function increments an internal video memory stack pointer, so each surface will be allocated after the previous one in memory (starting at memoryArea set by orgfx\_init). There is currently no memory management in place to recycle surface memory once it is no longer in use. The first surface initialized will point to the same memory that the video controller reads from, so it should be initialized with the width and height of the screen.
|
| 695 |
|
|
\begin{lstlisting}
|
| 696 |
|
|
struct orgfx_surface
|
| 697 |
|
|
orgfx_init_surface(unsigned int width,
|
| 698 |
|
|
unsigned int height);
|
| 699 |
|
|
\end{lstlisting}
|
| 700 |
|
|
|
| 701 |
|
|
\subsubsection{orgfx\_bind\_rendertarget}
|
| 702 |
|
|
\textbf{Description:} Binds a surface as the active render target. This function \textit{must} be called before any drawing operations can be performed.
|
| 703 |
|
|
\begin{lstlisting}
|
| 704 |
|
|
void orgfx_bind_rendertarget(struct orgfx_surface *surface);
|
| 705 |
|
|
\end{lstlisting}
|
| 706 |
|
|
|
| 707 |
|
|
\subsubsection{orgfx\_enable\_cliprect}
|
| 708 |
|
|
\textbf{Description:} Enables/disables clipping.
|
| 709 |
|
|
\begin{lstlisting}
|
| 710 |
|
|
inline void orgfx_enable_cliprect(unsigned int enable);
|
| 711 |
|
|
\end{lstlisting}
|
| 712 |
|
|
|
| 713 |
|
|
\subsubsection{orgfx\_cliprect}
|
| 714 |
|
|
\textbf{Description:} Sets the clipping rect. No pixels will be drawn outside of this rect (useful for restricting draws to a specific area of the render target). orgfx\_bind\_rendertarget will reset the clipping rect to the size of the surface.
|
| 715 |
|
|
\begin{lstlisting}
|
| 716 |
|
|
inline void orgfx_cliprect(unsigned int x0,
|
| 717 |
|
|
unsigned int y0,
|
| 718 |
|
|
unsigned int x1,
|
| 719 |
|
|
unsigned int y1);
|
| 720 |
|
|
\end{lstlisting}
|
| 721 |
|
|
|
| 722 |
|
|
\subsubsection{orgfx\_srcrect}
|
| 723 |
|
|
\textbf{Description:} Sets the source rectangle that will be used by texturing operations. This allows for only drawing a small part of a texture. orgfx\_bind\_tex0 will reset this to the size of the texture.
|
| 724 |
|
|
\begin{lstlisting}
|
| 725 |
|
|
inline void orgfx_srcrect(unsigned int x0,
|
| 726 |
|
|
unsigned int y0,
|
| 727 |
|
|
unsigned int x1,
|
| 728 |
|
|
unsigned int y1);
|
| 729 |
|
|
\end{lstlisting}
|
| 730 |
|
|
|
| 731 |
|
|
\subsubsection{orgfx\_set\_pixel}
|
| 732 |
|
|
\textbf{Description:} Set a pixel on coordinate x,y to color. This is done in software by direct memory writes. This operation is not affected by the clipping rect!
|
| 733 |
|
|
\begin{lstlisting}
|
| 734 |
7 |
maiden |
inline void orgfx_set_pixel(int x,
|
| 735 |
|
|
int y,
|
| 736 |
6 |
Orka |
unsigned int color);
|
| 737 |
|
|
\end{lstlisting}
|
| 738 |
|
|
|
| 739 |
|
|
\subsubsection{orgfx\_memcpy}
|
| 740 |
|
|
\textbf{Description:} Copies memory from the processor to the video memory. Size is in 32-bit words. This function is intended to work with the output array of the sprite converter utility to load images into memory. Remember to bind a texture as the render target first!
|
| 741 |
|
|
\begin{lstlisting}
|
| 742 |
|
|
void orgfx_memcpy(unsigned int mem[],
|
| 743 |
|
|
unsigned int size);
|
| 744 |
|
|
\end{lstlisting}
|
| 745 |
|
|
|
| 746 |
|
|
\subsubsection{orgfx\_set\_color}
|
| 747 |
7 |
maiden |
\textbf{Description:} Sets the current drawing color (for flat coloring).
|
| 748 |
6 |
Orka |
\begin{lstlisting}
|
| 749 |
|
|
inline void orgfx_set_color(unsigned int color);
|
| 750 |
|
|
\end{lstlisting}
|
| 751 |
|
|
|
| 752 |
7 |
maiden |
\subsubsection{orgfx\_set\_colors}
|
| 753 |
|
|
\textbf{Description:} Sets all the current drawing colors (for gradient coloring).
|
| 754 |
|
|
\begin{lstlisting}
|
| 755 |
|
|
inline void orgfx_set_colors(unsigned int color0,
|
| 756 |
|
|
unsigned int color1,
|
| 757 |
|
|
unsigned int color2);
|
| 758 |
|
|
\end{lstlisting}
|
| 759 |
|
|
|
| 760 |
6 |
Orka |
\subsubsection{orgfx\_rect}
|
| 761 |
|
|
\textbf{Description:} Draws a rect from (x0,y0) to (x1,y1) and fills it with the current drawing color. If texturing is enabled, the current texture will be drawn instead.
|
| 762 |
|
|
\begin{lstlisting}
|
| 763 |
7 |
maiden |
inline void orgfx_rect(int x0,
|
| 764 |
|
|
int y0,
|
| 765 |
|
|
int x1,
|
| 766 |
|
|
int y1);
|
| 767 |
6 |
Orka |
\end{lstlisting}
|
| 768 |
|
|
|
| 769 |
|
|
\subsubsection{orgfx\_line}
|
| 770 |
|
|
\textbf{Description:} Draws a line from (x0,y0) to (x1,y1) with the current drawing color. If texturing is enabled, the first pixel of the current texture will be drawn instead.
|
| 771 |
|
|
\begin{lstlisting}
|
| 772 |
7 |
maiden |
inline void orgfx_line(int x0, int y0,
|
| 773 |
|
|
int x1, int y1);
|
| 774 |
6 |
Orka |
\end{lstlisting}
|
| 775 |
|
|
|
| 776 |
7 |
maiden |
\subsubsection{orgfx\_line3d}
|
| 777 |
|
|
\textbf{Description:} Draws a line from (x0,y0,z0) to (x1,y1,z1) with the current drawing color. If texturing is enabled, the first pixel of the current texture will be drawn instead.
|
| 778 |
|
|
\begin{lstlisting}
|
| 779 |
|
|
inline void orgfx_line3d(int x0, int y0, int z0,
|
| 780 |
|
|
int x1, int y1, int z1);
|
| 781 |
|
|
\end{lstlisting}
|
| 782 |
|
|
|
| 783 |
6 |
Orka |
\subsubsection{orgfx\_triangle}
|
| 784 |
|
|
\textbf{Description:} Draws a filled triangle of the space spanned by (x0,y0), (x1,y1) and (x2,y2). The order of the points is important, since triangles calculated to be counter clockwise will be discarded (backface culling). The interpolate flag indicates if flat coloring or interpolated coloring should be used. The interpolate flag \textit{has} to be enabled for interpolated alpha, texture coordinates or depth is desired (flat coloring can be obtained by setting all three color registers to the same color).
|
| 785 |
|
|
\begin{lstlisting}
|
| 786 |
7 |
maiden |
inline void orgfx_triangle(int x0, int y0,
|
| 787 |
|
|
int x1, int y1,
|
| 788 |
|
|
int x2, int y2,
|
| 789 |
6 |
Orka |
unsigned int interpolate);
|
| 790 |
|
|
\end{lstlisting}
|
| 791 |
|
|
|
| 792 |
|
|
\subsubsection{orgfx\_triangle3d}
|
| 793 |
|
|
\textbf{Description:} This function works the same way as the triangle function, but the Z-values are set.
|
| 794 |
|
|
\begin{lstlisting}
|
| 795 |
7 |
maiden |
inline void orgfx_triangle3d(int x0, int y0, int z0,
|
| 796 |
|
|
int x1, int y1, int z1,
|
| 797 |
|
|
int x2, int y2, int z2,
|
| 798 |
6 |
Orka |
unsigned int interpolate);
|
| 799 |
|
|
\end{lstlisting}
|
| 800 |
|
|
|
| 801 |
|
|
\subsubsection{orgfx\_curve}
|
| 802 |
|
|
\textbf{Description:} Draws a Quadratic curve between the points (x0,y0) and (x2,y2) with the control points (x1,y1). The three points form a triangle. The \textit{inside} flag determines if the inside or outside of the curve is filled inside the triangle.
|
| 803 |
|
|
\begin{lstlisting}
|
| 804 |
7 |
maiden |
inline void orgfx_curve(int x0, int y0,
|
| 805 |
|
|
int x1, int y1,
|
| 806 |
|
|
int x2, int y2,
|
| 807 |
6 |
Orka |
unsigned int inside);
|
| 808 |
|
|
\end{lstlisting}
|
| 809 |
|
|
|
| 810 |
7 |
maiden |
\subsubsection{orgfx\_uv}
|
| 811 |
|
|
\textbf{Description:} Sets the three texture coordinates used in textured triangle renders.
|
| 812 |
|
|
\begin{lstlisting}
|
| 813 |
|
|
inline void orgfx_uv(unsigned int u0, unsigned int v0,
|
| 814 |
|
|
unsigned int u1, unsigned int v1,
|
| 815 |
|
|
unsigned int u2, unsigned int v2);
|
| 816 |
|
|
\end{lstlisting}
|
| 817 |
|
|
|
| 818 |
6 |
Orka |
\subsubsection{orgfx\_enable\_tex0}
|
| 819 |
|
|
\textbf{Description:} Enables or disables texturing.
|
| 820 |
|
|
\begin{lstlisting}
|
| 821 |
|
|
void orgfx_enable_tex0(unsigned int enable);
|
| 822 |
|
|
\end{lstlisting}
|
| 823 |
|
|
|
| 824 |
|
|
\subsubsection{orgfx\_bind\_tex0}
|
| 825 |
|
|
\textbf{Description:} Binds a surface as the current texture. Will reset the source rect.
|
| 826 |
|
|
\begin{lstlisting}
|
| 827 |
|
|
void orgfx_bind_tex0(struct orgfx_surface* surface);
|
| 828 |
|
|
\end{lstlisting}
|
| 829 |
|
|
|
| 830 |
7 |
maiden |
\subsubsection{orgfx\_enable\_zbuffer}
|
| 831 |
|
|
\textbf{Description:} Enables or disables reads and writes to the depth buffer. Requires that a depth buffer is bound.
|
| 832 |
|
|
\begin{lstlisting}
|
| 833 |
|
|
void orgfx_enable_zbuffer(unsigned int enable);
|
| 834 |
|
|
\end{lstlisting}
|
| 835 |
6 |
Orka |
|
| 836 |
7 |
maiden |
\subsubsection{orgfx\_bind\_zbuffer}
|
| 837 |
|
|
\textbf{Description:} Binds the depth buffer. This surface should have the same resolution as the render target.
|
| 838 |
|
|
\begin{lstlisting}
|
| 839 |
|
|
void orgfx_bind_zbuffer(struct orgfx_surface *surface);
|
| 840 |
|
|
\end{lstlisting}
|
| 841 |
|
|
|
| 842 |
|
|
\subsubsection{orgfx\_clear\_zbuffer}
|
| 843 |
|
|
\textbf{Description:} Clears the depth buffer.
|
| 844 |
|
|
\begin{lstlisting}
|
| 845 |
|
|
void orgfx_clear_zbuffer();
|
| 846 |
|
|
\end{lstlisting}
|
| 847 |
|
|
|
| 848 |
6 |
Orka |
\subsubsection{orgfx\_enable\_alpha}
|
| 849 |
|
|
\textbf{Description:} Enables or disables alpha blending.
|
| 850 |
|
|
\begin{lstlisting}
|
| 851 |
|
|
void orgfx_enable_alpha(unsigned int enable);
|
| 852 |
|
|
\end{lstlisting}
|
| 853 |
|
|
|
| 854 |
|
|
\subsubsection{orgfx\_set\_alpha}
|
| 855 |
|
|
\textbf{Description:} Sets the alpha blending value.
|
| 856 |
|
|
\begin{lstlisting}
|
| 857 |
|
|
void orgfx_set_alpha(unsigned int alpha);
|
| 858 |
|
|
\end{lstlisting}
|
| 859 |
|
|
|
| 860 |
|
|
\subsubsection{orgfx\_enable\_colorkey}
|
| 861 |
|
|
\textbf{Description:} Enables or disables colorkey.
|
| 862 |
|
|
\begin{lstlisting}
|
| 863 |
|
|
void orgfx_enable_colorkey(unsigned int enable);
|
| 864 |
|
|
\end{lstlisting}
|
| 865 |
|
|
|
| 866 |
|
|
\subsubsection{orgfx\_set\_colorkey}
|
| 867 |
|
|
\textbf{Description:} Sets the colorkey color.
|
| 868 |
|
|
\begin{lstlisting}
|
| 869 |
|
|
void orgfx_set_colorkey(unsigned int colorkey);
|
| 870 |
|
|
\end{lstlisting}
|
| 871 |
|
|
|
| 872 |
7 |
maiden |
\subsubsection{orgfx\_enable\_transform}
|
| 873 |
|
|
\textbf{Description:} Enables or disables hardware accelerated transformation of points.
|
| 874 |
|
|
\begin{lstlisting}
|
| 875 |
|
|
void orgfx_enable_transform(unsigned int enable);
|
| 876 |
|
|
\end{lstlisting}
|
| 877 |
|
|
|
| 878 |
|
|
\subsubsection{orgfx\_set\_transformation\_matrix}
|
| 879 |
|
|
\textbf{Description:} Sets the 3 by 4 transformation matrix used in hardware.
|
| 880 |
|
|
\begin{lstlisting}
|
| 881 |
|
|
void orgfx_set_transformation_matrix(int aa, int ab, int ac, int tx,
|
| 882 |
|
|
int ba, int bb, int bc, int ty,
|
| 883 |
|
|
int ca, int cb, int cc, int tz);
|
| 884 |
|
|
\end{lstlisting}
|
| 885 |
|
|
|
| 886 |
6 |
Orka |
\subsection{Extended newlib}
|
| 887 |
|
|
The extended library is provided in \textbf{orgfx\_plus.h} and \textbf{orgfx\_plus.c}, but \textbf{orgfx.c} also has to be compiled for it to work.
|
| 888 |
|
|
|
| 889 |
|
|
Instead of using surface structs directly, the extended API hides surface management by returning id tags for each surface. The screen surface (defined by id -1) is handled as a single surface, even when double buffering is enabled.
|
| 890 |
|
|
|
| 891 |
|
|
The driver defines the number of available surfaces (not counting the screen) with a static define. Change this if the default value is too low for your application.
|
| 892 |
|
|
|
| 893 |
7 |
maiden |
There are no 3D functions in this API. For the more advanced 3D functionality (meshes, depth buffering etc.), see the advanced API.
|
| 894 |
|
|
|
| 895 |
6 |
Orka |
\subsubsection{orgfxplus\_init}
|
| 896 |
7 |
maiden |
\textbf{Description:} Initializes the screen with the supplied video mode and returns an id for the screen. The only supported bpp is 16. Double buffering and depth buffering can be enabled (and the appropriate buffers will be allocated). The depth buffer is allocated with the same size as the screen. There is no support in the driver to allocate more than one depth buffer.
|
| 897 |
6 |
Orka |
\begin{lstlisting}
|
| 898 |
|
|
int orgfxplus_init(unsigned int width,
|
| 899 |
|
|
unsigned int height,
|
| 900 |
|
|
unsigned char bpp,
|
| 901 |
7 |
maiden |
unsigned char doubleBuffering,
|
| 902 |
|
|
unsigned char zbuffer);
|
| 903 |
6 |
Orka |
\end{lstlisting}
|
| 904 |
|
|
|
| 905 |
|
|
\subsubsection{orgfxplus\_init\_surface}
|
| 906 |
|
|
\textbf{Description:} Unlike the basic API, this function both initializes a surface and loads a prepared image to it in one function call. The return value is an id that can be used to bind the surface. It changes render target during operation, but switches back to the last render target on completion. Since the screen(s) are already initialized by a call to init, they do not need to be loaded using this function.
|
| 907 |
|
|
\begin{lstlisting}
|
| 908 |
|
|
int orgfxplus_init_surface(unsigned int width,
|
| 909 |
|
|
unsigned int height,
|
| 910 |
|
|
unsigned int mem[]);
|
| 911 |
|
|
\end{lstlisting}
|
| 912 |
|
|
|
| 913 |
|
|
\subsubsection{orgfxplus\_bind\_rendertarget}
|
| 914 |
|
|
\textbf{Description:} Binds a surface as the current render target.
|
| 915 |
|
|
\begin{lstlisting}
|
| 916 |
|
|
void orgfxplus_bind_rendertarget(int surface);
|
| 917 |
|
|
\end{lstlisting}
|
| 918 |
|
|
|
| 919 |
7 |
maiden |
\subsubsection{orgfxplus\_bind\_tex0}
|
| 920 |
|
|
\textbf{Description:} Binds a surface as the current active texture.
|
| 921 |
|
|
\begin{lstlisting}
|
| 922 |
|
|
void orgfxplus_bind_tex0(int surface);
|
| 923 |
|
|
\end{lstlisting}
|
| 924 |
|
|
|
| 925 |
6 |
Orka |
\subsubsection{orgfxplus\_flip}
|
| 926 |
|
|
\textbf{Description:} Swaps which buffer to draw on when using double buffering. Needs to be called once before anything shows up on screen!
|
| 927 |
|
|
\begin{lstlisting}
|
| 928 |
|
|
void orgfxplus_flip();
|
| 929 |
|
|
\end{lstlisting}
|
| 930 |
|
|
|
| 931 |
|
|
\subsubsection{orgfxplus\_clip}
|
| 932 |
|
|
\textbf{Description:} Sets the current clipping rect. This is reset to the size of the new render target when orgfxplus\_bind\_rendertarget is called.
|
| 933 |
|
|
\begin{lstlisting}
|
| 934 |
|
|
inline void orgfxplus_clip(unsigned int x0,
|
| 935 |
|
|
unsigned int y0,
|
| 936 |
|
|
unsigned int x1,
|
| 937 |
|
|
unsigned int y1,
|
| 938 |
|
|
unsigned int enable);
|
| 939 |
|
|
\end{lstlisting}
|
| 940 |
|
|
|
| 941 |
|
|
\subsubsection{orgfxplus\_fill}
|
| 942 |
|
|
\textbf{Description:} Draws a rectangle to the current render target with a flat color.
|
| 943 |
|
|
\begin{lstlisting}
|
| 944 |
7 |
maiden |
void orgfxplus_fill(int x0, int y0,
|
| 945 |
|
|
int x1, int y1,
|
| 946 |
6 |
Orka |
unsigned int color);
|
| 947 |
|
|
\end{lstlisting}
|
| 948 |
|
|
|
| 949 |
|
|
\subsubsection{orgfxplus\_line}
|
| 950 |
|
|
\textbf{Description:} Draws a line from (x0,y0) to (x1,y1) to the current render target with a flat color.
|
| 951 |
|
|
\begin{lstlisting}
|
| 952 |
7 |
maiden |
void orgfxplus_line(int x0, int y0,
|
| 953 |
|
|
int x1, int y1,
|
| 954 |
6 |
Orka |
unsigned int color);
|
| 955 |
|
|
\end{lstlisting}
|
| 956 |
|
|
|
| 957 |
|
|
\subsubsection{orgfxplus\_triangle}
|
| 958 |
|
|
\textbf{Description:} Draws a triangle between the points (x0,y0),(x1,y1) and (x2,y2) and fills it with a color.
|
| 959 |
|
|
\begin{lstlisting}
|
| 960 |
7 |
maiden |
void orgfxplus_triangle(int x0, int y0,
|
| 961 |
|
|
int x1, int y1,
|
| 962 |
|
|
int x2, int y2,
|
| 963 |
6 |
Orka |
unsigned int color);
|
| 964 |
|
|
\end{lstlisting}
|
| 965 |
|
|
|
| 966 |
|
|
\subsubsection{orgfxplus\_curve}
|
| 967 |
7 |
maiden |
\textbf{Description:} Draws a quadratic B\'{e}zier curve from (x0,y0) to (x2,y2) with the control point (x1,y1). Uses flat coloring.
|
| 968 |
6 |
Orka |
\begin{lstlisting}
|
| 969 |
7 |
maiden |
void orgfxplus_curve(int x0, int y0,
|
| 970 |
|
|
int x1, int y1,
|
| 971 |
|
|
int x2, int y2,
|
| 972 |
|
|
unsigned int inside,
|
| 973 |
6 |
Orka |
unsigned int color);
|
| 974 |
|
|
\end{lstlisting}
|
| 975 |
|
|
|
| 976 |
|
|
\subsubsection{orgfxplus\_draw\_surface}
|
| 977 |
|
|
\textbf{Description:} Draws a texture to the current render target.
|
| 978 |
|
|
\begin{lstlisting}
|
| 979 |
7 |
maiden |
void orgfxplus_draw_surface(int x0, int y0,
|
| 980 |
6 |
Orka |
unsigned int surface);
|
| 981 |
|
|
\end{lstlisting}
|
| 982 |
|
|
|
| 983 |
|
|
\subsubsection{orgfxplus\_draw\_surface\_section}
|
| 984 |
|
|
\textbf{Description:} Draws a section of a texture defined by src0, src1 to the current render target.
|
| 985 |
|
|
\begin{lstlisting}
|
| 986 |
7 |
maiden |
void orgfxplus_draw_surface_section(int x0, int y0,
|
| 987 |
6 |
Orka |
unsigned int srcx0,
|
| 988 |
|
|
unsigned int srcy0,
|
| 989 |
|
|
unsigned int srcx1,
|
| 990 |
|
|
unsigned int srcy1,
|
| 991 |
|
|
unsigned int surface);
|
| 992 |
|
|
\end{lstlisting}
|
| 993 |
|
|
|
| 994 |
|
|
|
| 995 |
|
|
\subsubsection{orgfxplus\_colorkey}
|
| 996 |
|
|
\textbf{Description:} Sets the colorkey color and enables or disables the use of the colorkey.
|
| 997 |
|
|
\begin{lstlisting}
|
| 998 |
|
|
void orgfxplus_colorkey(unsigned int colorkey,
|
| 999 |
|
|
unsigned int enable);
|
| 1000 |
|
|
\end{lstlisting}
|
| 1001 |
|
|
|
| 1002 |
|
|
\subsubsection{orgfxplus\_alpha}
|
| 1003 |
|
|
\textbf{Description:} Sets the alpha value and enables or disables the use of the alpha blending.
|
| 1004 |
|
|
\begin{lstlisting}
|
| 1005 |
|
|
void orgfxplus_alpha(unsigned int alpha,
|
| 1006 |
|
|
unsigned int enable);
|
| 1007 |
|
|
\end{lstlisting}
|
| 1008 |
|
|
|
| 1009 |
|
|
\subsection{Bitmap Fonts}
|
| 1010 |
7 |
maiden |
Note that bitmap fonts can be generated with the bitfontmaker utility. This utility generates an initialization function that calls the \textbf{orgfx\_make\_bitmap\_font} function and returns a valid font.
|
| 1011 |
6 |
Orka |
|
| 1012 |
|
|
\subsubsection{orgfx\_make\_bitmap\_font}
|
| 1013 |
7 |
maiden |
Creates a orgfx\_bitmap\_font from a image. \textit{glyphSpacing} is the space in pixels between two glyphs in the string, and \textit{spaceWidth} is the size of the space character.
|
| 1014 |
6 |
Orka |
\begin{lstlisting}
|
| 1015 |
|
|
orgfx_bitmap_font orgfx_make_bitmap_font(orgfx_tileset* glyphs,
|
| 1016 |
|
|
unsigned int glyphSpacing,
|
| 1017 |
|
|
unsigned int spaceWidth);
|
| 1018 |
|
|
\end{lstlisting}
|
| 1019 |
|
|
|
| 1020 |
|
|
\subsubsection{orgfx\_put\_text}
|
| 1021 |
7 |
maiden |
Puts the text "str" on the screen with the specified "font" on position x0,y0.
|
| 1022 |
6 |
Orka |
\begin{lstlisting}
|
| 1023 |
|
|
void orgfx_put_text(orgfx_font* font,
|
| 1024 |
7 |
maiden |
int x0, int y0,
|
| 1025 |
|
|
const wchar_t *str);
|
| 1026 |
6 |
Orka |
\end{lstlisting}
|
| 1027 |
|
|
|
| 1028 |
7 |
maiden |
Note the use of wide strings (which enables the use of special characters such as \aa \"{a}\"{o}). Example usage:
|
| 1029 |
|
|
|
| 1030 |
|
|
\begin{lstlisting}
|
| 1031 |
|
|
orgfx_put_text(&font, x0, y0,
|
| 1032 |
|
|
L"Some example text");
|
| 1033 |
|
|
\end{lstlisting}
|
| 1034 |
|
|
|
| 1035 |
6 |
Orka |
\subsection{Vector Fonts}
|
| 1036 |
7 |
maiden |
Note that vector fonts can be generated with the fonter utility. This utility generates an initialization function that calls the \textbf{orgfx\_make\_vector\_font} and \textbf{orgfx\_init\_vector\_font} functions and returns a valid font.
|
| 1037 |
6 |
Orka |
|
| 1038 |
7 |
maiden |
\subsubsection{orgfx\_make\_vector\_font}
|
| 1039 |
|
|
Creates a orgfx\_vector\_font from a series of glyphs.
|
| 1040 |
|
|
\begin{lstlisting}
|
| 1041 |
|
|
orgfx_vector_font orgfx_make_vector_font(Glyph *glyphlist,
|
| 1042 |
|
|
int size,
|
| 1043 |
|
|
Glyph **glyphindexlist,
|
| 1044 |
|
|
int glyphindexlistsize)
|
| 1045 |
|
|
\end{lstlisting}
|
| 1046 |
6 |
Orka |
|
| 1047 |
7 |
maiden |
\subsubsection{orgfx\_init\_vector\_font}
|
| 1048 |
|
|
Initializes the font for use. Needs to be called to set the index list.
|
| 1049 |
|
|
\begin{lstlisting}
|
| 1050 |
|
|
int orgfx_init_vector_font(orgfx_vector_font font);
|
| 1051 |
|
|
\end{lstlisting}
|
| 1052 |
6 |
Orka |
|
| 1053 |
8 |
Orka |
\subsubsection{orgfx\_put\_vector\_char}
|
| 1054 |
|
|
Prints one glyph from the font with the current transformation matrix. If the glyph is not supported in the font the function will return without doing anything.
|
| 1055 |
|
|
\begin{lstlisting}
|
| 1056 |
|
|
void orgfx_put_vector_char(orgfx_vector_font* font, wchar_t text);
|
| 1057 |
|
|
\end{lstlisting}
|
| 1058 |
|
|
|
| 1059 |
7 |
maiden |
\subsubsection{orgfx\_put\_vector\_text}
|
| 1060 |
8 |
Orka |
Prints a string of characters using a vector font. This function sets the transformation matrix from the \textit{offset}, \textit{scale} and \textit{rotation} parameters, then makes a series of calls to \textbf{orgfx\_put\_vector\_char}.
|
| 1061 |
|
|
\begin{lstlisting}
|
| 1062 |
|
|
void orgfx_put_vector_text(orgfx_vector_font* font,
|
| 1063 |
|
|
orgfx_point3 offset,
|
| 1064 |
|
|
orgfx_point3 scale,
|
| 1065 |
|
|
orgfx_point3 rotation,
|
| 1066 |
|
|
const wchar_t *str,
|
| 1067 |
|
|
unsigned int color);
|
| 1068 |
|
|
\end{lstlisting}
|
| 1069 |
6 |
Orka |
|
| 1070 |
7 |
maiden |
\subsection{3D API}
|
| 1071 |
|
|
There are two major parts of the 3D API, one is the transformation matrix interface and the other is the 3D mesh interface.
|
| 1072 |
|
|
|
| 1073 |
|
|
\subsubsection{Transformations}
|
| 1074 |
|
|
By setting the transformation matrix the ORGFX core can perform hardware accelerated transformations for every point sent to it, causing significantly less overhead than if this was done in software.
|
| 1075 |
|
|
|
| 1076 |
|
|
The relevant functions are listed below:
|
| 1077 |
|
|
|
| 1078 |
6 |
Orka |
\begin{lstlisting}
|
| 1079 |
7 |
maiden |
orgfx_matrix orgfx3d_identity(void);
|
| 1080 |
|
|
orgfx_matrix orgfx3d_rotateX(orgfx_matrix mat, float rad);
|
| 1081 |
|
|
orgfx_matrix orgfx3d_rotateY(orgfx_matrix mat, float rad);
|
| 1082 |
|
|
orgfx_matrix orgfx3d_rotateZ(orgfx_matrix mat, float rad);
|
| 1083 |
|
|
orgfx_matrix orgfx3d_scale(orgfx_matrix mat, orgfx_point3 s);
|
| 1084 |
|
|
orgfx_matrix orgfx3d_translate(orgfx_matrix mat, orgfx_point3 t);
|
| 1085 |
|
|
|
| 1086 |
|
|
inline void orgfx3d_set_matrix(orgfx_matrix mat);
|
| 1087 |
6 |
Orka |
\end{lstlisting}
|
| 1088 |
|
|
|
| 1089 |
7 |
maiden |
\subsubsection{orgfx3d\_make\_mesh}
|
| 1090 |
|
|
Initializes a mesh with the necessary arrays generated by the meshmaker utility.
|
| 1091 |
6 |
Orka |
|
| 1092 |
7 |
maiden |
\begin{lstlisting}
|
| 1093 |
|
|
orgfx_mesh orgfx3d_make_mesh(orgfx_face* faces,
|
| 1094 |
|
|
unsigned int nFaces,
|
| 1095 |
|
|
orgfx_point3* verts,
|
| 1096 |
|
|
unsigned int nVerts,
|
| 1097 |
|
|
orgfx_point2* uvs,
|
| 1098 |
|
|
unsigned int nUvs);
|
| 1099 |
|
|
\end{lstlisting}
|
| 1100 |
6 |
Orka |
|
| 1101 |
7 |
maiden |
\subsubsection{orgfx3d\_mesh\_texture\_size}
|
| 1102 |
|
|
This should be called \textit{only once} for each mesh that will be using texture coordinates. Since the ORGFX device uses pixel coordinates the UV coordinates must be updated with the size of the used texture.
|
| 1103 |
6 |
Orka |
|
| 1104 |
|
|
\begin{lstlisting}
|
| 1105 |
7 |
maiden |
void orgfx3d_mesh_texture_size(orgfx_mesh* mesh,
|
| 1106 |
|
|
unsigned int width,
|
| 1107 |
|
|
unsigned int height);
|
| 1108 |
6 |
Orka |
\end{lstlisting}
|
| 1109 |
|
|
|
| 1110 |
7 |
maiden |
\subsubsection{orgfx3d\_draw\_mesh}
|
| 1111 |
|
|
This function draws the mesh to screen, using the \textit{translation}, \textit{rotation} and \textit{scale} vectors stored in the mesh structure. If \textit{filled} is set to zero, the mesh will be drawn as a colored wireframe. If \textit{filled} is set to one and \textit{textured} to zero, the mesh will be drawn with interpolated colors (the mesh format currently does not support materials). If \textit{filled} is set to one and \textit{textured} is also set to one, the mesh will be textured using interpolated uv texture coordinates.
|
| 1112 |
|
|
|
| 1113 |
|
|
\begin{lstlisting}
|
| 1114 |
|
|
void orgfx3d_draw_mesh(orgfx_mesh* mesh,
|
| 1115 |
|
|
int filled, int textured);
|
| 1116 |
|
|
\end{lstlisting}
|
| 1117 |
|
|
|
| 1118 |
|
|
\subsection{Linux}
|
| 1119 |
|
|
The current version of the core does not have a Linux driver.
|
| 1120 |
|
|
|
| 1121 |
|
|
\subsection{Software emulation}
|
| 1122 |
|
|
The entire device has a software implementation to make it easier to write applications for the device. The \textbf{orgfx\_sw.c} file replaces the \textbf{orgfx.c} and \textbf{orgfx\_plus.c} files, and renders pixels as they would be rendered by the graphics accelerator, but on a PC. The software implementation uses SDL as the backend.
|
| 1123 |
|
|
|
| 1124 |
|
|
\subsection{Utilities}
|
| 1125 |
|
|
\subsubsection{Sprite maker utility}
|
| 1126 |
|
|
\label{sec:spritemaker}
|
| 1127 |
|
|
A small application that converts an image into a header file that can be included in the project when compiled. The application generates an array of color values that can be loaded as a sprite.
|
| 1128 |
|
|
|
| 1129 |
|
|
The application has support for reading common image file formats such as bmp, png and jpg (for a full list, see the supported file formats of the SDL\_image libaray). 8- 16- and 32-bit output is supported, and can be changed by passing a command line argument to the program (by default, the output is adjusted for 16 bit color mode).
|
| 1130 |
|
|
|
| 1131 |
|
|
The resulting output header file, which is named after the input, can be included in a program using the extended bare metal driver. The easiest way to use the sprite is to use the generated initialize function defined in the header file.
|
| 1132 |
|
|
|
| 1133 |
|
|
\subsubsection{Bitmap font maker utility}
|
| 1134 |
|
|
\label{sec:bitmapfontmaker}
|
| 1135 |
|
|
Another application generates the data structures necessary to load bitmap fonts with very little effort. It takes an image and a grid spacing as input, and automatically generates offsets for all the glyphs in the font. The font generated by the program has 256 characters arranged according to the ASCII charset, as seen in figure \ref{fig:ascii} and \ref{fig:ascii2}.
|
| 1136 |
|
|
|
| 1137 |
|
|
\begin{figure}
|
| 1138 |
|
|
\begin{center}
|
| 1139 |
|
|
\includegraphics[scale=0.6]{../pictures/ascii}
|
| 1140 |
|
|
\caption{The ASCII table. Each number from 0 to 127 refers to a character. The numbers 0 to 31 cannot be printed.}
|
| 1141 |
|
|
\label{fig:ascii}
|
| 1142 |
|
|
\end{center}
|
| 1143 |
|
|
\end{figure}
|
| 1144 |
|
|
|
| 1145 |
|
|
\begin{figure}
|
| 1146 |
|
|
\begin{center}
|
| 1147 |
|
|
\includegraphics[scale=0.6]{../pictures/ascii2}
|
| 1148 |
|
|
\caption{The extended ASCII table. Each number from 128 to 255 refers to a character, mostly special characters not included in the basic table.}
|
| 1149 |
|
|
\label{fig:ascii2}
|
| 1150 |
|
|
\end{center}
|
| 1151 |
|
|
\end{figure}
|
| 1152 |
|
|
|
| 1153 |
|
|
The application has support for reading common image file formats such as bmp, png and jpg (for a full list, see the supported file formats of the SDL\_image libaray). 8- 16- and 32-bit output is supported, and can be changed by passing a command line argument to the program (by default, the output is adjusted for 16 bit color mode). Both vertical and horizontal grid spacing are set to 32 pixels by default, but this can be changed through command line arguments.
|
| 1154 |
|
|
|
| 1155 |
|
|
The resulting output header file, which is named after the input, can be included in a program using the bare metal and font driver. The easiest way to use the bitmap font is to use the generated initialize function defined in the header file.
|
| 1156 |
|
|
|
| 1157 |
|
|
\subsubsection{Mesh maker utility}
|
| 1158 |
|
|
\label{sec:meshmaker}
|
| 1159 |
|
|
The mesh maker utility loads 3D objects and generates a header file that can be used by the advanced 3D API. Currently the utility only supports Wavefront .obj files which only contains 3rd order polygons. Any higher order polygons will be discarded, so all polygons in the model must be converted to triangles prior to running the utility.
|
| 1160 |
|
|
|
| 1161 |
|
|
The application supports loading texture coordinates for each vertex, allowing for textured meshes.
|
| 1162 |
|
|
|
| 1163 |
|
|
The resulting output header file, which is named after the input, can be included in a program using the bare metal 3D API. The easiest way to use the mesh is to use the generated initialize function defined in the header file.
|
| 1164 |
|
|
|
| 1165 |
|
|
\subsubsection{Vector font maker utility}
|
| 1166 |
|
|
\label{sec:fontmaker}
|
| 1167 |
|
|
The Font maker is a application that can convert a .ttf file to a format that the graphics card can handle. The Font maker outputs a .h file that can be included in a project to enable the graphics accelerators vector font capabilities. The converter finds all explicit vector points in a ttf file and then calculates the implicit points. At the same time it checks where the glyphs contours ends, the points is then sent to a Delaunay triangulation function based on the work of V. Domiter and B. Zalik and implemented by M. Green and T. \AA hl\'{e}n \footnote{http://code.google.com/p/poly2tri/}. The generated .h file consists of two fields for each glyph, one field for B\'{e}zier writes and one for triangle writes. The generated header file will contain two lists for each glyph, one to store B\'{e}zier writes and one to store triangle writes. The rendered result can be seen in figure \ref{fig:orsocgfxfont}.
|
| 1168 |
|
|
|
| 1169 |
|
|
\begin{figure}
|
| 1170 |
|
|
\begin{center}
|
| 1171 |
|
|
\includegraphics[scale=0.6]{../pictures/orsocgfxfont}
|
| 1172 |
|
|
\caption{A font rendered by the software implementation of the ORGFX. B\'{e}zier curves are single colored while the triangles are interpolated between current color and black}
|
| 1173 |
|
|
\label{fig:orsocgfxfont}
|
| 1174 |
|
|
\end{center}
|
| 1175 |
|
|
\end{figure}
|
| 1176 |
|
|
|
| 1177 |
|
|
|
| 1178 |
6 |
Orka |
\subsubsection{Regger}
|
| 1179 |
|
|
The regger is a application that keeps track of what register addresses is set in the RTL code and in the drivers.
|
| 1180 |
|
|
|
| 1181 |
|
|
\section{Programming examples}
|
| 1182 |
|
|
\label{sec:examples}
|
| 1183 |
|
|
The following piece of code shows how to use the extended interface for a bare metal implementation on the ORPSoCv2 platform. Bahamut\_cc.png.h is a 186 by 248 pixel image with a pinkish background (rgb code ff00ff, or f81f in 16 bit). The header file is generated by the sprite maker utility at 16 bit color depth.
|
| 1184 |
|
|
|
| 1185 |
|
|
\begin{lstlisting}
|
| 1186 |
|
|
#include "orgfx_plus.h"
|
| 1187 |
|
|
|
| 1188 |
|
|
#include "Bahamut_cc.png.h"
|
| 1189 |
|
|
|
| 1190 |
|
|
int main(void)
|
| 1191 |
|
|
{
|
| 1192 |
|
|
int i;
|
| 1193 |
|
|
|
| 1194 |
|
|
// Initialize screen to 640x480-16@60
|
| 1195 |
|
|
// No double buffering
|
| 1196 |
|
|
int screen = orgfxplus_init(640, 480, 16, 0);
|
| 1197 |
|
|
|
| 1198 |
|
|
// Initialize dragon sprite
|
| 1199 |
|
|
int bahamut_sprite =
|
| 1200 |
|
|
orgfxplus_init_surface(186, 248, Bahamut_cc);
|
| 1201 |
|
|
|
| 1202 |
|
|
// Activate colorkeying
|
| 1203 |
|
|
orgfxplus_colorkey(0xf81f, 1);
|
| 1204 |
|
|
|
| 1205 |
|
|
// Clear screen, white color
|
| 1206 |
|
|
orgfxplus_fill(0,0,640,480,0xffff);
|
| 1207 |
|
|
// Draw a few lines with different colors
|
| 1208 |
|
|
orgfxplus_line(200,100,10,10,0xf000);
|
| 1209 |
|
|
orgfxplus_line(200,100,351,31,0x0ff0);
|
| 1210 |
|
|
orgfxplus_line(200,100,121,231,0x00f0);
|
| 1211 |
|
|
orgfxplus_line(200,100,321,231,0xf00f);
|
| 1212 |
|
|
|
| 1213 |
|
|
// Draw the dragon at different alpha settings
|
| 1214 |
|
|
orgfxplus_alpha(64,1);
|
| 1215 |
|
|
orgfxplus_draw_surface(100, 100, bahamut_sprite);
|
| 1216 |
|
|
orgfxplus_alpha(128,1);
|
| 1217 |
|
|
orgfxplus_draw_surface(120, 102, bahamut_sprite);
|
| 1218 |
|
|
orgfxplus_alpha(255,1);
|
| 1219 |
|
|
orgfxplus_draw_surface(140, 104, bahamut_sprite);
|
| 1220 |
|
|
|
| 1221 |
|
|
while(1);
|
| 1222 |
|
|
}
|
| 1223 |
|
|
\end{lstlisting}
|
| 1224 |
|
|
|
| 1225 |
7 |
maiden |
More example programs are supplied with the implementation in the \textbf{sw/examples} directory.
|
| 1226 |
|
|
|
| 1227 |
6 |
Orka |
\end{document}
|
