Ericisonit 2023-08-24 08:10
Truncated to fit the 128KB max upload size, but you can have way more than just a couple dozen frames of video 🧠🫦
G-9 2023-08-24 13:14
very impressive
Timo 2023-08-24 13:49
This should be the new default format for web videos!
Timo 2023-08-24 13:53 (Edited)
This might interest you: https://tic80.com/play?cart=419
Even though it's the competition ;)
Pablo 2023-08-24 15:07
Neat!
McPepic 2023-08-24 16:00
This is so cool! Now if only we could convert wav files to play in NX. I was working on one before, but couldn’t get the samples playing correctly. I was thinking of either converting the frequencies to notes and playing those or using the frequency registers directly, but I couldn’t figure out how to play a sound directly by modifying the frequency registers.
SP4CEBAR 2023-08-24 18:47 (Edited)
@McPepic you could use the approach from my mp3 player attempt, for wav files that would be:
This should be the closest we can get to playing audio, I have no clue what it would sound like.
Ericisonit 2023-08-25 00:16
Working on a way to get more colors per frame, the algorithm to optimize per-raster palette sets has given me the biggest headache trying to figure out, but I’m close…
Ericisonit 2023-08-25 00:17
Oh and also gonna use Huffman trees and RLE’s to encode things and make them much more compact.
nathanielbabiak 2023-08-25 03:43 (Edited)
Stick to RLE's. The overhead for Huffman trees on datasets of this size make it unattractive. My posts under this upload might help you out.
SP4CEBAR 2023-08-25 07:29
What video format does it use? Is it a bitmap video?
Ericisonit 2023-08-25 08:17
I just made a program that opens the webcam and captures bitmap frames from it, resizes to the 80x64 dimensions, quantizes the pixels to the 64-color lowresnx palette, and since i'm using the technique from my QHD-or-whatever-i-called-it program - (where the raster callback shifts each row up halfway to fit the top-half of all 32 bg rows on the screen and uses both bg layers to cram 40 columns kinda the same way, only 1/4 of each tile is used, so you can have 4 double-sized pixels per tile, @2bpp and fit every possible combination of 4 4-color pixels within the 256 character part of video ram, so the character index of the tile is a bit-mask of the 4 pixels IN the tile, and each cluster of 4 can have its own palette, making it seem higher color resolution) - i just had it use a standard rainbow-ish type palette set and pick the best palette for each 2x2 cluster of pixels, then it's just a matter of streaming bytes to the $9000-$9FFF region of ram (char. index + palette index)... 4KB (8192 characters) for a full uncompressed frame, and then instead of storing each frame individually, i only had it calculate the differences between them, and the compressed frame data is just 4 bytes for each 2x2 cluster that is different (the character index byte and attribute/palette byte, preceeded by the 2-byte address at which to copy them, e.g. 9008FF06 puts char index 255 with palette 6 at tile {4,0} on BG 0)
luckily the fps kinda naturally just matched hehe
also, i wonder if because it's mostly the compressed frame data with very few repeating bytes... would RLE even do much good? of course, i could lay the bytes out differently to where it would be more compressible that way... hmmm, so many ways to crack an egg :-/
McPepic 2023-08-25 14:19
@Ericisonit
In case you haven’t seen it,
https://www.youtube.com/watch?v=aF1Yw_wu2cM
might give you some ideas for compression.
McPepic 2023-08-25 15:23 (Edited)
Also, I noticed that you’re using a lookup table to convert the hex string to a value. Is there a reason that you’re not doing:
VAL(“0X” + MID$(SZ$, I, 2))
?
Ericisonit 2023-08-29 08:03
@McPepic
I wish VAL worked that way, but it doesn't convert hex strings, it just uses atof under the hood.
McPepic 2023-08-29 14:06 (Edited)
@Ericisonit
I tried it on the program and it works. It actually just uses an Objective-C function. When you append “0x” to the string, it treats it as a hexadecimal value.
Check out the source code below:
Timo 2023-08-29 14:54 (Edited)
The core of LowRes NX is pure C and it uses "atoi" for the VAL function. Interestingly the standard "atoi" C function supports hex strings. (I didn't know when I made this, so it's a non-official feature, but I won't remove it.)
nathanielbabiak 2023-08-30 02:40
I'd seriously prefer using VAL( "0X" + ... ), but the datasets in this upload (and bad apple too) are actually little endian... except they're little *down to the nibble* (not even the byte!), so it's much slower than using an ATOH array. If the data was re-arranged so that it was big endian (or even little endian without being down to the nibble) it'd be much faster.
Ericisonit 2023-09-08 04:55
it's the whole having to use strings for the ginormous amounts of data beyond what a rom file can handle versus the string functions of the language and having to use a MID$(sz$,..,1) for each character since ASC only works with the first character (or use VAL on the concatenated "0X"+MID$(sz$,..,2)) - it's a give and take, if only we could use char pointers to walk the lengths of these strings ;)
nathanielbabiak 2023-09-08 15:30
Eh, I'm not convinced. VAL works 6 digits at a time, up to 24 bits, it just requires the string to be aligned and big-endian. It's much faster...
BlockHead 2023-09-21 18:54
I need to see the entirety of Shrek in this.
