For anyone looking for 64-bit example programs.
Some changes that aren't caused by the 64-bit calling convention or lack of old MASM features include:
* Moving and removing calls to GetClientRect and InvalidateRect
* Restricting painting proc to be used by WM_PAINT only
* Adapting to Unicode (UTF-16LE)
Some other notes:
* The windowing system invalidates rectangles for moving, scrolling, creating, resizing, and uncovering windows. Invalidating the rectangles posts WM_PAINT messages (per window).
* It's too bad MASM for 64-bit didn't retain ASSUME reg:structname. It would've simplified references to RSP-based data.
15-4x4.zip
Quotezedd's 4x4 game in 64-bits
:azn: I'm flattered.
The version with autosolve too. :thumbsup:
That is ancient code (around 10 years old, iirc). :tongue: Glad that you understood it enough to port it to 64 bits. :smiley:
It was actually not so bad. It was mostly straightforward.
The EBX carry over between function calls would've been a clever trick in my younger days. But it answers my question of "How does it ensure it does nothing if you've missed a case?"
There were a number of data that were not used. They were rooted out by the incremental builds I did after my first pass at conversion.
The autosolve is useless to those who don't look at the source code. It needs animation. Otherwise, you could've just re-initialized the board and said "I solved it for you!"
Well, NoCforMe's Game of Life has a blocky kind of animation that would fit right in. Smooth animation will have to wait.
Quote from: tenkey on June 04, 2025, 10:08:40 AMWell, NoCforMe's Game of Life has a blocky kind of animation that would fit right in. Smooth animation will have to wait.
Feel free to use that if you like. (And yeah, it is blocky!)
Quote from: tenkey on June 04, 2025, 10:08:40 AMThe autosolve is useless to those who don't look at the source code.
Ouch!! A little harsh, so here is a short explanation of my intent, in regards to the autosolver:
The purpose was to give the player a goal to meet, or exceed.
I.e., solve the puzzle in less moves than the game can solve itself. I optimized the auto solver for minimal number of moves from one position to another for a given game piece. But a clever player will always be able to beat the 'auto solvers' score. The auto solver did not take into account the moving of multiple game pieces at a time, and how the pieces are related to each other (in the sequence 1-15). A lot of improvement can be had.
QuoteIt needs animation.
Feel free to do that. :badgrin: :biggrin: Shouldn't be that hard. I did not think it would be needed, so I did'nt include that in the game.
Quote from: tenkey on June 04, 2025, 10:08:40 AMThe autosolve is useless to those who don't look at the source code. It needs animation. Otherwise, you could've just re-initialized the board and said "I solved it for you!"
But if you generate the random board,with start from a 1-15 board followed by lots of random moves,it's easy to save those moves and move backwards in time
Quote from: daydreamer on June 04, 2025, 01:30:56 PMBut if you generate the random board,with start from a 1-15 board followed by lots of random moves,it's easy to save those moves and move backwards in time
:rolleyes:
What are you even talking about?
Have you looked at the code to see how the autosover actually works? Have you seen how many times the board is scrambled to acheive its 'randomness'?
Quote from: tenkey on June 03, 2025, 05:07:03 AM* It's too bad MASM for 64-bit didn't retain ASSUME reg:structname. It would've simplified references to RSP-based data.
ML 32-bit won't let you use
ASSUME ESP:PTR BYTE either.
The whole PROC prologue/epilogue still works perfectly well with ML64,
provided you take care of shadow space on your own. Accessing parameters, locals, even USES works just fine.
MS probably looked at what ML64 was used for, decided it didn't need whole chunks, and killed them off (e.g. .if)
Did you use the standard MASM64 download? I usually have to find missing api details or newer constants.
Quote from: daydreamer on June 04, 2025, 01:30:56 PMQuote from: tenkey on June 04, 2025, 10:08:40 AMThe autosolve is useless to those who don't look at the source code. It needs animation. Otherwise, you could've just re-initialized the board and said "I solved it for you!"
But if you generate the random board,with start from a 1-15 board followed by lots of random moves,it's easy to save those moves and move backwards in time
Utterly useless to a human solver who doesn't know what those random moves are. The autosolver shows (if animated) one way to solve it without knowing those random moves.
Quote from: zedd on June 04, 2025, 12:32:49 PMI optimized the auto solver for minimal number of moves from one position to another for a given game piece. But a clever player will always be able to beat the 'auto solvers' score. The auto solver did not take into account the moving of multiple game pieces at a time, and how the pieces are related to each other (in the sequence 1-15).
Actually, set910 and set1112 position 2 pieces at a time, and not in their final destinations! Don't sell yourself short.
Quote from: tenkey on June 06, 2025, 04:42:05 AMActually, set910 and set1112 position 2 pieces at a time, and not in their final destinations! Don't sell yourself short.
Memories fade fast. I ain't young anymore. :tongue: