What are the gotchas for using CocosSharp between different platforms?

Hi, I've already found out that the CCClippingNode.Stencil option doesn't work on iOS or Mac (as in post https://forums.xamarin.com/discussion/comment/96458#Comment_96458) and I wondered if the CocosSharp guys know of any other things that don't work or work slightly differently between the supported platforms?

I do appreciate that some of these may be down to MonoGame but I'm hoping that these are known especially as the unit tests seem to be quite comprehensive and the same across platforms - this was how I found the problem with Stencil option in CCClippingNode on iOS.

Perhaps there should be a fixed thread that just the CocosSharp guys can edit that lists all of the current known issues/differences?

I'm mainly coding on iOS but regularly testing on Android and WinPhone builds every few days, but that does mean that sometimes things may work on iOS that don't on the other platforms or that I get stumped on iOS due to a known bug which I then have to work around (but which would have worked on the other platforms).

Apologies if this information is already available but if so I've failed to find it.

BTW I'm really enjoying using CocosSharp and the Xamarin team have done a great job of making it accessible via C#. I've learnt enough to be dangerous!

Best regards, Adrian

Posts

  • kjpou1kjpou1 LUMember, Xamarin Team Xamurai

    Adrian

    Really no list exists. You can start one for people to reference though. Can not think of any off the top of my head right now either. The ClippingNode is one that has been there for a while but we are now tracking that one to be looked at.

  • In that case it hardly warrants creating a new list if that's the only one, thought it was worth asking just in case :smiley:

    Thanks, Adrian

  • ShermanUitzetterShermanUitzetter USMember ✭✭

    I use CocosSharp with iOS, MacOS and Android. I'm using straight sprites mostly. I use a CCDrawNode for a lightning effect. I also use CCRenderTexture for a blur effect. That's about all I touch. It all works cross-platform, pretty much as expected.

    A couple of cross-platform issues I have run into...

    Early on I found an issue with pre-multiplication of alpha channels in loaded PNG textures. I believe this is only an issue for me because I don't use xnb files for content - I'm not using the recommended content pipeline. I have all image content loaded from PNG files.

    My observation was that on iOS and MacOS, textures were getting their alpha channels automatically pre-multiplied when loaded from PNG files. That is, the PNG image is not pre-multiplied in the resource of the app, but it gets pre-multiplied on load.

    On Android, the alpha was not pre-multiplied on load, but it was expected to be pre-multiplied once loaded. This resulted in needing a non-pre-multiplied and a pre-multiplied version of every PNG file (one for the iOS/MacOS projects and the other for the Android project). Obviously, you would want to keep the non-pre-multiplied PNGs for editing anyway.

    More recently I discovered an iOS-only issue where, if you called XNATexture.GetData() (maybe also SetData()) from within a closure (still on the main thread), it would mess-up up something with the OpenGL context (I think that's the correct terminology) and stop it from updating the screen.

    I had been happily testing away on MacOS and Android (those two are easier for me to test on) for a few weeks. When I finally did an iOS test, I discovered that, at a certain point screen updates just stopped. It looked like the game froze; however, time was still marching on - I got sounds and everything, just not screen updates, until the scene changed.

    I ended up having to re-work where I was making XNATexture.GetData()/SetData() calls. I may be wrong about my diagnosis of this issue - calling from within closure - but that's what fixed it for me and I tend to move on once I have a working fix.

    All in all, I'm very very happy with the cross-platform performance (capability?) of CocosSharp. It really does feel very "write once, deploy multiple places" to me. But, of course, you do have to test in all the places.

  • Thanks for the information!

    I don't quite understand the bit about pre-multiplied alphas though as at the moment I use exactly the same PNG and JPG files on Android and iOS and they look the same to me in both environments both in the simulators/emulators and on real devices.

    I'd like to use these on WinPhone as well without turning them into XNBs as a 2048x2048 JPG which may only be 200Kb turns into a 7Mb (ish) XNB - horrible. If I can't use JPGs directly on WinPhone in CocosSharp I'll probably just use a C# JPG decoder to get at the image pixels in from the JPG file and then set a texture with the result to avoid the size bloat when converting JPG to XNB.

    Sidebar: I do however have four resolutions of every image I use as I'm creating a universal app that works from small phones up to large tablets/desktops (I've not tested on Windows desktop yet but I mean to at some point, and I've not tested on MacOS either as I don't have a Xamarin license for it) and I have images based on 256x256, 512x512, 1024x1024 and 2048x2048 dimensions and I can scale up or scale down the images I use. I can also support custom sizes, so I may support 1080x1080 based images (rather than scaling down from 2038x2048 or scaling up from 1024x1024) - but at the moment I'm not doing that.

    In case you're wondering why I'm using those image sizes (especially when my game runs in portrait) that's because that is the base play area for the game, I have scores, icons, information that appear underneath the game area taking up the rest of the portrait real estate. All of my config for game levels is done using percentages in the game area which makes it really easy.

    Cheers! Adrian

  • DeanEllisDeanEllis USXamarin Team Xamurai

    I did a test with a 2048x2048 image that was a 337 kb jpeg image. Using the MonoGame content pipeline with a TextureFormat = Color resulted in a 16 meg .xnb file. This is to be expected since its exporting the raw pixels with no compression at all.

    Changing the TextureFormat = Compressed resulted in a 2.2 meg .xnb file. Yes this is allot bigger than the 337 kb but there is an important point here. The data in the 2.2 meg .xnb can be used directly by the GPU on the device, as it is , no decompression. a jpeg will need to be decompressed in to system memory then passed onto the GPU, which will take up ... 16 Meg of your GPU because its the raw texture data.

    I know the .xnb's are bigger but the benefits are huge if you consider the load times, and the amount of texture memory that is used. You use less texture memory leaving room for more graphics :) Also it can be optimised for each platform, on iOS PVRTC texture compression is used, on Windows Phone its DXT.

    On a side note the 2.2 meg .xnb was using DXT compression, the same image using PVRTC compression was about 2.1 meg, so not much difference.

  • Thanks for the info on XNB - definitely something to bear in mind.

    My main problem is that I wanted 200+ unique levels in my game (each level uses two large base images plus various associated sprite sheets and one bitmap font) - and that would work out at well over 800Mb using XNB (and possibly over 1Gb) just for the images!

    My game can take a performance hit due to using texture memory more inefficiently (although I suspect all my game graphics will fit easily into the texture cache) as it is not an out an out fast action game but a more casual game which will at times feature fast but not frantic action (all the graphics will be on one non-scrolling screen using an overhead type of view).

    It'll be interesting to see how things go as I'm just at the beginning of my game odyssey with CocosSharp (I've written games before going all the way back to my first published game in 1990 - which interestingly was for the Acorn Archimedes which featured the very first ARM chip!).

    Thanks, Adrian

  • kjpou1kjpou1 LUMember, Xamarin Team Xamurai
    edited January 2015

    Just discussed one yesterday.

    1. WP8 supports only .xnb consistently
    2. FromStream does not work very well for loading raw asset types.
  • Thanks, on WinPhone I've found that .fnt files do NOT need to be converted to .xnb but that the image referenced by the .fnt file does.

  • RamiTabbaraRamiTabbara AUMember, Xamarin Team Xamurai

    Hi Adrian,

    I think that each level having their own background (I'm assuming that's the base image) and other sprite sheets is a bit excessive, especially if you have 200+ levels. Even before we consider the overall size of the total content, creating the unique artwork for each of these levels would be a taxing task.

    My suggestion is that you should be using reusable assets across the levels or at the very least a selection of levels. If you think of AAA 2d titles such as a platformer (e.g. Rayman), they'll typically reuse a lot of the assets for at least a group of levels (e.g. different world), so even larger game studios aren't immune to this problem of a ballooning content size.

  • I think you're right, I am being overly ambitious!

    I'm already re-using my levels 15 times over as I have 5 game modes all using the same level graphics, and each game mode has three variations (easy, medium and hard versions). But I'd quite like to have 100 distinct levels, I'm going to have 10 themes with 10 different levels within each theme.

    My levels are entirely visible on screen, not made up of tiles, just one big graphic - once I get further with the game I'll release some more details which will make it obvious why this has to be so in my game.

    Thanks for your advice.

Sign In or Register to comment.