Simple Games - Research and Development

[zedd151]

And for my uses it worked, so I pointed it out to you.

Oh no Steve. Don't get me wrong it is very useful for me as well.

Just for sillyness, how do sudo.com and the brute force solver
compare in size and speed?

I think that the comparison would yield no useful insights. It is like comparing apples and oranges. Both are small enough and fast enough imo. At any rate, I have no clue how to put both of them in any sort if timing testbed. And certainly don't have any way of disassembling sudo.com, and if I did 16 bit code is rather foreign to me. I've never had the *pleasure* of having to code with it. Meant with a little sarcasm, seems not so easy to work with and at my age hard to learn new things. I know the registers, but beyond that I'm lost. I never had to deal with segments, interrupts, overrirides, etc. I've heard and read about some details of 16bit assembly.    . The brute force algo is much smaller, but takes many, many, many recursions to do its job. Sudo.com is quite a bit larger in bytes but makes only one pass seemingly. So, would most likely be very fast in a side by side comparison.
I don't have the exact sizes of each at the moment, I'll edit them into this post later...

And it seemed quick to me as well.

I'd say it's fast enough. And thanks for showing this to me.

Side note: I'll look at the other code in that link you provided at some point, to see if I can make sense of it...

[zedd151]

@ FORTRANS fyi:
  sudo.com weighs in at 1500 bytes in its assembled form -> edit: disassembly shows 1499 bytes of code.
  the backtracking brute force algo weighs in at 247 bytes of code.


I found a couple utilities to look at the disassembly of sudo.com. But as mentioned in the above post, I can't grasp 16 bit code. I'm basically lost even with seeing the code. Learning 16 bit code and its quirks and peculiarities is out of the question as it would most likely take way too much time for me, time better spent with the code I understand fairly well (x86). And I just barely grasp some of that.    Sometimes I do wish I had learned 16 bit code before learning 32 bit...


At any rate, I still have to finish up the work I'm doing on the current sudoku project GUI. So without further ado ... 

[FORTRANS]

Hi,

   There is yet another BATch file for creating sudo.com.  Look
for the following.

Code: [Select]

You again disassembled the decoder and not the program.
The following batch will generate the real (not ascii encoded)
binary which you can disassemble:

@echo off
echo hD1X-s0P_kUHP0UxGWX4ax1y1ieimnfeinklddmemkjanmndnadmndnpbbn>bat.com
echo hhpbbnpljhoxolnhaigidpllnbkdnhlkfhlflefblffahfUebdfahhfkokh>>bat.com
echo wvPp0w@L4k9C5/R/pN0d0uDL47bwo1YiQJEWtbGov5//B6mkuMEo0IL0l/w>>bat.com
echo ef2iC57R/pNEA/jeefHhC5AR/pNEA/juefXgC5ER/phCfDM@m042knfuur9>>bat.com
echo l3LYV5wPajYHk3aZPILM5uqAk3g/XQqHL3wYkRkPKAGPq2f9wNaZc4fXkNa>>bat.com

   It creates a sudo.com that is 992 bytes long.  And its code will
correspond to his listing when disassembled.  The other two mentioned
above are ASCII encoded executables.  All have the same functionality,
but the last one is nicer to look at and/or figure out.

   It has been a while.  Sigh.

Regards,

Steve N.

[zedd151]

...but the last one is nicer to look at and/or figure out.
Regards,

Steve N.

I did see that one, how would I pass an argument to it?
From command prompt:

Code: [Select]

bat.com puzzle.txt >result.txt??
Something like that? And same puzzle format? I answered these questions upon realization I didn't create sudo.com, only bat.com...

Nevermind. I found out what went wrong.    I skipped a crucial step 
I commented out the part where bat.com was copied to sudo.com. Didn't realize at first why this step was taken. Now I see why...
I have it working now, binary sudo.com. Works just like the other one. 
The disassembly is indeed much more readable. 894 bytes of code for this one. Now to experiment with making an assemble-able source from it, if I possess the coding skills for it. I understand most of the code there. A little trial and error is probably due.

[zedd151]

I made the unsolvable puzzle solvable. I inserted a 5 (correct placement btw) in the center cell:

Code: [Select]

97.18..3.
..3.6...2
.......9.
5..2..6..
.3.754.2.
..7..6..1
.6.......
3...4.2..
.8..91.67


976182435
153469782
248375196
594218673
631754829
827936541
765823914
319647258
482591367


solved with one recursion Okay, thats cheating but... 
used it for testing the binary sudo.com... it werks well. Will investigate the code later when I have some time... 

[zedd151]

I found several flaws in the brute force solver I had posted a few days ago. That code had been converted from a source by another author from nasm syntax to masm syntax. First impressions were that it worked satisfactorily. But further examination showed that not only did it not return a failure value for a completely empty puzzle ( which could have been acceptable in certain instances) it did not detect key violations of sudoku rules in that two of the same digit in a row, column or box. It solves puzzles that in itself tries not to violate the rules, but errant puzzles entered that do violate this rule and goes undetected. Therefore will no longer use that as a viable solver candidate. I have removed the attachment from that post. I could rewrite the algo there, but since the original code is not mine, I don't feel the need or desire to do that.

Anyway, I have been distracted the last few days looking at the solver showed to me by FORTRANS. That solver does much better at detecting violations of sudoku rules. However I did find several cases where it could not solve extremely difficult puzzles. It is a COM file and so far, my attempts at disassembly of the code have been futile at best. I used a couple different disassemblers which show differing results. Either way, not an easy conversion to code that can be reassembled.
So, I'll put these distractions aside and continue with the GUI...

Will add switchable (on/off) candidates window for each empty cell; highlighting for a selectable number (if 1 is selected as the number, all cells with "1" and candidates with "1" will be highlighted as a candidate elimination aid); plus a few other changes or additions.
I plan* on posting a preview image of the GUI in the coming days if everything goes as well as could be expected.
* left field tangents aside 
The code to implement the planned changes will not be easy, but I'll try my best. May take a while to get a tested and debugged version ready to post here.

[zedd151]

Here is a mockup of what the GUI will look like. Some things may change though, by the time I finish writing the code for it. 
Candidates (small numbers) are shown for the empty cells. All "3" are highlighted here. 3x3 boxes where there is only one highlighted (3 here) candidate, the highlighted candidate IS the value for that cell. Also notice there is one cell with a single candidate (1), a 1 belongs in that cell.  (there is also a 'pointing pair  of "3's" that points to a candidate that can be removed) More on this later.

[jj2007]

Looks impressing

Do you still images or icons, or is it now TextOut?

[zedd151]

I've played with TextOut as well as bitmaps. For mor ease of use have chosen bitmaps (on a static control), since there will be many changes during gameplay, drawing everything would make some large and messy code. Easier for me to use bitmaps. I made a few pieces of code that work well so far, now to gather everything and put into the GUI... The image above is a cheat, I just copy/pasted it together as an example of what the finished product should* look like.


As a side note the finished game will not have any 'auto solve' capability. It also will not generate games via an algorithm, but via a array of games which would then be mainipulated to produce a larger valid set of puzzles.


I will work on a generator in the future, but in order to do that would need a solver first to determine solvability and uniqueness of solution for a given puzzzle. Both of which are not trivial feats to accomplish, at least with my current coding skils. I do have some good reference material to work with as I have been researching these topics for quite some time. (Longer than my postings here on the subject)

[daydreamer]

If random generated sudoku from certain random seed that's solvable, you could use a LUT of the best sudoku, but only stored if tested for solvable
Just remember very old way of create big world's just starting with right random seed,before games became cdrom based
Gui looks great

[zedd151]

If random generated sudoku from certain random seed that's solvable, you could use a LUT of the best sudoku, but only stored if tested for solvable

Taking this into consideration for if/when I write a generator. Thanks for the input Magnus.
edit=typo.

[zedd151]

Looks impressing
Do you still images or icons, or is it now TextOut?

I'm currently reinvestigating using FillRect and DrawText for drawing to the DC. I with make a test piece and post it when I have perfected* it. Dealing with all these bitmaps here can be just as much of a PITA as the code to manually draw instead. Both ways are pretty wordy sourcewise. I already have the code for getting the rectangle coordinates in which mouse button clicks on, so coding the test piece should'nt* take that long, I'd think.


Nevermind scratch everything I just said above. Will work on this at another time, having issues... In the meantime I'll continue with the bitmap version, since it is 50-60% finished. These last bits are the hardest.

[jj2007]

Looks impressing
Do you still images or icons, or is it now TextOut?

I'm currently reinvestigating using FillRect and DrawText for drawing to the DC. I with make a test piece and post it when I have perfected* it. Dealing with all these bitmaps here can be just as much of a PITA as the code to manually draw instead. Both ways are pretty wordy sourcewise. I already have the code for getting the rectangle coordinates in which mouse button clicks on

Consider an ownerdraw button and WM_DRAWITEM. GetClientRect and DrawText are not that difficult to use.

[zedd151]

Consider an ownerdraw button and WM_DRAWITEM. GetClientRect and DrawText are not that difficult to use.

The code I'm experimenting with first draws the game board using FillRect. That part is ok.

Then upon a mouse click on a cell, using GetDc to fill the selected cells RECT with another color, then ReleaseDC in the left button message handler. That code is working as well.
Select a cell, ok. Select another cell the second cell now has the new color, first cell restored to white. Ok so far.
Right now after making two successive selections all seems well. Can move/resize the window and selected cell color remains.

But the problem is on the first time a cell is selected then window is minimized then maximized the selection coloring done by FillRect is gone.
BUT, and here's the confusion, after the first two times when two different cells are selected the selection color remains in the second cell selected and IS persistent no matter if window is moved or resized. I know that that code works ok, but...

Seems to be some sort of initialization error somewhere. A variable or ? I'm still trying to track that bug. I think it is in the RECT structure, not initialized properly or values got changed... I'm on my ipad at the moment...

Anyway when using DrawText in the key down message handler with the same methods that works (kind of) for selecting a cell, the entered char is not persistent no matter if it is the first time used or not.
btw, the cell selection works (after the first time used) without any additional WM_PAINT processing. No CompatibleDC, CompatibleBitmap, BitBlt, etc... So I don't understand why FillRect works but DrawText doesn't using the same methods. Will post some code when I'm back at my computer.


Briefly commented code (only the relevant parts)

edited to attach file "DrawTextFail.zip"

[zedd151]

More likely than not I am probably making the code attached above more complicated than it needs to be. Surely I am missing something somewhere. At any rate I'm more comfortable using code that I know how to use and is failsafe and tested. That's why I usually choose to use bitmaps for most programs that I write rather than messy WM_PAINT code. Much easier to change bitmaps in a static control than to use the drawing apis. I understand some of the concepts behind WM_PAINT processing but fail too many times to count. When I do succeed it is more of a happy accident, rather than me actually knowing what I'm doing. 


That's the reason why I choose static controls+bitmaps for my graphics.    My feeble mind just doesn't comprehend some things that those with decades of programming experience can do in their sleep. I do try though, and try to learn new things all the time.