How To

how do i draw pixels to the screen


GAMELEGEND 2020-11-19 22:37 (Edited)

i want to draw pixels to the screen but i cant figure it out

i looked at the manual
but i could not find it

i need some help

Timo 2020-11-19 23:38

As always I recommend to stick with cells and sprites and be creative. LowRes NX is not made for drawing pixels.
Of course it IS somehow possible and I‘m sure was8bit will tell you about it ;)

nathanielbabiak 2020-11-20 01:23 (Edited)

I wrote Pxl Library 2.0 to be as accessible as possible, but it's still pretty complicated. In the source code there's a bunch of global variables defined at the top, then the pxl display initialization, then some ASCII art.

You can delete everything inside the ASCII art and put your code there. To draw a pixel, use PXL2_SETP( PX, PY, PC ), which has arguments of the pixel coordinates (x, y) and pixel color (0 to 3).

For other pxl-level commands, the arguments in each of the subprograms will give you a hint. (PX,PY) is integer pixel coordinates, (FX,FY) is floating point pixel coordinates. And to keep it easy, only use the PXL2_ subprograms. The PXL_ subprograms require slightly different arguments (boolean values), and it's really annoying to use them.

GAMELEGEND 2020-11-20 01:26 (Edited)

thanks :)

I tried before to look for the drawing programs and the PXL library

but I couldn't find where to look in the code

thanks :)

Alice 2020-11-20 01:29

Not much into the graphics thing...but couldn’t you draw characters (or poke) with one pixel in each of the different positions in the character block and just place the correct character in the cell? You would just have to translate your pixel position to the specific cell and character and choose your color. Overlapping shouldn’t be a problem I think with a transparent background (black). Just an idea.

nathanielbabiak 2020-11-20 01:43 (Edited)

I never did write a manual for Pxl Library 2.0! I'll put it here :-)

The first few subprograms (lines 35 to 122) are for initialization, just ignore them for now.

The (line 123) subprogram PXL_CLS is an extension of the LowRes NX command, and works for both 2 and 4 color pxl display. (The included display is a 4 color pxl display.)

You can call (line 134) PXL_PALETTE( RED, GREEN, BLUE ) only when using a 2 color pxl display, and it'll set the foreground pixel color for you. (The background color of the pxl display will match the system background color.)

Starting on line 140, the PXL_ drawing subprograms are SET (meaning "set" a pixel to a certain color), TEST (to return a pixel's color), VERT and HORZ (for drawing straight lines), CIRC (for outline circles), CIRCFILL (for filled circles), LINE (which has a pair of X1,Y1 and X2,Y2 arguments for diagonal lines), RECT (for filled rectangles), TRIFAST (a triangle drawing routine that is "fast" because it isn't pixel-perfect), and TESSFAST (a tessellated triangle drawing routine, fast for the same reason).

The CELL, SPRITE, and TEXT subprograms are extensions of LowRes NX (but here CELL is limited to PX being a multiple of 8, and PY being a multiple of 2, it's much faster than SPRITE though).

There's also LOAD and SAVE (to grab a whole rectangular section of the screen and put it somewhere in working memory), but it's limited to PX being a multiple of 8 (no limit on PY).

The suffix "_CLIP" means a drawing command will automatically clip the border of the window.

Starting on line 1,488 is the PXL2_ drawing subprograms. These take argument PC (pixel color), rather than the terrible boolean logic of the PXL_ subprograms, so start with them even though they're a slower.

Also, some subprograms have variations for PX,PY and FX,FY. The PX,PY variants are for (integer) pixel coordinates, whereas the FX,FY variants are for floating-point (non-integer) pixel coordinates. Rounding is built into the FX,FY variants, which will be super useful for 3D polys.

nathanielbabiak 2020-11-20 01:48 (Edited)

Alice, yeah, that's exactly it! There's been a few implementations of that scheme on this site, but at 160x128 px, you'd need 320 characters to make it work, and LowRes NX only has 256. Some users have limited their pixel displays to 128x128 (using all 256 characters), and others use the raster interrupt to swap-out the bytes, like Pxl Library 2.0 does by default (although this can be changed).

There's a few features that make Pxl Library 2.0 unique, though:
* pre-calculates all the addressing math and bitmasks into arrays (for runtime speed)
* custom character layouts (using the Pxl BG Tool)
* simplified initialization (for token minimization)
* optimization for LowRes NX 1-clock-cycle cost of floating point operations (DDA algorithms from the 1960s are actually *slower* in many instances due to initialization cost)
* raster interrupt implementation is +/-350 clock cycles faster than other implementations on this site

was8bit 2020-11-20 05:47

@ Gamelegend,

Lowres NX is built on a foundation of cell blocks like a checkerboard, that can be filled with 8x8 designed graphics.... so lowres is NOT designed to directly control pixels with code while the code is running...

However, depending on what you want, and some cleverness, you CAN create smooth animations....

this one uses cleverly drawn graphics to create smooth flowing animations...

You CAN use POKE to edit pixels in one character, in this case character#0, but it requires complicated bit math...

Fancy manipulations of SPRITES can simulate drawing pixel points..

Additionally, if your "pixels" are "BIG" then again you can create neat things...

Using many sprites closely together can simulate a drawn line..

Misc. things...

If you want big screen of pixels, the trick is to first place empty characters on the screen, then use bit math to "draw" pixels... it isnt easy, and the "easiest" method only allows a smaller screen as 255 characters are not enough to fill the whole screen... here is my smaller screen pixel editor...

was8bit 2020-11-20 06:07 (Edited)


... so, long story short, technically speaking, you cannot draw pixels to the screen... but you CAN draw pixels into a character memory... so, when you place that 8x8 character on one of the screen's background, you can THEN see the pixel you drew...

So, to make a small screen 5x5 characters big (or 40x40pixels big) this will require:
1) 25 unused characters carefully arranged, lets say characters 1-25.. so


so to draw a line from the upper left corner of your "mininscreen" you now need to..
In each of the following charaters, you need to change these 0 bits into 1 bits


For each character #'s #1, #7, #13, #19, #25

And PRESTO, a straight diagnonal line :)

So, for ANY virtual plot on your 40x40 mini screen, it takes some math... so plot on pixel on the virtual screen PLOT (37,22) you first need to calculate WHICH chacacter is in that virtual spot... so

37/8=4.5 and 22/8=2.7 so thats 4 characters over and 2 characters down, or character#15

NOW which point in that character is it?

37-(4*8)=5 so Xpoint=5
22-(2*8)=6 so Ypoint=6

Now, you do a bunch of specific bit maths to put a point in that character#15 at pixel location (5,6)

And THAT is what is required to draw one pixel point on the screen!

Alice 2020-11-20 07:08

...yep...could just get the byte values for your frames, poke them in to one BG and display it while the other BG draws the next frame for your animation. Just preload them in an array of frames.

Again..just an idea...not a gfx guy at all.

Alice 2020-11-20 07:11

...I guess you could load them through the RASTER calls, line by line. (...or block of characters (use a MID(...blah,blah) with the raster value as the index.)).....)))...just in case I missed a “)”.

Alice 2020-11-20 08:44

...don’t know anything about the PXL library...just read the post. I guess it does what I was suggesting. There must be a program out there that can give you a line by line bit map of an image the size you want with the binary values. Then it would just mean copy/paste into data and read the lines. Might even be one that can give you that frame by frame for an animation. I’ll have a look when I have time.

Timo 2020-11-20 09:52

Alice, I think you think that each BG has memory for every pixel, but this is not correct. A BG only has memory to store a char number for each cell. And there can only be 256 different characters (at once), not enough to fill the complete screen. This is why tricks are needed.
This is how most 8- and 16-bit consoles worked, though most of them had more characters and could fill the screen.

was8bit 2020-11-20 10:30




Alice 2020-11-20 12:55 (Edited)

Timo...understood. They said in the manual that the characters had “invisible” for a color....but I guess it’s not invisible if you put one character over another and the first character disappears. For example. Character 1 has a pixel at position 0,0 (top left of the 8x8). Character 2 has a pixel at position 1,0 (one pixel to the right. Since the black (as I understood it) is supposed to be invisible, if character 2 is put in the same position as character 1 (say cell 0,0) then we should see two pixels next to each other...however...this is not the case. The character on top hides the character under it. The idea was to put the characters on top of each other on the back ground...but as you said...I think that’s not possible.

So...based on only have enough characters to show all combinations of pixels if your “pixels” are 4 pixels wide by 4 pixels high (4 “pixels” with 16 combinations). At 4x4 (because we can’t have 3x3) that would make 16 “pixels” that are 2 pixels high and 2 pixels wide. (That would make 65536 combinations)...but there’s only 256 characters. So if you want to use my on having big blocky “pixels” that are 4x4 actual pixels in size on a character (4 pixels per character). Might look neat if you designed the big pixels with different grades of color and make them look like a real CRT display.

The good news is, because you would need to read a 2x2 block of binary data to know what character to get, you could re-encode your image map and probably have a pretty fast graphic because of the lower resolution...maybe? Only need 16 characters and they can be labeled 0-F (hexadecimal codes) to only need to read one char in your array of graphics.

Would be quick to draw the 32 lines between raster calls?...let me know what you think. It would give you a resolution of 64x64 (2x2 per character).


qwaffe 2020-11-20 13:06 (Edited)

tested the black on two background layers and it works, the pixels appear next to each other

test.nx | Open in app
2020-11-20 13:06

Alice 2020-11-20 13:17 (Edited)

Yep...but there’s no simple way of adding a third...only two BGs. Problem is it wouldn’t be possible to get access to all the pixels in a character...only 255 characters. (Unless you start using POKE to modify individual characters...which you can do)

Because of the limit, and the 8x8 size...the only combination that would fit is 2x2.

But I agree...they are “invisible” to a character on a different BG. Good for other applications backgrounds. And the cool Tiny Timo Text thing. Thanks Timo!

Alice 2020-11-20 13:27 can modify individual characters with POKE as did was8bit in his example...problem is you can’t modify the whole screen because there are less characters (256) than the number of cells in a background (1024).

I was looking more for a solution that can modify the whole screen like a TV.

Timo 2020-11-20 14:18

Here again where all the trouble is coming from:

The whole system of LowRes NX was very much inspired by the Game Boy and other classic game consoles. The idea was to do things as there were done back then, which basically means to do all graphics with sprites and tiles instead of drawing on a pixel buffer.

I still think it's cool that some of you found ways to work around the limitations, this is actually part of the retro system fun. But for everyone who is more interested in making games instead of the technology I recommend to stick with sprites and tiles.

Just keep in mind that all these games for the Game Boy, NES, SNES, Master System, Mega Drive etc. were made like this.

Log in to reply.