:biggrin:
I need a few members to test the animation speed in this test program. I don't need any coding advice just let me know if you think it is too fast or too slow... :smiley: Personally I like it, as-is. Its not too slow or fast for me... but would like other opinions.
I don't want to add the ability for the user to select the speed, but would rather find a happy medium, and have the speed hard coded.
to test, left click on any column to fill up the column.
Speed is OK but I don't like the pause before it drops.
Also, this with the message boxes - they were hidden until I moved the window
Untitled.png
Closing the program leaves the boxes there too :biggrin:
Quote from: sinsi on April 05, 2025, 03:10:07 PMSpeed is OK but I don't like the pause before it drops.
I think the slight pause before dropping is needed, imo. I'll post an example without it if you want, to see the difference.
QuoteAlso, this with the message boxes - they were hidden until I moved the window
Closing the program leaves the boxes there too :biggrin:
The message boxes stating that the column is full was only for testing purposes. They will not be in the finished product. Nor in the next example without the pause before dropping... give me a few minutes. :biggrin:
Here you go, sinsi. No Message Boxes :greensml: (left clicking on a full column now does nothing) and now there is no pause before dropping the pieces into the selected columns. I liked it better with the 250 millisecond pause myself.
Much better :thumbsup:
Quote from: sinsi on April 05, 2025, 03:49:23 PMMuch better :thumbsup:
Maybe I should add some options for the user...
I'll think about it. :smiley:
I'll probably use an .ini file...
if I do.
Quote from: zedd151 on April 05, 2025, 03:21:38 PMI liked it better with the 250 millisecond pause myself
The pause is a bit long. Try 100ms
Quote from: jj2007 on April 05, 2025, 07:20:36 PMQuote from: zedd151 on April 05, 2025, 03:21:38 PMI liked it better with the 250 millisecond pause myself
The pause is a bit long. Try 100ms
I'll split the difference. :biggrin:
Between my preference of 250 and sinsi's preference of 0, and make it 125 ms. :tongue:
It seem that one size does not fit all. :hmmm:
I see probably a couple sets of radio buttons on the horizon (in a settings dialog box) along with that aforementioned ini file to save the settings, for the final product.
Maybe slowest, medium, and highest - for both the "drop delay" and "animation delay".
Since I will be using a settings dialog and ini file, I'd probably add ability for changing the piece colors as well as background and foreground colors of the game board.
I used actual bitmaps here for testing, but the finished game will use memory bitmaps. The resource dialog box, and settings dialog will remain in resources.
Now that I finally have the game piece animation working 100% as desired, its time to shorten all the code that I used to achieve the desired effect. It took me quite a long time (I tried a gazillion different ways 'til Tuesday) to get this working correctly. I did have working code once, but kept it on the Desktop, and never made a backup of it - it was inadvertently deleted during housekeeping without saving it. :sad:
Everything regarding the game graphics is coded linearly in WndProc, without using any loops or self contained procedures to minimize the code in WndProc. :biggrin:
More details will be available soon(ish).
Thanks to all (only 2 members though :tongue: ), that participated in testing thus far.
I will use this topic for further testing of the code after any significant changes to it...
Quote from: zedd151 on April 05, 2025, 11:22:48 PMQuote from: jj2007 on April 05, 2025, 07:20:36 PMQuote from: zedd151 on April 05, 2025, 03:21:38 PMI liked it better with the 250 millisecond pause myself
The pause is a bit long. Try 100ms
I'll split the difference. :biggrin:
Between my preference of 250 and sinsi's preference of 0, and make it 125 ms. :tongue:
Here is a version with a pause of
125 ms. before dropping the piece into the selected column. :biggrin:
I still prefer no pause :tongue:
It is now flickering every drop.
My OCD is disappointed, the pieces aren't perfectly centred in the holes :sad:
Quote from: sinsi on April 06, 2025, 01:27:43 AMIt is now flickering every drop.
really?
I don't see that
at all here on my Desktop PC, no matter the pause duration, or animation increment, or animation delay.
I have tested many variations of each... when testing for optimal values of each of them.
I will also now test on my laptop... and report my findings...
QuoteMy OCD is disappointed, the pieces aren't perfectly centred in the holes :sad:
Gravity happens. The are resting on the 'bottom' of the 'hole'. That is the desired effect. :biggrin:
Quote from: zedd151 on April 06, 2025, 01:30:53 AMGravity happens. The are resting on the 'bottom' of the 'hole'. That is the desired effect. :biggrin:
In every image of the game I've seen the piece is bigger than the hole, and fills it up entirely :biggrin:
Definitely flickers, even the background
Quote from: sinsi on April 06, 2025, 01:46:48 AMQuote from: zedd151 on April 06, 2025, 01:30:53 AMGravity happens. The are resting on the 'bottom' of the 'hole'. That is the desired effect. :biggrin:
In every image of the game I've seen the piece is bigger than the hole, and fills it up entirely :biggrin:
Welcome to zedds world. Other programmers have their way, I did it my way. :biggrin:
QuoteDefinitely flickers, even the background
Now I am on my laptop, still not seeing
any flicker at all. I'll need a few more testers...
It flickers after I click in both versions but the animation is fine (win 7)
Quote from: adeyblue on April 06, 2025, 06:15:31 AMIt flickers after I click in both versions but the animation is fine (win 7)
thanks for confirmation. I do not know why I do not see
any flickering. :sad:
Back to the drawing board...
I will post a smaller example including the source code later today, or tomorrow. I have removed the attachments posted above.
Okay, my first idea to resolve the flickering issue for other users.
Quote from: sinsi on April 06, 2025, 01:27:43 AMIt is now flickering every drop.
Quote from: adeyblue on April 06, 2025, 06:15:31 AMIt flickers after I click in both versions but the animation is fine (win 7)
I have omitted drawing the foreground in this example. I believe that may be where the problem lies.
Please test this version... :smiley:
Another version, no foreground or background painting, only the game pieces.
test_no_foreground flickers
no_foreground_or_back ok
Here is the very first version where I used the painting methods in the examples in all of the above posts.
Only 1 column is used here. In the other sources used above, I copied and pasted the code from this version and changed variables where necessary.
The WM_PAINT code seems proper to me, in regards to the buffering. The use of the bitmaps though, not to my liking either.
Source code included in this one.
Quote from: sinsi on April 06, 2025, 08:26:07 AMtest_no_foreground flickers
no_foreground_or_back ok
Thanks sinsi.
Probably due to my blitting the background and foreground bimtaps in 80x80 sections piecewise in every call to WM_PAINT.?. :rolleyes:
I tested all the one I could find on this page: seem OK. A little jerky, since you're only drawing at a few locations.
What happened to all the attachments on the previous page? I was trying to find the version that you used to create your avatar. Can you repost that one?
I am going to play around with it tonight. I'll use FillRect rather than painting the background in 80x80 segments, (it's only a single color - duh), and construct the full foreground bitmap only once during initialization. And blit the larger foreground only once, replacing the 42 blits using 80x80 foreground segments.
I saw no issues on my end, but if others see flickering, I'll do my best to remedy that. I am a noob when it comes to WM_PAINT stuff after all. :biggrin:
Quote from: NoCforMe on April 06, 2025, 08:45:30 AMWhat happened to all the attachments on the previous page? I was trying to find the version that you used to create your avatar. Can you repost that one?
I had removed the zips containing the buggy (flicker ridden) executables, there were no sources in those attachments.
Also, I never posted the avatar related code or executable. I made full size screen captures 640x640 and made a full sized .gif in ImageReady, then resized it to 128x128 for the avatar.
One point may still be pertinent.
If you don't handle WM_ERASEBKGND then the window manager will do it for you, presumably not double buffered. Handle it yourself and return 1.
Quote from: sinsi on April 06, 2025, 01:06:43 PMOne point may still be pertinent.
If you don't handle WM_ERASEBKGND then the window manager will do it for you, presumably not double buffered. Handle it yourself and return 1.
Ok.
.elseif uMsg == WM_ERASEBKGND
mov eax, 1
ret
Try it now. :biggrin:
Left click for red piece, right click for blue.
No flicker, even maximised on a 4K monitor :thumbsup:
Quote from: sinsi on April 06, 2025, 01:20:34 PMNo flicker, even maximised on a 4K monitor :thumbsup:
ReallY??? YaY!!! :eusa_dance: :eusa_dance: :eusa_dance:
Best tip then, sinsi. :thumbsup:
Where do I send the generous payment? :tongue:
I'll share the ugly code if you want to see it. :tongue:
After I got the first column animating reasonably, I copied and pasted a lot of code for the other columns.
The code is pretty much linear in WndProc, no loops where there could be, or split parts of it into procedures, etc.
Just remember, it is still a work-in-progress. It is kind of messy, etc.
I was fairly certain that it was not an issue in WM_PAINT per se, which could still stand to be improved obviously.
Also, I never noticed any flickering here on either computer. So I was really stumped as to the possible cause.
Now I can work on streamlining the code, replacing the resource bimtaps, adding more commenting, etc... before finishing up the automaton code for the 'computer' player. :greenclp:
I do remember experimenting using WM_ERASEBKGND some time ago after seeing it suggested here somewhere, but never noticed any difference, so never bothered with it after that. :rolleyes:
See also
WNDCLASSEX.hbrBackground
When this member is NULL, an application must paint its own background whenever it is requested to paint in its client area.
To determine whether the background must be painted, an application can either process the WM_ERASEBKGND message
or test the fErase member of the PAINTSTRUCT structure filled by the BeginPaint function.Doesn't apply to a dialog, but here in case anyone is stuck :badgrin:
Quote from: sinsi... but here in case anyone is stuck
Well, thanks. :biggrin:
It's a more common problem than some folks would realize. Many graphics related examples only tell part of the story, unfortunately.
Thank you to those that have participated in these tests for me. The issue is resolved as of This Post (https://masm32.com/board/index.php?msg=137924), many thanks to sinsi.
This concludes
this testing and debugging session. :smiley: The finished game
will should be released within the upcoming week, time permitting.
It will take some time to consolidate and rework some of the code, to add full commenting, to add and test the 'computer player' automation code, and other miscellany. :eusa_dance: :eusa_dance:
Quote from: NoCforMe on April 06, 2025, 08:45:30 AMI was trying to find the version that you used to create your avatar.
While I am reworking this current rather messy source code, I
might just try making a 128x128 version, specifically for creating avatar sized bitmaps. (To be compiled into an animated .gif using ImageReady, Gimp, or other third party tool)
Whether or not I actually do that will be highly dependent how difficult or time consuming that would be to accomplish.
It will need bitmaps created specially for that purpose - as the bitmaps here are large enough (80x80) to use TransparentBlt with acceptable results.
The avatar sized version would not be able to use TransparentBlt and have acceptable results, the much smaller (around 20% of the full sized version) bitmaps would not resemble circles as they now do in my current avatar (due to dithering while resizing in ImageReady).
I would most likely post that separately from the finished game, if I do make that version
Personally I like the idea of having a miniature sized version of my games, specifically for creating an avatar suitable for use on the forum. :azn:
Replaced the clunky code for the background and foreground painting...
.elseif uMsg == WM_PAINT
invoke BeginPaint, hWin, addr ps
mov hDC, eax
invoke GetClientRect, hWin, addr rct
invoke CreateCompatibleDC, hDC
mov mDC, eax
invoke CreateCompatibleBitmap, hDC, rct.right, rct.bottom
mov hBmp, eax
invoke SelectObject, mDC, hBmp
mov hBmp_old, eax
invoke drawback, hWin, mDC
invoke drawanim, hWin, mDC
invoke drawboard, hWin, mDC
invoke drawfore, hWin, mDC
invoke BitBlt, hDC, 0, 0, rct.right, rct.bottom, mDC, 0, 0, SRCCOPY
invoke SelectObject, mDC, hBmp_old
invoke DeleteObject, hBmp
invoke DeleteDC, mDC
invoke EndPaint, hWin, addr ps
drawback procedure to draw the background, and drawfore procedure to draw the foreground
drawback proc hWin:dword, mDC:dword
local pDC:dword, rct:RECT, hBrush:dword, hBmp1:dword, hBmp_old1:dword
invoke CreateCompatibleDC, mDC
mov pDC, eax
invoke GetClientRect, hWin, addr rct
invoke CreateCompatibleBitmap, mDC, rct.right, rct.bottom
mov hBmp1, eax
invoke CreateSolidBrush, 00FF7F3Fh
mov hBrush, eax
invoke FillRect, mDC, addr rct, hBrush
invoke DeleteObject, hBrush
invoke SelectObject, pDC, hBack
invoke StretchBlt, mDC, 40, 40, 560, 560, pDC, 0, 0, 1, 1, SRCCOPY
invoke SelectObject, pDC, hBmp_old1
invoke DeleteObject, hBmp1
invoke DeleteDC, pDC
ret
drawback endp
foreblit proc mDC:dword, xx:dword, yy:dword, pDC:dword
push esi
push edi
push ebx
push edx
push ecx
mov eax, 80
xor ecx, ecx
invoke TransparentBlt, mDC, xx, yy, eax, eax, pDC, ecx, ecx, eax, eax, 00FF00FFh
pop ecx
pop edx
pop ebx
pop edi
pop esi
ret
foreblit endp
drawfore proc hWin:dword, mDC:dword
local pDC:dword, rct:RECT, hBrush:dword, hBmp1:dword, hBmp_old1:dword
push esi
push edi
push ebx
push edx
push ecx
invoke CreateCompatibleDC, mDC
mov pDC, eax
invoke GetClientRect, hWin, addr rct
invoke CreateCompatibleBitmap, mDC, rct.right, rct.bottom
mov hBmp1, eax
invoke SelectObject, pDC, hBmp1
mov hBmp_old1, eax
invoke SelectObject, pDC, hFore
lea esi, x1
lea edi, y2
xor edx, edx
top1:
xor ecx, ecx
@@:
mov eax, [esi+ecx*4]
mov ebx, [edi+edx*4]
invoke foreblit, mDC, eax, ebx, pDC
inc ecx
cmp ecx, 7
jb @b
inc edx
cmp edx, 6
jnz top1
invoke SelectObject, pDC, hBmp_old1
invoke DeleteObject, hBmp1
invoke DeleteDC, pDC
pop ecx
pop edx
pop ebx
pop edi
pop esi
ret
drawfore endp
Had some issues when trying to only use FillRect to fill - first the client area of the dialog box - then fill the game background after adjusting the RECT structure. The results were not good. I checked and rechecked the RECT structure dimensions, used GetClientRect to refill the RECT structure with the client rectangle for subsequent blitting operations... to no avail. Wasted at least an hour...
In order to not waste any more time, I opted to shrink the bitmap previously used from 80x80 to 1x1 and used StretchBlt to fill the desired rectangle (game board background) with that instead. Weird.
I am pretty certain I had drawn rectangles on top of previously drawn rectangles before in an unrelated project.
executable only, in the attachment
I have cleaned up the rest of the previously untidy WM_PAINT related code. :biggrin:
Commenting still a bit sparse for now, trying to get the rest of the code tidied up a first, and ready for the masses. :tongue:
Next: Is to make the WM_TIMER and WM_LBUTTONUP code somewhat cleaner and easier to follow.
Source code included in the attachment below.
A little more cleanup in the source, moving code out of WM_TIMER into a seperate procedure, as well as moving code out of WM_LBUTTONUP into a separate procedure as well. Added some more commenting. Removed some unnecessary code.
I will rewrite the code for the timers and left mouse clicks at some point, as time permits. Although that code works as expected as is, it is lengthy and rather cumbersome.
I will be integrating slick new graphics into the program, if there are no issues with the proposed code.
(https://i.postimg.cc/VNdhdRYG/untitled.png)
There is a demo here (https://masm32.com/board/index.php?msg=137981) of how it will look when animating... :eusa_dance:
New example using the nice png graphics.
(https://i.postimg.cc/dtxSwMKk/untitled.png)
As before left click for red piece, right click for blue.
Let me know of any issues with the new graphics, i.e., flickering, etc. During my own testing, I had not encountered any issues thus far. I should be able to finish up the game very soon, indeed. :eusa_dance:
Perfect, no flicker :thumbsup:
While I cannot guarantee it will happen, I plan on finishing the code to the extent that the game will be playable by the end of this coming weekend.
There will undoubtedly still be bits of code that need some reworking (the overly lengthy code for the left mouse button and the timers - both could use loops to minimize the code, for instance).
But as I have other projects that I would like to get to, I really want to get this game finished to a playable state. :smiley: Even if that means putting off some improvements to the game graphics and image loading, and other misc. items. I can always revisit those changes at a later time.
So much to do... So little time... :eusa_boohoo: