Simple Games - Research and Development

[NoCforMe]

hiding one, means also showing the other (cells or candidates). Either a 48px size char (for cell) or up to 9 - size 12px? chars (for candidates) So a simple space will not be a solution for this.

I don't see why not; a 48 pt. space will surely cover a 48 pt. character (or two will cover the widest possible character, a 'W'). Or to show something else, just overwrite what's there now.

[zedd151]

... just overwrite what's there now.

That's what the current plan is. I haven't gotten that far yet though.

[zedd151]

l just had a profound though. Up until this point, I had been dealing with each candidate digit as a separate entity. Suppose however I deal with the candidates as a single entity that has 9 characters? DrawText only once for up to 9 chars example:


*********
* 1  2  3  *
* 4  5  6  *
* 7  8  9  *
*********


What remains then, is to color the background for one digit there. That should be a little easier.

I hadn't though about spaces at all, ever since I was using bitmaps. NoCforMe mentioned spaces. I was thinking "why, oh why do I need spaces"? Anyway I took a short nap after supper. When I woke up the exchanges from earlier were still on my mind. Needless to say a somewhat daunting task might be able to be reduced codewise. I will have to make some tests, to check the feasibility of this 'new' approach to displaying the candidates.


I really don't want to use a mono space font like courier, consolata, or fixedsys. But if needed can be accommodated. The test will be to highlight a square (okay a rect[angle]) behind a given digit. Can a font have a size (for 3x3 chars) that would be symmetrical in the cell? Further experiments and testing needed. Using DrawText - would a line of characters automatically wrap if it doesn't fully fit on a single line? Does it need carriage return, line feed? More questions    I will be testing all of this later.

[NoCforMe]

You might be overthinking this a little.

If you're drawing text (using either TextOut() or DrawText() ), writing a space character (20h) over any character will obliterate that character, unless the character happens to wider than a space character, which is why I suggested writing two spaces, which will wipe out any character, guaranteed.

DrawText() recognizes carriage returns and line feeds, but you'd have to set the line spacing exactly for the 2nd and 3rd lines to land where you want them. Probably easier to just position each character individually, using (x,y) positioning. But that's not hard to do. For each "cell", keep 9 pairs of coordinates, one pair for each character position. I'd suggest putting them in a data structure, for easier access.

[zedd151]

In one version of these sudoku experiments, I was using RECT structures throughout the game (one RECT structure per cell). That version only filled in a structure with values if a cell was selected and returned the cell index and address to the filled structure.
Suppose we either start with all structures pre-initialized in data, or initialize all of them at startup?


I think that would be an advantage rather than using (x, y, w, h) in some places and (address RECT) in others, constantly needing to convert one form to the other. Some of that code had been reused from the bitmap version of the game. Any function that needs (x, y, w, h) values i.e. BitBlt, et.al., can be easily accommodated from within a procedure for uniformity in using RECT structures throughout. Any thoughts?

[NoCforMe]

Well, yeah, probably better to standardize on how you store those numbers. If everything is in RECT format you can block-copy one rectangle to another (create your own memcpy() function, piece of cake).

[zedd151]

You might be overthinking this a little

Ya think??

Yes, I guess I'm pretty much consumed by this. I was posting the above as you were replying. I don't write text directly on top of text. Always blank it out by FillRect first. If that makes sense.

I should probably take a break from this and finish the 'Tic Tac Toe' game in the mean time.

[NoCforMe]

I don't write text directly on top of text. Always blank it out by FillRect first. If that makes sense.

Not really. Not necessary; text overwrites text. Try it.

[TimoVJL]

Less flickering, if in WM_PAINT is only BitBlt of bitmap and all other drawing happens outside of it, only when something changes.
One function draw grid to bitmap and other functions modify bitmap later, when needed.

EDIT
What does the CS_OWNDC class style do?

[jj2007]

Given that you use a mem DC anyway, you could use a single FillRect to clear the whole screen, then fill the cells one by one e.g. with a proc like this:

Code: [Select]

.data?
TheRects RECT 16 dup(<>)

.code
FillRectByIndex proc hDC, index, brush
  mov ecx, index
  imul ecx, ecx, RECT
  lea eax, TheRects[ecx]
  invoke FillRect, hDC, eax, brush
  ret
FillRectByIndex endp

[zedd151]

Well, okay now. New gui design. Again lol.
1. Using Predefined RECT structures for each cell. Those structures will be uninitialized in .data? reducing exe size a little bit. Will be initialized in WM_CREATE. Candidates will use those structures & x/y coord for position relative to structures dimensions.
2. Uses BitBlt & company    *should* help reduce, possibly eliminate flicker for show/hide candidates.
3. Use procedures for various drawing tasks (keeps WM_Paint less cluttered, and WndProc as well)
4. Draw to mem DC, rather than main window DC - will be BitBlt to hDC when return to WM_PAINT handler.
5. Use flags for digit highlighting color, selected cell color and show/hide candidates.
6. Add the other controls, check box and a pair of radio buttons and button for restore candidates.
7. Event processing. (Mouse clicks, button presses, check box, etc.)


I think I covered everything.
I have part of that already coded, just need to add the bits that are not there just yet and convert some code to be used with the RECT sutures. This should go pretty quickly as I have some bits of code already for most of the functions needed. Some needs conversion or to be rewritten. Now let's get cracking!   

I could probably use some of this in the unfinished Tic Tac Toe. 


Side note: Since this project has gone through so many iterations and changes it is anything but "Simple" so not really a "Simple Game", besides Angus Johnson (of Resource Hacker fame) already has 'Simple Sudoku' taken. 

[zedd151]

Slow and steady progress...
Test version 8
Start of the gooey code...

[jj2007]

It works, but try moving a small window over yours:

a) you have a massive Gdi leak (see Gdi objects in Task Manager)
b) it won't repaint completely (but I don't know why)

Check the attachment: for dcOnce=1, no more leak.

[zedd151]

It works, but try moving a small window over yours:

I have not experienced that effect.
zip a screenshot so I can see what you are talking about.
Minimize/maximize the window also, everything paints fine here.
Drag another window over it also fine.


Gdi in TaskMgr??? I don't see that in Task Manager.

[jj2007]

It works, but try moving a small window over yours:

I have not experienced that effect.
zip a screenshot so I can see what you are talking about.
Minimize/maximize the window also, everything paints fine here.
Drag another window over it also fine.

See below, after moving the Alarm clock window over yours. You can use the Windows calculator instead, but it's less evident.

Gdi in TaskMgr??? I don't see that in Task Manager.

You need to activate the respective column in the processes tab (this is Win7, I don't have a Win10 machine open in this moment).