ferris information 3285 glöps
- general:
- level: user
- personal:
- first name: Jake
- last name: Taylor
- portals:
- csdb: profile
- slengpung: pictures
- demozoo: profile
- cdcs:
- cdc #1: aether by mfx [web]
- cdc #2: Tsunami by Booze Design
- cdc #3: Aesterozoa by Kewlers [web]
- cdc #4: regus ademordna by Excess [web]
- cdc #5: Waillee by Prismbeings
- cdc #6: ▶ by Ümlaüt Design [web]
- 4k Windows Rekursive Rubik's by yugecin
- anatomically correct!
- rulezadded on the 2022-10-25 18:42:14
- 64k Atari ST Monotheist by SMFX
- missed this before now; excellent stuff!
- rulezadded on the 2022-10-25 08:59:13
- demotool Linux Windows UPKR
- anyways, just dicking around here, again, nice work :D
- isokadded on the 2022-10-24 21:17:26
- 1k invitation Amiga OCS/ECS Be a star by Loonies [web] & Fnuque [web]
- turned out nice!
- rulezadded on the 2022-10-24 21:14:00
- demotool Linux Windows UPKR
- And I can get another couple bytes by biasing the initial predictions (3468 with my update rule, 3469 with yours), so might be worth adding an option for that.
- isokadded on the 2022-10-24 20:59:03
- demotool Linux Windows UPKR
- Ah, actually, I did the initial test wrong - with my update rule in UPKR (rather than both using your bias and my output trick) compression is slightly better at 3470 bytes, but I'd guess the additional decompressor code for the more complicated update rule would make the result overall larger for a net loss.
- isokadded on the 2022-10-24 20:41:12
- demotool Linux Windows UPKR
- just hacked a quick test (yay open source!), and indeed the update rule used here (the simple bias) appears to work better without my trick, which is quite cool :)
- isokadded on the 2022-10-24 20:24:48
- demotool Linux Windows UPKR
- ah, now I see, the probabilities are biased before the shift, which would indeed make the update more accurate. Still, I wonder if the top/bottom of the probability ranges are being used effectively with this, something to play with :) .
- isokadded on the 2022-10-24 20:10:59
- demotool Linux Windows UPKR
- Just ran a quick test with Makeshift against the previous best packer/configuration (the packer which I talked about in the blog post linked in the UPKR readme), and just comparing compressed sizes, the previous best was 3523 bytes, and upkr with -9 achieves 3473 bytes. Of course a proper comparison would also have to account for added decoder complexity and I may spend some time looking into that, but at this point I'd be willing to bet that UPKR still comes out on top. Nicely done, this kicks ass :) .
One thing I'm a little surprised about is the probability update used. In my earlier post about rABS on 6502 (the "Modeling" section), I explain a (rather simple) trick to make 8-bit probabilities much more effective, and in my tests that had a quite meaningful effect on compression, so I'm a bit surprised to see that that's not also being used here. Perhaps further savings are possible, or is this perhaps something you tried and dropped when using more sophisticated modeling? - isokadded on the 2022-10-24 20:02:50
- 4k Amiga AGA Riversnake by Fnuque [web]
- quiter nicer!
- rulezadded on the 2022-10-24 09:41:04
account created on the 2005-11-23 21:48:43
