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)
This text has been moved to my Pxl Library 2.0 upload (and reorganized there too).
GAMELEGEND 2020-11-20 01:26 (Edited)
I tried before to look for the drawing programs and the PXL library
but I couldn't find where to look in the code
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)
This text has been moved to my Pxl Library 2.0 upload (and reorganized there too).
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
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....
You CAN use POKE to edit pixels in one character, in this case character#0, but it requires complicated bit math... https://lowresnx.inutilis.com/topic.php?id=118
Fancy manipulations of SPRITES can simulate drawing pixel points.. https://lowresnx.inutilis.com/topic.php?id=451 https://lowresnx.inutilis.com/topic.php?id=471 https://lowresnx.inutilis.com/topic.php?id=514
Additionally, if your "pixels" are "BIG" then again you can create neat things... https://lowresnx.inutilis.com/topic.php?id=475 https://lowresnx.inutilis.com/topic.php?id=532 https://lowresnx.inutilis.com/topic.php?id=543 https://lowresnx.inutilis.com/topic.php?id=554 https://lowresnx.inutilis.com/topic.php?id=1015
Using many sprites closely together can simulate a drawn line.. https://lowresnx.inutilis.com/topic.php?id=491 https://lowresnx.inutilis.com/topic.php?id=1057 https://lowresnx.inutilis.com/topic.php?id=1067
Misc. things... https://lowresnx.inutilis.com/topic.php?id=556 https://lowresnx.inutilis.com/topic.php?id=729 https://lowresnx.inutilis.com/topic.php?id=875 https://lowresnx.inutilis.com/topic.php?id=884 https://lowresnx.inutilis.com/topic.php?id=926 https://lowresnx.inutilis.com/topic.php?id=1275
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... https://lowresnx.inutilis.com/topic.php?id=854
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
I MADE A DEMO THAT SHOWS YOU ONE WAY OF EDITING ANY PIXEL IN ANY CHARATER# USING ALL 3 COLORS :)
I USE THE APROACH OF AN ARRAY THAT USES COLOR #'S 0,1,2,3 AS THAT IS SIMILAR TO HOW YOU WOULD EDIT A CHARACTER ALREADY, SO THE FORMAT IS A FAMILIAR INTERFACE, SO DONT HAVE TO WORRY ABOUT THE BIT MATH.... I ALSO WROTE THE CODE OUT IN A MORE READABLE FORMAT JUST IN CASE YOU WANTED TO EXPLORE THE MATH :)
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 that...you 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 method..lol...plan 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
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 ...ummm...like backgrounds. And the cool Tiny Timo Text thing. Thanks Timo!
Alice 2020-11-20 13:27
...you 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.