Show HN: A UIKit Game Engine(github.com)
github.com
Show HN: A UIKit Game Engine
https://github.com/MosheBerman/MBTileParser
30 comments
I don't know if I'm lazy or not, but the fact that I have to commit to downloading and running it before I can see what exactly it does is pretty off putting to me.
Agree, I think having at least a screenshot is a must. Or even an animated gif if it's some interaction (e.g. see plug [1]) you're trying to present.
[1] https://github.com/shurcooL/Slide#slide
[1] https://github.com/shurcooL/Slide#slide
The only sites blocked in China that bother me are like dropbox and youtube. Suffice it to say, I see nothing on your github page, and all the links are broken.
http://i40.tinypic.com/21dkpx.gif
Re-uploaded the GIF file for him, hopefully this one loads for you.
Re-uploaded the GIF file for him, hopefully this one loads for you.
TIL tinypic.com is blocked also :) CMCC wifi is a bit more strict than the other Chinese ISPs, they block imugr also while many other ISPs do not.
My problems are admittedly very niche, and I will get to see everything when I'm at work tomorrow (if my VPN was working, I could see them now...drats). Thanks for the try though!
My problems are admittedly very niche, and I will get to see everything when I'm at work tomorrow (if my VPN was working, I could see them now...drats). Thanks for the try though!
Here, let me see if I can get blocked in china now: http://www.simcop2387.info/Slide_1.gif
Yes, that works, thanks!
You need a paid VPN account (, free ones works before they got too much attention and got blocked,) or other encrypted tunnels for HTTP payloads, in China.
BTW, nytimes.com and other whistle-blowers also get blocked.
BTW, nytimes.com and other whistle-blowers also get blocked.
We have a paid VPN account, it no longer works and we can't get a refund. It's like a game of cat and mouse, and I've kind of given up.
Wow, I didn't know that. So everything I host on Dropbox (and I host _everything_ on Dropbox) is unavailable in China?! Is this country-wide or ISP-specific?
YouTube, Dropbox, Facebook are nationwide blocks. Imgur, tinypic, media wiki etc...seem to be blocked by some ISPs.
I'm obviously careful about this, there are good alternatives that work (for now) in china, e.g. Skydive rather than Dropbox. But even I have to we YouTube for video uploads.
I'm obviously careful about this, there are good alternatives that work (for now) in china, e.g. Skydive rather than Dropbox. But even I have to we YouTube for video uploads.
Thanks for the heads up. That's pretty awful. I'm not going to stop using Dropbox over it, but it is upsetting to know so many people can't access my work posted there.
You accelerate the mouse precisely in the points where I want to see the anomalies (when intersecting the table).
The object keeps sliding on its background surface as long as at least one of its pixels is visible, unless it encounters a collision that cannot be resolved otherwise. Once that's no longer the case, it pops forward (keeping the same spot under your mouse) until it is.
There are 2 other videos where hopefully you can see this happening. Or, better yet, you can try it running it yourself on Windows or Mac.
There are 2 other videos where hopefully you can see this happening. Or, better yet, you can try it running it yourself on Windows or Mac.
Added it.
You're right, sorry. I've gotten better at this sort of release since posting this repo. I'll add some screenshots to the project.
A screenshot is a nice to have, or something that qualifies as a legitimate request, but it's not critical nor would I expect it to be off putting if not provided.
Ok, added. Thanks for the feedback!
Wouldn't drawing with UIKit be less efficient than using an OpenGL backend?
SDL[1] on Windows for instance, falls back to GDL when proper DirectX support isn't available. GDI is what most GUI apps use to draw their elements on Windows. It is akin to UIKit on iOS. But GDI is horribly slow as all the computation is done on the CPU.
In fact, realizing this fact, Microsoft has recently developed Direct2D, which does the computation on the GPU and which regular GUI apps can use to achieve better performance. (BTW, I believe Direct2D is somewhat similar to Cairo 2D.)
[1] Simple DirectMedia Layer -- used by plenty of games to achieve cross-platform compatibility. Most games in the Humble Indie Bundle use this.
SDL[1] on Windows for instance, falls back to GDL when proper DirectX support isn't available. GDI is what most GUI apps use to draw their elements on Windows. It is akin to UIKit on iOS. But GDI is horribly slow as all the computation is done on the CPU.
In fact, realizing this fact, Microsoft has recently developed Direct2D, which does the computation on the GPU and which regular GUI apps can use to achieve better performance. (BTW, I believe Direct2D is somewhat similar to Cairo 2D.)
[1] Simple DirectMedia Layer -- used by plenty of games to achieve cross-platform compatibility. Most games in the Humble Indie Bundle use this.
Yep. While UIKit is going to draw using OpenGL anyway with this case you're missing a big optimisation in being able do batch drawing of the tiles and using VBO's etc.
UIKit is fantastic for normal UI's and the 'general case' but almost certainly isnt optimised for doing efficient drawing of a large number of sprites / tiles (trading efficiency for flexibility).
Couple years ago I actually wrote my own API compatible version of UIKit but backed by OpenGL , and then extended support for these type of cases. As it was basically a drop in replacement I was able to confirm UIKit (at least at the time) was not very clever or fast when it came to a large view hierarchy. So my fraemwork was optimising for large batch drawing from a single texture mostly which is what you really want in the OP's case.
I should release it one day as open source.. though is all OpenGL 1 so a little outdated on iOS these days.
UIKit is fantastic for normal UI's and the 'general case' but almost certainly isnt optimised for doing efficient drawing of a large number of sprites / tiles (trading efficiency for flexibility).
Couple years ago I actually wrote my own API compatible version of UIKit but backed by OpenGL , and then extended support for these type of cases. As it was basically a drop in replacement I was able to confirm UIKit (at least at the time) was not very clever or fast when it came to a large view hierarchy. So my fraemwork was optimising for large batch drawing from a single texture mostly which is what you really want in the OP's case.
I should release it one day as open source.. though is all OpenGL 1 so a little outdated on iOS these days.
> I should release it one day as open source.. though is all OpenGL 1 so a little outdated on iOS these days.
You definitely should! :-D
You can worry about porting/updating it later. You might even get help in doing so, once you open-source it.
You definitely should! :-D
You can worry about porting/updating it later. You might even get help in doing so, once you open-source it.
Yes and no. The -(void)drawFrame call uses CPU, but almost everything else you do in UIKit is done in the gpu. (Everything that can be animated is done in the gpu)
This wasn't about efficiency for me. When I wrote this, I didn't know OpenGL, but I already knew how to work with UIKit.
I started with processing TMX files and Texture Packer files, just to see if I could get UIKit to load them. Once I had that working, I added virtual controls, basic dialog, and basic game state.
I started with processing TMX files and Texture Packer files, just to see if I could get UIKit to load them. Once I had that working, I added virtual controls, basic dialog, and basic game state.
This is an admirable effort, but I would not recommend ever using this in practice. I am saying this from experience: I wrote a game engine on top of UIKit, which I spent months trying to fine-tune before finally ditching it and re-writing everything to use Cocos2d.
The performance aspect is just not there. Once you get to a game with a large number of sprites and animations, animations will jitter and glitch. You're really going to be stretching what Core Animation can handle.
What I usually recommend these days is to use Cocos2d for your main game view, but using UIKit for the rest of the interface (menus, score screens, etc.).
The performance aspect is just not there. Once you get to a game with a large number of sprites and animations, animations will jitter and glitch. You're really going to be stretching what Core Animation can handle.
What I usually recommend these days is to use Cocos2d for your main game view, but using UIKit for the rest of the interface (menus, score screens, etc.).
The performance of MBTileParser is fantastic. I've profiled map loading to take under 300 milliseconds. I wouldn't necessarily use this for an action game, but for RPGs, this is more than sufficient.
With a UIKit engine, you don't have to deal with OpenGL and UIKit fighting for performance.
With a UIKit engine, you don't have to deal with OpenGL and UIKit fighting for performance.
Yeah, I wonder why you would even try this when something like Cocos2d already exists and is awesome.
Cocos2d (at least when I was using it) engendered some really bad anti-patterns in regards to memory management and architecture. MBTileParser doesn't just offer a way to show graphics onscreen, but it considers the MVC architecture in a way that cocos2d doesn't. (When I started, cocos2d was somewhere between 0.9 and 1.1. The state of the engine has very likely improved since, but that's why I wrote this.) Cocos2d didn't even support ARC back then.
+1 for native!