I’ve seen a lovely flat shaded rendering style yesterday and while trying to emulate it, I noticed it’s important to have quads actually being flat for flat shaded rendering. As the rendering system splits everything into triangles, having a non-flat quad results in a edge that is visible as both triangles of the quad will have a slightly different shading. To my surprise, no good information on how to make a polygon flat could be found on the net…
The easiest way that I came up with to make a non-axis aligned polygon flat is this:
- Change the Transformation Orientation Mode from Global to Normal (combo box next to the transformation gizmo settings)
- Change the vertex snapping mode from Increment to Vertex and deactivate it (the little magnet is grayed out, combo box next to it shows two dots on a cube)
- Select three vertices that form the final plane you want the quad to lie in.
- Press Ctrl+Alt+Space to create a new custom orientation (transformation coordinate system), give it some name and make sure the Overwrite Previous is turned on. The coordinate system’s z-axis will be orthogonal to our defined plane (left part of the screenshot).
- Now select the off-plane vertex, press g to translate, and twice z to limit the transformation to the newly created coordinate system’s z axis (notice the blue line in the right part of the screenshot).
- Press and hold ctrl and move the mouse cursor over one of the three reference vertices so that the transformation snaps its z-value to that vertex (notice the orange snap circle in the right part of the screenshot).
- Release the mouse button and voila, the quad is now perfectly flat.
Since we enabled “Overwrite Previous”, for the next quad one just has to select three vertices, press ctrl+alt+space (overwriting the previously generated coordinate system), g, z, z, hold ctrl and move over a reference vertex (to snap), release, done. Sounds complicated at first but it’s actually very fast to do. Hope that helps
When you’re working with strings on iOS, it’s only a question of time before you start using stringWithContentsOfURL, either for downloading something from the web or handling a file import to your App. One of the major pains of working with strings is the encoding issue: a string is an array of bytes and to make sense of it, you got to know how what the bytes mean. In the early days, one just used one byte for a character and came up with the famous ASCII encoding. But of course 256 characters is by far not enough to handle all the characters in the world (think of all the Asian languages) so different people invented different encodings until at one point, the Unicode people came around in an effort to propose an encoding that contains all characters for all languages. Unfortunately, there is both UTF8 and UTF16, so there is not even a single Unicode encoding, but hey, that’s besides the point here. Unicode made a lot of stuff simpler and the world a better place.
well, once again I missed a self-set deadline. I wanted to finish the first version of Streetsoccer and submit it to Apple end of the first week of January but I guess that one is over now. I’ve been busy though and the list of missing things has gotten pretty short. What’s mainly preventing me from submitting the app are a few art assets plus some bigger changes to the internal data structures that require some more testing. But hopefully, another week and than it’s finally on it’s way…
I’ve lately been working on creating 3D models for Streetsoccer that act as background props. One of the most interesting areas is low poly trees and if you look through the Internet, there is hardly any good information out there. Most low poly assets or tutorials one finds do not work well in real time engines due to two things that are always difficult in real time 3D: Transparency and self-shadowing. Since a lot of people I talked to didn’t have the experience of falling into all the pit falls related to that topics yet, I thought I just quickly write down some of them and what one can do about them.
unfortunately, the brand new 1.5.0 update contains a bug that crashes the app every time you try to open a recipe, author, drink, and so on on iOS 4.x and 5.x. A fix is already on its way to Apple…
Update (Nov 13, 2012): Version 1.5.1 containing the fix is now available in the AppStore.
… granted, it’s only the “food and drinks” section AND it’s only in the Austrian AppStore, but Recipes is currently listed in the “What’s hot”-section!!! Missed Germany by one place (!) a couple of days ago… pretty damn cool… : )
first post in a while and first Recipes update in a while, too : ) . As already mentioned in another post, the introduction of iClouds had changed some rules on what Apple permits when submitting updates. Although I don’t plan to support iClouds in the near feature (database synchronization = programming headaches), code that had been in the app since day one had to be changed. Well, as of last week, 1.4.0 is out and finally the app is up to date again…
Just downloaded XCode 4.5 and migrated Streetsoccer to support iOS6 and the new, longer iPhone 5 screen. This was necessary as Apple only allows app submissions built with the latest development environment which as a developer I can totally understand. Supporting old versions is always a source of major headaches. What I cannot really understand is why they dropped support for pre-4.3 devices in XCode 4.5! iOS 5.1 SDK was still able to do it, so why drop it now?
I was totally unaware of this and - of course - only noticed it AFTER updating my system. This rendered two of my test devices (a 1st and 2nd gen iPod Touch) completely obsolete, one of which I had sent someone just recently to do some testing of the Streetsoccer beta builds and who I was planning to send an updated version soon.
So after 5 years, my very first iPod Touch has lost its last reason to stick around. I basically got it the first day it was available in Germany and started programming for it the first day the SDK went public. I distinctly remember a good friend of mine asking why I “did buy this piece of electronic garbage” that has no real use compared to his stylus-based mobile phone. Aaaah, those were the days. Now you almost cannot buy an iPhone because everyone else has one!
Hopefully, my 1st-gen iPad will stick around just a bit longer. They dropped iOS 6 support for it already, so it’s only a question of time until I won’t be able to develop for it I guess…
long time no post, I know … as always, it’s been a mixture of ambitious feature development and live simply getting in the way of ambitious feature development. For the last couple of weeks, I’ve been implementing and testing a new database feature inside the app which stores all sessions played.
One of the most daunting tasks when developing a computer version of a boardgame is creating a good computer opponent. Granted, with the advent of mobile devices and MMOs, it has become more important to connect users with each other than to have a strong AI. However, there are still lots of situations where it is simply more convenient to play against the computer: The AI won’t complain if you take a break and continue the game days later, it’s independent of your network connection and it’s available even at the strangest hour. So having an AI that is fun and/or challenging is great. A lot of users won’t notice it or will simply take it for granted but pretty much everyone will notice a bad one or none at all.