Over the past few days, I have been writing a version of graphx for Column-Major mode. This has benefits such as removing screen tearing, and making it easier to implement the hardware cursor.

To convert a graphx program to a graphy program, all you will have to do is to perform a find and replace of gfx_ to gfy_ and GFX_ to GFY_.

graphy is written in C and will wrap graphx functions when possible. While C does make it easier to implement graphy, it does come with the drawback of speed. It takes ~15 seconds to move across the screen in the graphy version of Oriam compared to ~2 seconds in the graphx version. Once every function has been implemented/wrapped, graphy can start being optimized in assembly.

Since graphy was coded in C, it could make it easier to port graphx programs to Windows/Linux. One of my own games that was written in C can be compiled for the ti84ce or Windows with the use of a few macros.

Currently, all v1-v4 graphx functions have been implemented except for triangles and polygons. My main focus at the moment is fixing bugs and clipping with the v1 functions, along with finding ways to optimize the code.

GitHub: https://github.com/ZERICO2005/toolchain/tree/add-graphy/src/graphy

A very nice initiative, well done

Excuse my ignorance, but what does it mean to be column major, and how does it help with screen tearing and hardware cursor? Are there other benefits?

The ti84ce's lcd is actually a 240x320 lcd, but by default, its run in row-major mode to make it a 320x240 screen. This means that vram gets copied to the screen row by row while the lcd gets updated column by column, creating a diagonal screen tearing effect.

For a comparison, graphx is on the left (at 50% speed), and graphy is on the right (at 300% speed).

Oh, fantastic! Very much looking forward to the optimized version of this. Could be quite useful for raycasting endeavors.

this kinda hurts my brain looking at it lol

GraphY is now a proper library graphy.8xv. I still have to implement some functions and rewrite them in assembly, but here is a playable demo of ILIUG (Column-Major OIRAM), which removes the diagonal screen tearing:
https://github.com/ZERICO2005/toolchain/releases/tag/ILIUG_alpha


Keep in mind that graphy.8xv is currently unstable, so I would highly discourage shipping GraphY programs until the interface is finalized.

The performance gap has reduced significantly as more functions are ported over to assembly. With the buffered cube demo running at 72% the speed of graphx now.

Some of graphx functions were relatively easy to convert to a column-major implementation. gfy_RotateScaleSprite only required 4 lines to be changed, allowing for FruitNinjaCE to run at almost full speed instead of around 1.2fps with the C implementation of the function.

The next hurdle I have to clear is implementing clipping routines such as gfy_TransparentSprite in assembly. Which is currently responsible for the frame-rate dropping in ILIUG when an enemy is on the edge/border of the screen.

This looks very promising, looking forward to a stable, optimized version

I definitely have plans to use this when it comes out, the screen tearing with graphx always bugged me.

Do you use the buffers and swap them? I don't have that much tearing when using them