For the past year I have been working on an isometric city builder. So far I have not used any framework apart from a loose PureMVC clone.
I have heard of Starling but only recently have I played with it.
From my research, the performance boost is fenomenal, but this forces me to manage my resource a lot tighter.
At the moment, I am exporting building animations one building at a time, in ~16 frames/pngs. These are cropped, resized and exported in Photoshop by a script and then imported in Flash, then exported as a swf, to be loaded / preloaded / postloaded on demand.
The frames are way too big to make a spritesheet with them, per building. I believe its called an atlas.
These pngs are then blited between lock() and unlock(). After the buildings + actors walking around are sorted, that is.
I am unsure if just using starling.Movieclip for the buildings, where instead of loading the pngs, I would build a MovieClip symbol with its frames. So bliting wouldn't even be necessary. Unless adding bliting on top of Starling would improve performance even more. That would allow fatter features such as particles effects, maybe some lighting.
Google isn't offering me a strait answer, thus I am asking here.
Google isn't offering a straight answer because there isn't such. It depends very very much on what you've done, how much knowledge you've got and what are your goals.
Using Starling gives benefits as well as drawbacks. Your idea of resources will change totally. If you really have enormous amount of assets, then putting them into GPU will be really slow process. You must start from there - learn what Starling does, how resources are managed with it and what you need to change in order to make the transition between the two.
If this is not that hard and time consuming task, you will have some performance optimization. BUT again it depends on your current code. Your current code is really important in this situation as if it's perfectly optimized your gain won't be that much (but commonly would still be).
If you need to switch between graphics regularly or you need to have dynamic assets (as images for example) you must keep in mind that uploading to GPU is the slowest part when talking about Starling and Stage3D.
So again, there is not a straight answer. You must think of GPU memory and limit, GPU upload time, as well as assets management. You also need to think of the way your code is built and if you are going to have any impact if you make the switch (if your code heavily depends on the MovieClip like structure, with all that frames and things) - it will be hard for you. One of the toughest things I fought with Stage3D was the UI implementation - there is almost only Feathers UI which will take you a few weeks to get along with.
On the other hand, Starling performs pretty well, especially on mobile devices. I was able to maintain a stable 45fps on a heavy UI app with a lot of dynamic loading content and multiple screens on an old iPhone 4S, which I find great. Latest mobile devices top at 60fps.
It's up to you to decide, but I'll advise you to have some experimental long-lasting project to test with, and then start applying this approach to your regular projects. I've done the dive to use it in a regular very tightened deadline project, and it was a nightmare. Everything worked out great, but I thought I would have a heart attack - the switch is not that easy :)
I would suggest using DMT for rasterizing your vector assets into Straling sprites at runtime, and it'll also keep your DisplayTree! meaning that you'll still have the parent/child relations that you had in your Flash Assets.
DMT will not duplicate assets, and will rasterize the vectors into texture atlases only one time (Cache is saved)
you can find it here: https://github.com/XTDStudios/DMT
Related
I'm making a flash game, and I can't decide to use a bigger stage or a smaller one, with scrolling background to make it run smoother. I's going to be some kind of strategy game if it matters.
Thanks
One option is to have a bitmap object the size of your stage for example 800x600, then draw your objects into the bitmapdata of that bitmap using copyPixels this is known as blitting and is pretty fast.
Another option is to just use the flash display list and add every object as sprites onto the stage.
Second method is easier to handle in terms of mouse events and stuff.
My advice is to start with the second option and see if performance is enough, if not go with option 1.
There are many, many variables that determine the performance of your application.
To answer your question, a smaller stage area will make your program run faster. The amount of difference will depend on the way your application deals with display objects. Flash will not render things that are completely outside the stage bounds. So keeping only those objects that are needed at any given time on the stage is a good practice.
using flash player 11's new stage3D features (even for 2D stuff) will likely make your game very smooth. Lots of good frameworks out there that can take care of the low-level stuff if you don't want to get into it. For 2D, starling is very easy to get started with, and seems to be Adobe's favored framework.
At a bare minimum, make sure you use GPU acceleration in your output/compiler options.
There are LOTS of other tips for optimization people could get into, but that is better suited for google searches as Stackoverflow is about specific questions.
paper.js
EaselJS
fabric.js
KineticJS
Hello guys I am new in html5 canvas development and I am lost in choosing canvas frameworks. There are so many of them that I can't find out what to use. So here I am! I want your help to choose which one is better for my needs. There are my needs
1) I want the framework used Vector graphics, I know canvas is not DOM, I realy don't care about it but what I mean is I want to manipulate with objects after its creation, PaperJS has this feature I don't know about others. If advanced mouse events will be available it would be better.
2) I want to use the framework for images, I will load image and animate them with canvas, move, animate some colors...
3) I want the framework to be fast because of my needs (image animation should be smooth)
4) I want the framework to have good community because I know I will need some help.
So what do you think which one is better for me? and please if you can write down from my list which are the strength and weakness for each framework?
HTML5 canvas is still very fresh environment. You can get impression there is a lot of tools already available, they are often quite immature though.
My answer will cover only part of your question because I used only KineticJS and EaselJS.
You can start from reading opinions at this page (mine is the last one at the bottom).
Speaking shortly KineticJS has lower entry barrier. It's simple drawing library and has some support for mouse events too. At the time I was trying to use it it was barely extendable. I found it really hard to customize for my needs.
EaselJS is a bit harder to start with, but it's more advanced too. Now it's part of other libs set known all together as CreateJS. It seems that lot of development going around there.
Both Kinetic and Easel supports mouse event. I don't remember
well the Kinetic, sensing 'onMouseOver' is costy with Easel though.
Also both mentioned libs allows objects manipulation. You can find
here TweenJS also useful as addition.
Again both Kinetic and Easel allows this. Easel also has support for
sprites - 'animated images' well known for web game developers.
I'm not sure about Kinetic as I haven't reached animation part of my
project before I dropped it (the lib, not the project). With Easel
speed is tricky. It has some optimization methods implemented like
for example objects cache or snapToPixel flag. Examples seems to run
really well. However for my project using Easel smoothness still is
an issue despite quite a lot of effort put in optimization. Maybe I
misused the API or there is still place for more optimalization I
haven't noticed.
Both libs are quite young but seems to be actively developed.
Authors are rather responsive. Community still isn't big, but I
guess CreateJS as more complete set of tools for creating games will
grow faster.
If you want to check here is the project I mentioned. It's a web page made with usage of EaselJS + TweenJS. Still needs some minor tweaking though.
My colleague and me made an HTML 5 iPad game ( http://braille.gandzo.com/ ) and we would like to upgrade it, and our framweork is not enoguh, for what we want. Some of the things we would change are: graphics update, animations/"effects", multi-player, achievements and so on. The game would stay 2d. Now, as far as I understand, both Unity and Cocos would be good for this task, with Unity having the advantage of being multi-platform.
What I want to know is are there unknown qualites/"flaws" to these two programs which would influence my decision (maybe even by choosing something else). Examples that come to mind are "Unity is too complicated/has too much unneeded options/hoops because it's made with 3d in mind" or "Cocos is significantly more suited for 2d games".
If the game is pretty much in 2d... I would suggest for cocos2d. I am working on cocos2d for past 1 and half years... I don't have experience in Unity but ya my colleagues who used to work on Unity had so many problems with animation, texturing etc.
BTW I was not able to play you game on my Chrome. :)
I can see how this might not be a good enough question but I have just embarked on a journey to build the first decent Game Engine for HTML5 canvas that is cross browser and most of all fast. The only problem is I am very new to game design and don't know many tricks of the trade that will help me.
The game I am currently implementing for which the engine will be taken out of is a tile based 2D platformer with MANY tiles (around 3500). I'll start with some tips that I've thus far learnt.
Redraw Regions - only redraw areas that change
Avoid unnecessary function calls (Firefox does not like too many of them)
Use the DOM if you can
Chunk tiles together for quicker access
Other things I am looking for are things like Terrain Generation, Lighting in 2D, Maps, quick server communication. If this is too vague, I will try and close it. Just want to know game design better.
Links/resources would be good. Especially for physics or important maths.
Only draw stuff that's visible, that means only draw the tiles etc. that are currently on the screen. For tiles that's fairly easy, if you got lots of entities you may either want to use a sliding window to keep a list of screen local objects or use such a thing like a quadtree.
Since there's no easy/fast way to copy one canvas to another, redrawing regions is really complicated, since you can't keep a buffered state of (for example) the background if it hasn't changed. So keeping a list of "dirty rectangles" will be a computational overhead for sure.
The whole topic is very broad, even handling the FPS rate can be quite difficult, this question contains some good links and answers on that topic:
https://gamedev.stackexchange.com/questions/1589/fixed-time-step-vs-variable-time-step
You've also mentioned server communication, if you want to do some multiplayer you'll have to care about even more stuff, you can't trust the client, need to worry about bandwidth, synchronization issues, interpolation on the client etc.
I've done some rather simple 2D games in the past, most of them are not in JavaScript but they should give you some hints:
http://github.com/BonsaiDen/Norum
(Platformer engine demo in C, camera zones, moving platforms)
http://github.com/BonsaiDen/Tuff
(2D Platformer in Java, got never finished, powerups and some cool stuff)
http://github.com/BonsaiDen/NodeGame-Shooter
(2D multiplayer space shooter written in JS, using Node.js for the server and WebSockets for communication)
For some final words I'd say that you should start small, like for example just do a scrolling tile map first, then add a player, then rewrite the whole thing. You want write the perfect engine just from scratch it will take many iterations until you find out all the quirks and tricks.
If you want more precise answers you should open questions on the single components you run into troubles with.
Is there any significant performance/load time impact if single web page will load, say, 10 identical flash objects? 20? 30?.. any evidential data on sustainability of such kind of setup?
This would be the same flash app, each instance serving its own stream.
There's definitely going to be some overhead in size as there is a certain amount of code that is contained in every swf regardless of it's developer created content.
I'm almost certain there would be speed issues as well, which would see frame rates drop right down the more swfs you add to the page.
To be honest the concept smells a little fishy and i would think there must be a better solution to your problem.
EDIT
Also there is a restriction on having two steams coming over http per domain. Sure you could get around this but it will definitely be an issue.
I found this post which might help. The trick is to use SWFObject to embed your swf files.
I ran into a strange problem today. On the music charts page on Muziboo, I was displaying a list of songs and a playlist on the right. Each song has a small button player done in OpenLaszlo. In firefox everything was fine and in IE (not unusually), the page would freeze for sometime. This would happen once and repeat only if I delete cache and try again. I googled a bit and learnt that it's a good idea to embed give each swf a unique id otherwise the browser misbehaves. I then went ahead and used swfobject to embed the swf files and everything started working great!
Yes, it'll likely nuke the browser if you go too far down that road.
If you want to deal in multiple streams, perhaps combining all your would-be applets into one giant one might work better. It'll certainly offset the serious overhead you'd have with 10-40 of the little blighters.
If this is a music player, you want to have a serious look at doing some JavaScript remoting. It's fairly trivial to control a flash app via JS so you could have standard HTML/CSS controls without having to load up a billion flash instances.
Design-wise this just sounds like a bad idea. You'd be running multiple instances of the Flash player inside a browser, each of which has an individual cost, and the host (in this case the browser) will run all of them on the same thread (with the exception of certain elective asynchronous processes), so you're almost surely going to run into problems of various kinds -- jittery playback, UI blocking, processor burden, memory bloat, consequent instability of the host, etc.
Unless the SWFs are very tiny, and doing very little work, it seems like a design that's just asking for trouble. Indeed you could test such a thing fairly easily; have you run any tests yet? Just curious.
Also curious as to the requirements; we might be able to offer more constructive alternatives if we knew a little more about what you were aiming for. Have you considered simply loading all the SWFs into a single container SWF requiring only a single browser-hosted instance of the Flash player?