Jump to content

Search the Community

Showing results for tags 'pletter'.



More search options

  • Search By Tags

    Type tags separated by commas.
  • Search By Author

Content Type


Forums

  • Atari Systems
    • Atari 2600
    • Atari 5200
    • Atari 7800
    • Atari Lynx
    • Atari Jaguar
    • Dedicated Systems
    • Atari 8-Bit Computers
    • Atari ST/TT/Falcon Computers
  • Gaming General
    • Classic Gaming General
    • Classic Computing
    • Modern Gaming
    • Prototypes
    • Arcade and Pinball
    • Emulation
    • Hardware
    • Gaming Publications and Websites
    • International
  • Marketplace
  • Community
  • Game Programming
  • Site
  • Classic Gaming News
  • The Club of Clubs's Discussion
  • I Hate Sauron's Topics
  • 1088 XEL/XLD Owners and Builders's Topics
  • Atari BBS Gurus's Community Chat
  • Atari BBS Gurus's BBS Callers
  • Atari BBS Gurus's BBS SysOps
  • Atari BBS Gurus's Resources
  • Atari Lynx Programmer Club's CC65
  • Atari Lynx Programmer Club's ASM
  • Atari Lynx Programmer Club's Lynx Programming
  • Atari Lynx Programmer Club's Music/Sound
  • Atari Lynx Programmer Club's Graphics
  • The Official AtariAge Shitpost Club's Shitty meme repository
  • The Official AtariAge Shitpost Club's Read this before you enter too deep
  • Arcade Gaming's Discussion
  • Tesla's Vehicles
  • Tesla's Solar
  • Tesla's PowerWall
  • Tesla's General
  • Harmony/Melody's CDFJ
  • Harmony/Melody's DPC+
  • Harmony/Melody's BUS
  • Harmony/Melody's General
  • ZeroPage Homebrew's Discussion
  • Furry Club's Chat/RP
  • PSPMinis.com's General PSP Minis Discussion and Questions
  • PSPMinis.com's Reviews
  • Atari Lynx 30th Birthday's 30th Birthday Programming Competition Games
  • 3D Printing Club's Chat
  • Drivers' Club's Members' Vehicles
  • Drivers' Club's Drives & Events
  • Drivers' Club's Wrenching
  • Drivers' Club's Found in the Wild
  • Drivers' Club's General Discussion
  • Dirtarians's General Discussion
  • Dirtarians's Members' Rigs
  • Dirtarians's Trail Runs & Reports
  • Dirtarians's Wrenching
  • The Green Herb's Discussions

Blogs

There are no results to display.

There are no results to display.

Calendars

  • AtariAge Calendar
  • The Club of Clubs's Events
  • Atari BBS Gurus's Calendar
  • ZeroPage Homebrew's Schedule

Find results in...

Find results that contain...


Date Created

  • Start

    End


Last Updated

  • Start

    End


Filter by number of...

Joined

  • Start

    End


Group


Website


Facebook


Twitter


Instagram


YouTube


eBay


GitHub


Custom Status


Location


Interests


Currently Playing


Playing Next

Found 4 results

  1. DOWNLOAD ColecoVision SlideShow Sample in 5 formats: SLIDESHOW SAMPLE.ZIP README.TXT Hello everyone, My name is NewColeco and I'm gonna tell you what I've been worked on during the last 3 years. Not everyone is aware that graphics are very difficult to add in our beloved homebrew games, especially within the standard 32K cartridge size. To make things worse, some graphics cannot be compressed at all to keep the action fluid and fast. In order to add great looking bitmap screens and tilesets into our projects, we use data compression. I've been working very hard on lossless data compression for our graphics data. My new compressed formats are named DAN1, DAN2, and DAN3; they work especially well for big graphics like charset and bitmap screens. They are, technically speaking, LZ77 variants and developed based on our graphics need. The ZIP file in the download section contains 5 files of the exact same slideshow sample, the only difference is the data compression format used in each one of them. Information about the Slideshow ROM files: in Pletter - ROM size 27730 bytes. in ZX7 - ROM size 27665 bytes. in DAN1 - ROM size 27094 bytes. in DAN1 without RLE support - ROM size 27078 bytes. in DAN3 - ROM size 26999 bytes. For this slideshow sample, saving about 700 bytes is a big deal; should be enough to add an extra picture without going over 32K. Now you know what I've been working on lately. Question? Thanks for reading!
  2. DAN2 Lossless Compression by Daniel Bienvenu aka NewColeco A variant of DAN1 Compression Format Based on LZ77 data compression, multiple offset sizes, unary code and elias gamma. The project started after Alekmaul remarks and test data during December 2016. Technical information Three (3) differences compared to DAN1: The set of 4 different sizes to encode offset values becomes { 1, 4, 8, max } where max value is set by the user. The capability to store sequences of literal bytes is removed. The END OF DATA code is 17 bits long instead of 18. The data format changed a little, making it incompatible with the original DAN1 format. The first bits is an unary code to set the maximum of bits for offset values ( 0 = 10 bits, 10 = 11 bits, 110 = 12 bits, etc.) The second byte is the first raw byte to copy as literal. The rest of the data format follows similar to DAN1 specifications, except there is no sequences of literals (RLE) and also the END code is shorter by 1 bit. Comparing DAN1 and DAN2 In term of speed, the compression and decompression are virtually the same speed as DAN1. In term of size, the decompression routine is slightly bigger than DAN1, +7 bytes according to my z80 data compression library. The expected improvement in compression ratio is only due to the possibility to adjust the maximum number of bits to encode offsets. Test samples from Exomizer test1.bin (audio wave file) Original: 202762 ZX7: 223933 DAN1: 204208 (sequences of raw bytes help to not blow up in size) DAN2 -m 16: 216898 Pletter: 221245 MegaLZ: 221136 Aplib aka APPACK: 219793 PUCrunch: N/A test2.bin (text file filled only with the letter q) Original: 196608 ZX7: 19 DAN1: 18 DAN2 -f -m 10: 18 Pletter: N/A *error during compression* MegaLZ: 2510 Aplib aka APPACK: 19 PUCrunch: N/A test3.bin (formatted text file with fields such as name and date) Original: 111261 ZX7: 52035 DAN1: 48103 DAN2 -m 16: 37048 Pletter: 44563 MegaLZ: 47052 Aplib aka APPACK: 37094 PUCrunch: N/A Test samples from Alekmaul Robee Blaster Title (Pattern, Color, and Name version) Original: 2024, 2024 and 768. Total 4816 ZX7: 970, 790 and 383. Total 2143 DAN1: 965, 793 and 385. Total 2143 DAN2 m -10: 947, 784 and 385. Total 2116 Pletter: 957, 787 and 385. Total 2129 MegaLZ: 972, 806 and 384. Total 2162 Aplib aka APPACK: 986, 806 and 384. Total 2176 PUCrunch -d -c0 -s: 940, 772 and 373. Total 2085 Robee Blaster Title (Pattern and Color only version) Original: 6144 and 6144. Total 12288 ZX7: 1257 and 793. Total 2049 DAN1: 1248 and 799. Total 2047 DAN2 -m 11: 1233 and 791. Total 2024 Pletter: 1259 and 795. Total 2054 MegaLZ: 1269 and 832. Total 2101 Aplib ka APPACK: 1273 and 825. Total 2098 PUCrunch -d -c0 -s: 1235 and 770. Total 2005 Test Sample Bitmap Graphic II Download DAN2 (EXE, SRC, ASM) version BETA-20170106 : dan2-beta-20170106.zip Change Log for version BETA-20170106: increased up to 16 bits max offset size value fixed bug with default max bits fixed bug occurring with test2.bin sample DAN2 (EXE, SRC, ASM) version BETA-20170101 : dan2-beta-20170101.zip * BUG FOUND , PLEASE DOWNLOAD NEWER VERSION *
  3. From my presentation about my recent work on Coleco graphics tools; Coleco ADAM users annual convention ADAMCon 29, July 20-23, 2017, in Guelph, Ontario. The following text is about data compression obtained by using popular LZ variants for 8-bit systems, including my own named Dan, applied on several bitmap pictures for 8-bit systems. These pictures include formats Coleco .PC, MSX .SC2, and ZX Spectrum .SCR. The pictures are limited to PATTERN and COLOR tables only (no sprites allowed). Table showing results with MIN, MAX, and AVERAGE for each cathebory. Please note : Exomizer needs extra RAM prior to decompress data, and RLE (Run Length Encoding) is not a LZ variant. 3822.74 <- Exomizer 3930.13 <- Dan3 3931.65 <- Dan4 3939.92 <- Dan1 3940.85 <- Dan2 3944.20 <- PuCrunch 4044.70 <- MegaLZ 4059.60 <- Pletter , BitBuster 4063.13 <- ZX7 4077.10 <- ApLib aka APack 5899.67 <- RLE Table 1 - Average compression in bytes obtained on 95 Graphic Mode 2 bitmap pictures of 12K bytes each. 4797.03 <- Exomizer 4928.53 <- Dan4 4930.37 <- PuCrunch 4940.84 <- Dan3 4958.74 <- MegaLZ 4961.80 <- Pletter , BitBuster 4963.39 <- ZX7 4986.14 <- ApLib aka APack 4992.42 <- Dan2 4996.06 <- Dan1 6059.89 <- RLE Table 2 - Average compression in bytes on 1115 ZX Spectrum .SCR complex pixel art of 6912 bytes each. 2714.56 <- Exomizer 2828.22 <- Dan3 2832.77 <- Dan4 2863.85 <- Pletter , BitBuster 2865.63 <- MegaLZ 2866.14 <- PuCrunch 2867.64 <- ApLib aka APack 2867.65 <- ZX7 2875.06 <- Dan2 2890.77 <- Dan1 4264.42 <- RLE Table 3 - Average compression in bytes on 615 ZX Spectrum .SCR simple pixel art of 6912 bytes each. DAN3 and DAN4 data compression DAN3 is a lossless data compression based on the idea to compress relevant data with some patterns more than optimizing patches of emptiness, using the best ideas of LZ77-LZSS variants DAN1 and DAN2 data compression, but changed how doublets ( size and relative index values ) are encoded; using Golomb Gamma instead of Elias Gamma, limited the size of sequences, and simplified the binary tree to decode offset values. DAN4 is an attempt to improve DAN3. First, the modified k=1 Exp-Golomg values reads bytes instead of bits for large values which improves the decompression speed. Second, the two (2) supported modes, one optimized for simple data and one for complex data such as detailed pixel-arts and heavily dithered graphics. Of course, DAN3 and DAN4 are not miracle solutions. Because of its nature, DAN3 struggle to do better compression ratio results for pictures with lots of spaces like the following one. And sometimes, DAN1 is better than DAN3 for bitmap with dithering like the following one by 66 bytes. So how to decide which data compression to use for our projects? Trial and error? Perhaps, or simply use the data compression tools you are most comfortable with. Samples with their data compression results: NewColeco Presents ROM File Edition 837 < Exomizer 845 < Dan2 845 < Dan1 858 < Dan4 863 < PuCrunch 895 < ZX7 895 < ApLib 898 < Pletter 908 < Dan3 969 < MegaLZ 1478 < RLE Smurf Challenge 1140 < Exomizer 1162 < Dan2 1164 < Dan1 1170 < PuCrunch 1185 < Dan4 1188 < Dan3 1229 < ApLib 1233 < Pletter 1237 < ZX7 1245 < MegaLZ 1705 < RLE Bejeweled Title Screen 1306 < Exomizer 1358 < Dan2 1359 < Dan1 1372 < Dan4 1376 < Dan3 1380 < PuCrunch 1424 < ApLib 1427 < Pletter 1427 < ZX7 1463 < MegaLZ 2711 < RLE Robee Blaster 1937 < Exomizer 2005 < PuCrunch 2016 < Dan3 2023 < Dan4 2024 < Dan2 2047 < Dan1 2050 < ZX7 2054 < Pletter 2098 < ApLib 2101 < MegaLZ 8752 < RLE Maze Maniac 2433 < Exomizer 2504 < PuCrunch 2522 < Dan3 2551 < Dan4 2554 < Dan2 2570 < Dan1 2620 < Pletter 2621 < ZX7 2650 < MegaLZ 2671 < ApLib 4609 < RLE Anniversary Cake Demo 2947 < Exomizer 2993 < PuCrunch 3020 < Dan2 3025 < Dan3 3028 < Dan1 3058 < Dan4 3108 < ApLib 3123 < MegaLZ 3126 < ZX7 3130 < Pletter 4048 < RLE F1SPP 3913 < Exomizer 4013 < Dan3 4028 < Dan2 4033 < Dan4 4045 < Dan1 4096 < PuCrunch 4107 < MegaLZ 4170 < Pletter 4170 < ZX7 4208 < ApLib 6770 < RLE Lena aka Lenna (used a lot in papers about imaging) 8595 < Exomizer 8812 < Dan4 8840 < Dan3 8873 < Dan1 8897 < Dan2 8925 < PuCrunch 8962 < MegaLZ 9084 < ZX7 9085 < Pletter 9141 < ApLib 11958 < RLE UPDATES : November 17, 2017. Added informations about DAN4 results developped during October-November 2017.
  4. It's not the first time we talk about data compression, particulary for graphics and because. For graphics, we want a way to decompress data directly into VRAM using near to zero extra RAM space. The common ways to compress data are Run Length Encoding, Huffman and Dictionary. Run Length Encoding (RLE) is the fastest one to encode and decode and can give a decent compression ratio. Huffman is basicaly an optimization by encoding with a small number of bits what occurs the most. Its decompression time is usually a bit longer than for other compression methods. Not a big deal normaly since it's during the initialiation of the graphics for a title screen or a grame screen. Dictionary compression is normaly the best one, but its main problem is usualy the need for extra memory space to create the dictionary while decompressing data which isn't the way to go for ColecoVision games because of the limited RAM space. I created my own data compression long ago which is basicaly an improved encoded RLE compression by using a fixed huffman to encode data. I called it DAN0 and I'm quite proud of myself for saving even more ROM space than with the RLE method I was using for years. Then I was curious to see the other data compressions and I saw that there are many many of them, some can decompress data directly into VRAM, and some of them are just simply better than the others. To help comparing the different data compressions out there, I decided to use a bitmap screen 256x192 with just enough complexity in it to see a difference in size for the different results of compression. LET'S COMPARE SOME OF THE DATA COMPRESSION WE MIGHT USE FOR TITLE SCREENS From my ColecoVision Strip Poker game project : strippokertitlescreen.zip RAW (no compression) : 12288 bytes RLE : 4528 DAN0 : 4143 Pucrunch : 4000 BitBuster or BitBuster Extreme : 3595 PLETTER : 3557 aPLib : 3543 MegaLZ : 3524 Exomizer v2 : 3337 Please note that the size of the program to decompress the data isn't included. Because the end result depends mostly on the original data, we can't say that Exomizer is the best, sometimes aPLib is better than Exomizer, it varies. But a few things are constant like DAN0 is always better than RLE, and Pletter is always better than BitBuster. Side note : SMS homebrew scene is very interesting for ColecoVision homebrewers because it imply Z80 assembly and the port number for VRAM is the same. Which makes links like this one from Maxim quite interesting. Feel free to comment, ask questions, and do your own tests with other data compression programs
×
×
  • Create New...