how 2 compress fat bitmap

[fir]

i get a little big tired when coding roguelike and maybe i could rest coding a side problem

in my roguelike i use now 24bpp bitmap to store a tile map,
it is 2000x2000 pixels (as pixel is something like 'big meter'
in game world (something like 1.5 m x 1.5 m) this would be like a 3 km x 3 km square of land

you could check it packed in

minddetonator.htw.pl/platform12.zip
minddetonator.htw.pl/platform14.zip

it is 12 MB bmp file and loading it makes 1 second delay at game startup (on my hdd, on some more new hdd could be faster)

but obviously it could be packed, as i use only come sobset of colors on this map (it would be at most like few thousands of colors/tile types, now i use less than 30) so it may be
well packed (it also shopuld be simple to pack as i need
only pack raw rectangle of pixels, not other form of data,
bitmap header i may skip at all)

even compressing each pixel into index form - thus reducing 24 bit of color into loke 6-12 bit of index would spare to half or 1/4 of oryginal size.. yet more elaborate ways of compresing (exploring the fact that there are regular patterns of colors not chaotic pixels) could be used (zip packs this 12 MB to 80 kB rar packs 12 MB to 60kB)

the question is - what algorithm to use to pack it - it could be reasonably simple to write but also maybe something more effective then if i would just turn colors to palette entries?


what do you think?

[fir]

PS doeas maybe you know how to name such container (which i would need probably to use here): ->

stores some entries (which may be various, here it will be just 32 bit color values), also stores the number of occurances of each color value in a bitmap

technically it would be the array (of pair color, number_of_occurances) where key will be just array index
like in normal array - but in some abstract way i think it is begining to be some other container, more like dictionary maybe (but im not sure what would be a key here - normal array index or this color value be tha key?)

(keys will be unique and need to be inserted, if found the number of occurances increased)

[Rick C. Hodgin]

On Monday, March 27, 2017 at 11:26:50 AM UTC-4, fir wrote:
> ...i use now 24bpp bitmap to store a tile map, it is 2000x2000 pixels...
> ...is 12 MB...

If you want to keep bmp, install or use GIMP to convert it to index
palette format. 8 bits per pixel instead of 24. That will get you
down to a little over 4 MB, but will increase image load time as you
will have to restore it to 24 bpp format for use unless you're using
OpenGL which I believe has the ability to read in indexed color
format images.

If you are able to leave BMP, try using PNG. It's lossless, and
stores its data in a compressed format.

I typically use uncompressed 24-bpp or 32-bpp bitmaps for all of my
graphics work that winds up being used in software. Memory and hard
disk storage are cheap these days. It makes the algorithms easier,
and there is no delay on use after load ... which, everybody expects
a small delay for load I would think.

Thank you,
Rick C. Hodgin

[fir]

i should not answer toy you rick as youre abusing this group and destroyng the minds .. but i will ;c yet coz no much answer to talk with

i got no code to read png and i use only system winapi
dlls or my own (dont want any dependencies), code for reading png may be maybe more complex for compresing it myself to my own format

as to 8 bit bmp it is funny but there i dont know 16-bit or yet better 'variable index length' bitmap format
- and that would be needed 256 it to rigorous, 16 bit would sufice (it would be much better conformant to game mechanics as i could identify tile by array-id not by 24bit color which is not array-id but only some key (!)
(i wanted to write on this once as this is interesting imo) ) but there is no such format - it also would do not offer much compression

and tjis compresion and this delay really matters, now i use 12 MB map but in theory i would want to use larger maps and this delay here really matters (for me - who needs to write handsome games ;c )

later versions i would probably use something like a big amount of "1000x1000 pix" maps (whoch would yeld to 3MB uncompressed each - at least i vaguelly plan something like that - if so that would be quicker to read only taking hdd space after zip unpacking - but as i said i cant be sure i would not want larger, and cpu unpacking is fas - much quickier than hdd load)

[fir]

PS
i wrote simple code (sory for to long names, i got a problem of this, how to name it)

struct ColorAndCountPair {
unsigned color;
unsigned count;
} ;



const int dictionary_of_color_and_count_max = 1000*1000;

ColorAndCountPair dictionary_of_color_and_count[dictionary_of_color_and_count_max];


int dictionary_of_color_and_count_top = 0;

int FindColorEntry(unsigned color)
{
for(int i=0; i<dictionary_of_color_and_count_top; i++)
{
if( dictionary_of_color_and_count[i].color == color )
{
return i;
}
}

return -1;
}

void AddColorToColorCountDictionary(unsigned color)
{
int id = FindColorEntry(color);

if(id>=0)
{
dictionary_of_color_and_count[id].count ++;
}
else
{
dictionary_of_color_and_count[dictionary_of_color_and_count_top].color = color;
dictionary_of_color_and_count[dictionary_of_color_and_count_top].count ++;

dictionary_of_color_and_count_top++;

if(dictionary_of_color_and_count_top>=dictionary_of_color_and_count_max)
ERROR_("Overflow off dictionary_of_color_and_count_top" );
}

}

void AnalyzeLoadedBitmap()
{
double sum = 0;


for(int y=0; y<map_y; y++)
for(int x=0; x<map_x; x++)
{
AddColorToColorCountDictionary(map[y][x].color);
}

int pixels_added = 0;

for(int i=0; i<dictionary_of_color_and_count_top; i++)
{
pixels_added+=dictionary_of_color_and_count[i].count;
}

ERROR_("pixels added %d unique colors %d", pixels_added, dictionary_of_color_and_count_top );
}


it just adds colors to "dictionary" and counts them, it counted 4 000 000 pixels added and 28 unique colors, seem to work - so most basic would be to encode it in an array as a stream of 4 mln * 6 bits = 4 MB * 6/8 = 3 MB (out of initial 12 MB, better but still would like to get a bit better, maybe i should dictionarize blocks of 2, 4, 6, or
8 pixels? after a bit of resting i will try it

[fir]

i revrited it now to count/collect block of 4 pixels

const int color_block_length = 4;

struct ColorBlockCount {
unsigned color[color_block_length];
unsigned count;
} ;

const int dictionary_of_color_block_count_max = 1000*1000;

ColorBlockCount dictionary_of_color_block_count[dictionary_of_color_block_count_max];


int dictionary_of_color_block_count_top = 0;

int FindColorBlockEntry(unsigned color[color_block_length])
{
for(int i=0; i<dictionary_of_color_block_count_top; i++)
{
int eq = 1;

for(int k=0; k< color_block_length; k++)
{

if( dictionary_of_color_block_count[i].color[k] != color[k] )
{
eq = 0;

}
}

if(eq) return i;

}

return -1;
}


void AddColorBlockToColorBlockCountDictionary(unsigned color[color_block_length])
{
int id = FindColorBlockEntry(color);

if(id>=0)
{
dictionary_of_color_block_count[id].count ++;
}
else
{
for(int k=0; k<color_block_length; k++)
dictionary_of_color_block_count[dictionary_of_color_block_count_top].color[k] = color[k];

dictionary_of_color_block_count[dictionary_of_color_block_count_top].count ++;

dictionary_of_color_block_count_top++;

if(dictionary_of_color_block_count_top>=dictionary_of_color_block_count_max)
ERROR_("Overflow in dictionary_of_color_block_count" );
}

}

void AnalyzeLoadedBitmap2()

{
double sum = 0;


for(int y=0; y<map_y; y++)

for(int x=0; x<map_x; x+=color_block_length)
{
static unsigned color[color_block_length];

for(int k=0; k<color_block_length; k++)
color[k] = map[y][x+k].color;

AddColorBlockToColorBlockCountDictionary(color);
}

int pixels_added = 0;

for(int i=0; i<dictionary_of_color_block_count_top; i++)
{
pixels_added+=dictionary_of_color_block_count[i].count*4;
}

ERROR_("pixels added %d unique blocks of colors %d", pixels_added, dictionary_of_color_block_count_top );
}

should maybe yet revrite it to count twodimensional blocks

when i run it it yeilded to 12 011 unique blocks of 4-pixels (im not sure though if it was done correct (to check that i would need to fully build compressed data and decompress it and im to wearylazy to it as this moment)

assuming this is good letss see what compression would it mean:

12 011 means 14 bit index key for each 4 pixels
it means 1 mln * 14 bits = (lets take 16 bits) 1 mln * 16 bits = 2 MB

better (than 3 MB of per-pixel-indexing) but not critically better (yet i forget i must add 'palette size
which would be 12k * 12 bytes = 144KB)

maybe i will try yet with 2 byte block and 8 byte blocks

[fir]

2-pixel block yeilded to 333 entries = 9 bit * 2M = a bit over 2 MB of storage,
8-pixel i cannot check (seems yeilds to hang) as 2000 do not divides by 8, will try 10-pix
...10 pix also seem to hang, i must look whats the reason ;c

[fir]

5-pixel indexing gives 32 106 entries it is 15 bit x 4/5 M = a bit less than 2 MB of storage,
seems that 2 MB is some kind of natural limit of indexing method here.. well maybe i will need to try longer pixel-blocks though, hope it will not overflow the palette

[fir]

10-pix indexing yeilded to 108 463 entries.. it showed it was not hang error, it just processes so damn long (dont know about 30 seconds maybe, dont know why is that.. well the palette seems longer and inserting in it grows probably in square)

108 463 entries means 17 bits of 4M/10 = 1 MB, now that is a progress (though yet palette must be added and this is 108k * 30 bytes = 3 MB of palette, now that is disaster...
palette could be compressed too i think.. but i dont go into it.. so it seems 2 MB is a limit.. maybe i should find another method.. those RLE runtime length encoding i heard something of..

[fir]

ps note thet those all tests mentioned are for this ugly bitmap

minddetonator.htw.pl/avanor.zip

not for those contenied in those previous links, this one
i not checked is not so well compressed by zip and rar
(they give 825k and 765k) so if my 4-pixel indexing gives 2 MB it seems not so bad (still it is 1/6 , though still worse than 1/15 or ziprar :C

this pozition stands me before not obvious decision if
use it, not use it, or try to use zip/png

could yet try the RLE if is enough easy

[bitrex]

On 03/27/2017 11:26 AM, fir wrote:

> it is 12 MB bmp file and loading it makes 1 second delay at game startup (on my hdd, on some more new hdd could be faster)

Why are you concerned about a 1 second delay in loading what I assume is
an x86 PC game? Have you played any recent games for the platform?

If that 1 second is the bulk of the load time (and it must be since
you're focusing on it so intently) then it's probably already the
fastest loading PC game ever made.

[Rick C. Hodgin]

On Monday, March 27, 2017 at 1:02:11 PM UTC-4, fir wrote:
> W dniu poniedziałek, 27 marca 2017 18:44:18 UTC+2 użytkownik Rick C. Hodgin napisał:
> > On Monday, March 27, 2017 at 11:26:50 AM UTC-4, fir wrote:
> > > ...i use now 24bpp bitmap to store a tile map, it is 2000x2000 pixels...
> > > ...is 12 MB...
> >
> > If you want to keep bmp, install or use GIMP to convert it to index
> > palette format. 8 bits per pixel instead of 24. That will get you
> > down to a little over 4 MB, but will increase image load time as you
> > will have to restore it to 24 bpp format for use unless you're using
> > OpenGL which I believe has the ability to read in indexed color
> > format images.
> >
> > If you are able to leave BMP, try using PNG. It's lossless, and
> > stores its data in a compressed format.
> >
> > I typically use uncompressed 24-bpp or 32-bpp bitmaps for all of my
> > graphics work that winds up being used in software. Memory and hard
> > disk storage are cheap these days. It makes the algorithms easier,
> > and there is no delay on use after load ... which, everybody expects
> > a small delay for load I would think.
> >
> i should not answer toy you rick as youre abusing this group and destroyng the minds .. but i will ;c yet coz no much answer to talk with
>
> i got no code to read png and i use only system winapi
> dlls or my own (dont want any dependencies), code for reading png may be maybe more complex for compresing it myself to my own format

Windows has the ability to read PNG files. If you use the GdiPlus:Bitmap
object:

https://msdn.microsoft.com/en-us/library/windows/desktop/ms534420(v=vs.85).aspx

// using namespace gdiplus
Gdiplus::Bitmap
Gdiplus::Bitmap* image = Gdiplus::Bitmap(bmpFilename);

It will handle a wide array of formats. To access the rows:

RECT lrc;
Status status;
BitmapData imageBits;
HBITMAP hbmp;

SetRect(&lrc, 0, 0, image->GetWidth(), image->GetHeight());
status = image->LockBits(&lrc, ImageLockModeRead,
PixelFormat24bppRGB, &imageBits);

// Grab a handle to the bitmap
image->GetHBITMAP(RGB(255,255,255), &hbmp);

// Load into a device context
SelectObject(hdc, hbmp);

// Now you can BitBlt() into it, extract data out of it to
// other sources, whatever

// When finished
image->UnlockBits(&imageBits);
delete image;

Put this at the start and end of your program:

// In global space
ULONG_PTR token;

// At the start
GdiplusStartupInput startupInput;
GdiplusStartup(&token, &startupInput, NULL);

// At the end
GdiplusShutdown(token);

> as to 8 bit bmp it is funny but there i dont know 16-bit or yet better
> 'variable index length' bitmap format

Use GIMP. You can look at the image in various forms and find out which
one you like better. Ctrl+Z will undo. 256 separate colors will usually
give you enough information for a scene, remembering that textures will
be rendered with color blending automatically.

> and tjis compresion and this delay really matters, now i use 12 MB map but in theory i would want to use larger maps and this delay here really matters (for me - who needs to write handsome games ;c )

PNG files are about as small as you can get while remaining lossless.
JPGs go smaller, but they are lossy.

I typically use 6000 x 8000 pixel images for posters I create. The
PNG files for those are 512 KB to ~3 MB depending on content. Here
are two examples:

512 KB:
http://www.libsf.org:8990/projects/LIB/repos/libsf/raw/arxoda/core/cache_l1/cache1__4read_4write_poster.png

3.1 MB:
http://www.libsf.org:8990/projects/LIB/repos/libsf/raw/king/keyboard_designs_poster.png

[fir]

sorry for adding many postscripts to post buy as there is no edit post function this is the only way

out of curiosity i tried to run this indexing method on
those previous bitmap from platform12 (which is more easily compressable)
for 10-pix indexing it yeilded to only 2880 entries this means 12 bits * 4M/10 = 600 KB (nicer size but still 10 times worse then rar here)
yet tried 20-pix it yeilded to 3181 entries (isnt it an error?) if so it means 12 bits * 4M/20 = 300 KB, now that is quite nice.. (+ palette of 3181*60 = 180KB must be added)
40-pix gives 4451 = 13 bits * 4M/40 = about 160 KB + like 500 KBfor palette)

but my bitmaps will be more like those heavier one

[fir]

i just write fast games, i measure even load time in miliseconds (i mean windows lasks the (very needed ime function for it so i measure not my app load time but
my app setup time (which adds to natural load))

i know also i could load this bitmap 'asynchronously' in the background of my app starting menu atc (winapi has
such functions and it even worked very well on one
core old pentium 4 when i tested it - dont know how it work but it really works, do not really holds a cpu when reading in vacground) - but i just also would like to compress my data as basic compression is as it seen quite easy

[fir]

i use only pure core winapi (not any kind of c# shit) and it must be compatible with winxp - is this in core winapi of win xp?

newer windows has some suport for zip compression so probably maybe it also gives some functions for zip compression but i dont know, as i said it must be core win xp compatible

[Rick C. Hodgin]

On Monday, March 27, 2017 at 4:12:29 PM UTC-4, fir wrote:
> W dniu poniedziałek, 27 marca 2017 21:54:25 UTC+2 użytkownik bitrex napisał:
> > On 03/27/2017 11:26 AM, fir wrote:
> >
> > > it is 12 MB bmp file and loading it makes 1 second delay at game startup (on my hdd, on some more new hdd could be faster)
> >
> > Why are you concerned about a 1 second delay in loading what I assume is
> > an x86 PC game? Have you played any recent games for the platform?
> >
> > If that 1 second is the bulk of the load time (and it must be since
> > you're focusing on it so intently) then it's probably already the
> > fastest loading PC game ever made.
>
> i just write fast games, i measure even load time in miliseconds (i mean windows lasks the (very needed ime function for it so i measure not my app load time but
> my app setup time (which adds to natural load))

Everyone expects load time on a game or graphics app, fir. It
takes time to load and process that much data, to generate mipmaps
and what not.

I think you're spending a lot of time making sure your turn
signals have a good on/off rate when your engine isn't fully
designed yet.

Remember the general guidelines:

(1) Design
(2) Code
(3) Error free and functionally correct
(4) Optimization

If you're good, you can design for (4) in the other steps, but in all
honesty, you probably won't know what the slowest factor of your total
performance is until it's completed. At that point, you can spend
some time optimizing a few algorithms and gain a huge speedup in your
project, as there are usually about 5% or less of the algorithm code
responsible for 95% of the CPU time.

[Rick C. Hodgin]

> i use only pure core winapi (not any kind of c# .. ) and it must be compatible with winxp - is this in core winapi of win xp?

If you'd like me to continue helping you, remove all profanity from
your posts. It is the cost of communicating with me, fir.

It's GdiPlus, not C#.

https://msdn.microsoft.com/en-us/library/windows/desktop/ms533798(v=vs.85).aspx

> newer windows has some suport for zip compression so probably maybe
> it also gives some functions for zip compression but i dont know, as
> i said it must be core win xp compatible

As I understand it, GdiPlus takes advantage of a lot of things GDI
doesn't. It's worth looking in to if you're going to be using any
aspect of core Windows for load operations instead of custom add-on
libs like OpenGL (which will handle it for you).

[fir]

if you would be a bit wiser you probably you would know that i know that - so no need to say that (as it gives no additional value)

anyway this load time matters and matters quite a lot,
and i said why im doing that - making core game mechanics
gets me tired so i need to rest with such less convoluted pieces of work as here ;c (core game is more scary ;c )

[fir]

not really, you talk side non much important pices and i only talk with you ocassionaly, esp if youre a kind of zombie that trashes usenet with harmfull brainless spaming as we both know

im more or less bulshit free so you will not manage to
make me sign up to your bulshit Chirograph - im not taking syupidity even for money - it would be silly if you would try to sold me stupidity at the requirement to sold me more stupidity so get off spaming idiot rick, im sorry

[fir]

>
> not really, you talk side non much important pices

the topic is anyway on compression not on gdi or ogl,
gdi + as far as i remember was added in windows6
(probably this id about this gdiplus.dll mentioned,
i searched for it and i got it in c:\WINDOWS\WinSxS\
which suggest that is maybe some side component
maybe not presented on all instals, im not sure though)

[fir]

gdi plus was also as i remember famous for being buggy slow, yet it was famous for this bug that allowed to infect desctop by virs just by opening some prepared jpg in apps using it ;c (im not sure if that was jpg or maybe png or some other image format) (virus infection by opening image, that was scary ;c)

i could use some code for some copmpresion though if this is small source and freeware, yawn.. otherwise i could yet try a bit with this RLE or some oteher simple recipe

[Rick C. Hodgin]

On Monday, March 27, 2017 at 4:32:13 PM UTC-4, fir wrote:
> ... esp if youre a kind of zombie that trashes usenet with harmfull

> brainless spaming as we both know

Here's what it's like to be judged, and thrown into Hell, fir:

https://www.youtube.com/watch?v=CppcAsLdy8I

I don' want that end for you, fir. I don't want that end for anyone,
which is why I am obedient to the Lord Jesus Christ who came to save
ALL people who will come to Him and ask forgiveness. He will save
everyone no matter what sin they've committed. All each person need
do is to believe in Him, and ask Him to forgive them.

I teach you about this because the enemy at work in this world wants
you destroyed, Jesus wants you saved, and I want you saved, fir.

It is not spam. It's the only lifeline God is offering mankind. And
because of who Jesus is, and because of what He did at that cross,
One is sufficient.

[Rick C. Hodgin]

On Monday, March 27, 2017 at 5:08:46 PM UTC-4, Rick C. Hodgin wrote:
> On Monday, March 27, 2017 at 4:32:13 PM UTC-4, fir wrote:
> > ... esp if youre a kind of zombie that trashes usenet with harmfull
> > brainless spaming as we both know
>
> Here's what it's like to be judged, and thrown into Hell, fir:
> https://www.youtube.com/watch?v=CppcAsLdy8I

And another:
https://www.youtube.com/watch?v=gXhh6I_DWGs

-----
People look at this warning as a joke. There's an active enemy at
work in this world deceiving people into believing they're fine,
that sin won't be judged, or doesn't even exist.

That's what the enemy says. What does God say?

http://biblehub.com/ezekiel/18-4.htm

4 ... the soul that sinneth, it shall die.

All I can do is raise my voice and point you to scripture. I can
teach you what Jesus is teaching everyone who will listen. I cannot
make you believe, and it pains me to no end to know that there are
still some who will not hear this message, and who will be cast into
the eternal lake of fire without any possibility of getting out ever.

It tears me up to think about that end for so many people I care
about!!

[fir]

i revrited it to take those 2 dimensional blocks as a
'keys' (as it is said sometimes that taking such blocks
gives better results than 1-dimensional one and for
example when taking 4 pixels

4-pix horisontal = 12 011 unique entries/blocks
4-pix vertical = 12 033 unique blocks
2x2 - pix = 11 586 unique blocks

the less is better, seen here 2x2 is in fact better here but not so very much

still its 14 bits * 1 M + 11 586 * 12 bytes ==
about 2 MB

for 16 pix horisontal it is 98 835 entries
16 vertical= 99 406
4x4 pix = 94 043 unique blocks
=
(17 bits * 4M/16 = about 500 KB) + (94k*48bytes == 5 MB)

not effective, unles maybe 'palette' would be compressed

[Chris M. Thomasson]

Perhaps something like keeping the stride of like colors, just thinking
out loud here:

struct stride
{
uint16_t len; // 0xFFFF worth of space
};

((stride.len & 0xFFF0) >> 4) gets the stride field

(stride.len & 0x000F) gets the meta data describing the strides details

We have a max stride length of 0xFFF, and 0xF worth of meta data...

How many total colors can you have on a map? What about classes of
colors, like shades of green?

[fir]

ye i will try some RLE, colors as i said i be used i think at most couple of thousands, may probably try at first convert 24bit pixel into 8bit-length 16-bit index
or something more elaborate ->

read byte
if 7th bit up - read 7 bytes al length next 16 as index
if 7th bit down - read next 15 bit as index

will try it later

[fir]

gett of stupidity buffed idiot

[fir]

W dniu poniedziałek, 27 marca 2017 23:50:09 UTC+2 użytkownik fir napisał:

> for 16 pix horisontal it is 98 835 entries
> 16 vertical= 99 406
> 4x4 pix = 94 043 unique blocks
> =
> (17 bits * 4M/16 = about 500 KB) + (94k*48bytes == 5 MB)
>
> not effective, unles maybe 'palette' would be compressed
>

i was thinking a bit and this in fact maybe could be some way

it gives good base of 250k indexes (of 17 bits) (0.5 MB)

palette is damn heavy say 100k * block size - it could be effective if this block size would be in a range of 5 to 10 bytes, raw block is 16 pixels of 24bits = 48 bytes but could be compressed as at most 16 colors in each block (and usually there would be less, sometimes like only 2,3,4, probably quite often 8 or less ) - if so such 16 pixel block could be encoded in at most 16*4bits = 8 bytes and probably most often encoded as 16*3 bits = 6 bytes, and sometimes (but probably also quite often as
16*2 bits = 4 bytes ) besides that also some palettes
need to be build, i dont know how many but probably like 10k plettes or less each palette like maybe 5-15 bytes long

so it would yeild maybe to 17b * 250k = 0.55 MB base
7*100k of blocks = 0.7 MB of blocks + 10k * 10 bytes - 0.1 MB of palettes - that would be like 1.35 MB of a result.. that i would be starting to get satisfied (if zip gives 12MB- > 0.8 MB imo the 12MB->1.3 MB of home easy packing would be starting to get satisfied

the code would be also not to much hard to write in one evening - though im weary now and get no mood to code it now

also could try this RLE but also to weary now

[fir]

PS i write this RLE packing.. though i not tested if it works ok (im sometimes to wearylazy to test i just wrote and run as here)

//////////////////////////////

int CheckHowLongRepeatingSequenceOfUnsignedsHere(unsigned * input, unsigned * input_last)
{
int counter = 0;

for(unsigned * p = input; p<=input_last; p++)
{
if(*p==*input) counter++;
else break;
}
return counter;
}


int Encode31bitUnsignedsRLE(unsigned* input, int input_max, unsigned * output, int output_max)
{

int input_i = 0;
int output_i = 0;

for(;;)
{
if(input[input_i] & 0x80000000) ERROR_("error: 31 bit input values are assumed");
if( input_i>=input_max) return output_i;
if(output_i>=output_max) ERROR_("error: overflow in output (in EncodeRLE)");

int rep = CheckHowLongRepeatingSequenceOfUnsignedsHere(&input[input_i], &input[input_max-1]);

if(rep==1)
{
output[output_i] = input[input_i];

input_i ++;
output_i ++;

}


if(rep > 1)
{
output[output_i] = input[input_i] & 0x80000000;
output_i++;
output[output_i] = rep;
output_i++;

input_i += rep;
}

}

}

const int BitmapRLEEncoded_max = 4000*4000;

unsigned BitmapRLEEncoded[BitmapRLEEncoded_max];


int BitmapRLEEncoded_top = 0;


int EncodeBitmapRowRLE(int y)
{
int encoded_row_size = Encode31bitUnsignedsRLE(&indexed_map[y][0], map_x, &BitmapRLEEncoded[BitmapRLEEncoded_top], BitmapRLEEncoded_max - BitmapRLEEncoded_top );

return encoded_row_size;

}

int EncodeBitmapRLE()
{
int summaric_encoded_length = 0;

for(int y=0; y<map_y; y++)

{
int encoded_row_size = EncodeBitmapRowRLE(y);

flog("\n encoded row %d size %d", y, encoded_row_size );

summaric_encoded_length += encoded_row_size;

}

flog("\n summaric_encoded_length %d ", summaric_encoded_length );

}

///////////////////////////////

the results (im not sure if this encodes well though as i said) was


encoded row 0 size 315
encoded row 1 size 350
encoded row 2 size 400
encoded row 3 size 446
encoded row 4 size 514
encoded row 5 size 583
encoded row 6 size 565
encoded row 7 size 641
encoded row 8 size 666
encoded row 9 size 717
encoded row 10 size 736
encoded row 11 size 787
encoded row 12 size 801
encoded row 13 size 823
encoded row 14 size 843
encoded row 15 size 878
encoded row 16 size 916
encoded row 17 size 924
encoded row 18 size 926
encoded row 19 size 935
encoded row 20 size 903
encoded row 21 size 912
encoded row 22 size 886
encoded row 23 size 860
encoded row 24 size 835
encoded row 25 size 826
encoded row 26 size 865
encoded row 27 size 858
encoded row 28 size 854
encoded row 29 size 808
encoded row 30 size 864
encoded row 31 size 824
encoded row 32 size 818
encoded row 33 size 791
encoded row 34 size 796
encoded row 35 size 764
encoded row 36 size 766
encoded row 37 size 714
encoded row 38 size 796
encoded row 39 size 737

(...)

encoded row 1970 size 231
encoded row 1971 size 225
encoded row 1972 size 217
encoded row 1973 size 235
encoded row 1974 size 250
encoded row 1975 size 259
encoded row 1976 size 244
encoded row 1977 size 236
encoded row 1978 size 233
encoded row 1979 size 245
encoded row 1980 size 245
encoded row 1981 size 239
encoded row 1982 size 228
encoded row 1983 size 225
encoded row 1984 size 215
encoded row 1985 size 218
encoded row 1986 size 212
encoded row 1987 size 205
encoded row 1988 size 215
encoded row 1989 size 200
encoded row 1990 size 198
encoded row 1991 size 194
encoded row 1992 size 198
encoded row 1993 size 190
encoded row 1994 size 167
encoded row 1995 size 179
encoded row 1996 size 174
encoded row 1997 size 168
encoded row 1998 size 154
encoded row 1999 size 164
summaric_encoded_length 1257765

if so that would be 1.25 M ints it is quite well, better than even probably a bit eleborate indexing (i even encoded rows in separate encoding all rows as one could be probably only tiny better though)

if so that would be a full succes to me, though i need
to test if it is ok as i maybe not quite belive it and there are some errors here

this number is number of ints but those ints are indexes
and number of those indexes = number of unique colors and
can be encoded like in 8-16 bits (in present case even in 6 bits but it will grow, still for some time it will be 10 bits or less so for my case if this work it seems
good solution)

need to test if this really works well, i will check it later

[fir]

W dniu poniedziałek, 27 marca 2017 17:26:50 UTC+2 użytkownik fir napisał:

> i get a little big tired when coding roguelike and maybe i could rest coding a side problem
>

ye i m resting from coding by doing coding

(could even say im doing rest form softcore coding by doing hardcore coding, (softcore seems harder), but its hard to say i coding rogualike is in fact more softcore and bitmap compression more hardcore (it would semms so to me, but do really?)- anyway in fact there are as it seems to me quite various types of coding work, they resemble selfs in many aspects but quite differ in other many aspects, well, i dont know)

[fir]

i think maybe the core difference is as when compressing bitmap one need to plan it and rethink (as this is algorithm that need rethinking) when coding roguelike otherwise it is a lot of more strightforward code, but a
lot of typing code jumping and error checking (less amount of complex thinking but a bigger amount of practical but quite wearysome mind-usage (quite scary there is so much lot of it needed then in fact one could rest thinking on some algorithm :C))