New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

support utf8 debug text #1244

Closed
wants to merge 1 commit into
base: master
from

Conversation

Projects
None yet
2 participants
@cloudwu
Contributor

cloudwu commented Sep 29, 2017

This patch introduced 7445 unicode (chinese) 16x16 glyph. And let bgfx::dbgTextPrintf support utf8 text.

If a character with code point > 127 , it will use 2 video memory slots . The first one's attribute is always 0xff for this case, and the second is the real one. So we can show the Chinese glyph (or more unicode glyph).

Turn off the macro UNICODE_GLYPH_SUPPORT can disable this feature to save about 2M memory for larger font texture.

@bkaradzic

This comment has been minimized.

Show comment
Hide comment
@bkaradzic

bkaradzic Sep 29, 2017

Owner

Intent of this system is to have rudimentary text support as in VGA text color mode: https://en.wikipedia.org/wiki/VGA-compatible_text_mode

For more complex use cases you should just write debug text support on the top of the library.

Owner

bkaradzic commented Sep 29, 2017

Intent of this system is to have rudimentary text support as in VGA text color mode: https://en.wikipedia.org/wiki/VGA-compatible_text_mode

For more complex use cases you should just write debug text support on the top of the library.

@bkaradzic bkaradzic closed this Sep 29, 2017

@bkaradzic

This comment has been minimized.

Show comment
Hide comment
@bkaradzic

bkaradzic Sep 29, 2017

Owner

Anyhow if you have idea how Chinese text worked back in days of VGA and codepages, I could add ability to replace debug font texture and set codepage. In that case translation UTF8 -> codepage translation could happen inside renderer.

Owner

bkaradzic commented Sep 29, 2017

Anyhow if you have idea how Chinese text worked back in days of VGA and codepages, I could add ability to replace debug font texture and set codepage. In that case translation UTF8 -> codepage translation could happen inside renderer.

@cloudwu

This comment has been minimized.

Show comment
Hide comment
@cloudwu

cloudwu Sep 30, 2017

Contributor

I don't think it breaks the compatibility of VGA text color mode, because bgfx::dbgTextImage works fine like before, and it doesn't change the VGA screen buffer structure.

I know I use a small trick to support double-wide glyph , but it's a common way for CJK (Chinese Japanese Korean) environment in DOS days 20 years ago. The CJK character need at least 2 bytes to encode one code point and the glyph is double width of ascii glyph.

This trick use one seldom use attribute byte to indicate the following 2 characters should be consider as one. I choose 0xff as this special attribute, because it always show a white box for any character now, and we can use other way to get the same white box .

bgfx::dbgTextPrintf(1, 0, 0xff, "A");  // a white box
bgfx::dbgTextPrintf(0, 0, 0xf0, " ");  // the same white box

ps. We can support utf8 string for bgfx::dbgTextPrintf at first (IMHO) ? Converting the unicode to CP 437 ( https://en.wikipedia.org/wiki/Code_page_437 ) in this API may be better to use.

Contributor

cloudwu commented Sep 30, 2017

I don't think it breaks the compatibility of VGA text color mode, because bgfx::dbgTextImage works fine like before, and it doesn't change the VGA screen buffer structure.

I know I use a small trick to support double-wide glyph , but it's a common way for CJK (Chinese Japanese Korean) environment in DOS days 20 years ago. The CJK character need at least 2 bytes to encode one code point and the glyph is double width of ascii glyph.

This trick use one seldom use attribute byte to indicate the following 2 characters should be consider as one. I choose 0xff as this special attribute, because it always show a white box for any character now, and we can use other way to get the same white box .

bgfx::dbgTextPrintf(1, 0, 0xff, "A");  // a white box
bgfx::dbgTextPrintf(0, 0, 0xf0, " ");  // the same white box

ps. We can support utf8 string for bgfx::dbgTextPrintf at first (IMHO) ? Converting the unicode to CP 437 ( https://en.wikipedia.org/wiki/Code_page_437 ) in this API may be better to use.

@cloudwu

This comment has been minimized.

Show comment
Hide comment
@cloudwu

cloudwu Sep 30, 2017

Contributor

There is a small example modified from example-00-helloworld .

bgfx::dbgTextImage(
	  bx::uint16_max(uint16_t(m_width /2/8 ), 20)-20
	, bx::uint16_max(uint16_t(m_height/2/16),  6)-6
	, 40
	, 12
	, s_logo
	, 160
);

bgfx::dbgTextPrintf(
	bx::uint16_max(uint16_t(m_width /2/8 ), 20)-20,
	bx::uint16_max(uint16_t(m_height/2/16) ,  6) - 7, 
	0x0f, "\x1b[9;m你\x1b[10;m好\x1b[11;m,\x1b[12;m世\x1b[13;m界\x1b[14;m。");

image

Contributor

cloudwu commented Sep 30, 2017

There is a small example modified from example-00-helloworld .

bgfx::dbgTextImage(
	  bx::uint16_max(uint16_t(m_width /2/8 ), 20)-20
	, bx::uint16_max(uint16_t(m_height/2/16),  6)-6
	, 40
	, 12
	, s_logo
	, 160
);

bgfx::dbgTextPrintf(
	bx::uint16_max(uint16_t(m_width /2/8 ), 20)-20,
	bx::uint16_max(uint16_t(m_height/2/16) ,  6) - 7, 
	0x0f, "\x1b[9;m你\x1b[10;m好\x1b[11;m,\x1b[12;m世\x1b[13;m界\x1b[14;m。");

image

@cloudwu

This comment has been minimized.

Show comment
Hide comment
@cloudwu

cloudwu Sep 30, 2017

Contributor

The point is we need a small trick to indicate there is a double wide glyph to render. 2 slots in VGA text buffer have 4 bytes totally. We need 2 bytes for code point and 1 bytes for attribute in this case . So we can choose a special byte to classify .

Attribute 0xff is one of the choices, another choice is using character 0xff in the first slot of text buffer. Because code point 0xff of code page 437 is the same with 32 (space) , it seldoms to use .

In old DOS days, we use VGA graphics mode to emulate VGA text mode to support CJK . With these tricks , even the software doesn't design for CJK can render the double wide glyph correctly.

Contributor

cloudwu commented Sep 30, 2017

The point is we need a small trick to indicate there is a double wide glyph to render. 2 slots in VGA text buffer have 4 bytes totally. We need 2 bytes for code point and 1 bytes for attribute in this case . So we can choose a special byte to classify .

Attribute 0xff is one of the choices, another choice is using character 0xff in the first slot of text buffer. Because code point 0xff of code page 437 is the same with 32 (space) , it seldoms to use .

In old DOS days, we use VGA graphics mode to emulate VGA text mode to support CJK . With these tricks , even the software doesn't design for CJK can render the double wide glyph correctly.

@bkaradzic

This comment has been minimized.

Show comment
Hide comment
@bkaradzic

bkaradzic Sep 30, 2017

Owner

ps. We can support utf8 string for bgfx::dbgTextPrintf at first (IMHO) ? Converting the
unicode to CP 437 ( https://en.wikipedia.org/wiki/Code_page_437 ) in this API may be better to use.

Yes, this is good start.

Owner

bkaradzic commented Sep 30, 2017

ps. We can support utf8 string for bgfx::dbgTextPrintf at first (IMHO) ? Converting the
unicode to CP 437 ( https://en.wikipedia.org/wiki/Code_page_437 ) in this API may be better to use.

Yes, this is good start.

@bkaradzic

This comment has been minimized.

Show comment
Hide comment
@bkaradzic

bkaradzic Sep 30, 2017

Owner

Actually it's not big deal if we change underlying buffer to be attribute + uint16_t for example. What I want to avoid is ifdefery, specific for CJK. Basically if it's easy to support it should be always available. VGA inspired is to minimize features.

Owner

bkaradzic commented Sep 30, 2017

Actually it's not big deal if we change underlying buffer to be attribute + uint16_t for example. What I want to avoid is ifdefery, specific for CJK. Basically if it's easy to support it should be always available. VGA inspired is to minimize features.

@cloudwu

This comment has been minimized.

Show comment
Hide comment
@cloudwu

cloudwu Sep 30, 2017

Contributor

attribute + uint16_t sounds better, but it may change the behavior of bgfx::dbgTextImage . We need a different data source, or add a new text image data type / new api for uint16_t codepoint.

Contributor

cloudwu commented Sep 30, 2017

attribute + uint16_t sounds better, but it may change the behavior of bgfx::dbgTextImage . We need a different data source, or add a new text image data type / new api for uint16_t codepoint.

@bkaradzic

This comment has been minimized.

Show comment
Hide comment
@bkaradzic

bkaradzic Sep 30, 2017

Owner

but it may change the behavior of bgfx::dbgTextImage

It would just do conversion...

Owner

bkaradzic commented Sep 30, 2017

but it may change the behavior of bgfx::dbgTextImage

It would just do conversion...

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment