I am working on a project that will have the user seeming to fly in 3D from point to point in an architectural model, based on choices. It is a tree-flow, with everything starting from one point and branching out from there, and it only needs to animate in one direction, which makes things easier.
The thing is that the animations from place to place are C4D animations rendered as PNG sequences, and in total they will be VERY large, so I want to package each segment as an individual SWF and load and unload them dynamically as needed.
I expect the first thing to do will be to see if I can have my upstream guy render them as JPG sequences instead... is that a good idea performance-wise? I imagine it will be in terms of bandwidth.
The main question, however, is how I can dynamically load one of these sequences, have it play and stop on its final frame (over which data and choices will display), and then - based on the user's selection - load and play the next animation seamlessly from the first, without endlessly stacking up loaded clips. When the user goes back a level, I only need to jump to the first frame of the animation, but going forward always involves a smooth flight.
I suspect the solution may have to do with adding, say, to the loader by specific names, then as we transition out, load the next one with a specific name, and then unloadChild() and do whatever other kind of garbage collection I need to do to purge from memory entirely. I want to be as cognizant of memory usage and performance as I can, because at certain spots there will be other images and videos loaded on top of the flight animations.
Does anyone have any ideas about this? I'm sure it's a common need, I've just never done it before, and I want to do this as timeline-free as possible.
Thanks in advance for any advice!
Mattynabib
Related
I'm writing a graphic console that highlights different entries and stores things when you input them (in AS3) but I've found that once there are thousands of entries, the program starts lagging and scrolling is slow. If I want scrolling to be animated with acceleration it gets even slower.
How do I move the giant block of objects that are my stored entries up and down?
Do I have to progressively load messages around where the user is looking? How does the scrollbar handle this, then?
you should create a custom container instead TextField, it would be easier to build an accelerated scrolling too,
each log entry would be an extended DisplayObject that holds anything you want just like inflating layouts in android.
the most important part should be reducing Memory usage:
you may only store plain text of log enteries in something like a global array and when scroll position is close enough, generate this layouts, then adding them in container to show, and vice versa for removing far behind chats.
however this proccess stills using much memory during runtime.
so, just according the concept of android's DiskLruCache, it is possible to storing some part of our invisible data which would be too far from our scroll position to disk instead memory, using SharedObject's.
How do I move the giant block of objects that are my stored entries up
and down?
You don't. As you have noticed, when the number Display Objectson the DisplayList greatly increases, the memory overhead increases and the housekeeping details of managing the Display Objectseventually causes performance to suffer. You don't mention any details of how you are implementing what you have so far so my comments will be general.
The way this is handled by various platform list components in Flex, iOS and I assume, Flash, is to only display the minimum number of objects needed, and as the user scrolls, objects are shuffled in and out of the render list. A further optimization is to use a "pool" of "template" objects which are reused so you don't pay a initialization time penalty. There is probably an actual name for this ("...buffering...") technique but I don't know what it is (hopefully some kind person will provide it and a link to a fuller description for how it works).
And as for how it works – you can DIY it, figuring out, as the user scrolls, which objects are moving off-screen and can be recycled, which are going to move on-screen, etc. Of course this all assumes that you have your objects stored in a data structure like and Array, ArrayList or ArrayCollection. As an alternative to coding all this from scratch, you might see if the DataGrid or List components will meet your needs – they manage all of this for you.
Flash Tutorial: The DataGrid Component (youTube video)
Customize the List component
Lots of other examples and resources out there.
(again, I work in Flex where the DataGrid and other list-based components can customized extensively using "skins" and custom item renderers for visual style – not sure if it is the same in Flash)
I understand it's often faster to pre-render graphics to an off-screen canvas. Is this the case for a shape as simple as a circle? Would it make a significant difference for rendering 100 circles at a game-like framerate? 50 circles? 25?
To break this into two slightly different problems, there are two aspects to what you're asking:
1) is drawing a shape off-screen and putting it on-screen faster
2) is drawing a shape one time and copying it to 100 different places faster than drawing a shape 100 times
The answer to the first one is "it depends".
That's a technique known as "buffering" and it's not really about speed.
The goal of buffering an image is to remove jerkiness from it.
If you drew everything on-screen, then as you loop through all of your objects and draw them, they're updating in real-time.
In the NES-days, that was normal, because there wasn't much room in memory, or much power to do anything about it, and because programmers didn't know much better, with the limited instructions they had to work with.
But that's not really the way games do things, these days.
Typically, they call all of the draw updates for one frame, then they take that whole frame as a finished image, and paste that whole thing on the screen.
The GPU (and GL/DirectX) takes care of this, by default, in a process called "double-buffering".
It's a double-buffer, because there's room for the "in-progress" buffer used for the updates, as well as the buffer that holds the final image from the last frame, that's being read by the monitor.
At the end of the frame processing, the buffers will "swap". The newly full frame will be sent to the monitor and the old frame will be overwritten with the new image data from the other draw calls.
Now, in HTML5, there isn't really access to the frame-buffer, so we do it ourselves; make every draw call to an offscreen canvas. When all of the updates are finished (the image is stable), then copy and paste that whole image to the onscreen canvas.
There is a large speed-optimization in here, called "blitting", which basically copies over only the parts that have changed, and reuses the old image.
There's a lot more to it than that, and there are a lot of caveats, these days, because of all of the special-effects we add, but there it is.
The second part of your question has to do with a concept called "instancing".
Instancing is similar to blitting, but while blitting is about only redrawing what's changed, instancing is about drawing the exact same thing several times in different places.
Say you're painting a forest in Photoshop.
You've got two options:
Draw every tree from scratch.
Draw one tree, copy it, paste it all over the image.
The downside of the second one is that each "instance" of the image looks exactly the same.
If your "template" image changes colour or takes damage, then all instances of the image do, too.
Also, if you had 87 different tree variations for an 8000 tree forest, making instances of them all would still be very fast, but it would take more memory, because you now need to save 87x more images than when it was just one tree, to reference on every draw call.
The upside is that it's still much, much faster.
To answer your specific question about X circles, versus instancing 1 circle:
Yes, it's still going to be a lot faster.
What a "lot" means, though, will change based on a lot of different things, because now you're talking about browsers on PCs.
How strong is the PC?
How good is the videocard?
How large is the canvas in software-pixels (not CSS pixels)?
How large are the circles? Do they have alpha-blending?
Is this written in WebGL or software?
If software is the canvas compositing in hardware mode?
For a typical PC, you should still be able to hit 60fps in Chrome, drawing 20 circles, I think (depending on what you're doing to them... ...just drawing them onscreen, every frame is simple), so in this case, the instances are still a "lot" faster, but it's not going to matter, because you've already passed the performance-ceiling of Canvas.
I don't know that the same would be true on phones/tablets, or battery-powered laptops/netbooks, though.
Yes, transferring from an offscreen canvas is faster than even primitive drawings like an arc-circle.
That's because the GPU just copies the pixels from the offscreen canvas (not much CPU effort required)
I'm working on a program in Flash coded in Actionscript 3 and I'm trying to determine if I should remove MovieClips from the stage when they're not on screen, or just stop moving them once they're outside the viewing area. If I do not removeChild() the MovieClips once they move out of the viewing area, I can potentially end up with tens of thousands of MovieClips on the stage (though not in view).
Is there a standard recommendation for hiding vs. removing MovieClips when not in view?
Basically, I'm trying to find out:
Does having MovieClips on the stage but outside of the viewing area use a lot of resources?
How much of a penalty does removing and adding MovieClips to and from the stage incur?
Is there an estimate of how many MovieClips you are working with before you should switch from one method to the other?
Thanks!
--EDIT--
In my program, MovieClips will often have to reappear on the screen. This means that when I remove them from the stage, they might have to be added back. If I hide them off-screen, they might have to be moved back on-screen. This is why I don't just removeChild() everything and null out the object.
Does having MovieClips on the stage but outside of the viewing area
use a lot of resources?
Your MovieClip uses the same amount of memory whether it is inside or outside of the viewing area.
How much of a penalty does removing and adding MovieClips to and from
the stage incur?
Removing/nulling is cheap, creating new object is much more expensive.
Is there an estimate of how many MovieClips you are working with
before you should switch from one method to the other?
If you are dealing with hundreds or thousands of instances have a look into object pooling.
There is also a nice video tutorial about object pooling. It is worth watching if you want to know more about destroying/creating display objects.
If you do not intend to reuse the movieclips, you should definitely remove them. The action is costless and it frees the memory of your movieclip. Having a hidden movieclip uses the same amount of memory, it is just easier on the display process (your application won't lag but this is a major memory leak).
It's a good idea to remove them if they are not being used. If it's an item that moves (say at an x speed of 5px/s), even once it's left the screen the item is still being processed and is moving farther and farther away.
Basically if it's not in use and serves no purpose then remove it to save on resources.
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.
When i play a video game (any old game like a racing game or pack man or whatever) how does everything get displayed on the screen in terms of what is going on in the program? is there some big RenderEverything method that is executed once a frame? this strikes me as a bit of a slow way to go about such a thing though.
EDIT: as a follow up question:
How does the computer doing the rendering define the frame both for rendering graphis and for doing in game activites like having a character walk across a room slowly. Like is there some clock t that keeps increasing and every render and every movment hapens as a function of t? If so how is t defined relative to the system that it runs on?
I intend this question to be somewhat synonomous to: When my cursor in the screen right now blinks twice every second how does it know what a second is? Also in java how would i make a program that displays a line of text then waits a second and desplays another line? (perahps this is getting too spacific)
They have a loop. Inside this loop it's called a method for rendering graphics and another for processing logic (and getting input). So this method will calculate everything based on the input and the graphics method print on screen based on the data already computed -- like what should be printed and its position.
Is that what you asked?
Questions about game development should be made here: https://gamedev.stackexchange.com/ :)
When i play a video game (any old game like a racing game or pack man or whatever) how does everything get displayed on the screen in terms of what is going on in the program? is there some big RenderEverything method that is executed once a frame?
Depends on the game. 2D games may be able to keep part of scenes rendered in previous frames, especially old games without scrolling screens. 3D game most likely redraws entire screen. Also good game never renders everything - only visible objects. Because rendering everything is slow, while rendering only visible objects is significantly faster.
this strikes me as a bit of a slow way to go about such a thing though.
You are free to try to find different way. Normal game repaints every visible object. Non-hardware-accelerated game may track unmodified screen regions, and repaint only objects that changed, moved, etc. Hardware accelerated game doesn't have to do that - it can redraw everything on screen every frame. As game/frame/scene complexity increases, it is much easier to simply repaint every visible object during every frame instead of tracking things that changed from previous frame.
That's basically it. The 'video game' is effectively a big state machine where all state is updated according to a frame rate. User input combined with game rules and enemy AI affect the state of the game. Once every frame the players view of the game, not the complete view of the game, is rendered.
Download the quake source, it makes for some interesting reading in the comments and also gives excellent insight as to how a game is constructed.