From comment in #37:

Currently I have a bug with CCLabel when upgrading from 1.1 to 1.2.
I have confirmed with Mike Bluestein. Maybe unification with solve this?

Details: The code below centres the label in 1.1 but for 1.2 it is set to the left.

    var label = new CCLabel ("Tap to Start", "Arial", 44)
    {
        Position = VisibleBoundsWorldspace.Center,
        Color = CCColor3B.Green,
        IsAntialiased = true,
        HorizontalAlignment = CCTextAlignment.Center,
        VerticalAlignment = CCVerticalTextAlignment.Center,
        AnchorPoint = CCPoint.AnchorMiddle
    };

Using "AnchorMiddleLeft" will centre the label, so therefore it is an offset bug I think.

Please tell me if you wish to raise this as a bug or wait. Cheer, Mark.

Stage is not centered in a Window when orientation is changed from landscape to portrait (or portrait to landscape).

Test: https://github.com/vancura/fracthor/commit/f2191f248817d1eb8f638e54ca0c620c5665b05d

Based off a question in the CocosSharp forums here, creating a CCLabelBMFont and running a CCMoveByAction on it, the label remains in its original position.

The current "CocosSharp for Windows Phone 8" v1.0.0.0 Nuget package can not be installed into a Windows Phone 8.1 project within Visual Studio 2013. Nuget says the following:

Could not install package 'CocosSharp.WindowsPhone8 1.0.0.0'. You are trying to install this package into a project that targets 'WindowsPhoneApp,Version=v8.1', but the package does not contain any assembly references or content files that are compatible with that framework. For more information, contact the package author.

If setting up a new application without setting a window size then application will error out.

https://github.com/Sohojoe/CocosSharp-Forms-sample

I was able to get forms to start a CocoSharp session, but I got stuck when trying to close down CosoSharp and resume forms - is this possible with the current state of play?

A change in the content size of a CCSprite object after it's created does not update the underlying texture dimensions.

Sets the main window's design resolution size e.g. mainWindow.SetDesignResolutionSize(960, 640, CCSceneResolutionPolicy.ShowAll) implicitly specifies the default visible bounds of any new CCLayer.

There appears to be some numerical errors depending on the chosen resolution size that result in 1 or 2px offsets in the visible bounds (e.g. expected bounds: (0,0, 960, 640), actual bounds: (0,1, 960, 640)).

The numerical errors are popping up because by default the camera is using a 3d projection and so the underlying perspective camera that belongs to a Layer needs to calculate the correct positioning so that the projection results in a visible area that matches the desired bounds.

Event if the default projection is changed to 2d, the ability for a 3d projection to lock on to a fixed bounds would be a desired feature for users who want to implement a 2d game with some 3d effects, so there is a need to fix these numerical errors to make it robust.

I am checking android dependencies and it's interesting
box2d.Android = 2.2
MonoGame.Framework.Android = 4.4
Lidgren.Network.Android = 4.4
CocosSharp.Android = 4.2
so, I guess we should have at least what's needed by vendor libraries (4.4)
but the thing is I am not sure why would MonoGame or Lidgren need 4.4?

This error occurs both on emulator (used Genymotion) as well as actual device (used Nexus 7 2012).

To reproduce create a new project with the following code in GameAppDelegate for ApplicationDidFinishLaunching:

    public override void ApplicationDidFinishLaunching (CCApplication application, CCWindow mainWindow)
    {
        application.PreferMultiSampling = false;
        application.ContentRootDirectory = "Content";

        mainWindow.SupportedDisplayOrientations = CCDisplayOrientation.Portrait;

        // todo:  Add our GameScene initialization here
    }

Crash occurs when SupportedDisplayOrientations is set:

at Microsoft.Xna.Framework.Game.get_Window () <IL 0x00006, 0x00024>
at Microsoft.Xna.Framework.GraphicsDeviceManager.set_SupportedOrientations (Microsoft.Xna.Framework.DisplayOrientation) <IL 0x0000d, 0x0003f>
at CocosSharp.CCDrawManager.set_SupportedDisplayOrientations (CocosSharp.CCDisplayOrientation) <IL 0x00007, 0x0002f>
at CocosSharp.CCWindow.set_SupportedDisplayOrientations (CocosSharp.CCDisplayOrientation) <IL 0x00007, 0x00043>
at BouncingGame.GameAppDelegate.ApplicationDidFinishLaunching (CocosSharp.CCApplication,CocosSharp.CCWindow) [0x00015] in c:\FlatRedBallProjects\Test\BouncingGameEmptyAndroid\BouncingGame\GameAppDelegate.cs:13
at CocosSharp.CCApplication.LoadContent () <IL 0x00048, 0x00168>
at Microsoft.Xna.Framework.DrawableGameComponent.Initialize () <IL 0x00010, 0x0004c>
at CocosSharp.CCApplication.Initialize () <IL 0x00008, 0x0003f>
at Microsoft.Xna.Framework.Game.InitializeExistingComponents () <IL 0x00029, 0x00104>
at Microsoft.Xna.Framework.Game.Initialize () <IL 0x0000d, 0x00063>
at CocosSharp.CCGame.Initialize () <IL 0x00001, 0x00027>
at Microsoft.Xna.Framework.Game.DoInitialize () <IL 0x00012, 0x00058>
at Microsoft.Xna.Framework.AndroidGamePlatform.BeforeUpdate (Microsoft.Xna.Framework.GameTime) <IL 0x0000e, 0x00053>
at Microsoft.Xna.Framework.Game.DoUpdate (Microsoft.Xna.Framework.GameTime) <IL 0x0000d, 0x00044>
at Microsoft.Xna.Framework.Game.Tick () <IL 0x000f5, 0x00693>
at Microsoft.Xna.Framework.AndroidGameWindow.OnUpdateFrame (object,OpenTK.FrameEventArgs) <IL 0x00059, 0x0014f>
at OpenTK.GameViewBase.OnUpdateFrame (OpenTK.FrameEventArgs) [0x00014] in /Users/builder/data/lanes/1131/2a7b6821/source/monodroid/src/OpenGLES/Android/GameViewBase.cs:312
at OpenTK.Platform.Android.AndroidGameView.UpdateFrameInternal (OpenTK.FrameEventArgs) [0x00013] in /Users/builder/data/lanes/1131/2a7b6821/source/monodroid/src/OpenGLES/Android/AndroidGameView.cs:338
at OpenTK.Platform.Android.AndroidGameView.RunIteration (System.Threading.CancellationToken) [0x00096] in /Users/builder/data/lanes/1131/2a7b6821/source/monodroid/src/OpenGLES/Android/AndroidGameView.cs:523
at OpenTK.Platform.Android.AndroidGameView/c__AnonStorey0.<>m__0 (object) [0x0000d] in /Users/builder/data/lanes/1131/2a7b6821/source/monodroid/src/OpenGLES/Android/AndroidGameView.cs:431
at Android.App.SyncContext/c__AnonStorey1.<>m__0 () [0x00000] in /Users/builder/data/lanes/1131/2a7b6821/source/monodroid/src/Mono.Android/src/Android.App/SyncContext.cs:32
at Java.Lang.Thread/RunnableImplementor.Run () [0x0000b] in /Users/builder/data/lanes/1131/2a7b6821/source/monodroid/src/Mono.Android/src/Java.Lang/Thread.cs:36
at Java.Lang.IRunnableInvoker.n_Run (intptr,intptr) [0x00009] in /Users/builder/data/lanes/1131/2a7b6821/source/monodroid/src/Mono.Android/platforms/android-19/src/generated/Java.Lang.IRunnable.cs:71
at (wrapper dynamic-method) object.5e1ebc2f-dbce-4f9d-98c2-c2a678b4178c (intptr,intptr) <IL 0x00011, 0x0001b>

When specifying width of label the positioning is off.

See forum post : https://forums.xamarin.com/discussion/26097/could-somebody-explain-cclabelbmfont-positioning#latest which has screen shots of the difference.

When loading a CCSprite, by default the size of the sprite in world space is taken to be the texture pixel size.

However, users typically want to set a fixed design resolution irrespective of the true screen size. Thus, to allow them to support hi/low res images, we need a way to allow users to set the sprite texel to content size ratio. e.g. If the hi-res image was 2:1, then they can set the content size ratio to 2.

In addition it is not only CCSprite that will be impacted, but other derived classes/ classes that load sprites (e.g. CCLabel, CCTMXLayer). So the setting of scale should be hierarchal

• CCApplication.DefaultTexelToContentSizeRatio
  • CCSprite.DefaultTexelToContentSizeRatio
  • CCTMXLayer.DefaultTexelToContentSizeRatio

so that setting the CCApplication.DefaultTextureToContentRatio will impact all relevant classes, but users can still customise the distinct scale factors for particular art assets. e.g. Tilemap art may scale differently to regular sprites.

Finally, these properties should be of type CCSize to allow for the possibility of different width/height scales.

Box2d can have its own metric coordinate system, and the translation between Box2d and CocosSharp's world system (in points) is handled via the convention of defining a PTM_RATIO static var.

For debugging purposes, people may want to draw the Box2d physics objects and can use CCBox2dDraw which is derived from the abstract b2Draw class

The vertices provided to CCBox2dDraw are in Box2d coordinates, and will need to be scaled using the PTM_RATIO so that they line-up with the corresponding CCNode object (e.g. CCSprite).

For some reason, the CCBox2dDraw constructor does not allow users to set the desired PTM_RATIO, even though the abstract base constructor is expecting this parameter.

A CCScene is the top-most node of the rendering chain and as such Layer should be null. Otherwise we get ambiguous behaviour where a user can add a child to a scene (that's not a layer) that can potentially be rendered.

as per discussion here #33 the CCLabel and CCLabelBMFont needs to have IgnoreAnchorPointForPosition = true for the positioning to work consistently between them.

Reference the following forum post :
http://forums.xamarin.com/discussion/27070/walktrough-using-the-monogame-pipeline-tool-for-building-cocossharp-specific-content#latest

We should build this automatically in our build process.

The code below works fine when using CCLabelTtf - the label will be centered both horizontally and vertically. However with CCLabel, horizontal alignment won't work. The label is all the way to the left side.

Interesting: CCTextAlignment.Center puts it all the way to the left, CCTextAlignment.Left (!) centers it perfectly and CCTextAlignment.Right places the label half way off the screen to the left.

var label = new CCLabel ("Bildschirm berühren!", "Times New Roman", 44)
            {
                Position = this.VisibleBoundsWorldspace.Center,
                Color = CCColor3B.White,
                HorizontalAlignment = CCTextAlignment.Center,
                VerticalAlignment = CCVerticalTextAlignment.Center,
                AnchorPoint = CCPoint.AnchorMiddle,
            };
            this.AddChild (label);

http://forums.xamarin.com/discussion/25870/is-animationinterval-ignored#latest

I try to set my FPS with AnimationInterval but it looks like it is ignored or at least I can't see a difference in frames. Sadly DisplayStats throws still an exception so I can't see the actual frames on screen.

Is there anything that I need to consider when using AnimationInterval, is this the wrong method for changing FPS or is it really ignored?

This is in addition to #17 and #18 requesting templates for iOS and Android respectively.

Why CC everywhere ?

The process to create a new project from scratch is tedious and error prone.

The default projection for Layers and Camera is 3D. This works fine as default as long as no 3D effects or VertexZ values are used. There is a Layer constructor that takes a projection parameter, CCCameraProjection.Projection2D and CCCameraProjection.Projection3D, where each Layer/Camera would need to be passed the Projection2D property when being setup.

What this enhancement will provide is a default Projection property so users will not have provide this projection parameter each time.

The property should be placed on CCWindow or a static property on CCLayer providing the default projection to use on creation of a new CCLayer.

Since Tiled Qt 0.9.0, there is the ability to create a staggered isometric map renderer, so we should provide the ability to read in these TMX map types.

This is a currently an open issue with MonoGame here that was introduced with the inclusion of OpenAL for Android here.

As a temporary fix, we can't have Android projects reference both MonoGame.Framework.Android and MonoGame.Framework.Net.Android.

During initialisation, if dimension parameter is not passed the ContentSize is set to 0x0 which will impact the positioning (among other things).

Given a font and font size, we need a way of determining the size of the label before necessarily drawing it. In particular, if no dimensions are provided then the default behaviour should be to set the ContentSize as the union of the sprite rects.

To be safe, to do this one should override the ContentSize setter, recalculating size if label changed font/font-size and user-defined dimensions were not set.

On Mac, when initialising a game and creating a CCApplication in the overridden NSApplicationDelegate FinishedLaunching method, the game is assumed to be full-screen if no arguments are supplied to the CCApplication constructor.

Currently, attempting to instantiate a CCApplication this way on the Mac platform results in the app crashing.

For mobile devices, when creating the CCApplication instance, one can determine the supported orientation from the - iOS) Info.plist, Android) ActivityAttributes or WP8) WindowsPhonePage.xaml, so a user shouldn't need to set these again in the application delegate.

In fact, there's a potential issue of providing mismatching supported orientations which will lead to problems and in addition, the supported orientations should be given to the CCApplication constructor anyway so that the underlying buffer is setup correctly.

Moreover, there currently isn't support for most devices to allow users to change the supported orientations after initialisation and so the CCWindow.SupportedDisplayOrientations property setter should be additionally removed to avoid confusion.

From forum discussion http://forums.xamarin.com/discussion/27220/ccspritebatchnode-issue

I've switched-over to using CCSpriteBatchNode for my sprites. It's mostly gone just fine, but I'm noticing an issue where the first sprite in a batch node is getting its on-screen position reset to (0, 0) (it's being incorrectly drawn in the lower-left of the screen).

It seems to happen only to the first sprite in the batch, after adding a new sprite to the batch, but not every time a new sprite is added. For example, I have a sprite (in a batch node) sitting in the middle of the screen. So far so good. At some point later, possibly after having added more sprites to the batch node without issue, I add another sprite to the batch node and, mysteriously, that very first sprite, pops down to (0, 0).

I wanted to try to find something in the CocosSharp test suite to point to, and I think I may have found an issue that's at least similar to what I'm seeing:

On the SpriteTest section of the test suite, the 36th test (index = 35), "SpriteChildrenVisibility", it looks like something similar to what I'm seeing is happening. If you go to that test (it's titled "Sprite & SpriteBatchNode Visibility"), you'll see that all the sprites are stuck in the lower-left corner of the window (0, 0). Looking at the code, it seems the sprites should be nicely centered on screen. Hopefully whatever's causing that issue is also my issue.

A simple CCLabelTtf that worked flawlessly in the previous nuget version, seems to be 'squashed down'. If you add a large scale to the label (e.g. 10) it draws, but still skewed (wide & flat). Look at the following post for example code and some before & after screenshots

http://forums.xamarin.com/discussion/26014/cclabelttf-problem-in-new-version-1-1-0-0-ios#latest

Creating a CCMusicPlayer, setting the Volume property and then opening a particular music file resets the Volume to 1.0

I tried setting the volume in the GoneBananas sample like this:

CCSimpleAudioEngine.SharedEngine.BackgroundMusicVolume = 0.02f;

but it had not effect.

When this is created it installs all 3 nugets into each project. It should only install android in android, ios in ios, and pcl in pcl

From the forums:

http://forums.xamarin.com/discussion/26829/ccsimpleaudioengine-bug

For some reason if I have an mp3 sound effect with duration greater than cca 0.5 seconds, CCSimpleAudioEngine is playing it twice.

It's iOS application.

I preload effect like this:

CCSimpleAudioEngine.SharedEngine.PreloadEffect ("hd/game/sounds/win");

I play effect like this:

CCSimpleAudioEngine.SharedEngine.PlayEffect ("hd/game/sounds/win");

Thank you.

The default CCLayer constructor creates a corresponding CCCamera on your behalf. The camera itself by default uses a 3d projection whose projection along the plane z=0 matches the set design resolution size (0,0, w, h). This is done so that 3d transition/depth/sprite effects will appear as expected. In other words, if the user does not use any 3d effects, the game, for all intents and purposes, will appear to be 2d.

However, the CCCamera does include an explicit 2d orthographic projection should a user want this. Hence when creating a CCLayer, we should provide users with the ability to specify the projection of the corresponding default CCCamera.

http://forums.xamarin.com/discussion/25870/is-animationinterval-ignored#latest

DisplayStats throws still an exception so I can't see the actual frames on screen.

There are currently a lot of (understandable) misunderstandings between all the different flavours of labels (CCLabel, CCLabelTtf, CCLabelBMFont, etc.). In addition, the fact that these classes are derived from different parents (CCSprite/ CCSpriteBatchNode) also gives rise to further maintenance issues.

Ideally, we should just have a single CCLabel class with a basic constructor

CCLabel("foo", "arial", 22, CCLabelType.Ttf)

We should also have a default CCLabelType.Auto that first attempts to locate fonts within the Content folder and then as a last resort attempts the Ttf version of the font if no font files were found.

CCLabel should be derived from CCNode as a container object, with specific-ivars for the different label flavours.

I'm working on a portrait-only app with a 2x3 aspect ratio. I'm using CCSceneResolutionPolicy.ShowAll, so that the app's aspect ratio will be preserved when the scene is scaled for the device it's running on.

For example, on an iPhone 5 (taller than 2x3), the screen should show black bars, top and bottom so that the scaled image (between the bars) will maintain the correct 2x3 aspect ratio. After updating to 1.1 this morning, there are no black bars and the image is stretched too much, top to bottom (squares are no longer square).

This was working perfectly, pre-1.1.

When a user calls DrawRect, DrawCircle etc, the underlying triangle or line vertices are updated so that the primitives will render, but the ContentSize is not updated.

This will cause issues when adding children to a CCDrawNode, because if the content size is 0, then the local transform will be incorrect.

Attempted to open a keyboard to accept text input using CCTextFieldTTF (running the TextInputTest in the tests.iOS project) and it has no effect.

If only landscape orientation is enabled, app with a wrong window position. This is how it looks when launched:

As soon as the screen is rotated to the other landscape mode, everything is fine:

And since then it's always fine.

It could be connected with #39.

As described here, the introduction of the Unified API results in a library split where monotouch.dll -> Xamarin.iOS.dll, XamMac.dll -> Xamarin.Mac.dll.

Additionally, when targeting iOS, the NuGet platform identifier has changed from MonoTouch10 to Xamarin.iOS10.

The Nuspec's need to be updated to incorporate these changes, making sure to also keep support for the Classic API as well.

As per forum post https://forums.xamarin.com/discussion/comment/82295/#Comment_82295 there is confusion between AnimationInterval on CCWindow and AnimationInterval on CCApplication.

The CCWindow.AnimationInterval does not work. There needs to be a decision on which one to use.

Based off of cocos2d-x v3 CCFastTMXLayer we want to remove reliance of CCSpriteBatchNode and implement culling so that only visible tiles are rendered.

When deploying CocosSharp to an Android device and Pausing/Resuming the GL context is destroyed which in-turn means that the underlying GraphicsDevice is Reset upon Resuming the application.

We should be able to gracefully handle the case of a graphics device being reset, but in this particular instance, Pause/Resuming on a device should not result in the context being destroyed.

The process to create a new project from scratch is tedious and error prone.

Not sure yet if it is a problem with the CCLabel or something else but the Gone Bananas sample and also my code no longer show any labels.

This renders nothing but a black screen:

https://github.com/xamarin/mobile-samples/blob/master/GoneBananas/GoneBananasShared/GameStartLayer.cs#L26

Currently, there's two resolution policies - one for a CCScene and another for CCViewport. The CCScene ultimately sets up the correct exact fit viewport rect based on:

• specified design resolution
• CCScene resolution policy

which are specified in CCWindow.SetDesignResolutionSize and then afterwards the Viewport scales the exact rect to get the actual rect based on the CCViewportResolutionPolicy which can be one of either:

• ExactFit
• AspectFill
• AspectFit

By default the CCViewport is created with an ExactFit policy meaning no subsequent scaling is performed.

But there is no need (and in fact it's confusing) to further specify an additional viewport resolution policy which subsequently scales the exact bounds. Instead, a user can simply set a different design resolution to get the exact fit bounds they want.

As an analogy, it's like setting int x=4; x = x /2; vs. int x = 2;

Changing the orientation of an iOS device does not correctly update the viewport for a game that supports both landscape and portrait orientations. In particular the viewport rect does not appear to be centered correctly after an orientation change.

Additionally the default behaviour should be to preserve the aspect ratio when swapping orientation so that stretching/compression of content doesn't occur. i.e. The default CCViewport constructor should have the CCViewportResolutionPolicy changed from ExactFit. There's a need to support both a fixed landscape and fixed portrait aspect ratio.

Finally, the transition when changing orientations needs to be smooth. Currently, the swapping behaviour appears jarring to the user.

From the forums:

http://forums.xamarin.com/discussion/27152/simple-tilemap-tmx-scroller

I am loading a timemap with this CCTMXMapInfo mapInfo = new CCTMXMapInfo ("lvl01.tmx"); map = new CCTMXTiledMap (mapInfo);

I tried using a camera but got perspective camera when moving it... (maybe a missed parameter?)

Then I ended up just setting the design resolution size like this to fit the height of the tile map mainWindow.SetDesignResolutionSize (568, 320, CCSceneResolutionPolicy.FixedHeight);

but am now missing the part where I can move the map.

I added a simple sprite to move across the screen but for some reason couldn't get the ccfollow action to work quite right. Maybe I need to add the map to a special node and then use the action on that?

Any help and pointers are appreciated :-)

In the CocosSharp.Test.iOS solution, the MonoGame.Framework.iOS project references a few source files that could not be found:

CocosSharp/MonoGame/MonoGame.Framework/Audio/AudioCategory.cs
CocosSharp/MonoGame/MonoGame.Framework/Audio/AudioEngine.cs
CocosSharp/MonoGame/MonoGame.Framework/Audio/AudioStopOptions.cs
CocosSharp/MonoGame/MonoGame.Framework/Audio/Cue.cs
CocosSharp/MonoGame/MonoGame.Framework/Audio/SoundBank.cs
CocosSharp/MonoGame/MonoGame.Framework/Audio/WaveBank.cs
CocosSharp/MonoGame/MonoGame.Framework/Audio/XactClip.cs
CocosSharp/MonoGame/MonoGame.Framework/Audio/XactSound.cs
CocosSharp/MonoGame/MonoGame.Framework/Graphics/GraphicsDevice.OpenGL.FramebufferObject.cs
CocosSharp/MonoGame/MonoGame.Framework/Graphics/GraphicsDevice.OpenGL.RenderbufferObject.cs

It looks like they are in monogame master but not in the monogame xamarin branch.