Alice 2020-11-21 05:37
Hey, as per the message below, was8bit said you had a solution for what I was looking for. I want to draw a full screen image and be able to load others to make a full screen animation without POKEing.
Because there are 1024 cells and only 255 characters, I was not able to find a solution other than what I mentioned to was8bit which can produce full screen animation but with a resolution of 64x64.
https://lowresnx.inutilis.com/topic.php?id=1547#post-10733
See post above.
I wasn’t able to find the solution was8bit was referring to.
Thanks.
“
was8bit 2020-11-21 04:25
Nathanielbabiak (sp?) has already resolved how to fill the whole screen... it takes quite a few tricks to pull off... otherwise you can only have an 128x128 sized pixel screen.... with top left corner (char#0) unused...
“
was8bit 2020-11-21 08:08 (Edited)
The "without POKEing" was as far as the end user is concerned..
POKE is just a command, much like CELL 2,2,123 is a command, and in fact the CELL command actually does the identical thing that POKE does, you just dont see it...
the only difference is that CELL 2,2,123 is user friendly to those who want the feel of basic commands, but it actually "pokes" data into the background memory for you without you trying to figure out all the needed memory math... ;)
Alice 2020-11-21 08:10
Ok
was8bit 2020-11-21 08:15
Check out this...
https://lowresnx.inutilis.com/topic.php?id=243
With NO conventional data like characters, backgrounds, sound editor data, etc... i can COMPLETELY bypass all basic commands and basic data structures, and go directly into the main engine of lowres and "fire it up" ;)
was8bit 2020-11-21 08:17
The clever person we mentioned above uses clever tricks, in addition to POKE, and bit math, to accomplish smooth animations... but i really cant wrap my mind around those tricks... i have a hard enough time managing bit math...
was8bit 2020-11-21 08:22
Here is another one... i added using POKE into the sprite memory banks..
was8bit 2020-11-21 08:26
Others have worked on full screen, but it flashes alot, so not as good...
was8bit 2020-11-21 08:32
Looking near the bottom of the help section you find this...
Hardware Reference
Memory Map
$0000 - Cartridge ROM (32 KB)
$8000 - Character Data (4 KB)
$9000 - BG0 Data (2 KB)
$9800 - BG1 Data (2 KB)
$A000 - Working RAM (16 KB)
$E000 - Persistent RAM (4 KB)
$FE00 - Sprite Registers (256 B)
$FF00 - Color Registers (32 B)
$FF20 - Video Registers
$FF40 - Audio Registers
$FF70 - I/O Registers
Lowres uses the data stored in these to totally run everything... so whether you use basic commands to edit this data, or use POKE or COPY to edit this data, lowres doesnt really care which method you use, the end result will be the same :)
Alice 2020-11-21 09:33
..saw that. The whole idea is to avoid that. I want to load a frame in an array and have it display through the use of characters. I don’t want to modify a character or characters with a POKE since there are not enough characters to cover the whole screen. If you have more changes in one frame to the next you will touch displayed characters that will redraw on the line call.
Yes...I understand what you mean, but the idea is to use the existing characters. See the example I just put up...that’s the characters that are done. Now it’s just the decoder and reading the array for the frame(s).
Alice 2020-11-21 09:35 (Edited)
I’m not saying you are wrong in anything you are saying...seems like that is what you are saying. I’m just trying to do this with the characters. Thanks for your help though.
was8bit 2020-11-21 12:03
The background layers do not actually hold the graphics, the graphics actually only exist in memory $8000...what is stored in the background ($9000) is merely the character #, so you are talking about changing different values in different places in $9000
was8bit 2020-11-21 12:13
Each character holds 8x8 pixels.. in your posted example, each character simulates 4x4 pixel sized blocks.... A very intersting approach... however you leave no more room for additional graphics, and can no longer print text or numbers anymore (the font set resides on page 4) so you are restricted to the 4x4 block design
Its very clever though... i look forward to what you can create with this approach :)
Alice 2020-11-21 13:30 (Edited)
Not sure how far I will take this thing...graphics are not for me. But I’ll have it working to display a graphic fed from a string. The idea was just to have full screen graphics from characters that can handle different pixel configurations in the resolution of 64x64. Back to my other project after that.
To change a specific pixel, you’d just have to map the xy to the cell and identify which of the 4 pixels to change. A tool working at 2x zoom would give you the ability to use touchable characters since at 2x zoom the pixels would be a whole character. Then you could edit the entire background like a big canvas. You could poke a small pixel size canvas as a preview using a few characters. However...I’m not the guy that’s going to start making graphics tools. The tool could be used as a frame by frame editor.
Anyhow,...just throwing it out there if anyone is interested.
was8bit 2020-11-21 15:09
:)
nathanielbabiak 2020-11-22 02:21
I read the other thread and this one, and checked out your code too. I like that, to keep track of the character data, you've mapped the character numbers to the quadrant colors. Something like %DDCCBBAA, where %AA represents the color of the block of pixels in quadrant I, %BB00 represents the color in quadrant II, %CC0000 represents the color in quadrant III, and %DD000000 represents the color in quadrant IV.
I did notice something in your code though. The background size is 32x32 cells, but the screen itself only shows 20x16. So, you don't need to replace all 32x32 cells for full-motion video (FMV), you only need to replace 20x16.
Anyway, here's some info that might be what you're getting at:
Because of the way LowRes NX stores background cell information (alternating between character number and attribute data), you can either copy a continuous 639 bytes, or you can write a loop to copy only 320. Either approach is fast enough to sit inside the VBL interrupt. (For continuous, use COPY, for individual looping, use POKE.)
However, the ROM limit of 32 kB is actually the limiting factor for FMV. Even "slow" video every-other-VBL (at 30 FPS) would cost 18.75 kB (640*30) per second of video for the continuous option. To reduce the ROM footprint, you'll have to loop-through, costing 9.4 kB per second. You could use a C64 deflate algorithm, but then even the best case scenario might be a few more seconds of FMV, and at that point you'd need to consider the CC cost of each frame being decompressed inside the VBL interrupt (limited to 1140 CC).
Alice 2020-11-22 07:19 (Edited)
Very good to know about the 20x16...I should have noticed that since my Tiny Timo Text calls for a continue at the bottom of the screen (before it was tiny).
As for the character addressing...the character number is the decimal equivalent of the base 4 value of the 4 pixels on the characters. So.. a character with all black is 0000=0 DEC. A the colors are 0=black/invisible, 1=shade 1, 2= shade 2, 3=shade three. So a character with 4 pixels 3001 (top left shade 3, top right invisible, bottom left invisible, bottom right white) is the character number 193 (from base-4 3001 = 64x3+0x16+0x4+1). That also ensures that all the characters are included. Also makes it super easy when encoded in 4 color (3 color) bit maps.
Because 255 characters are used which leaves no room for text, the next step will be to identify what characters can be eliminated by finding equivalent characters when you flip/rotate (two flips). For example character 1122 is equivalent to a flipped 2211, 1212 is equivalent to a flipped 2121...etc. Other equivalents with two flips for a rotate. The idea is still to just use the characters.
That will free up space for Text characters and hopefully some extra ones for game sprites. So you will be able to have a fully animated layer based on frames plus some moving sprites.
Again...no POKE...
Might do that part...but I was actually working on something else and this is really getting to be a long Segway.