My friends and I are developing a game for Ipad/Iphone using the monogame Framework. We are at the final stage of the development and we are having some issues concerning the deploy of the game.
This is our first IOS game and we really need help to make this game happen.
This is our website: http://www.dumativa.com.br/index.php/pt-BR/projetos/dragon-festival (This isn't the newest version of the game but you can see what it looks like)
Since this is our first game we kinda made some mistakes we are trying to fix. Our textures were made focusing the ipad size (1024x768). We don't really know if that was the right aproach. We thought it would be better to scale them down to iphone instead of the other way around.
We need help with the following topics:
1 - The PVRTC compression.
1.1 - Is it really necessary to implement this in order to improve the game performance?
1.2 - How does transparency works with these compressed textures? We have some textures that have a transparency gradient and we wonder how is it going to look after compression.
1.3 - Do you recomend us to remake all the textures to texture atlas using "power of 2" in order to make the PVRTC compression work?
2 - ARMv7
2.1 - How does it helps to improve the game performance?
2.2 - How do we make sure that it is working after I enabled it in monodevelop?
3 - Texture Size/Resolution
3.1 - Are we right about the scaling or should we develop textures for iphone resolution and then scale them up to ipad?
3.2 - Should we have two different apps (one for iphone and one for ipad) with the same textures but with different sizes for each device?
4 - Sugestions
Do you have any sugestion or point that we are missing? We don't really know how to improve further then the topics listed above. We need every possible direction.
Basically we need to decide which way we need to go to improve our performance and playing experience. We would really apreciate your help and you wont regret once this game is launched :)!
Thank you very much.
The answer to most of your questions is going to be "it depends". There is no substitute for testing on an actual target device and seeing if it's acceptable or not.
I have two general suggestions: (a) make sure you have as few textures/spritesheets as possible, ideally one per scene for a 2D game. And (b) yes, I would create resized/resampled graphics for different target devices instead of relying on dynamic scaling. This is very important for non-Retina hardware like the iPad mini, where it is a terrible idea to load huge images unnecessarily. Better to have a slightly larger download up front followed by an optimal playing experience.
Related
Currently, I have a relatively simple 2D game which should not be too taxing on a cpu. It runs fine on my computer however when I build it to my iPhone or iPad the game starts to be quite jittery and has a poor frame rate. Does anyone have any suggestions on how I could improve the performance (I already use object pooling et cetera I think it has something to do with my draw calls / graphics)
EDIT: turns out the renderer is using most of my cpu
If the issue is as you say too many draw calls then one simply way to reduce those is to pack your sprites using the Sprite Packer. This places all your sprites tightly which reduces the amount of draw calls, if they don't all fit nicely or there's too many of them then they will be split into subpages. If you'd like to see how to use the Unity texture packer in simple steps I would direct you to this blog post that talks about it in more depth. Here's a simple step by step guide that I based off of the blog post linked.
Step 1 Select all those sprites that you want to pack in together
Step 2 Give a Packing Tag as shown in the picture below:
Step 3 Open Sprite Packer window and perform packing
Step 4 Click the Pack button as seen above
There are also third party tools like Texture Packer that can do this, and they have more complex algorithms which gives them the edge over Unity's built in verison.
It's also possible there are issues with your games performance not relating directly to draw calls, I would recommend taking a look at the official Unity guide for mobile optimisation.
In Unity3D the logic dictates that objects are not to be rendered unless in the field of view. This is obviously the way to go for optimization purposes. However, it still renders meshes that can not be seen by a player due to being occluded. I would like to solve this and was wondering if there was already a method to do so or if I had to do it myself.
Here's a picture to help illustrate my point.
So far my only real ideas are using the culling, but that still would be in a range not necessarily visible.
https://docs.unity3d.com/ScriptReference/Camera-layerCullDistances.html
I guess essentially what I need to know is how to do occlusion culling after a scene starts because the scene is generated, it's not premade.
For anyone who's interested, I asked the unity community
Answer by Bunny83 ยท 4 hours ago
No, that's not possible. At least not with the occlusion culling
system that Unity uses. The calculation which parts are visible from
which points is quite complicated and has to be precomputed in the
editor. So it won't work for procedurally generated levels.
You have to roll your own solution if you need something like that.
Just a few weeks (or month?) ago i implemented a VisPortals solution
similar to those used by Doom3 (basically how most ID Tech engines
work). It's more a prove of concept than a ready-to-use solution.
Usually i upload a webplayer demo onto my dropbox, however i just
realised that Dropbox finally prevented to directly view HTML pages
off my public folder. They now force a download of the page which
breaks everything. So if you want to try it, you have to download the
project.
Of course vis portals doesn't work in all situations. They are perfect
for closed environments which can be split nicely into seperate areas.
Of course this splitting into areas and the creation of the visportals
currently is done by hand. So you would need to automate this
yourself.
Be careful with static batching, it might break the system as each
area has to be seperate so it can be enabled / disabled seperately.
Which technology to choose, that gives me the possibility to draw a 3d human in browser, with tricks like move the body with mouse, with less cpu use.
Thank in advance.
Silverlight 4 is not as competent in 3d rendering as Flash is.
Having said that, Silverlight 5 will have greater support for 3d thanks to its XNA integration
EDIT: It seems I was rather fast to judge - the official 3d support fo flash (aka molehill) is still under incubation, but flash still has some impressive community-based libraries for 3d still making it (IMO) the more mature solution (Add to that it's larger cross-platform and user support).
This depends on what is a target market of your program.
Silverlight: is C#, 3D modelling is possible, there is even port of Silverlight of Mono MoonLight, but basically yuo should consider that your clients in this case will be Windows OS owners, and considering a OSes destribution information from Os destribution worldwide, you're on winner train.
So looking on your tags: C#, I would say go for Silverlight.
There is another really good product for 3D in browsing, like WebGL, but it's currently not supported of IE, for security concerns, which doesn't mean that will not be supported in future, but.. you know, for now it's not. Here is explanation: Microsoft not going to support WebGL. If you are ready to say "no" to IE (at least for now), it's a good choice.
So for now, I personally, would suggest to use Silverlight 3D. Just google "Silbverlight 3D samples" and you will be given plenty of samples available on inetrnet.
EDIT
Good comparing article on CodeProject
Hope this helps.
Regards.
Flash doesn't really have 3D graphics support, although there are a couple of libraries available. Silverlight also doesn't do 3D. So, really, the answer is "none of the above work all that well."
If you're willing to force your clients to use a current browser, you can use HTML5 and WebGL to render 3D objects without too much trouble.
I realise there are numerous questions on here asking about choosing between XNA and SlimDX, but these all relate to game programming.
A little background: I have an application that renders scenes from XML descriptions. Currently I am using WPF 3D and this mostly works, except that WPF has no way to render scenes offscreen (i.e. on a server, without displaying them in a window), and also rendering to a bitmap causes WPF to fallback to software rendering.
So I'm faced with having to write my own renderer. Here are the requirements:
Mix of 3D and 2D elements.
Relatively few elements per scene (tens of meshes, tens of 2D elements).
Large scenes (up to 3000px square for print).
Only a single frame will be rendered (i.e. FPS is not an issue).
Opacity masks.
Pixel shaders.
Software fallback (servers may or may not have a decent gfx card).
Possibility of being rendered offscreen.
As you can see it's pretty simple stuff and WPF can manage it quite nicely except for the not-being-able-to-export-the-scene problem.
In particular I don't need many of the things usually needed in game development. So bearing that in mind, would you choose XNA or SlimDX? The non-rendering portion of the code is already written in C#, so want to stick with that.
I haven't used SlimDX, but based on my experience with XNA and reading about SlimDX's objective. I'd suggest SlimDX. XNA while it can be used for other things is primarily a Game Engine, not a Rendering Engine. It's got lots of specific optimizations & methodology geared towards Games.
Also, XNA likes to pre-build it's resources into DirectX Files (.x) if you're working with dynamic files, I think SlimDX is the best choice for you.
XNA and SlimDX are very close in nature, but there are some differences:
XNA requires a GPU with a least pixel/vertex shaders 1.1 while I think SlimDX does not.
SlimDX supports DirectX10 and 11, while XNA only supports DirectX 9.
XNA is a cross platform between Windows, Xbox 360, Zune and Windows Phone 7, while SlimDX is not.
XNA has a strong community (creators.xna.com) with tons of tutorials and help materials.
I would go with XNA.
I'm making a turn-based top-down game in C#. The graphics requirements are pretty simple: it's entirely 2D, requires drawing some images taken from graphics files (perhaps rotating them first), line drawing to make a hex grid and the ability to place text at any position on the screen.
I'm wondering what the best API is for doing these graphics. Is XNA overkill for this, is there something more appropriate? Thanks (I have zero experience of graphics or game development in .net so don't be afraid to dumb-down any answers).
I'd recommend XNA for this. If you don't want some of the overhead of XNA, I've found SlimDX to be a very nice little framework. They also provide some basic game classes to make this type of thing easy.
Doing your drawing directly in WPF is also fairly easy, but more difficult to extend later. XNA and SlimDX give you access to shaders, very fine grained control of alpha blending, as well as the potential to easily extend portions into 3D later if needed.
I've used the Farseer Physics engine before which was pretty cool and extremely easy to pickup (I am an enterprise developer, not a game developer). It works for Silverlight so you could actually make your game web based. I would suggest silverlight or WPF for 2D.
http://www.codeplex.com/FarseerPhysics
I would recommend WPF. Loading your graphics and moving them around should be fairly easy. Since WPF also is vector based, your line drawing is straight forward.
XNA would be the next step. Great support for sprite graphics and also gives you access to shaders.
If it is as simple as it sounds, and not even real-time, maybe you don't need any of this stuff. Drawing a hex grid and some images should not be hard even without a game engine. Maybe WPF would be good for this.
Given your requirement you could just use plain C# and the GDI (for 2d rastering). However learning XNA is easy enough, and it'll serve you well once you decide to make a realtime game (2d or 3d) down the road. Either way have fun, and if XNA seems to complicated when your starting out, just drop back to GDI. Making games should be as fun as playing them :)
XNA sounds like a good choise (it will better than using DirectX SDK !! and it is quite easy to learn)
You can do this by just using classes inside the System.Drawing namespace. And XNA is certainly overkill for this type of stuff. Also you would introduse many dependencies for your small game which might be an unwanted thing for your gamers.
Check out Unity 3D - it's based on C# and it can be used for 2D. It might be overkill (including price), but for game development it's in general HUGE help.