4x4 avatar version

[zedd151]

Here is my 4x4 game (avatar version) that I will use for making a demonstration of playing the 4x4 game, and what to do if the bottom row appears to be unsolvable.

This is just the basic 4x4 game for now. I will be adding the code to generate a bitmap after each move is take in the next version. (credit to Vortex for that function)

After the code is finished, I will make the "4x4 demonstration avatar" from the series of bitmaps representing actual game play into an animated .gif and proudly display it in my profile as well as posting it in the 4x4 topic as a demo. 


 

[zedd151]

Demo of playing 4x4...
A longer demo.... 4 games

There are a couple of caveats for using the attached program to capture each "frame" while playing the game.

1. The empty folder "pix" must reside where the program is executed from. If there are files already present, they will be overwritten without warning. Any remaining files that were previously present may erroneously make their way into the created animated .gif if you are not careful in ensuring that folder "pix" is empty before starting the process.

2. Upon any action (WM_KEYUP in this program) there is a delay in that InvalideRect returns before any painting is finished. Meaning that each screen capture is one frame behind. But I added another call so that the last frame is captured. This has little effect on the outcome, just thought that I would mention it here.

The bitmap files will be named "000.bmp" sequentially numbered up to the number of captures made.
This makes it convenient for opening a program to create the animated .gif by choosing "Import -> Folder as Frames" or similar option. I used ImageReady to create the .gif here.

Challenge project for some time in the near future...
Create an animated .gif from a series of bitmap files.
With gdiplus, it should indeed be possible. There may be examples on the internet somewhere already (even if it is in C).
But optimising the palette and optimizing how the .gif is stored might prove challenging, if file size is to be kept as minimal as possible. I have never done such work, but I imagine it would not be easy.

[daydreamer]

Nice zedd
I remember when had physical 4*4 game ,other side was puzzle of image
So I got idea of make program that let user choose image file and split it into 4*4 images, for use in 4*4 game

I once got it as task in Java class to make 4*4 with 4*4 buttons
Very hard to find out because restrictions to move around buttons I had to fake it

[zedd151]

Nice zedd
I remember when had physical 4*4 game ,other side was puzzle of image
So I got idea of make program that let user choose image file and split it into 4*4 images, for use in 4*4 game

Interesting. That should be a little more difficult than using numbered tiles.

At least two members here had difficulty with using numbered tiles. That is they got'stuck', not being able to solve the bottom row.  No patience maybe? Each game is guaranteed to be solvable, btw.
So I made a full size 512x512 Demo of how to play, and what to do if the bottom row seems unsolvable, In addition to this tiny avatar sized demo.

4x4 full size demo

[FORTRANS]

Hi,

Challenge project for some time in the near future...
Create an animated .gif from a series of bitmap files.
With gdiplus, it should indeed be possible. There may be examples on the internet somewhere already (even if it is in C).
But optimising the palette and optimizing how the .gif is stored might prove challenging, if file size is to be kept as minimal as possible. I have never done such work, but I imagine it would not be easy.

   I have worked with animated GIF images, including reducing file size,
and palette fix ups.  All in 16-bit DOS code though.  I am not sure what
problems you might be encountering?

Regards,

Steve N.

[zedd151]

Hi,

  I have worked with animated GIF images, including reducing file size,
and palette fix ups.  All in 16-bit DOS code though.  I am not sure what
problems you might be encountering?

Regards,

Steve N.

I haven't even looked into what would be necessary to do that yet. I recently learned only a little bit about some gdiplus functions for working with animated .gif files (reading them, not creating them). That is why I mentioned it is a project for the future, it will take some time for me to wrap my head around what will be necessary.

I am sure that it will be a interesting endeavor, and rewarding if done properly.

Larry

Update: after searching the internet, the only things I had come up with re: converting a series of bitmap to animated .gif are C++ code and ImageMagick, otherwise a lot of sources say to use a third party program or library to make the conversion. Surely someone has to have had done it by coding it up themselves other than your 16 bit code, Steve. Seems it will be a long path to attempt doing this.  I was hoping to find some C code at least, to aid in my research.   
I did however find some useful information here:  https://en.m.wikipedia.org/wiki/GIF for the file header and data compression used, and other errata.

[NoCforMe]

Well, for one thing you'd need a LZW encoder, since the image data is compressed.

I'm sure somebody out there has a free library that will do that.

[zedd151]

Well, for one thing you'd need a LZW encoder, since the image data is compressed.

I'm sure somebody out there has a free library that will do that.

Yes, during my research I did indeed find that .gifs were compressed using LZW.
But as I am currently working on other projects, I will continue further research at another time.

[FORTRANS]

Hi,

Well, for one thing you'd need a LZW encoder, since the image data is compressed.

I'm sure somebody out there has a free library that will do that.

   Or you can write your own.  There are (or were) plenty of documents,
tutorials, or examples in code.  Slogging through those was bunches of
fun when I wrote my encoder (and decoder of course).

Cheers,

Steve N.

[NoCforMe]

Hi,

Well, for one thing you'd need a LZW encoder, since the image data is compressed.

I'm sure somebody out there has a free library that will do that.

  Or you can write your own.  There are (or were) plenty of documents,
tutorials, or examples in code.  Slogging through those was bunches of
fun when I wrote my encoder (and decoder of course).

Now that you mention it, that would be my preference, assuming it's in the realm of possibility for a mere mortal like me. I don't know how complex LZW is; however, I have written RLE (run-length encoding/decoding) code, and that wasn't too hard.

Do you happen to have a link to a LZW specification handy?

[zedd151]

Do you happen to have a link to a LZW specification handy?

May be this can help? It has a C++ (garbage  ) example, plus pseudo code examples

https://www.geeksforgeeks.org/lzw-lempel-ziv-welch-compression-technique/
And a list of references at the bottom of page.

pdf from MIT regarding LZW compression

From the c++ and pseudo code shown, seems rather simple pair of algorithms... on paper anyway. In practice, who knows? It should be doable in assembly...

Even better C sources from GitHub https://github.com/MichaelDipperstein/lzw

I might fiddle around with the C code later this evening... to see how easy or not to port to assembly

Maybe this LZW stuff needs own topic?

[NoCforMe]

Could make it a new topic, sure. (Let's leave this stuff here for now.)
Whaddya know: that page you linked is the same page I found by a quick search.
I didn't realize that Lempel-Ziv constructs a data dictionary on the fly. Pretty kewl.
Now I want to code this up myself.
Should be very do-able in assembly. Remember, Zedd, there's really nothing stopping us from coding practically anything in our favored language.

[zedd151]

Now I want to code this up myself.

    Glad to have inspired you.
Okay you can start that topic, we can leave this stuff here.

Should be very do-able in assembly. Remember, Zedd, there's really nothing stopping us from coding practically anything in our favored language.

Yes, it looks a lot simpler than I had imagined it would be. (The LZW algos)

[daydreamer]

Could make it a new topic, sure. (Let's leave this stuff here for now.)
Whaddya know: that page you linked is the same page I found by a quick search.
I didn't realize that Lempel-Ziv constructs a data dictionary on the fly. Pretty kewl.
Now I want to code this up myself.
Should be very do-able in assembly. Remember, Zedd, there's really nothing stopping us from coding practically anything in our favored language.

I agree,good luck David

[FORTRANS]

Hi,

I didn't realize that Lempel-Ziv constructs a data dictionary on the fly. Pretty kewl.

  Yeah, that helps make it a one pass algorithm.  Unlike Huffman
which requires one to read everything in to generate the required
statistics table.

Now I want to code this up myself.
Should be very do-able in assembly. Remember, Zedd, there's really nothing stopping us from coding practically anything in our favored language.

  Well I did it, so most here could probably do so as well.  For
*.GIF files, make sure you use the LZW variant.  And note that,
for me to get working code, it took quite some time and effort.
Of course I probably did a lot of rewriting to get an acceptable
program to play with.  And I tried all sorts of excursions along
the way.

Regards,

Steve N.