The current way I'm doing it works, but is really heavy on performance, and I'd like to reduce the lag as much as possible.
Basically I'm copying the pixels of said FlxCamera onto an FlxSprite, and then I'm rendering that FlxSprite's pixels to a normal Sprite (openfl.display.Sprite), which then gets put onto the window. The lag doesn't seem to be coming from putting the camera onto an FlxSprite, it seems to be coming from putting the FlxSprite onto the Sprite (this is all in the update function btw). Is there a better way to put the FlxSprite onto the Sprite without having to copy the pixels every single frame? Or possibly a better way of copying the pixels that lags less?
This is the current code for it (just the FlxSprite to Sprite part):
notesSprite.graphics.clear();
notesSprite.graphics.beginBitmapFill(cameraSprite.pixels, new Matrix());
notesSprite.graphics.drawRect(0, 0, cameraSprite.pixels.width, cameraSprite.pixels.height);
notesSprite.graphics.endFill();
I've tried removing endFill(), nothing changed. I've tried removing drawRect() from update and only calling it once but that made the Sprite empty. I've scrolled through all the functions and variables to see if there was another way, but it didn't seem like it.
running clear() does seem to reduce the lag a lot, but considering I have a really good pc and it's still bringing me down to 60 fps, I wanna make sure the game is playable on other people's pcs that may or may not be as good. I've yet to test this on a worse pc (I'm gonna send a build to my friend soon so he can test it), but seeing as I'm working with a rhythm game I wanna make sure that the fps stays at 60 or higher constantly.
Related
I have a weird problem I can't figure out. I'm new enough to Unity 3D I have a hard time even posing the questions sometimes.
Take a careful look at this picture where I drew the red circles:
The problem is that both in the actual game and in the animation preview, this Mixamo character, using the Mixamo running animation, shows her feet under the ground. Actually, this is a problem with all animations. She does NOT start out under the ground (and in fact starts above ground.) But when the game runs, she falls to the ground (well, she doesn't really fall since she has no ridge body. She appears suddenly at level 0, which you'd think is right on the ground, but in fact it shows her a foot or two under the ground), and the animation then plays with her too low. She doesn't have a ridged body, so that is not the problem.
You can also see my settings for the animation. I've played around with all of them and can't fix it. This happens whether or not I apply root motion or foot IK.
Is there a way to 'lift' the animation up so that it is right on the ground?
I just found an issue in Unity. When i kept the T-Pose Model (Skinned) in a folder and the animation of it in another folder then the Animations turn out to misbehave. Like Legs twitching or parts of body going down. When I brought the T-Pose and other animations together in one folder and updated the reference in Rig of T-Pose then all became normal.
One shitty basic problem is just:
There's an obscure setting actually on "Layers" in Animator, on the "base" layer you have to explicitly turn on "IK Pass".
Only in very unusual situations would you want this "off", just another bizarre mistake by Unity.
Reimporting fixed the problem. I do not know why. It seems that when you play with the animations, they sometimes get corrupted.
I'm trying to implement a cross-platform UI library that takes as little system resource as possible. I'm considering to either use my own software renderer or opengl.
For stationary controls everything's fine, I can repaint only when it's needed. However, when it comes to implementing animations, especially animated blinking carets like the 'phase' caret in sublime text, I don't see a easy way to balance resource usage and performance.
For a blinking caret, it's required that the caret be redrawn very frequently(15-20 times per sec at least, I guess). On one hand, the software renderer supports partial redraw but is far too slow to be practical(3-4 fps for large redraw regions, say, 1000x800, which makes it impossible to implement animations). On the other hand, opengl doesn't support partial redraw very well as far as I know, which means the whole screen needs to be rendered at 15-20 fps constantly.
So my question is:
How are carets usually implemented in various UI systems?
Is there any way to have opengl to render to only a proportion of the screen?
I know that glViewport enables rendering to part of the screen, but due to double buffering or other stuff the rest of the screen is not kept as it was. In this way I still need to render the whole screen again.
First you need to ask yourself.
Do I really need to partially redraw the screen?
OpenGL or better said the GPU can draw thousands of triangles at ease. So before you start fiddling with partial redrawing of the screen, then you should instead benchmark and see whether it's worth looking into at all.
This doesn't however imply that you have to redraw the screen endlessly. You can still just redraw it when changes happen.
Thus if you have a cursor blinking every 500 ms, then you redraw once every 500 ms. If you have an animation running, then you continuously redraw while that animation is playing (or every time the animation does a change that requires redrawing).
This is what Chrome, Firefox, etc does. You can see this if you open the Developer Tools (F12) and go to the Timeline tab.
Take a look at the following screenshot. The first row of the timeline shows how often Chrome redraws the windows.
The first section shows a lot continuously redrawing. Which was because I was scrolling around on the page.
The last section shows a single redraw every few 500 ms. Which was the cursor blinking in a textbox.
Open the image in a new tab, to see better what's going on.
Note that it doesn't tell whether Chrome is fully redrawing the window or only that parts of it. It is just showing the frequency of the redrawing. (If you want to see the redrawn regions, then both Firefox and Chrome has "Show Paint Rectangles".)
To circumvent the problem with double buffering and partially redrawing. Then you could instead draw to a framebuffer object. Now you can utilize glScissor() as much as you want. If you have various things that are static and only a few dynamic things. Then you could have multiple framebuffer objects and only draw the static contents once and continuously update the framebuffer containing the dynamic content.
However (and I can't emphasize this enough) benchmark and check if this is even needed. Having two framebuffer objects could be more expensive than just always redrawing everything. The same goes for say having a buffer for each rectangle, in contrast to packing all rectangles in a single buffer.
Lastly to give an example let's take NanoGUI (a minimalistic GUI library for OpenGL). NanoGUI continuously redraws the screen.
The problem with not just continuously redrawing the screen is that now you need a system for issuing a redraw. Now calling setText() on a label needs to callback and tell the window to redraw. Now what if the parent panel the label is added to isn't visible? Then setText() just issued a redundant redrawing of the screen.
The point I'm trying to make is that if you have a system for issuing redrawing of the screen. Then that might be more prone to errors. Thus unless continuously redrawing is an issue, then that is definitely a more optimal starting point.
As an exercise, I decided to write a SimCity (original) clone in Swift for OSX. I started the project using SpriteKit, originally having each tile as an instance of SKSpriteNode and swapping the texture of each node when that tile changed. This caused terrible performance, so I switched the drawing over to regular Cocoa windows, implementing drawRect to draw NSImages at the correct tile position. This solution worked well until I needed to implement animated tiles which refresh very quickly.
From here, I went back to the first approach, this time using a texture atlas to reduce the amount of draws needed, however, swapping textures of nodes that need to be animated was still very slow and had a huge detrimental effect on frame rate.
I'm attempting to display a 44x44 tile map where each tile is 16x16 pixels. I know here must be an efficient (or perhaps more correct way) to do this. This leads to my question:
Is there an efficient way to support 1500+ nodes in SpriteKit and which are animated through changing their textures? More importantly, am I taking the wrong approach by using SpriteKit and SKSpriteNode for each tile in the map (even if I only redraw the dirty ones)? Would another approach (perhaps, OpenGL?) be better?
Any help would be greatly appreciated. I'd be happy to provide code samples, but I'm not sure how relevant/helpful they would be for this question.
Edit
Here are some links to relevant drawing code and images to demonstrate the issue:
Screenshot:
When the player clicks on the small map, the center position of the large map changes. An event is fired from the small map the central engine powering the game which is then forwarded to listeners. The code that gets executed on the large map the change all of the textures can be found here:
https://github.com/chrisbenincasa/Swiftopolis/blob/drawing-performance/Swiftopolis/GameScene.swift#L489
That code uses tileImages which is a wrapper around a Texture Atlas that is generated at runtime.
https://github.com/chrisbenincasa/Swiftopolis/blob/drawing-performance/Swiftopolis/TileImages.swift
Please excuse the messiness of the code -- I made an alternate branch for this investigation and haven't cleaned up a lot of residual code that has been hanging around from pervious iterations.
I don't know if this will "answer" your question, but may help.
SpriteKit will likely be able to handle what you need but you need to look at different optimizations for SpriteKit and more so your game logic.
SpriteKit. Creating a .atlas is by far one of the best things you can do and will help keep your draw calls down. Also as I learned the hard way keep a pointer to your SKTextures as long as you need them and only generate the ones you needs. For instance don't create textureWithImageNamed#"myImage" every time you need a texture for myImage instead keep reusing a texture and store it in a dictionary. Also skView.ignoresSiblingOrder = YES; helps a bunch but you have to manage your own zPosition on all the sprites.
Game logic. Updating every tile every loop is going to be very expensive. You will want to look at a better way to do that. keeping smaller arrays or maybe doing logic (model) updates on a background thread.
I currently have a project you can look into if you want called Old Frank. I have a map that is 75 x 75 with 32px by 32px tiles that may be stacked 2 tall. I have both Mac and iOS target so you could in theory blow up the scene size and see how the performance holds up. Not saying there isn't optimization work to be done (it is a work in progress), but I feel it might help get you pointed in the right direction at least.
Hope that helps.
So I have established the base for an SFML game using a tilemap. For the most part, I've optimized it so it can run at a good 60 fps. However, I can only get this 60 fps if at some point the map is halfway off the screen so there is less of it being rendered. This seems like it would make sense, less being drawn means it runs faster, but once the fps increases it stay permanently, even if I then make the entire screen rendering the map with the map. I can't understand this irregularity with the fps in that I either have to start the map slightly offset, or move the map offscreen for a moment to get a solid fps. Clearly there isn't a problem with the ability of my computer to render at this fps, as it can stay there once it starts, but I can't understand why the map has to be offscreen momentarily for it to achieve this speed.
How does Flash deal with elements that are off-stage?
Obviously Flash doesn't actually render them (because they don't appear anywhere on-screen), but is the process of rendering them still existent, slowing down my game as much as it would if the elements were on-screen?
Or does Flash intelligently ignore elements who don't fall into a renderable area?
Should I manually manage removing objects off the DisplayList and adding them back on as the exit and enter the stage, or is this going to be irrelevant?
Yes, they are slowing down your game.
In one of my early experiments I've developed a sidescroller game with many NPCs scattered around the map, not all visible in the same screen. I still had to calculate stuff but they weren't on the screen. The performance was significantly better when I handled their removal off the display list when irrelevant (by simply checking their X in relation to the 'camera'). Again, I'm not talking about additional code and events that may be attached to them, just plain graphical children of a movieclip.
The best practice though, in my experience, is drawing the objects in bitmaps. Of course if you're too deep into your game already this may be irrelevant, but if you have the time to invest, this is one of the best ways to get the most out of AS3 regarding 2D games. I found some of the greatest tutorials regarding bitmaps and AS3 in 8bitrocket
http://www.8bitrocket.com/books/the-essential-guide-to-flash-games/ I can elaborate on the subject if you want, but I think I'm going off topic here.
Even if some display objects are out of the stage area, they are still executed. If they have any animation playing in them, that might slow down the performance.
The question arises, why do we need to keep unused items outside the stage area? if you need to 'cache' the movieClips for faster loading , then load them in a keyframe where the control will never go. for eg. load the display objects which you want to show in frame 1, then put a stop() in the actions panel of the frame, make it a key frame, and in frame 2 load the unused animations. since there is a stop() in frame 1, the control never goes in frame 2, but the display objects are cached.
Or, if you have codes in the unsused displayobjects, and thus need to load them along with the main game components, then, try putting stop() in the frames of the unused display objects so that they don't animate.