I've got a problem in actionscript3 with moving large DisplayObject-s. When the size of the DisplayObject is quite large (more than screen size) the movement loses smoothness and it looks like the object starts jumping forward and backward, which overall looks very unpleasant.
Does anybody know the way to fix that? I am trying to make a sort of a race game, where I need to move the background sprite to make the illusion of movement.
Try turning on cacheAsBitmap. That may give you some performance improvements, especially if the object is static (doesn't have any animated bits in it). With AS3 and Flash Player 10 or newer you should be able to get smooth movement even with a large sprite. I've got several games that do it.
Have to agree with Laurent - it is probably better to split the background into small pieces and move them
Related
I've built an game in Libgdx which uses a single FitViewport passed-in to some Screens (Splash/Intro/Game/Menu/Pause etc.).
Each Screen has it's own Stage containing Groups of Actors - I've written a custom render loop to allow Screens to fade-in/out or slide around or render behind each-other - that's all great.
I now want a 'UI' screen which will rotate on smartphones to match their orientation (everything else in the game will NOT rotate).
I can make this work visually by using a TransformMatrix on the SpriteBatch but that doesn't affect the Stage's 'touch' detection (or debugdraw) and it seems there is no way to do this within the Stage (localtoparentcoords allows for rotation and scale but NOT transformation)
Bear in mind that it will not be 'square' (the FitViewport enforces 16x9 ratio) so it needs translation as well as rotation...
Note: I've tried to mess around with cameras but that's the wrong paradigm - cameras are a different view of the same thing - I want different things (transformation and rotated) drawn into the same view!
Note also: I've already started to create my own version of a Screen/Stage class to do this - I think it might be quicker than kicking the existing code into working properly but I'll be surprised if I'm the first person to want this?
I think I've sort-of solved this by stepping-back a bit and looking at how the Stage/Actor system works.
The idea of rotating AND transforming an entire Stage is fraught with complexity - that I could do it at the SpriteBatch level was a distraction which led to a lot of wasted time - sadly.
It was only when I realised that as I was calculating the position of all my UI (Actor) elements relative to either the screen center or a corner, I may as well take the further step of rotating and transforming them at the same time! I also realised that Grouping them ,made this very simple (indeed I could have static and rotating elements simply by using 2 separate Groups!)
Rotating/Moving an Actor will, of course, adjust it's bounding box/touch-area as well - so I now have a proper Stage/Group/Actor model which rotates as the device is rotated - I could be just static information (scores) or even a dynamic menu or an overlay for a 'cue' in a pool game or whatever...
As Edison would have said - I didn't waste 2 days, I just spent 2 days coming up with a large number of ideas which I now know not to work!
i have been looking into an effective way to simulate a camera in as3. everywhere i have read have basically told me the same thing; dont move the character, just move the stage around it.
ok, that works for simple things. but what happens when you want to zoom in? simply inflating objects doesnt work, because distances fluctuate and movement values suddenly arent to scale.
is there an effective way to work around this? vcams (virtual cameras) seem like an easy alternative, but from my research, i cant afford that memory
One easy solution is to just scale the entire instance of the game itself.
So, create an instance of the game's class, just like you normally would, and center it on the stage.
Then use scaleX and scaleY to make the instance of the game look bigger. The game will still behave like it should and you won't need to adjust the movement values or anything like that.
I'm making a game similar to 'Run' (http://www.albinoblacksheep.com/games/run) but I can't quite figure out the floor part. I'm not wanting the sides and a ceiling like in 'Run', just the main floor.
I'm new to Flash game development (AS3) but I know the basics. I realise the character isn't moving and is just turning (the level itself moves). How do a make a continuous floor, do I have to make a very long .fla file, or do I have to do this with code?
All ideas and help appreciated, Thanks. =)
You should use Tiles. Basically, a tile game consists of a lot of squared tiles, which are inserted when appear in screen and removed when goes out.
In your case, maybe you could use a big tile, with screen's size.
You can visualize a good example here, also a very good resource for gamedev on Flash.
You need to generate sprites of the edge of the screen and either recycle them when their x < some value or dispose and create new ones.
I think you can just use Bitmap.draw() to draw different pixels on a Bitmap that you've applied a 3D transformation to. You can see the basic concept illustrated here.
I hope my English is good enough.
The Problem:
I am developing some canvas game, using context2d. I did a perfomance test to see how well canvas render and stuff.
For painting, the method drawImage was used with some 50x50 jpg preloaded in memory at start.
My test was to instantiate a lot of logic square 50x50 objects moving random in the canvas
with no collission just to see the fps.
main loop was done with interval.
The problem, i noticed low fps when about 3000 random 50x50 on the screen, well i know the more you render, the less framerate. But i wanna ask something.
The question:
Is a good idea render every logic object in the canvas screen alone?
For example, with no collision, if i overlap two 50x50 in the same position, or almost the same position, the visible output is something lesser than (50·50)2 pixels, but i am drawing (50·50)2 pixels using drawimage for each element in the main loop.
Hope you guys understand the problem and the question.
Render alternatives? some logic techniques to archieve this instead of rendering every object alone?
I understand what you are asking, you are asking maybe you should try and rendering the collisions so you don't have to draw twice. Well frankly, I think you'd be better off just drawing the second square on top of the first one, and I'll tell you why:
Your logic will probably take more actions to determine the amount of overlapping and drawing the more complex shape, then actually drawing it.
So in my opinion, you'd be better off not testing for collisions in this one.
People, correct me if I'm wrong.
Definitely just draw. The bitblt (pixel copy) is optimized and will certainly be faster than collision logic between sprites. However, the one exception is possibly testing for off-screen sprites. This is a fast test because you're only checking against the screen bounds, that is, if a sprite is off the screen. If you have 10,000+ sprites, and many are off-screen most of the time - for example when zoomed in - then the test is worth it.. If they're always on screen, then just draw.
I'm working with a few programming buddies to create an AS interface to the kinect and one problem we're running into is image differencing. We need to be able to throw out image data that doesn't change from image to image so we can pin-point only things that are moving(i.e. people).
Anyone have any experience with this or a direction we can go?
I would consider creating a pixel bender shader to find the difference and also do any other math or tracking. Pixel bender gets its own thread outside of the normal flash player so you can get some more horse power for your setup. Pixel Bender shaders can be applied to bitmaps, vectors, or video so I think it is perfect for this project. Good Luck!
http://www.adobe.com/devnet/flash/articles/pixel_bender_basics.html
And is is a full collection of shaders including difference
Take a look at the threshold method on BitmapData.
It'll allow you to do this stuff. Their docs have a simple example so check that out.
It might be a long shot, and this is just me rambling, but in sound theory (strange how I'm relating it to image cancellation, but here goes...) the concept of cancellation is when you take a wave sample and add its inverse. It's how you make acapellas from instrumentals + originals or instrumentals from acapellas + originals.
Perhaps you can invert the new image and "normalize" the two to get your offsets? I.e. the first image is 'black on white' and the second image is 'white on black', and then detect the differences for the bitmap data. I know I did a similar method of finding collisions with AS3 a few years back. This would, in theory, cancel out any 'repeating' pixels and leave you with just the changes from the last frame.
With BitmapData your values are going to be from 0 to 255, so if you can implement a cancellation (because a lot of parts of the image are going to stay the same from frame t frame) then you can easily find the changes from the previous frame.
Just a thought! Whatever your solution is it's going to have to be quick in order to beat the flash runtimes' slow speeds. Your Kinect read FPS rate will be greatly hindered with bad code.
Here is some frame differencing code I wrote awhile back. It uses bitmapData: http://actionsnippet.com/?p=2820
I also used this to capture moving colors in a video feed: http://actionsnippet.com/?p=2736