--载入字体文件
--Load Font files
function love.load()
local f = love.graphics.newFont("fonts/simkai.ttf", 16)
love.graphics.setFont(f)
end
--载入主界面
--load MainTitle files
function love.load()
maintitle = love.graphics.newImage("images/maintitle.jpg")
end
--主界面显示
--Show MainTitle
function love.draw()
love.graphics.draw(maintitle, 0, 0)
love.graphics.print("Hello World", 400, 300)
--鼠标坐标
-- Gets the x- and y-position of the mouse.
local x, y = love.mouse.getPosition()
-- Draws the position on screen.
--显示鼠标坐标
love.graphics.print("The Mouse is at (" .. x .. "," .. y .. ")", 50, 50)
end
I come from China, just contact with Love, but it does not support Chinese font. Will it do to support Chinese characters on it? UniCode???
For example, display Chinese characters as HGE, HGE does not support the official version, was so that he supported
Wow, that's quite cool, I have never thought about giving comments using 汉字.
There are at least 3 interpretation of support:
Output Support
I assume that you want to print Chinese characters in your program. I don't really know if that's already handled by LÖVE (I might miss the feature), but the Lua-users Wiki indicates that the feature is not provided per se:
Lua-users Wiki wrote:===UNICODE LUA PROGRAM===
Literal Unicode strings can appear in your lua programs. Either a UTF-8 encoded string can appear directly with 8-bit characters or you can use the \ddd syntax (note that ddd is a decimal number, unlike some other languages). However, there is no facility for encoding multi-octet sequences (such as \U+20B4); you would need to either manually encode them to UTF-8, or insert individual octets in the correct big-endian/little-endian order (for UTF-16 or UTF-32).
So, no, Lua couldn't handle multi-octet unicode; it must be crafted manually. Btw, is there a method to directly access a particular glyph in a loaded font?
Input Support
Regarding unicode input, the love.keypressed(key, unicode) captures the unicode of the pressed key. The problem is that (most of) the chinese character input method is based on keys sequence such as in pinyin method, ['a'+'i'+'space'+'return'] would generate a single 爱. This generated character somehow is not thrown to the love.keypressed() callback (the printed character is not changed). I haven't found what data is returned by the IME to the active application. Anyone?
function love.load() u = 0; end;
function love.draw() love.graphics.print(tostring(u), 30, 30); end;
function love.keypressed(key, unicode) u = unicode; end;
In-Code Support
Regarding the unicode characters for identifier
Lua-users Wiki wrote:===UNICODE LUA PROGRAM===[cont'd]
Unless you are using an operating system in which a char is more than eight bits wide, you will not be able to use arbitrary Unicode characters in Lua identifers (for the names of variables and so on). You may be able to use eight-bit characters outside of the ANSI range. Lua uses the C functions isalpha and isalnum to identify valid characters in identifiers, so it will depend on the current locale. To be honest, using characters outside of the ANSI range in Lua identifiers is not a good idea, since your programs will not compile in the standard C locale.
So, in short, I think you have to work some code for Chinese character I/O. Or you could avoid it anyway.
What you can do, if you only have a limited set of characters you need to display, is using an ImageFont. You might need to map them to Latin characters to make it work, although I'm not sure about that.
Robin wrote:What you can do, if you only have a limited set of characters you need to display, is using an ImageFont. You might need to map them to Latin characters to make it work, although I'm not sure about that.
And if you run out of characters... then I guess the second best option would be to render all the text to individual images.
By now I've run into the character set problem, and I'll just say that for my purposes using the ANSI set works fine. However, only some ANSI characters work, no matter what font I set.
For instance, the beyond-ASCII symbols ÷ (division sign) and ¶ (paragraph symbol) display fine. But ‡ (double dagger) shows up as the infamous blank box. Changing fonts does not affect this.
After a little investigation, the only connection I can see is that those first two symbols use low Unicode values which are the same as the ANSI code. The double dagger, Euro sign, etc., are in the ANSI set but use high Unicode values. Does that sort of make sense?
Anyway, will this be a limitation in LÖVE forever and ever and ever?
If all you want is comments with that then you might be able to compile it, as LuaC might be able to handle it. Then LOVE would never have to touch the UTF-8.
Also, did you guys no that Alt+O produces [ l i s t = ] [ / l i s t ]. I was curious if that was how you guys were typing the special O but I accidentally discovered that.
Luiji wrote:Also, did you guys no that Alt+O produces [ l i s t = ] [ / l i s t ]. I was curious if that was how you guys were typing the special O but I accidentally discovered that.
Oh, lol. (By "O", you mean "Shift+O", right? That's what I need to do.)
Other niceties: Alt+Shift+I Alt+Shift+B