42bs Posted September 15, 2020 Author Share Posted September 15, 2020 Just now, karri said: yep. I am getting a bit interested in doing a brute force packer as no logic seems to work. Why, oh why are we so stupid? I think your(?) approach with looking only at a small window might be a way. Having a sliding window of 32 pixels. 1 Quote Link to comment Share on other sites More sharing options...
Songbird Posted September 15, 2020 Share Posted September 15, 2020 Thanks for the quick look at this, @42bs! 1166 is pretty close to 1151 and much improved from my first try. I did not realize the -e option could be used to define the "edge" color, which in this case was index 0 defined to be black. There was already a background sprite clearing the screen to black, so the bootscreen sprite did not need to set every pixel in the rectangle; just the non-black ones. Quote Link to comment Share on other sites More sharing options...
+karri Posted September 15, 2020 Share Posted September 15, 2020 I am just running SuperSqueek with the brute force algo. Simple lines have just around 80000 variations that I need to evaluate. But the complex lines take ages... The worst line is 5^15 variations. Just generating the test vectors takes minutes... I really have to cut down the problem with some kind of logic. 1 Quote Link to comment Share on other sites More sharing options...
42bs Posted September 15, 2020 Author Share Posted September 15, 2020 (edited) Also made a small tool which dumps a sprite to compare sprpck vs. Amiga packer. Here some interesting finding: L<n>(color(s)) or P<n>(color) (Where n = count-1). Amiga: 18:L5(011100) PF(0) P2(1) sprpck: 19:L3(0111) PF(0) P1(0) P2(1) #include <stdio.h> #include <stdlib.h> unsigned char curByte; unsigned int bitcount; int readBits(FILE *in, int bits, int *len) { int ret; if ( bitcount == 0 ){ if ( feof(in) != 0 ){ return -1; } fread(&curByte, 1, 1, in); //-> printf("[%02x]",curByte); --(*len); bitcount = 8; } ret = 0; if ( bits > bitcount ){ ret = curByte >> (8-bitcount); ret <<= bits-bitcount; if ( feof(in) != 0 ){ return -1; } bits-= bitcount; fread(&curByte, 1, 1, in); //-> printf("{%02x}",curByte); bitcount = 8; --(*len); } ret |= curByte >> (8-bits); curByte <<= bits; bitcount -= bits; //-> if ( bitcount == 0 ) printf("+"); return ret; } int main(int argc, char **argv) { FILE *in; char inb; int bps; int nxt; int p; int cnt; int col; if ( (in = fopen(argv[1],"rb")) == NULL ) { printf("Couldn't open %s !\n",argv[1]); return -1; } if ( argc == 3 ){ bps = *argv[2]-'0'; if ( bps < 1 || bps > 4 ){ printf("BPS must be 1,2,3 or 4\n"); return -1; } printf("BPS: %d\n",bps); } else { bps = 4; } curByte = 0; int dummy; while( 1 ){ bitcount = 0; nxt = readBits(in,8,&dummy); if ( nxt < 0 ) break; printf("%2X:",nxt); for( --nxt; nxt > 0; ){ p = readBits(in, 1, &nxt); if ( p < 0 ) break; if ( p == 0 ) { printf("P"); cnt = readBits(in, 4, &nxt); if ( cnt < 0 ) break; printf("%X", cnt); col = readBits(in, bps, &nxt); if ( col < 0 ) break; printf("(%X) ", col); } else { printf("L"); cnt = readBits(in, 4, &nxt); if ( cnt < 0 ) break; printf("%X(",cnt); for( col = 1; cnt >= 0 && col >= 0; --cnt){ col = readBits(in, bps, &nxt); if ( col >= 0 ) { printf("%X",col); } } printf(") "); if ( col < 0 ) goto leave; } } printf("\n"); } leave: fclose(in); printf("\n"); return 0; } Edited September 15, 2020 by 42bs Quote Link to comment Share on other sites More sharing options...
+karri Posted September 15, 2020 Share Posted September 15, 2020 Thanks. I realized that the amount of data you need to analyse is on both sides of a literal packet. If either side has a runlength packet you need to analyse up to a certain number of bits that you should turn to literals. The number depends on the bpp like: def better_as_literal(self): self.longest = 0 for i in range(1, 16): if i * self.bpp < 1 + 4 + self.bpp: self.longest = i So for 1 bpp you may need to check for +- 5 pixels while for 4 bpp it is enough with +- 2 pixels. Here is the first line of SuperSqueek. Zero means runlen while one is literal [[0, 16], [0, 16], [0, 16], [0, 16], [0, 16], [0, 7], [0, 3], [0, 7], [0, 2], [1, 1], [0, 4], [0, 16], [0, 16], [0, 6], [0, 2], [0, 7], [0, 2], [0, 7]] With a little logic the only place where variation makes sense is in the middle. Here I vary the spot from -2..2. Here is the interesting part from -2, -1, 0, 1, 2 (0, 7), (0, 0), (1, 3), (0, 4), (0, 16), (0, 7), (0, 1), (1, 2), (0, 4), (0, 16), (0, 7), (0, 2), (1, 1), (0, 4), (0, 16), (0, 7), (0, 2), (1, 2), (0, 3), (0, 16), (0, 7), (0, 2), (1, 3), (0, 2), (0, 16), Of course I also need to clean up the vector Quote Link to comment Share on other sites More sharing options...
42bs Posted September 15, 2020 Author Share Posted September 15, 2020 9 minutes ago, karri said: So for 1 bpp you may need to check for +- 5 pixels while for 4 bpp it is enough with +- 2 pixels. In sprpck I do this, but only to the right. I have this "int plimit[4] = { 6,5,4,3 };", means a packed chunk of this number of elements is not worth to further investigate. But sprpck cannot "see" beyond a full packet. Maybe I should "split" up into 16 pixel chunks as last step.... (this is so mind-bogling, writing a 249byte rotozoomer is a piece of cake compared to this). Quote Link to comment Share on other sites More sharing options...
+karri Posted September 15, 2020 Share Posted September 15, 2020 53 minutes ago, 42bs said: In sprpck I do this, but only to the right. I have this "int plimit[4] = { 6,5,4,3 };", means a packed chunk of this number of elements is not worth to further investigate. But sprpck cannot "see" beyond a full packet. Maybe I should "split" up into 16 pixel chunks as last step.... (this is so mind-bogling, writing a 249byte rotozoomer is a piece of cake compared to this). I was planning to do it the other way. Start with up to 512 pixel chunks and process only the pixels outside "chunk % 16" both to right and left. My latest version is pretty fast already. But it is still just an algorithm study. Quote Link to comment Share on other sites More sharing options...
42bs Posted September 16, 2020 Author Share Posted September 16, 2020 New update pushed. Now Carl's picture compresses down to 1156 (5 bytes left from Amiga tools). Fixed the bug found in the "Astroid Chasers" credit screen. Removed "logic" compression. Now it only uses a sliding window of 32 pixels to find the best compression. Still it packs differently in most parts then the Amiga tool. 1 Quote Link to comment Share on other sites More sharing options...
LX.NET Posted January 4, 2021 Share Posted January 4, 2021 What is the story on the 64bit support? I have been building a toolchain in Docker images, so it becomes very easy to run a dev environment from Visual Studio Code. The Docker image uses a 64-bit version of alpine. To build the image, it gets all the latest sources of CC65 and sprpck and builds it using make. First issue is the sizes in the header definition for 64-bit. #define WORD unsigned short #define DWORD unsigned long #define LONG long There seem to be some glitches in the generation of the .spr files $(SPRPCK) -t6 -p2 -r001005 -S021007 -a000000 panels.bmp With an older version of sprpck (Windows 1.98) the errors do not occur. Any takers? If anyone is interested in this new dev environment, please let me know and I can follow up panels.bmp Quote Link to comment Share on other sites More sharing options...
42bs Posted January 4, 2021 Author Share Posted January 4, 2021 (edited) 19 minutes ago, LX.NET said: First issue is the sizes in the header definition for 64-bit. #define WORD unsigned short #define DWORD unsigned long #define LONG long What is the problem with this? AFAIK even for x64 VS uses "long" == 32bit. But I agree, it would be better to use stdint.h definitions instead. Thanks for the BMP, I'll have a look (but it is different from what you show in the post). Edited January 4, 2021 by 42bs Quote Link to comment Share on other sites More sharing options...
42bs Posted January 4, 2021 Author Share Posted January 4, 2021 Ok, I see the problem. I'll dig into it. For the time being you may use "-u" (unpacked). 1 Quote Link to comment Share on other sites More sharing options...
LX.NET Posted January 4, 2021 Share Posted January 4, 2021 54 minutes ago, 42bs said: What is the problem with this? AFAIK even for x64 VS uses "long" == 32bit. But I agree, it would be better to use stdint.h definitions instead. Thanks for the BMP, I'll have a look (but it is different from what you show in the post). It would be great if we have source code that would compile cleanly on 32-bit and 64-bit. In Visual Studio Code (not Visual Studio 2017 or 2019) the Dev Container runs a Linux distro of your choosing. Most likely 64-bit from here on in. Quote Link to comment Share on other sites More sharing options...
LX.NET Posted January 4, 2021 Share Posted January 4, 2021 1 hour ago, 42bs said: Ok, I see the problem. I'll dig into it. For the time being you may use "-u" (unpacked). That works. Thanks for the workaround for now. Quote Link to comment Share on other sites More sharing options...
42bs Posted January 5, 2021 Author Share Posted January 5, 2021 I wonder: Why don't you use -s1 ? It saves a lot of space. Quote Link to comment Share on other sites More sharing options...
42bs Posted January 5, 2021 Author Share Posted January 5, 2021 Fixes pushed. Quote Link to comment Share on other sites More sharing options...
Cyprian Posted January 5, 2021 Share Posted January 5, 2021 19 hours ago, LX.NET said: If anyone is interested in this new dev environment, please let me know and I can follow up I'm interested. Thanks Quote Link to comment Share on other sites More sharing options...
+karri Posted January 5, 2021 Share Posted January 5, 2021 34 minutes ago, Cyprian said: I'm interested. Thanks Me too. The idea of using Visual Studio Code is pretty clever as if runs on Linux as well. Perhaps we could have an integrated emulator and symbolic debugger as well. The cc65 does already have high level C-symbols included in the assembly source. So it should be doable. Quote Link to comment Share on other sites More sharing options...
sage Posted January 5, 2021 Share Posted January 5, 2021 yepp, that is on the wish list since 1999 Quote Link to comment Share on other sites More sharing options...
42bs Posted January 5, 2021 Author Share Posted January 5, 2021 ? I am asking IAR every now and then the give away their IDE for 6502 for free for hobby projects. Still they refuse. But I never got worm with VS Code or even Docker. My IDE is spelled: e, m, a, c, s ? Quote Link to comment Share on other sites More sharing options...
LX.NET Posted January 6, 2021 Share Posted January 6, 2021 On 1/5/2021 at 7:24 AM, 42bs said: Fixes pushed. Thanks for fixing this so quickly. I can confirm that everything works perfectly. Quote Link to comment Share on other sites More sharing options...
LX.NET Posted January 6, 2021 Share Posted January 6, 2021 On 1/5/2021 at 11:32 AM, karri said: Me too. The idea of using Visual Studio Code is pretty clever as if runs on Linux as well. Perhaps we could have an integrated emulator and symbolic debugger as well. The cc65 does already have high level C-symbols included in the assembly source. So it should be doable. If you have a machine that can run Docker containers, the development experience becomes even better. I will try to post about this some time next week. Quote Link to comment Share on other sites More sharing options...
+karri Posted January 13, 2021 Share Posted January 13, 2021 On 1/6/2021 at 4:38 PM, LX.NET said: If you have a machine that can run Docker containers, the development experience becomes even better. I will try to post about this some time next week. I just decided to take a leap and give Windows a chance by ordering a modern laptop. Any hints in how to run things in Docker containers is highly appreciated. I hope to avoid dual boots. Quote Link to comment Share on other sites More sharing options...
42bs Posted January 13, 2021 Author Share Posted January 13, 2021 1 hour ago, karri said: I just decided to take a leap and give Windows a chance by ordering a modern laptop. Any hints in how to run things in Docker containers is highly appreciated. I hope to avoid dual boots. I am not using Docker, but for a long time I use VirtualBox VMs with (in my case) Xubuntu for various things where I need Linux. It even works nicely with USB, so I can run JTAG debuggers withing the VMs. Nice thing: I have a VM per customer. But I suggest to spend an extra penny for sufficient RAM (I have 32GB). Quote Link to comment Share on other sites More sharing options...
Nop90 Posted January 13, 2021 Share Posted January 13, 2021 On my pc (with Windows for company policy) I keep my coding stuff on a Ubuntu VM on VMWare, and I'm really happy with this configuration. Quote Link to comment Share on other sites More sharing options...
+karri Posted January 13, 2021 Share Posted January 13, 2021 Thanks for these ideas. I am familiar with virtualisation. The idea to keep Lynx in a separate VM might be the cleanest solution. Quote Link to comment Share on other sites More sharing options...
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.