I'm programming a 2D game with HTML5 canvas. so it won't take a lot of time for rendering all the objects and frames.
I want to ask about both 2D and 3D games.
Suppose that I made a change or more on one of the objects.should I render all the objects when I only need to redraw that object? is rendering all objects and frames is the only option? and if the game was 3D, won't rendering take a lot of time? specially on slow internet connections
So [performance] depends only on the browser and computer of the user.
If you are making a game which is played simultaneously across several computers then the connection speed is important. Otherwise, the connection speed is mostly irrelevant (except as it relates to initially downloading your game resources). A better CPU/GPU, memory on the local computer will most affect your app performance.
About performance
In theory, you get better performance if you redraw only those game items which have changed since the last frame.
In practice, redrawing one game item often requires redrawing multiple other game items. You might want to redraw the player who moved, but in doing so you must also redraw the background plus any other game items colliding with the player.
As a result, it's often better to clear the entire canvas and redraw all the game items in their current position. So the unsatisfying answer to your question is that you should test your unique game app to determine if you can efficiently redraw just changed items or if a complete redrawing is faster.
Related
I am writing a program in visual basic 2010 to create a 2D scrolling map. I am using Pictureboxes at the moment, all 50 by 70 in size. It starts with 1, and depending on what is needed may easily end up with 1000 - 2000 of them. They all need to be clickable. I am concerned it might use too many resources and run too slow. Can anyone tell me what the best approach to make something like would be.
Thankyou.
A common method is to only draw the tiles (or pictureboxes in your case) when they can be seen by the player's camera. So you should first determine how many boxes fill the screen and then calculate whether or not they are within the bounds of the player camera as represented by a rectangle. Additionally, you should draw boxes slightly outside the player's view (1 or 2 additional boxes per edge, this is explained below).
When the player moves, move the position of the world, not the player. So if the player moves left, scroll all of the tiles to the right while the player sprite remains stationary. Now when a player's position changes you should check again which tiles are visible in the player's screen. Since you are drawing additional rows slightly outside the view of the player, the edges will smoothly scroll in and will not 'pop' in as is a common problem when starting out.
Since you are only drawing tiles which are visible to the player, your game should run a lot more efficiently. It is OK to store this data in a 2D array in memory for now. In the future when you have huge maps, it may be a good idea to load sections of your map which are far outside of the player's view from disk to memory. You don't want to load in map data from disk which the player can navigate to before it is fully loaded.
Exactly how much map data to store in memory is up to you and depends on what platforms you want to release on and other constraints.
Additionally, you may want to look into different rendering libraries. Common low-level libraries are DirectX and OpenGL. These libraries work directly with your graphics card to dramatically speed up rendering. There are libraries built on top of those for various languages, but I don't know any for Visual Basic. An example for JavaScript is PixiJS. Additionally, there are full featured game creation libraries such as Unity or the Unreal Engine 3.
Some background:
I have an existing OS X card game app that uses OpenGL.
The window is resizable, and a 4:3 aspect ratio is always maintained.
When the window is resized, the OpenGL view is resized accordingly. All visual elements are scaled accordingly. i.e. the cards maintain their relative sizes and distances from each other.
I'm interested in moving the code to a system that either uses Sprite Kit, or one predominantly based on Core Animation layers. Sprite Kit is more attractive to me in terms of feature set for my needs, but...
... I am concerned about Sprite Kit performance (or rather, needless performance, particularly on battery-powered Macs) for a game that essentially blasts the same textures to the screen, 60fps, even when nothing much is happening. (Most of the time, the cards are static, as the player ponders their next move.)
To reduce some of the (repetitive) drawing required, particularly at very large window sizes (e.g. fullscreen on a 30" monitor), I'm interested in using a "dirty rects/region" or "as-required" drawing system.
Question:
Does Sprite Kit provide some kind of dirty-rect drawing system, or the ability to implement such a drawing system? (Or, is it basically going to draw everything over and over at 60fps, regardless of the need to redraw?)
SK is a OpenGL renderer, naturally it will redraw its contents every frame. That however doesn't make it slow. While the dirty rect drawing of UI frameworks is a way to improve performance but also to reduce power consumption, they have to use this approach because rendering in UI frameworks is typically a lot slower (often not hardware accelerated) than in an OpenGL renderer.
On the other hand SK can be slower frame over frame if the rendered scene's complexity is extreme. But that sounds highly unlikely for a card game.
Generally You shouldn't concern yourself with performance until you wrote some code to test it with. Premature optimization and all...
background: i am developing a real-time multiplayer html5 canvas game using kineticjs which primarily will be played on MOBILE PHONE BROWSERS. There's a lot going on in the game such as socket communication with the server every second, redrawing and animations using kineticjs based on the server response and all this on top of a heavy graphic interface. The game functions well in desktop browsers however is SLUGGISH on mobilephones. So, I need to find all the ways in which the code can be optimized.
My questions,
lets say I need to redraw a particular part of the screen based on a server response that I just received from server, should I keep these need-to-be-redrawn elements in a separate layer, so that I need to redraw fewer elements. As in my case I need to redraw ever second, will this lead to performance improvement?
If the answer to the above is yes, then what is the optimal number of layers in which I should divide my layout. I ask this because I have a lot of different parts on the screen that need to be redrawn based on different server responses (although not all at the same time), if all these need to be put in separate layers, I need to know how far I can stretch the logic above, for example can I have 10 different layers without sacrificing the performance which is the aim of all this exercise anyway.
Eric Rowell (creator of KineticJS) has done some stress tests here: http://www.html5canvastutorials.com/labs/html5-canvas-kineticjs-drag-and-drop-stress-test-with-1000-shapes/
And he says this:
"Create 10 layers each containing 1000 shapes to create 10,000 shapes. This greatly improves performance because only 1,000 shapes will have to be drawn at a time when a circle is removed from a layer rather than all 10,000 shapes."
"Keep in mind that having too many layers can also slow down performance. I found that using 10 layers each made up of 1,000 shapes performs better than 20 layers with 500 shapes or 5 layers with 2,000 shapes."
So your takeaway is that
1.Yes, multiple canvas layers which isolate different groups of redrawables is the way to go.
And,
2.To optimize the tradeoff ( overhead of multiple canvas’s vs simplicity of 1 canvas ), you need to test with your own particular code in the environments they will be operating within.
Good luck with your game :)
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.
I've been doing some research on caching resources for a game environment. By analyzing various games both 2D and 3D, I've come up with some questions.
In 2D games, such as Link to the Past, we see seemless transition from overworld to dungeon, or from house to overworld etc. I would imagine this means that all the game's resources are precached. That's all fine for 2D games since their resources tend to be smaller, but what about 3D games?
Half-Life 2 and Assassin's Creed for example, both have a loading screen inbetween map transitions. I know HL2 uses a sound cache, where a 5 second clip of the start of music will play while the actual mp3 loads. But this doesn't answer questions about textures and models. Do these games precache these resources to speed up load times, or do they not to save memory?
Further, we see 3D games like Twilight Princess where there is again seemless transition. Is this implying that all resources are cached here as well? I can understand this a bit more for PC games, but on the Wii of all platforms?
Overall, what is the best option to use for game development in both 2D and 3D environments?
Loading screens are what happens when a game's resources are moved from being on disk to being in RAM, while something like Twilight Princess uses something akin to Lazy Loading, where parts of the world are dynamically loaded into the game (while unloading other parts of the world to keep RAM usage low). Resources aren't necessarily cached, so much as managed differently.
In the case of a 2d game like Link to the Past (or Super Mario), there ARE loading screens, but they're short enough and often hidden by Link entering a dungeon, or the level/amount of lives left message in Mario, or the animation of going through a door in Metroid. Also, and perhaps more accurately, cartridge based games are effectively solid state memory, and the memory access speed is equivalent to RAM.
As always, the best option depends on what you're making. Ideally, you want to prevent ANY loading screens, but that's usually hard/impossible, especially with a large 3d game with tons of assets. While some games are clearly divided into levels (Portal especially comes to mind here), an open world game wouldn't be any good if you had to sit through a loading screen every city block. 2d games are a bit easier, since you don't have to deal with complex model data, but many of them have some sort of loading screen, usually when you start the game. The more complex the game, the more likely you'll have to deal with some sort of loading screen.
For great examples of 'lazy loading' in games, check out (the 3d) Grand Theft Auto games, Minecraft (infinite worlds), and Ultima 7 (the massive gameworld was divided into regions which got loaded when you go close to them)