This is a post for every iPhone/iPad developer. Every day, we try to use “best practices” when writing code, and building apps.
Categories
Month: November 2013
OpenGL Texturing has been re-invented multiple times, with different hardware implementations each time. As a developer, you need to be comfortable with all of them.
Apple invented “bundles” and “frameworks” to greatly improve the ease of development and maintenance of OS X projects. They are really good.
But Apple modified Xcode to try and stop people using these on iOS. I don’t know why.
Today I delved into this to find out the correct, working, simplest/easiest solution…
Categories
Server overloaded by moronic spammers
I got an email this morning noting that my blog was taking “forever” to load a single post.
A quick check, and I found that it was running 70x overloaded, due to a vast number of spammers trying (and, in every case, failing) to submit wordpress comment-spam.
No spams will get through, because wordpress is set to only allow comments from people who’ve commented before – that’s a chicken-egg scenario that spammers can’t escape. (I wonder. Would the scourge that is “wordpress comment-spam” be reduced easily, instantly if Automattic (the people that make WordPress) had this as the default?).
…but at 2,000+ spammers a day, it was bringing the virtual site down. Server was fine, but I had the site limited precisely so that *it* would die instead of the server, in cases like this.
Now we’re going to try something new, since Automattic’s Akismet is pretty much useless these days. Anti-Spam, let’s see how you do…
I’ve recently been working with a group of teenagers, helping them learn to program for themselves, and build their own iPhone/iPad/Android games. So, when Cengage offered me a review copy of this book, I thought it would be a good idea to have a look and see if it would be helpful to a similar audience.
This blog isn’t a review site, so I’m going to pull out just the key interesting bits worth mentioning.
What’s the book for?
The blurb on the back cover claims:
- “games that enchant players and stand the test of time [are only made by people who know the] principles of good game design”
- “[this book has] the core theoretical knowledge”
- “math, textures, … geometry, … lighting, sound”
- “all your questions will be answered”
This book has nothing on game-design. There are few filler sections on this, but you’d get more detail by typing “game design blog” into Google and picking a link at random.
“Core theoretical knowledge” of game development is a big topic. If most people tried to write it down, I’d expect a thick, heavy tome. Thankfully, this book doesn’t try that. I’d say it aims for approximately 25% of the core knowledge, which is a reasonable compromise. Better to do some of it well, than do all of it badly.
On those named details:
- “math” can’t be covered in a book unless that’s 50% of your content. This book has basic vector-math (really basic: not enough for game development), and quickly moves on.
- “textures” skips all the bits about implementing textures, and instead focusses on issues to do with authoring simple 2D textures.
- “geometry” only talks about things that 3D artists need to know when making models, it misses out all the things at the engine level, at design time, etc.
- “lighting” is covered well, with a good explanation of deferred lighting (which is one of the major modern issues in lighting and 3D engines). More on this later
- “sound” has basic info on implementing and playing-back sounds in-game.
In conclusion: the blurb on the cover is about 30% accurate. The book covers both more and less than it claims. On the face of it, this looks bad – but I think the book has rather more important/better content than the marketing claims
(this is a post mainly to document some new features and fixes I’ve added to SVGKit version 1.2 today – they are already on the main development branch (currently: 1.x), ready for use)
SVGKit overview, November 2013
While a group of us were cleaning up and improving SVGKit about 2 years ago, I did a quick-n-simple re-architect of the in-memory data structures to split it into three wholly independent sets of source code / classes:
- Parsing an SVG file
- Parsing a legal XML file, with a new conforming DOM parser I wrote from scratch (because SVG Spec requires you to use a DOM parser, and Apple won’t let you use/extend their one on iOS/OSX!)
- Parsing the core SVG spec where it differs from XML-DOM
- Adding a system for user-supplied custom-parsers so that you can parse your custom XML in-line with the SVG (this is a major feature of SVG, but difficult to parse!)
- Rendering an SVG file with pixels on-screen
- Converting in-memory SVG data into Apple’s CALayer rendering format (used on all Apple Operating Systems)
- Optionally converting Apple’s CALayer format into highly-optimized hybrid data that lets you render SVG’s *fast*
- Painstakingly implementing every feature of SVG, from radial gradients to rich text (we’re about 90% complete now, still features left to add – please help!)
- Outputting an SVG file back to disk
- …not supported … until now!
I’ve got a long-running project around rendering 3D Earth in interesting ways. It’s being used in a game project, and some non-game stuff too. Here’s a recent screenshot:
I added a particle system that uses Vector Fields to move the particles based on arbitrary incoming data, and then wraps it round a globe. Yay!:
…and then I increased the size of each particle, and something very strange happened. I wanted to splurge them out to be huge, but
The mysterious Holes Of Doom
… these weird holes appeared in the middle:
WTF? I must have done something stupid. I double checked everything. I removed the textures. I switched from quads to basic tris, with vertex colours … but still, this perfect circle cut out of the center! My vertex and fragment shaders by this point were exactly one line of code!
…I spent ages looking at this, trying to understand what could possibly create “holes” in my geometry. They were obviously holes – you can see through them!
Eventually, tired, and with lots of more important work to do, I gave up, shelved it, went off to do other things. Then today I suddenly realised the problem. I’m sure it’s obvious to most of you, but it’s taken me ages to figure it out.
When a hole is not a hole
And this is what makes it worth posting: the hole is not a hole.
My particles are on a 2D plane, so that I can calculate simple x/y coords from a vector-field. Great. My shader wraps the corners to a sphere. I’m rendering quads / tris like this:
Great. But GL doesn’t “bend” the edges – it draws straight lines between corners. So … when I made my tris larger … the corners were still slightly above the surface of the globe.
…and the EDGES were still slightly above
…but the centers … slightly interesected the globe. And so, of course, the depth-test cut them out. In the diagram below, it looks as if the quad moved closer to the center of the globe – but it hasn’t. The corners are all still the same height above the surface – only the middle has (implicitly) gone “inwards”.
Lesson to self: sometimes, it’s not a triangle-with-a-hole-that-I-can-see-through … instead, it’s a triangle-that-has-a-sphere-poking-through-the-middle
#facepalm