@Vega I will try include your changes in the next update — It sounds like you took care of all the bits I didn’t attempt.
@Simeon, further on the subject of the font picker: is there any practical benefit in the picker listing ‘Emoji’ (AppleColorEmoji) and ‘Zapf Dingbats TC’ (ZapfDingbatsITC) when those fonts have no interesting characters in the 0-255 range?
Those slots in the picker might be used for one of the iOS fonts with interesting characters in the 0-255 range, such as “BradleyHandITCTT-Bold”, “Chalkduster”, “DBLCDTempBlack” or “PartyLetPlain”.
You can use the Emoji fonts by enabling Emoji on the iPad keyboard. That way you can actually type little pictures into your code, and have them render.
A number of people have done this for their games, given the wide variety of colourful symbols.
Zapf is probably not as useful since there is no way to enable the extended characters on the keyboard outside of copy+paste.
I have been loafing around here, helping people as much as possible, testing things, and learning the language because I didn’t really have any good ideas for a new game I’d like to make. While working on updating the Brickout example, I started to get a bit of an idea for a game and it has grown into a full-fledged game plan today.
It really has little to do with Brickout, other than it does use a small ball (or several) bouncing around. I guess you never know what might inspire you or help your brain make a crucial connection.
Someday, maybe I will sell 10k copies and look back remembering that time I worked on the Brickout game and suddenly had an epiphany 
Epiphanies are the best. Looking forward to seeing your game.
@Andrew_Stacey I think what sets the iPad apart as a controller is that you can directly touch the things you want to interact with. Creates a more direct connection between the player and the game elements.
Tilt controls are interesting too, though I prefer direct-touch control where possible. I like tilt controls in Labyrinth-style games.
@Simeon, thank you for explaining about the iPad keyboards and emoji - I did not know that. I also did not appreciate that the print() and text() functions implemented in Codea were Unicode-aware (at least, I assume the multiple bytes for each character are its Unicode).
On the face of it, none of that would require (or be helped) by AppleColorEmoji being included in the font picker. However, my experiments suggest that text() behaves oddly at large - but not small - fontSize if the font is not Emoji. For example:
(Edit: It looks like my attempt to copy-paste code with emoji characters has not worked. I will will try to explain what my experiment was in another way.
Replace the text ‘[emoji characters]’ below with six emoji characters entered using the emoji iPad keyboard.)
function setup()
str = "emoji: [emoji characters]" -- Entered with emoji iPad keyboard
print(#str, str) -- print() is Unicode-aware
-- Multiple bytes for each emoji character
for i = 1, #str do
local c = str:byte(i)
print (i, c, string.char(c))
end
fill(255)
end
function draw()
background(0)
fontSize(32 * (1.25 + math.sin(ElapsedTime)))
font("ArialMT")
text(str, WIDTH/2, HEIGHT*3/4) -- Unicode-aware, but emoji not scaled symmetrically
font("AppleColorEmoji")
text(str, WIDTH/2, HEIGHT/4) -- Unicode-aware, AND emoji are scaled
end
Simeon, you wouldn’t say that if you’d seen my kids playing with my iPad. Maybe your compromise of an option at the start is best. I agree with Vega that a fullscreen game is better with the instructions at start-up - I’ll post a variant of yours a bit later to show.
Re text: yes, unicode works just fine so long as the font supports it (I wrote a crude font-chart project to see what the different fonts support, happy to share as always). You can get arbitrary unicode characters by passing the necessary numbers to string.char(). You need to take the decimal representation of the unicode entry. I have a library that does all of this.
Okay, here’s Brickout with my modifications. Notably:
- Tilt controls. It takes a bit to get used to, and if you find it over/under-sensitive then tweak the parameter (currently set to 1600).
- Fullscreen. So the instructions are shown at start-up and then disappear for evermore.
- Collision Testing. Not sure if this will actually produce an improvement, but when testing the bat it tests the vertical first as that’s most likely to fail, and for the blocks then it works out which block position the ball is in and tests only the neighbouring blocks.
Code at http://www.math.ntnu.no/~stacey/documents/Codea/Brickout.lua
Hello @Andrew_Stacey. Thank you for the pointer to your UTF-8 library.
In function utf8dec(a), I think the line:
elseif a < 1114112 then -- 0x110000 = 2^20 + 2^16
should be:
elseif a < 2097152 then -- 0x200000 = 2^21; (21 = 3 + 6 + 6 + 6)
Looks right to me. Playing with numbers, my guess is that the error stems from the fact that 1114112 = 0x110000 so at some point I’ve obviously gotten confused with binary and hexadecimal. Shows how often I’ve used characters with such high unicode numbers!
(And hooray for libraries: now I just have to change one number in only one file!)
Thanks for the fix. Are there any more of my files I can interest you in? You seem to have a good eye for mistakes!