SpritesMind.Net

flamewing wrote: Fri Sep 01, 2017 3:34 pmYeah, it can definitely achieve perfect compression with my generic LZSS backend; this format is a LZ variant.

Nope, Trouble is last_offset & LWM.

And so on. Like I had said before, a generic tile splitter is not useful if you can't specify what you are after; each game is a game, and has different priorities.
It's too bad... We gonna die.

Btw, one more case: if tiles compressed, and uncompressed size calculated by sprite size (3x4 for ...

Can you give more details on this format? It sounds like the kind of thing that could be brought to perfect compression level using my generic LZSS backend.


Pseudocode (mix of python, c++, and pascal :lol: ):
copy first byte.
last_offset := uninitialized // some trash that is happened to be in ...

http://elektropage.ru/r57shell/aplib_pack.exe

Ahh... Here is aPLib binary for packing and unpacking files without header:
http://elektropage.ru/r57shell/appack_raw.exe

Sorry for bump of old post. But introspec from zx scene sent me some files that my packer fails to beat standard one.
So I ...

BigEvilCorporation wrote: Thu Aug 31, 2017 10:22 amI'm lazy and don't want to read the whole thread - which algo won?

We need arrangement of competition first.

For hangs it shows barcode at bottom right corner
with columns colors equal to hex digits of opcode starting from highest.

Anyone up to making testing of algorithm tool? If none, then I'm off.

Source: https://github.com/realmonster/smd_emu_tests
Compiled: http://www.mediafire.com/file/03oy89xl4ruxkf3/m68k_opcode_sizes.bin
:D
Pass: Hardware, gens-gx(musashi), mess(musashi), Exodus.
Hangs: BlastEm, PicoDrive
Fails: Gens, GensGS, Regen, Fusion, Mednafen.

Surprisingly, it shows, that ...

So ... my question is, is this correct behavior? If a game starts a VDP DMA fill operation, it's supposed to block until the fill byte is written to the data port.
In case if I get question right: it will not block M68k, and it will not block M68k during fill.
There is no reason for blocking.
M68k ...

Sik wrote: Wed Aug 23, 2017 6:27 pmTry this one, then abandon all hope (I know why I'm saying this...)

You should have some benchmark and test cases first, and then decide, is algorithm bad, or not.
I don't have good one tool for this purpose atm.

Just in case if you need some tests.
http://gendev.spritesmind.net/forum/viewtopic.php?f=8&t=1585#p21261
Here is ROM which has few tests of shadow highlight.
One is where it asks for "full rect is same color"
and other ...
Anyway, just play with it.

Maybe this is how kabuto inspired his vertical ...

I have idea of algorithm that requires 800 MB of RAM usage, and solves this task at pixel precision for image size 128x128,
but it would not return "obvious" for us solution in following corner case:
http://i.imgur.com/dH3mMdn.png
Edit: Oh sh... It takes not 800MB but much more.
Ok, it requires ...

Sik wrote: Mon Aug 21, 2017 12:58 amThen explain it instead of leaving people trying to figure out what it's doing.

Nope. At least I'm not lying.

Don't drop shadow on my algo.
It indeed bruteforce shift, and count empty tiles.
But it's end of similarity.

I didn't go into code-like pseudo-code because the exact approach depends a lot on how you're handling data internally (e.g. how bitmap data is stored in RAM, how you're storing the mappings, what kind of container are you using in your given language, etc.). But the steps are pretty much that. By ...