Is this too difficult?

I am really ROFLMAO, I decided to see if PUZZLE_SIZE meant anything in my code as I had incorporated it to deal with different puzzle sizes, but I was doubtful that puzzle sizes would not cause the program to barf bits all over the machine. I had to make more images to get puzzle size 7, but puzzle sizes down to 3x3 work. It would not be sensible to have a puzzle size < 3 unless TRIPLETS was excluded and since I thought of that , I will try it now. :)

I am ROFLMAO again. Can you solve this puzzle? I wonder if you have to have an IQ of 98 to solve it? A is left of B, A and 2 are in the same column, and A is adjacent to the column that contains 1. I think it is TMI IMHO or IMHOTEP the Egyptian scientist. I think I can solve it, but I will need to hire some mathematical analysts.

If I do puzzle size one, there could only be one hint type and that would be a given, so the puzzle is "1" in a square and the hint is , it is 1. I wonder if I could solve that, well maybe some day I will set PUZZLE_SIZE to 1. I just can't stop laughing now.

dependo:  $(DEPENDS)
                gcc -c -Wall -W -ansi -pedantic  $(PROJECT)_game.c \
                $(PROJECT)_sdl.c $(PROJECT)_save.c $(PROJECT)_gl.c \
                $(PROJECT)_textures.c \
  $(PROJECT)_matrix.c $(PROJECT)_menu.c

I did learn an interesting thing that had been bugging me, and that is the fact that when changes are made to header files that are included, the corresponding objects are not rebult unless you specifically request it in the structure of the make. It is kind of like being too helpful. So I added the above to deal with that, but I know it is a bit noobish to do it that way and I will find out how to do it better.

You'll have to make individual targets for each C file, and then list the header file as a dependency. You can still use your generic targets, and just place the .h dependencies afterwards, like so:

%.o: %.c
        @echo Compiling $<...
        $(CC) $(CFLAGS) -c -o $@ $<

foo.c: bar.h
# And so on...

I Googled and this is what I expected and so I may add that to the make or just let it hang for now. I think it would help and so I will probably go to the trouble of either scripting something that touches files or do "make dependo" when I make changes in the headers. It was a spooky issue before, because I saw it happen with the original "einstein" game and now I see why it had a latency in response to changes in headers, as it had no dependency relationship in make and 'sub' objects did not get rebuilt when I expected and then the code did impossible things, or so I thought. When things are impossible, it always means that you misunderstood something or missed something.

I'm thinking of a number between 0 and 2, I will give you only one hint, it is one. It actually is a bit interesting to play the game at puzzle size 3, 4 and 5, so I will add a menu option to define puzzle size at least to 3-7, anyway. A child might have fun at puzzle size 3.

I had to put up another picture at puzzle size 7, and I made no unique characters for the level seven and so there are duplicate textures, but as you can see, it generates a puzzle, hints and is solvable. I could do much higher levels, but the hint numbers would be large and unwieldy and it would be tedious to apply them. That is just my opinion, but I am including the option to do level 7, just for the h2l of it.

I did find a flaw in the code when I started doing this. I found that I had used a variable improperly when checking the validity of near matches and it would only have caused a problem if that hint were the first and it was at column 0. That is the kind of odd problem that can haunt a person if they revisit the code at some later date to fix problems. The code is coherent and clear in my mind now, but if it were years later, I would have trouble identifying such a wild intermittent. This type of problem happens so rarely that it comes and goes so infrequently that finding it with a trap is not feasible. You need tho know when it happens.