At some point of development of my new game, I stumbled upon a problem which lead me to discovery of Adobe Scout. The problem occurred after some time of gameplay when the game started lagging more and more heavily up to the point when the whole application crashed. I did some profiling with Scout, and here's what I found: most, if not every heavy memory load is caused by gotoAndPlay() function (if I understand the data presented by the profiler correctly). This function always seemed and even felt like an easy task for Flash, but turns out it's not? Or is it caused by using text labels instead of frame numbers? I am currently looking for possible workarounds to use this method less, and while I do, it would be infinitely helpful to hear thoughts or possible options from people who are aware of this issue.
Related
Has anyone experienced a very slow resume when closing the dashboard of swarm? There is about a 5 second delay in my application where a black screen is displayed after the dashboard is closed and before the actually game screen is rendered. I had originally thought that maybe my show() method for the current was doing too much and causing the lag, but after looking a bit closer I see that the show() method is actually never even called when switching from the swarm dashboard back to the game, I suppose this is due to the fact that Swarm is not operating in a libgdx context but an android one.
Any help appreciated.
That's OpenGl context Loss. your assets need to be reloaded. If you have a lot of assets, you should separate them and load them when needed. That will help your game to feel much faster, especially when starting and when coming back from swarm dashboard.
Here is the game
http://www.kongregate.com/games/austinkan/cookie-clicker-v0-1a
I need help to make the game at least save your total cookies so that when you reopen the game it keeps your score. The saving of what upgrades you have can be implemented once I grasp the concept of saving.
Here is the code WARNING it is fairly large
http://pastebin.com/9QgpddbT
Saving and Loading in Actionscript 3 (Mini-Lesson) is a fairly good tutorial on how to do what you have asked.
Hi I'm creating an adobe AIR application..Its working fine ,But I want to make my application without performance issues..How to Check Adobe AIR applications performance ?Is there any tools available?
Take a look at Adobe Scout
"Adobe Scout is the next-generation profiling tool for Adobe Flash Player and AIR."
When building any flash application you define the application FPS. If the real FPS (flash can skip frames under high load) is lower than the defined FPS- you have troubles. You can check the FPS by vast variety of FPS meters here.
If your real FPS coinsides with the defined one - it is great, but try rising the defined FPS value up to 120 (which is max) and check out the real value, it is hardly be higher than 60 during animations, but the higher you can get - the better your application is. With this approach you can eliminate or at least point out "slow code".
ADD: It also worth mentioning that if the defined FPS value is 24, and the application is in stable state (the amount of animation, animation complexity and computational complexity stay more or less the same) the real value will "float" across some value, let's say 23 FPS with the spread of 1-2 (i.e. 22.7, 23.5, 23.9, 23.1, etc). And the mean value will be always lower than the defined FPS value.
Try to check memory usage. I would start trying to launch Flash Builder profiler remotely while your app is running live on the device and check out memory utilization. Refer this
Try to check redraw regions. Note that MovieClips that are not visible (e.g. throbbers) are still redrawing unless the are stopped. So if you see some region redraws without sencible reason - try to figure out why. The ideal case is to call stop() and visible=false or remove from stage the unused animations.
ADD: Redraw regions indicator is a part of Debug version of Flash Player. You can enable it through the context menu of the debug version of Flash Player.
UPDATE: I added some details to my answer as I see the interest to the Adobe Flash Perfomance issue. I don't remember the exact acticle, but I found a lot of usefull advices on the Abode's site, now I see that the number of such articles there increased.
Also I didn't know about the Adobe Scout before, but it sounds promising. I'll definately try it soon.
I'm working on a little networked flash game. I have my own server built in C/Linux and I connect to the server via a flash socket. I'm debating whether to put the heavy load of game logic on the client or on the server. The main concern is someone hacking the code and ruining the game for others.
Even if I put as much logic on the server as I can, if someone can hack the code and figure out my messages that are sent to the server it seems impossible to stop all intrusions.
How should I handle this and how worried should I be about AS3 hackers?
I gave a talk on a conference 2 years ago about protecting flash games. Check out the slides.
Yes, it is pretty easy to decompile a swf and modify it as desired. The risk is fairly low, but if there is some large possible monetary reward, then yes I would be careful.
So, my advice is:
Don't put high risk logic on the client
But do put high cost algorithms on the client.
Edit: I would like to add one more point. If the server is relying on the client to it some state of the game, you can also proxy, inspect, and then modify the requests with a tool like Charles. Someone can use this tool to setup breakpoints on requests, and then modify the results before forwarding them to the server. It is even easier than decompiling and modifying a swf.
The lesson is, you should never rely on having an honest client.
Flash code is incredibly easy to hack. I may be wrong, but I think that when you decompile a swf, it's a full decompile - it gives you the original names of the variables and everything. It's also fairly easy to use tools like Cheat Engine to modify memory while the game is running. Unless you intentionally obfuscate your code and your data structures, I'd recommend putting most computation on the server.
I opened this matrix multiplication benchmarks and my browser (Firefox 7.0.1) froze until the benchmarks finished (I opened the page in an old Asus EeePC 1000H).
I heard that web workers were invented to separate processing from displaying the web pages. Is it possible to make use of the Web Workers API to make WebGL not stall the whole web browser ?
For the sake of clarity: the benchmark that you linked to does not use WebGL at all. (I should know, I wrote it.) And in the case of that particular benchmark you absolutely could run it in a Web Worker now and it would be perfectly fine.
(Fun fact - Web Workers didn't support TypedArrays when the benchmark was built, and since most of the matrix libraries rely on that it was impractical to run it in a Worker at that time. That has since been fixed.)
Anyway, to answer your original question: No, WebGL cannot run in a worker. The core blocker to this is that in order to get a WebGL context you need to call getContext on a canvas element. Web Workers explicitly disallow DOM access (which is a good thing, BTW!) and as such you'll never be able to access WebGL from a worker.
But that's not as bad as you might think. For one, consider that most all 3D rendering is actually happening in a different thread anyway. Specifically, a whole bunch of threads running on your GPU. The only part the browser has in it is to tell your graphics driver "Hey! Start rendering some triangles using this data!" and then it moves on without waiting for the triangles to actually be rendered. As such, while the draw commands must be executed from the main process, the time it spends blocking that process is (usually) very little.
Of course, that's not what's going to eat up a bunch of your time if you were coding a realtime game. You've got animations, physics, AI, collision detection, pathfinding... there's a lot of non-graphical tasks involved that will eat your CPU alive if you let them. In some case (animation), it's usually just gobs and gobs of matrix math, just like the benchmark you linked to! Fortunately for us, however, that type of processing CAN be done in a Worker, and all we need to communicate back to the main thread is the data required to render the scene.
Yes, this introduces some challenges in terms of synchronization and data transfer, but on the whole it will be vastly preferable to locking up your browser while we try and simulate those 500 boxes colliding.
Yes, on Firefox!
https://hacks.mozilla.org/2016/01/webgl-off-the-main-thread/
We’re happy to announce WebGL in Web Workers in Firefox 44+! Using the new OffscreenCanvas API you can now create a WebGL context off of the main thread.
By default you can't use WebGL in a Web Worker as Toji explained.
You can check out WebGLWorker which is a library that lets you do WebGL stuff in a Web Worker, by transparently proxying commands to the main thread.
Here is a nice blog post that explains how it works.