flat assembler
Message board for the users of flat assembler.
![]() |
Author |
|
vivik 09 Jun 2018, 14:56
I'm making a text editor, in directdraw, I hope it will be faster than gdi, (and I'm planning to make a game anyway). Yet I'm still using gdi for drawing text, for fonts. I'm doing ->GetDC(), then DrawTextW (though maybe I should be using TextOut), then ->ReleaseDC().
What do you think, will it worth it to cache every character in a separate directdraw surface? Just so that I have to call gdi as rarely as possible, and copy characters from that surface instead? Or DrawTextW is fast enough? I will probably use monospace font, I'm used to it anyway, and I don't have to remember width of every individual character. Yet I want asian characters to be bigger, since they have more detail each. This means, I will draw latin letters on a grid of one size, and asian on a grid of a bigger size. So, two separate font caches for latin and asian. Looks like gdi already has some sort of caching for font: http://download.sr-support.com/dispdoc/graphics_using_gdi.html >Drawing of fonts may be slower when a character is drawn for the first time in a new font. Also on speed of text drawing: https://theartofdev.com/2013/08/12/the-wonders-of-text-rendering-and-gdi/ |
|||
![]() |
|
vivik 11 Jun 2018, 15:26
Hm.
Code: //int dx[2]; int dx; int fit; SIZE the_size; GetTextExtentExPointW(dc, L"WWWWWWWW", 8, -1, &fit, &dx, &the_size); Docs https://msdn.microsoft.com/en-us/library/windows/desktop/dd144935(v=vs.85).aspx say that alpDx is a pointer to an array, yet my visual studio says it's a LPINT. Maybe I should edit headers? I can see that it modifies more memory than it should. This is what headers contain: Code: WINGDIAPI BOOL APIENTRY GetTextExtentExPointW( __in HDC hdc, __in_ecount(cchString) LPCWSTR lpszString, __in int cchString, __in int nMaxExtent, __out_opt LPINT lpnFit, __out_ecount_part_opt (cchString, *lpnFit) LPINT lpnDx, __out LPSIZE lpSize ); Edit: nevermind Code: GetTextExtentExPointW(dc, L"WWWWWWWW", 8, -1, &fit, &dx[0], &the_size); |
|||
![]() |
|
revolution 12 Jun 2018, 07:28
vivik wrote: 0x0044005c, ![]() |
|||
![]() |
|
vivik 12 Jun 2018, 14:22
I'd watch that movie.
Didn't check return value, it was zero, the function was falling. My head doesn't work. Hm, fails even if I'll change "Courier New" to "MS PGothic" and DEFAULT_CHARSET to SHIFTJIS_CHARSET in CreateFont. |
|||
![]() |
|
vivik 12 Jun 2018, 16:15
This worked though.
ABC abc; GetCharABCWidthsW(dc, L'薔', L'薔', &abc); abc.abcA == 0 abc.abcB == 13 abc.abcA == 1 |
|||
![]() |
|
vivik 12 Jun 2018, 18:45
Something is wrong. I'm told that L'薔' and L'l' have the same width of 7, yet asian character is obliviously wider when printed.
Code: ABC abc; GetCharABCWidthsW(dc, L'薔', L'薔', &abc); GetCharABCWidthsW(dc, L'l', L'l', &abc); Code: ExtTextOutW(dc, 0, 0, 0, //fuOptions 0, //lprc L"薔薇薔薇薔薇", 6, 0 //lpDx ); ExtTextOutW(dc, 0, 15, 0, //fuOptions 0, //lprc L"sususu", 6, 0 //lpDx ); Edit: that's if I specify DEFAULT_CHARSET, with SHIFTJIS_CHARSET 薔 is 14 and l is 2 |
|||
![]() |
|
tthsqe 12 Jun 2018, 22:47
Hmm interesting. I am making a 2d text editor and simply copying from prerendered bitmaps. That obviouly doesnt give subpixel rendering...
|
|||
![]() |
|
vivik 16 Jun 2018, 06:59
res = GetTextExtentExPointW(dc, L"薔薇薔薇薔薇薔薇", 8, 0x1000, &fit, &dx[0], &the_size);
This worked. Notice 0x1000 instead of -1. So, for font with height 14, kanji has width 14 and latin has width 7. |
|||
![]() |
|
< Last Thread | Next Thread > |
Forum Rules:
|
Copyright © 1999-2025, Tomasz Grysztar. Also on GitHub, YouTube.
Website powered by rwasa.