I'm not sure why, but for some reason whenever the camera in my game moves, everything but the character it's focusing on does this weird thing where they move like they should, but they almost vibrate and you can see a little trail of the back of the object, although it's very small. can someone tell me why this is happening? here's the code:
x+= (xTo-x)/camera_speed_width;
y+= (yTo-y)/camera_speed_height;
x=clamp(x, CAMERA_WIDTH/2, room_width-CAMERA_WIDTH/2);
y=clamp(y, CAMERA_HEIGHT/2, room_height-CAMERA_HEIGHT/2);
if (follow != noone)
{
xTo=follow.x;
yTo=follow.y;
}
var _view_matrix = matrix_build_lookat(x,y,-10,x,y,0,0,1,0);
var _projection_matrix = matrix_build_projection_ortho(CAMERA_WIDTH,CAMERA_HEIGHT,-10000,10000)
camera_set_view_mat(camera,_view_matrix);
camera_set_proj_mat(camera,_projection_matrix);
I can think of 2 options:
Your game runs on a low Frames Per Second (30 or lower), a higher FPS will render moving graphics smoother (60 FPS been the usual minimum)
another possibility is that your camera is been set to a target multiple times, perhaps one part (or block code) follows the player earlier than the other. I think you could also let a viewport follow an object in the room editor, perhaps that's set as well.
Try and see if these options will help you out.
If your camera is low-resolution, you should consider rounding/flooring your camera coordinates - otherwise the instances are (relative to camera) at fractional coordinates, at which point you are at mercy of GPU as to how they will be rendered. If the instances themselves also use fractional coordinates, you are going to get wobble as combined fractions round to one or other number.
I am experiencing HUGE performance issues with iOS9 and I just can't figure out what to do. I've read many posts - here, and here for example, but their suggested solutions don't help or make little difference.
My game has gone from 60fps on an old iPad 2 (iOS 8.4) to < 15fps on a new iPad mini (iOS 9).
I'm trying to work out the main culprit. I'm pretty certain one of them is SKCropNodes. I usually render several SKCropNodes in my scene (6 - 18). This was never an issue in iOS8, but it appears iOS9, while it does a better job of cropping, also eats up performance doing so.
If I render the crop nodes as normal SKSpriteNodes, I gain maybe 5fps on old devices, and up to 30 on a newer iPhone 6. I have no alternative to using crop nodes, but it can't be the whole problem.
I thought perhaps the wrong texture atlas was being used - i.e. one of a much larger resolution. However forcing my device to use a very small atlas made no difference.
I'm using Texture Packer to generate my atlases with scaling variants for the different devices. I've noticed XCAssets now features an option to add a Sprite Atlas (I can't seem to find any documentation about this). This isn't suitable to my game, since I use 100s of sprites. I've tried adding my atlases to XCAssets, but then for some reason it won't use the scaling variants. Nevertheless, with low res textures, it still runs terribly.
I have tried setting
skView.ignoresSiblingOrder = YES;
and given all my nodes zPosition values, but still no effect. I have also added the .png extension to every image name (originally a problem that meant they wouldn't render.)
I have some SKEffectNodes in my scenes, but removing and adding these doesn't seem to have an effect.
I don't understand how the same hardware and the same code can produce such drastically different results. Obviously Apple has changed something to do with rendering that has had an adverse effect. They also seem to have no intention of fixing these issues. I am aware of bugs on the issue that have been there for months - long before iOS9 was released.
I've been working on this game for 2 years now, and only just released it before iOS9. It's now suffering from terrible performance, and regular crashes.
Has anyone figured out what exactly Apple did to kill performance? If I knew that, I could at least try to work around it... Thanks.
UPDATE
Below are some figures for the same scene, with the absolute maximum number of nodes the game would generate at one time.
iOS 8, iPad 2, ~200 nodes, ~100 draws, 58.7 - 60 fps
iOS 9, iPhone6, ~280 nodes, ~216 draws, around 20 fps
I assume the difference in number of nodes is due to the different screen sizes. If I change the scene on iPhone 6 to achieve equivalent values, the FPS is still around 24.
UPDATE 2
Using Xcode's template Sprite Kit project, and changing the spaceship to an SKCropNode containing the spaceship, on iOS 8 I am able to add 100s of ships with no frame rate issue. On iOS 9, same project, I can add about 25 before the frame rate drops to < 30.
iOS 8 on iPad2:
iOS 9 iPhone 5:
In terms of texture atlas use, as in my comment, I can't guarantee that anything will be drawn from the same atlas. My game contains customised characters, with assets from a range of atlases (each of which contains ~100 textures). There can be up to 9 characters on screen at a time. I understand this isn't the most efficient in terms of draws, but I've never had a problem until iOS9...
Update 3
I've submitted a bug to Apple, including my sample program. I also used up one of my tech support requests. So far, nothing from Apple.
There are two main issues.
One is a radical drop in performance of Sprite Kit from iOS 8 to iOS 9 for all manner of reasons, some of which you've linked to, but there are others. It seems many aspects of rendering, sorting and storing/dealing with nodes is either broken or doubling or tripling their previous loads on CPU/GPU.
However there's another issue that further compounds efforts to resolve any of the possible performance problems. It's a pervasive and seemingly arbitrary frame rate capping mechanism that's most frequently noticeable when it operates at 40fps. But it also operates at other frequencies.
For many years this capping has been (rarely) noticed when folks manually use CADisplayLink to create game loops or other timing based mechanisms on a frame per frame basis.
With iOS 9 this seemingly automated capping has become a terribly unwanted "feature" of Sprite Kit, SceneKit, Metal and OpenGL ES based applications.
In the case of SceneKit this is most telling because the capping occurs regardless of rendering choice - Metal or OpenGL - and seemingly on all devices, including things like the new 6S phones and the iPad Air 2, even with very simple, default template projects.
"Renderer" is a line item in the detailed statistics of SceneKit, onscreen, on the device. It's the most telling indication of a capping process. It's not there when a game runs stably at 60fps.
When capped at 40fps, no matter the amount of time required to do other activities onscreen and in logic, this component will absorb all remaining time in the game loop needed to maintain a solid 40fps capping. It varies according to the time required for other actives, always forcing an apparent goal of the underlying OS to hold the frame-rate at 40fps.
This problem in conjunction with the issues regarding iOS 9 Sprite Kit performance mean that it may not currently be possible to resolve all your issues. It will be extremely difficult to ascertain when you're hitting one of these (seemingly) arbitrary fps caps versus having caused an actual problem.
Just as an aside, these caps are not limited to 40fps. I've noticed them at 30fps, 24fps, 20fps, 15fps, 12fps and 8fps.
Of course Apple has never conceded nor admitted to this capping mechanism within the OS, nor commented on when/how/why it's so heavily impacting game and rendering processes.
My theory, as expressed in this post ( Inconsistent SceneKit framerate ), is that it's part of iOS designed to facilitate the use of variable frame rate technology soon to come in the iPad Pro, and possibly in other devices.
It would make sense that 120Hz become a base rate for future devices, particularly given the focus on performance advantages of iOS, the new Apple TV and 240Hz sampling of the screen touches/pen within the iPad Pro... and the considerable number of 120Hz televisions in the market.
Even without variable frame rate technology (say... your TV), 120Hz display rates means 24fps movies can be played back at a stable 5:5:5 pattern of frame display -- this massively increases the joy/immersion when watching films, just about all of which are shot at and truly exploit the advantages of a true 24fps for blur and motion effects.
120Hz with either variable frame rate technology or 5:5:5 frame display will also save Apple enormous effort in terms of compression and decompression of films when compared to the pulldown methods currently used on all devices with a maximum frame rate of 60fps.
All speculation, but I'd guess the use of these frame rate cappings in game engine technologies are there to help make games use less power, too, and give (in the future) developers an option to framerate lock their games in a variable frame rate device world. It's very unfortunate that (if this is the case) they have done such a poor job or sorting out the capping issues in the OS and the nature of Sprite Kit, leading to a scenario where you're fighting blindly to get good, high, consistent frame rates.
Apple silence and seemingly uncaring attitude towards the problems these two sets of issues are causing is (quite possibly) a very strong indication of how they feel about "their game development community".
And it's the greatest single problem of dealing with the kinds of cutting edge and performance critical development problems inherent to game making within a closed source framework from a needlessly secretive and uncommunicative (almost belligerent) organisation.
It seems the majority of iOS9 issues are addressed in the latest iOS9.2 beta & Xcode 7.2 beta.
Thank you Apple for finally addressing the problem. Too bad I spent 2 months working on work-arounds.
I've been posting on Apple's forums, submitting bugs and communicating with a support technician. It's a shame that at no point did Apple offer any clarity over what issues they were aware of, and what the Sprite Kit team were addressing.
Still, at least it seems the majority of Sprite Kit issues are now resolved, and a career change is no longer necessary :]
In the example you provided I can see one way to improve the draw count and to validate that the crop node isn't the problem. I don't know how practical this is in your actual game, but this drastically limits your draw calls.
#import "GameScene.h"
#interface GameScene ()
#property(nonatomic, strong)SKTexture *spaceshipTexture;
#end
#implementation GameScene
-(void)didMoveToView:(SKView *)view {
/* Setup your scene here */
SKLabelNode *myLabel = [SKLabelNode labelNodeWithFontNamed:#"Chalkduster"];
myLabel.text = #"Hello, World!";
myLabel.fontSize = 45;
myLabel.position = CGPointMake(CGRectGetMidX(self.frame),
CGRectGetMidY(self.frame));
[self addChild:myLabel];
//Create one texture to be used over an over
SKSpriteNode *sprite = [SKSpriteNode spriteNodeWithImageNamed:#"Spaceship"];
sprite.xScale = 0.5;
sprite.yScale = 0.5;
SKCropNode *cropNode = [[SKCropNode alloc] init];
SKSpriteNode *mask = [SKSpriteNode spriteNodeWithColor:[UIColor blackColor] size:CGSizeMake(100, 100)];
mask.position = sprite.position;
[cropNode setMaskNode:mask];
[cropNode addChild:sprite];
[self addChild:cropNode];
//temp add to scene to create the texture than remove
//keep pointer to texture so it can be reused
self.spaceshipTexture = [self.view textureFromNode:cropNode];
[cropNode removeFromParent];
}
-(void)touchesBegan:(NSSet *)touches withEvent:(UIEvent *)event {
/* Called when a touch begins */
for (UITouch *touch in touches) {
CGPoint location = [touch locationInNode:self];
//re use texture
SKSpriteNode *sprite = [SKSpriteNode spriteNodeWithTexture:self.spaceshipTexture];
sprite.position = location;
[self addChild:sprite];
}
}
#end
The downside is that the issue remains when you get up to 120+ ish nodes on screen.
Also note I created a fresh SpriteKit app using the default template and removed the SKAction. Unfortunately even the default Apple template suffers huge fps drops when you get up to 120+ nodes. So I don't know if there will be an answer and your best course of action is to file a bug report because I believe it should (and use to be able to) handle that many on screen without a drop in fps.
Also something worth noting this error comes up on the default project which could be related...
2015-10-20 10:46:50.640 Test[2218:658384] <CAMetalLayer: 0x15fe987c0>: calling -display has no effect.
Update
Doing a little more research I ran into this...
https://forums.developer.apple.com/thread/14487
Looks like others are filing bugs for this...
Lots of draws... Have you tried this?
skView.ignoresSiblingOrder = YES;
Are you using SKLightNode? If so try removing all light node's from your code. I did this and my game is running back at 60fps like it did in iOS8.
Source:SKLightNode performance issues
I'm having a strange and irritating problem on WinRT Surface tablet when using DirectX (hosted in BackgroundSwapChainPanel). Basically once in a while (like once a day, or few times a week / while testing for few hours every day), half of my 3D scene goes black, like on the picture below (cut vertically or sometimes horizontally):
http://www.zurawcli.vot.pl/dxProblem.JPG
While this happens, the DirectX is still rensponsive and i have full control of the app.
I don't think posting code makes any sense ( i'm simply using standard SwapChain and resizing viewport and back texture whenever screen size changes - actually getting screen size from Core Window). This only happens once in a while : ( when i try to explicitly force this - like by splitting screen between two / switching between apps / and so on, I CANNOT repeat this error - viewport always resizes correctly. Then sometimes just using the app, this will happen.
Did anybody had any experience similliar to this ? Any ideas what is causing this ?
Thanks in advance,
cheers
i developed a game for the iphone4. Now i got problems with the iphone5 and the 4inch screen. My game is on the left side of the 4inch screen and i have a big black border on the right side. But the buttons from the game are in the middle of screen, they have same position like on the iphone4. I checked everythin but i dont know why the background-images and the sprites are on the left side and the buttons are in the middle. I want that everything is in the middle or on the left side. It would be great if anybody could help me!! Thanks!!
COCOS2d-iPhone:
If you're using the latest beta, the only change you should need to
make is export all your images at twice the size and use the "-hd"
suffix, similar to Apple's "#2x". The documentation also says you need
to set the content scale factor of the director.
You can find the documentation here.
and more detail here.
COCS2d-X:
Cocos2D-x has a very easy solution for multi-resolution problem.
In fact you just need to set your DesignResolution and then just imagine your target device will has this resolution.
If target device really has this resolution ( or some other but with same ratio) cocos2d will handle to fix screen and your game looks same in all devices.
And when ratio of target device is different, you have many option ( as cocos2d language, policy) to manage that.
For example if you use Exact fit policy, cocos2d will force your game ( and design) to fit target device screen (without that black boarder).
Exact fit
The entire application is visible in the specified area without trying
to preserve the original aspect ratio. Distortion can occur, and the
application may appear stretched or compressed.
For more detail just take a look at this link : http://www.cocos2d-x.org/projects/cocos2d-x/wiki/Multi_resolution_support
I have a little iPad app which shows a MKMapView instance (map). In order to save the state I try saving the map.region to the NSUserDefaults. This works very well storing only the single values as doubles. On launching, the app combines the numbers and produces a valid MKCoordinateRegion. This happens in application:didFinishLaunchingWithOptions:. Now there are several problems.
1) Imagine: You leave the app in landscape orientation. The app saves the corresponding MKCoordinateRegion. The app is terminated. Now, holding the iPad landscape, launching the app, the map doesn't show the same state as before leaving the app. And no, this is not a problem of regionThatFits:. I tracked it down and this is what happens: Also when it isn't visible to the user, the app starts in portrait mode. The app restores his state. After that the map is rotated into landscape mode.
With other words the app saves the landscape state but restores it to portrait. If you repeat these steps the map zooms out with every launch. Not the best UX.
2) Even if problem one would be solved by restoring in the right orientation there is still the problem that the launching orientation could differ from the leaving orientation. I think one of the better ways to solve this is to store always the values for the portrait orientation also when the user leaves in landscape. By doing this the state would be restored properly because the app is launched initially in portrait by the system.
One possible way would be to change the latitude/longitude values if the app is left in landscape. But this would be too inaccurate because CLLocationDegrees differ if they are latitude or longitude.
An other way (and I think this would be the best way) would be to "simulate" a rotation of the mapview or to calculate the visible region for the portrait mode when the app is left. But I really don't know how to do this. Here is the point where I need your help and your ideas.
I appreciate every ray of hope. :) — And please tell me if I think into a wrong direction.
Hmm. If I understand your question correctly, you're saving the MKMapView's region (that is, its center and span), and would like to use these values to restore the map's center and zoom level, independently of whether the user rotates the device between sessions.
Have you tried calculating the width-to-height ratio of your map rectangle, and then multiplying out the changes to the span? That is, if your map has bounds of size 800 x 600 in landscape mode, then you'd multiply the longitudeDelta by 600/800 (0.75) and the latitudeDelta by 800/600 (1.33) to get the appropriate span for a 600 x 800 rectangle in portrait mode.