Simple Games - Research and Development

[zedd151]

One thing: Are you creating your fonts with the CLEARTYPE_QUALITY value? That's the way to get the most nicely-rendered text.

Whatever quality used in hutch's "RetFontHandle" procedure in the masm32 library. Hmmm, I'll check on this... a bit later. Thanks for the tip. Iirc, it's probably set to default as most args there... I'll have'ta make my own proc. to test your suggestion. May be other parameters that can be tweaked as well, we'll see...

[NoCforMe]

I'd just do my own CreateFontIndirect() call to make sure I get the options I want. Not difficult, just set up a LOGFONT structure and make the call.

[zedd151]

I'd just do my own CreateFontIndirect() call to make sure I get the options I want. Not difficult, just set up a LOGFONT structure and make the call.

I think that's a case of tom-ay-toes versus tom-ah-toes. You should be able to set params similarly in either. I'll look into it though
In any case it can wait really. Right now all I need is the digits to display, ugly or not... fixing that will come later though. At the moment, busy with other code.

[NoCforMe]

Nope.

Whoever wrote that used one of the poorer quality constants, PROOF_QUALITY. And since it's hard-coded, it's not a parameter you can change without rewriting the function.

Proof that if you really want something done you shouldn't rely on those labor-saving macros and functions. Just roll your own. It's not difficult, and then you know exactly what you're getting.

[zedd151]

I tried this code, the results not visibly any different At least with font "simhei", 48px. I like the style of the digits with that font.

Code: [Select]

    MakeFont proc lpfname:dword, fhgt:dword, fwgt:dword
        invoke CreateFont, fhgt, 0, 0, 0, fwgt, 0, 0, 0,
               HANGEUL_CHARSET, OUT_OUTLINE_PRECIS,
               CLIP_DEFAULT_PRECIS, CLEARTYPE_QUALITY,
               FF_MODERN, lpfname
        ret
    MakeFont endp
I find no advantage in using CreateFontIndirect over CreateFont. The LOGFONT structure has the same parameters as using CreateFont.
This issue is no huge deal breaker, btw. So most likely I will not pursue any other fixes for this at this time. I've got my hands full atm.

[zedd151]

Proof that if you really want something done you shouldn't rely on those labor-saving macros and functions. Just roll your own. It's not difficult, and then you know exactly what you're getting.

I use the occasional macro, and *usually* write my own functions especially if same parameters will be used more often than not. Better than constantly invoking an API with 14 arguments  . That's just too much. 3 arguments makes mor compact code, no line continuation chars needed and no characters spilling into the hole in my monitor screen because the line is toooooooooo looooonnnnnnggggg 

[zedd151]

The simhei font I have been using looks better to me than tahoma which looks similar. That font also displays kind of blocky. I will be "shopping around" the internet for an alternative font. Similar to both those types of sans serif style fonts. If I find one with a slightly thinner stroke, I'll try that. There is a sudoku ipad app that uses a similar font as described (thinner stroke, similar in appearance to the simhei font digits but thinner stroke). If I search in the right place, I'll find it. But that's like a needle in a hay stack.

[zedd151]

Regarding listing the candidates:
Each row has 9 cells, each columns has 9 cells each of 9 boxes has 9 cells. Therefore each cell has 24 other cells that it can 'see'. Inferring that we can disregard one cell in a row, column and box. Because of course a cell will always see itself.

But as a matter of simplicity, it would be easier to have each of those 'lists' have all 9 cells in it. So we don't have to have an offset table specifically for each cell, meaning a hard coded table with 24-27 byte entries for each cell.

My solution is to have predefined lists of 9 bytes in length off the cell offsets for each row, column and box.
We now have 27 - 9 digit lists with the offsets. Already have that in the code btw.

Each cell would have a structure that holds 3 dwords, namely the offsets off the intersecting row, column and box respectively, for a given cell. A lot easier to manage methinks.

At game startup using the structures, we check for the 'candidates' for each cell. A candidate is a number that cannot be 'seen' from a given cell.  Each cell will have a list of up to 9 candidates upon return from that function.

Now each time a player selects an empty cell, the cell gets highlighted indicating the cell is selected. A flag appropriately titled 'selected' will be given the offset of the selected cell.
Then when the player presses a number key (1-9), we check the value of board+selected(selected cell offset)

Then using the 3 pointers in the structure representing address of the row, column and box that the selected cell resides in - we make the candidate list. First we check each row column and box for "1". If NONE of those contains a "1", it means that "1" is a valid candidate and is added to the candidate list associated with the selected cell. We do the same for each digit 1-9.

Now we test to see if the key pressed is a valid candidate, if so we finally place that digit into the game 'board' and flag 'selected' is intialized to -1...Upon painting, the digit is drawn into the selected cell, and highlighting is removed.

For displaying the candidates, the process will be much similar but we will use all of the candidates found for each cell to display them, these candidates are dynamic. Meaning any time a cell is filled the new cell value is effectively removed as a candidate for the associated row, column and box.

All this sounds easy in theory. First I will make the 3 structures for each cell as mentioned. And use this in determining a valid cell value or not. Once that is working will move on to displaying the candidates as well. User selecteble via check box whether to display candidates or not.

Now time to make those structures and test what I have written here...

[NoCforMe]

I find no advantage in using CreateFontIndirect over CreateFont.

Well, there is an advantage, and given your complaint about overly-long lines because of functions with 14 arguments, you should appreciate it: with CreateFontIndirect() you stuff all those parameters into a LOGFONT structure one by one, then just pass a pointer to that structure to the function. Does exactly the same thing, but you avoid those horrible long lines (I don't like those either). Plus you can see what each one means, which is harder to discern with a long line with 27 parameters

[zedd151]

ok thank you
A procedure with only 3 arguments serves the same purpose. The underlying code only written once, same as with log font.
Tom-ayy-toes and Tom-ahh-toes. 

[NoCforMe]

Sure, that works, until you need a font that's bold. Or italic. Or something else, and now you're up to 5-6-7 parameters.

[zedd151]

Quite right. However, since I rarely if ever need bold or italic fonts in my code, my procedure with 3 arguments is just fine and dandy. I can tell you're not a big fan of the Masm32 SDK library, I get that. You alluded to that with your "whoever wrote that used one of the poorer quality constants, PROOF_QUALITY" remark in reply #183. But this isn't the time or place for that discussion, nor in my purview to explain the how or why it was coded like that. No 'coding style' wars here please. This is the Game Development sub forum. A place for fun topics. 

[NoCforMe]

I can tell you're not a big fan of the Masm32 SDK library, I get that.

Let me put it this way: I'm glad they're there for those who want to use them, especially those who are just learning assembler. I just don't see a need to use them myself. I like to "roll my own", and have my own library, plus a lot of my own code that I copy and paste from all the time.

[zedd151]

I like to "roll my own", and have my own library, plus a lot of my own code that I copy and paste from all the time.

Fair enough. I'll consider this a truce.    I use the masm32 library code a lot of times only as a template from which I customize. It is well tested code, and works - albeit some could use customizations, which I do as mentioned. Maybe that remark I mentioned was not as sideways as it first appeared to be. I think that win32.hlp was used as a reference in writing that procedure RetFontHandle, which lists there the highest quality as "PROOF_QUALITY".
FYI:

fdwQuality

Specifies the output quality. The output quality defines how carefully GDI must attempt to match the logical-font attributes to those of an actual physical font. It can be one of the following values:

Value   Meaning
DEFAULT_QUALITY   Appearance of the font does not matter.

DRAFT_QUALITY     Appearance of the font is less important than when the PROOF_QUALITY value is used. For GDI raster fonts, scaling is enabled, which means that more font sizes are available, but the quality may be lower. Bold, italic, underline, and strikeout fonts are synthesized if necessary.

PROOF_QUALITY     Character quality of the font is more important than exact matching of the logical-font attributes. For GDI raster fonts, scaling is disabled and the font closest in size is chosen. Although the chosen font size may not be mapped exactly when PROOF_QUALITY is used, the quality of the font is high and there is no distortion of appearance. Bold, italic, underline, and strikeout fonts are synthesized if necessary.

in its entirety there for CreateFont.fdwQuality in win32.hlp.
Probably meant for regular GDI.dll, not GDI32.dll apparently as win32.hlp is as old as the hills.

[NoCforMe]

That code is definitely showing its age.

BTW, I'm not admonishing you to not use whatever resources you like, just saying that if you do use them, be aware of the possible drawbacks.