How To

Implementing a pixel buffer

0

SomePerson 2020-05-26 07:04

how does one implement a pixel buffer here in nx like the one in the original?

is there a tutorial? i can follow?


was8bit 2020-05-26 12:37

These examples are your only possible options...

https://lowresnx.inutilis.com/topic.php?id=216

https://lowresnx.inutilis.com/topic.php?id=1161


Timo 2020-05-26 17:33

As usual I want to mention that pixel buffers in NX are a complicated feature for advanced programmers. The main feature of NX are sprites and tilemaps.


was8bit 2020-05-26 17:51 (Edited)

Yes, and to clarify...

ORIGINAL LOWRES: the backgrounds actually held the pixels, and timing on showing the backgrounds was whenever, as in it is possible to wait a few seconds or even a few minites before the visible screen changed and updated

LOWRES NX: the backgrounds only hold character# and palette# only, the pixels only exist in the CHARACTERS as shown using CHAR DESIGNER..timing is a strict 60 frames a second, and the visible screen is always refreshed on this timing of every 1/60 of a second (to facilitate smooth animations)

To "simulate" drawing individual pixels on the screen, you must populate the background with all characters and then use complicated math to edit each individual character using PEEK POKE commands ... this approach does not completely fill the whole screen so additional advanced tricks must be used to simulate a full screen...


was8bit 2020-05-26 17:54

The user nathanielbabiak has done a great job on the math behind this issue, i recommend researching their work and or asking them for further clarifications :)

https://lowresnx.inutilis.com/user.php?id=221


nathanielbabiak 2020-06-03 17:13 (Edited)

The key information is actually in the manual, where it says "The first 8 bytes of a character contain the low bits of all its pixels, followed by 8 more bytes containing the high bits of all pixels."

The setup is best exemplified in my upload Pxl Library Direct Display, but unfortunately it's for a binary image display (not 4-color).

(I actually have a 4-color variant that's even faster *regarding the drawing algorithms* than the two color variant but haven't uploaded it yet, I had to develop it to make progress on the ray casting program.)


nathanielbabiak 2020-11-01 04:01

I wanted to necro post on this thread... just to say I've finally uploaded the 4-color variant - it took a while! (Life gets in the way.) With the tool and library of subprograms I've uploaded, you don't need to know the math. You can just use the drawing subprograms. Or, if you want to make your own drawing algorithm, use the addressing arrays directly.

I don't mean to steer you away from implementing your own to learn the structures required in the system's memory, but I will say today's upload (using addressing arrays) is between two and five times faster than my upload from June, and it's also easier to read the code too.


Log in to reply.