Sorry, here we go, long post.... For our recent App launched in December, 'Tip & Tumble', we (as in 'I') wrote our own OpenGL-based engine. Whilst I've been programming for decades I had no previous experience of OpenGL or any other computer graphics, so I'd be interested in any comments/feedback on its effectiveness. Obviously it would have been easier to use a commercial engine, and I need to reconsider that option again for future Apps. I was particularly pleased with the 'rolling balls' effect. I had to support many rolling balls at once, and rotating multiple fully rendered and lit spheres with surface markings would have been challenging, performance-wise. It is actually achieved by a 'static' sprite for each sphere, i.e. a flat disc, wrapped in a cuboid frame with a separate 'dot' sprite on each face of the cube. While the disc simply glides with a camera-facing translation, the enclosing cube is accurately rotated. This allows for a smoothly rendered sphere with consistent lighting effects on the dots as it rolls, yet relatively few polygons. It's not perfect, but the artefacts are not too noticeable. I have no idea whether that approach was original, or if there would have been better or easier ways! I don't even know for sure if I'm using the right terminology... as confessed, this is all new to me, learned from a pretty good book I found on Amazon. Here is a YouTube clip. If you want to see it in the App, whilst you can buy it today and we won't complain, you may want to wait a couple of days as we plan to do a 'free for a day' promotion this Friday/Saturday. Once that promotion is in effect I will announce in appropriate TA Forum, and update this thread too if there's been any dialogue. Tip & Tumble Idle Complexities Ltd An extended collection of tilt mazes from Andrea Gilbert, the original clickmazes designer. Includes three variations w… $0.99 Buy Now Watch Media DetailsAn extended collection of tilt mazes from Andrea Gilbert, the original clickmazes designer. Includes three variations with different goals. Think you’ve seen it before? Think again! Tip the tray to start the balls rolling. Once tipped stays tipped, until all balls are at rest. No dexterity required, just forward planning and logical thinking. Find the right sequence of tips to solve the puzzle. Game features: - Easy to learn, tutorial included - Play by tilting the device or swiping - 90 hand-designed puzzles, graded easy to hard - Solutions stored for review and playback - Realistic 3D animation Information Seller:Idle Complexities Ltd Genre:Board, Puzzle Release:Dec 17, 2014 Updated:Apr 04, 2023 Version:3.0 Size:13.8 MB TouchArcade Rating:Unrated User Rating:Unrated Your Rating:unrated Compatibility:HD Universal Cheers, Bill Stroffolino Well-Known Member Patreon Silver Apr 28, 2009 1,100 8 38 Software Engineer Pennsylvania http://www.northernbytes.ca #2 Stroffolino, Jan 28, 2015 Looks pretty, but I'm curious if you bothered trying the more obvious brute force approach with real geometry/lighting, and if so, how it compared cosmetically and performance-wise. Idle Complexities Active Member Dec 10, 2014 25 0 1 #3 Idle Complexities, Jan 28, 2015 Well, sort of. The sphere sprites were rendered using a massive (10,000s -100,000s I can't remember) polygon count, and brute force in the simulator, then the screenshot captured and used for the sprite. That allowed the lighting effects to be fairly correct and consistent with the rest of the scene. The brute force render took something like several seconds for each sphere. Obviously the code could have been optimised, polygon count reduced, and the device may have been faster, but it seemed unlikely that it would ever improve enough to render multiple spheres at 60fps. Stroffolino Well-Known Member Patreon Silver Apr 28, 2009 1,100 8 38 Software Engineer Pennsylvania http://www.northernbytes.ca #4 Stroffolino, Jan 28, 2015 Simulator is very sluggish. You could probably have gotten away with a "good enough" real time sphere renderer on devices by using a more modest poly count, but I like what you did, as it gives what appear to be perfectly rendered/aliased spheres without you having to even worry about performance. Idle Complexities Active Member Dec 10, 2014 25 0 1 #5 Idle Complexities, Jan 28, 2015 Thinking harder to recollect what I did, you may be right. That 'one-off' brute force render also included drawing the sphere, as well as rendering it. I'm sure there's MUCH better ways of drawing spheres, but my simplistic approach was to start with a very week approximation to a sphere (six triangles in a circle), and then iterate, repeatedly subdividing each triangle, experimenting with iteration depth until the end-result looked satisfactory. The iterative drawing is probably where the CPU time went, whereas that obviously would not have been needed at run time in deployed App. No regrets though, a bottleneck avoided has to be better than a bottleneck optimised. Thanks for feedback. Ovogame Well-Known Member Sep 25, 2010 570 0 0 Game Developer Morestel, France http://www.ovogame.com/ios #6 Ovogame, Jan 31, 2015 It was a good learning exercise for you. Graphically, it is lacking lighting and shadows. A simple sprite projected on the board surface will make your game look like 100x more solid. I'm using my own engine too. It's more advance as your one as I've been doing it for a long time (and it was my job to write game engine). But you should have a look, I'm sure you can grab a few tips there: http://forums.toucharcade.com/showthread.php?t=253948 JC Idle Complexities Active Member Dec 10, 2014 25 0 1 #7 Idle Complexities, Jan 31, 2015 Thanks, I'm not sure what we'll be doing for next App, there's a couple of ideas in mjnd. But for at least one of those, the suggestion for shadows is worth exploring. I dismissed the shadows as 'too complex' for T&T as the shadows would ideally 'land' correctly not just on the floor, but also on the sloping wedges, and the walls. But think I can see how it could be done, maybe gave in too easily! Ovogame Well-Known Member Sep 25, 2010 570 0 0 Game Developer Morestel, France http://www.ovogame.com/ios #8 Ovogame, Feb 1, 2015 for the shadows... 2 solutions: a) create a texture of a blurry blob and cast it to your geometry for each sphere. It means re-draw your geometry N+1 (N being the number os shperes casting shadows). For each new passes you are using your mesh but force the texture to be the blob shadow. Also, you need to change the uv but it is dead simple to convert your sphere into the uv metric of your mesh. b) similar to a) but you draw your geometry only twice (instead of N+1). You create just one big shadow map with all your shadows on it. You can do it in software, you won't have much cpu requiered for that. Make your texture low res anyway, it will look better as it give it a blurry look. then draw your mesh using that shadow map, the uv are even easier to compute than a) JC (You must log in or sign up to post here.) Show Ignored Content Share This Page Tweet Your name or email address: Do you already have an account? No, create an account now. Yes, my password is: Forgot your password? Stay logged in
Looks pretty, but I'm curious if you bothered trying the more obvious brute force approach with real geometry/lighting, and if so, how it compared cosmetically and performance-wise.
Well, sort of. The sphere sprites were rendered using a massive (10,000s -100,000s I can't remember) polygon count, and brute force in the simulator, then the screenshot captured and used for the sprite. That allowed the lighting effects to be fairly correct and consistent with the rest of the scene. The brute force render took something like several seconds for each sphere. Obviously the code could have been optimised, polygon count reduced, and the device may have been faster, but it seemed unlikely that it would ever improve enough to render multiple spheres at 60fps.
Simulator is very sluggish. You could probably have gotten away with a "good enough" real time sphere renderer on devices by using a more modest poly count, but I like what you did, as it gives what appear to be perfectly rendered/aliased spheres without you having to even worry about performance.
Thinking harder to recollect what I did, you may be right. That 'one-off' brute force render also included drawing the sphere, as well as rendering it. I'm sure there's MUCH better ways of drawing spheres, but my simplistic approach was to start with a very week approximation to a sphere (six triangles in a circle), and then iterate, repeatedly subdividing each triangle, experimenting with iteration depth until the end-result looked satisfactory. The iterative drawing is probably where the CPU time went, whereas that obviously would not have been needed at run time in deployed App. No regrets though, a bottleneck avoided has to be better than a bottleneck optimised. Thanks for feedback.
It was a good learning exercise for you. Graphically, it is lacking lighting and shadows. A simple sprite projected on the board surface will make your game look like 100x more solid. I'm using my own engine too. It's more advance as your one as I've been doing it for a long time (and it was my job to write game engine). But you should have a look, I'm sure you can grab a few tips there: http://forums.toucharcade.com/showthread.php?t=253948 JC
Thanks, I'm not sure what we'll be doing for next App, there's a couple of ideas in mjnd. But for at least one of those, the suggestion for shadows is worth exploring. I dismissed the shadows as 'too complex' for T&T as the shadows would ideally 'land' correctly not just on the floor, but also on the sloping wedges, and the walls. But think I can see how it could be done, maybe gave in too easily!
for the shadows... 2 solutions: a) create a texture of a blurry blob and cast it to your geometry for each sphere. It means re-draw your geometry N+1 (N being the number os shperes casting shadows). For each new passes you are using your mesh but force the texture to be the blob shadow. Also, you need to change the uv but it is dead simple to convert your sphere into the uv metric of your mesh. b) similar to a) but you draw your geometry only twice (instead of N+1). You create just one big shadow map with all your shadows on it. You can do it in software, you won't have much cpu requiered for that. Make your texture low res anyway, it will look better as it give it a blurry look. then draw your mesh using that shadow map, the uv are even easier to compute than a) JC