Coder Social home page Coder Social logo

mono / cocossharp Goto Github PK

View Code? Open in Web Editor NEW
492.0 492.0 160.0 155.69 MB

CocosSharp is a C# implementation of the Cocos2D and Cocos3D APIs that runs on any platform where MonoGame runs.

C# 99.69% NSIS 0.14% PowerShell 0.03% Python 0.04% Batchfile 0.01% Shell 0.10%

cocossharp's Introduction

Mono is a software platform designed to allow developers to easily create cross platform applications. It is an open source implementation of Microsoft's .NET Framework based on the ECMA standards for C# and the Common Language Runtime.

The Mono project is part of the .NET Foundation

Join us on Discord in the #monovm channel:

Contents

  1. Compilation and Installation
  2. Using Mono
  3. Directory Roadmap
  4. Contributing to Mono
  5. Reporting bugs
  6. Configuration Options
  7. Working with Submodules

Build Status

Public CI: Azure Pipelines

Legacy Jenkins CI (no longer available publicly):

OS Architecture Status
Debian 9 amd64 debian-9-amd64
Debian 9 i386 debian-9-i386
Debian 9 armel debian-9-armel
Debian 9 armhf debian-9-armhf
Debian 9 arm64 debian-9-arm64
OS X amd64 osx-amd64
OS X i386 osx-i386
Windows amd64 windows-amd64
Windows i386 windows-i386
CentOS s390x (cs) centos-s390x
Debian 9 ppc64el (cs) debian-9-ppc64el
AIX 6.1 ppc64 (cs) aix-ppc64
FreeBSD 12 amd64 (cs) freebsd-amd64

(cs) = community supported architecture

Compilation and Installation

Building the Software

Please see our guides for building Mono on Mac OS X, Linux and Windows.

Note that building from Git assumes that you already have Mono installed, so please download and install the latest Mono release before trying to build from Git. This is required because the Mono build relies on a working Mono C# compiler to compile itself (also known as bootstrapping).

If you don't have a working Mono installation

If you don't have a working Mono installation, you can try a slightly more risky approach: getting the latest version of the 'monolite' distribution, which contains just enough to run the 'mcs' compiler. You do this with:

# Run the following line after ./autogen.sh
make get-monolite-latest

This will download and place the files appropriately so that you can then just run:

make

The build will then use the files downloaded by make get-monolite-latest.

Testing and Installation

You can run the mono and mcs test suites with the command: make check.

Expect to find a few test suite failures. As a sanity check, you can compare the failures you got with https://jenkins.mono-project.com/.

You can now install mono with: make install

You can verify your installation by using the mono-test-install script, it can diagnose some common problems with Mono's install. Failure to follow these steps may result in a broken installation.

Using Mono

Once you have installed the software, you can run a few programs:

  • mono program.exe runtime engine

  • mcs program.cs C# compiler

  • monodis program.exe CIL Disassembler

See the man pages for mono(1), mcs(1) and monodis(1) for further details.

Directory Roadmap

  • acceptance-tests/ - Optional third party test suites used to validate Mono against a wider range of test cases.

  • data/ - Configuration files installed as part of the Mono runtime.

  • docs/ - Technical documents about the Mono runtime.

  • external/ - Git submodules for external libraries (Newtonsoft.Json, ikvm, etc).

  • ikvm-native/ - Glue code for ikvm.

  • libgc/ - The (deprecated) Boehm GC implementation.

  • llvm/ - Utility Makefiles for integrating the Mono LLVM fork.

  • m4/ - General utility Makefiles.

  • man/ - Manual pages for the various Mono commands and programs.

  • mcs/ - The class libraries, compiler and tools

    • class/ - The class libraries (like System.*, Microsoft.Build, etc.)

    • mcs/ - The Mono C# compiler written in C#

    • tools/ - Tools like gacutil, ikdasm, mdoc, etc.

  • mono/ - The core of the Mono Runtime.

    • arch/ - Architecture specific portions.

    • benchmark/ - A collection of benchmarks.

    • btls/ - Build files for the BTLS library which incorporates BoringSSL.

    • cil/ - Common Intermediate Representation, XML definition of the CIL bytecodes.

    • dis/ - CIL executable Disassembler.

    • eglib/ - Independent implementation of the glib API.

    • metadata/ - The object system and metadata reader.

    • mini/ - The Just in Time Compiler.

    • profiler/ - The profiler implementation.

    • sgen/ - The SGen Garbage Collector implementation.

    • tests/ - The main runtime tests.

    • unit-tests/ - Additional runtime unit tests.

    • utils/ - Utility functions used across the runtime codebase.

  • msvc/ - Logic for the MSVC / Visual Studio based runtime and BCL build system. The latter is experimental at the moment.

  • packaging/ - Packaging logic for the OS X and Windows Mono packages.

  • po/ - Translation files.

  • runtime/ - A directory that contains the Makefiles that link the mono/ and mcs/ build systems.

  • samples/ - Some simple sample programs on uses of the Mono runtime as an embedded library.

  • scripts/ - Scripts used to invoke Mono and the corresponding program.

  • support/ - Various support libraries.

  • tools/ - A collection of tools, mostly used during Mono development.

Contributing to Mono

Before submitting changes to Mono, please review the contribution guidelines. Please pay particular attention to the Important Rules section.

Reporting bugs

To submit bug reports, please open an issue on the mono GitHub repo.

Please use the search facility to ensure the same bug hasn't already been submitted and follow our guidelines on how to make a good bug report.

Configuration Options

The following are the configuration options that someone building Mono might want to use:

  • --with-sgen=yes,no - Generational GC support: Used to enable or disable the compilation of a Mono runtime with the SGen garbage collector.

    • On platforms that support it, after building Mono, you will have both a mono-boehm binary and a mono-sgen binary. mono-boehm uses Boehm, while mono-sgen uses the Simple Generational GC.
  • --with-libgc=[included, none] - Selects the default Boehm garbage collector engine to use.

    • included: (slightly modified Boehm GC) This is the default value for the Boehm GC, and it's the most feature complete, it will allow Mono to use typed allocations and support the debugger.

    • none: Disables the inclusion of a Boehm garbage collector.

    • This defaults to included.

  • --enable-cooperative-suspend

    • If you pass this flag the Mono runtime is configured to only use the cooperative mode of the garbage collector. If you do not pass this flag, then you can control at runtime the use of the cooperative GC mode by setting the MONO_ENABLE_COOP_SUSPEND flag.
  • --with-tls=__thread,pthread

    • Controls how Mono should access thread local storage, pthread forces Mono to use the pthread APIs, while __thread uses compiler-optimized access to it.

    • Although __thread is faster, it requires support from the compiler, kernel and libc. Old Linux systems do not support with __thread.

    • This value is typically pre-configured and there is no need to set it, unless you are trying to debug a problem.

  • --with-sigaltstack=yes,no

    • Experimental: Use at your own risk, it is known to cause problems with garbage collection and is hard to reproduce those bugs.

    • This controls whether Mono will install a special signal handler to handle stack overflows. If set to yes, it will turn stack overflows into the StackOverflowException. Otherwise when a stack overflow happens, your program will receive a segmentation fault.

    • The configure script will try to detect if your operating system supports this. Some older Linux systems do not support this feature, or you might want to override the auto-detection.

  • --with-static_mono=yes,no

    • This controls whether mono should link against a static library (libmono.a) or a shared library (libmono.so).

    • This defaults to yes, and will improve the performance of the mono program.

    • This only affects the `mono' binary, the shared library libmono.so will always be produced for developers that want to embed the runtime in their application.

  • --with-xen-opt=yes,no - Optimize code for Xen virtualization.

    • It makes Mono generate code which might be slightly slower on average systems, but the resulting executable will run faster under the Xen virtualization system.

    • This defaults to yes.

  • --with-large-heap=yes,no - Enable support for GC heaps larger than 3GB.

    • This only applies only to the Boehm garbage collector, the SGen garbage collector does not use this configuration option.

    • This defaults to no.

  • --enable-small-config=yes,no - Enable some tweaks to reduce memory usage and disk footprint at the expense of some capabilities.

    • Typically this means that the number of threads that can be created is limited (256), that the maximum heap size is also reduced (256 MB) and other such limitations that still make mono useful, but more suitable to embedded devices (like mobile phones).

    • This defaults to no.

  • --with-ikvm-native=yes,no - Controls whether the IKVM JNI interface library is built or not.

    • This is used if you are planning on using the IKVM Java Virtual machine with Mono.

    • This defaults to yes.

  • --with-profile4=yes,no - Whether you want to build the 4.x profile libraries and runtime.

    • This defaults to yes.
  • --with-libgdiplus=installed,sibling,<path> - Configure where Mono searches for libgdiplus when running System.Drawing tests.

    • It defaults to installed, which means that the library is available to Mono through the regular system setup.

    • sibling can be used to specify that a libgdiplus that resides as a sibling of this directory (mono) should be used.

  • Or you can specify a path to a libgdiplus.

  • --enable-minimal=LIST

    • Use this feature to specify optional runtime components that you might not want to include. This is only useful for developers embedding Mono that require a subset of Mono functionality.

    • The list is a comma-separated list of components that should be removed, these are:

      • aot: Disables support for the Ahead of Time compilation.

      • attach: Support for the Mono.Management assembly and the VMAttach API (allowing code to be injected into a target VM)

      • com: Disables COM support.

      • debug: Drop debugging support.

      • decimal: Disables support for System.Decimal.

      • full_messages: By default Mono comes with a full table of messages for error codes. This feature turns off uncommon error messages and reduces the runtime size.

      • generics: Generics support. Disabling this will not allow Mono to run any 2.0 libraries or code that contains generics.

      • jit: Removes the JIT engine from the build, this reduces the executable size, and requires that all code executed by the virtual machine be compiled with Full AOT before execution.

      • large_code: Disables support for large assemblies.

      • logging: Disables support for debug logging.

      • pinvoke: Support for Platform Invocation services, disabling this will drop support for any libraries using DllImport.

      • portability: Removes support for MONO_IOMAP, the environment variables for simplifying porting applications that are case-insensitive and that mix the Unix and Windows path separators.

      • profiler: Disables support for the default profiler.

      • reflection_emit: Drop System.Reflection.Emit support

      • reflection_emit_save: Drop support for saving dynamically created assemblies (AssemblyBuilderAccess.Save) in System.Reflection.Emit.

      • shadow_copy: Disables support for AppDomain's shadow copies (you can disable this if you do not plan on using appdomains).

      • simd: Disables support for the Mono.SIMD intrinsics library.

      • ssa: Disables compilation for the SSA optimization framework, and the various SSA-based optimizations.

  • --enable-llvm

    • This enables the use of LLVM as a code generation engine for Mono. The LLVM code generator and optimizer will be used instead of Mono's built-in code generator for both Just in Time and Ahead of Time compilations.

    • See https://www.mono-project.com/docs/advanced/mono-llvm/ for the full details and up-to-date information on this feature.

    • You will need to have an LLVM built that Mono can link against.

  • --enable-big-arrays - Enable use of arrays with indexes larger than Int32.MaxValue.

    • By default Mono has the same limitation as .NET on Win32 and Win64 and limits array indexes to 32-bit values (even on 64-bit systems).

    • In certain scenarios where large arrays are required, you can pass this flag and Mono will be built to support 64-bit arrays.

    • This is not the default as it breaks the C embedding ABI that we have exposed through the Mono development cycle.

  • --enable-parallel-mark

    • Use this option to enable the garbage collector to use multiple CPUs to do its work. This helps performance on multi-CPU machines as the work is divided across CPUS.

    • This option is not currently the default on OSX as it runs into issues there.

    • This option only applies to the Boehm GC.

  • --enable-dtrace

    • On Solaris and MacOS X builds a version of the Mono runtime that contains DTrace probes and can participate in the system profiling using DTrace.
  • --disable-dev-random

    • Mono uses /dev/random to obtain good random data for any source that requires random numbers. If your system does not support this, you might want to disable it.

    • There are a number of runtime options to control this also, see the man page.

  • --with-csc=roslyn,mcs,default

    • Use this option to configure which C# compiler to use. By default the configure script will pick Roslyn, except on platforms where Roslyn does not work (Big Endian systems) where it will pick mcs.

      If you specify "mcs", then Mono's C# compiler will be used. This also allows for a complete bootstrap of Mono's core compiler and core libraries from source.

  If you specify "roslyn", then Roslyn's C# compiler will be used. This currently uses Roslyn binaries.

  • --enable-nacl

    • This configures the Mono compiler to generate code suitable to be used by Google's Native Client: https://code.google.com/p/nativeclient/

    • Currently this is used with Mono's AOT engine as Native Client does not support JIT engines yet.

  • --enable-wasm

    • Use this option to configure mono to run on WebAssembly. It will set both host and target to the WebAssembly triplet. This overrides the values passed to --host or --target and ignored what config.sub guesses.

      This is a workaround to enable usage of old automake versions that don't recognize the wasm triplet.

Working With Submodules

Mono references several external git submodules, for example a fork of Microsoft's reference source code that has been altered to be suitable for use with the Mono runtime.

This section describes how to use it.

An initial clone should be done recursively so all submodules will also be cloned in a single pass:

$ git clone --recursive [email protected]:mono/mono

Once cloned, submodules can be updated to pull down the latest changes. This can also be done after an initial non-recursive clone:

$ git submodule update --init --recursive

To pull external changes into a submodule:

$ cd <submodule>
$ git pull origin <branch>
$ cd <top-level>
$ git add <submodule>
$ git commit

By default, submodules are detached because they point to a specific commit. Use git checkout to move back to a branch before making changes:

$ cd <submodule>
$ git checkout <branch>
# work as normal; the submodule is a normal repo
$ git commit/push new changes to the repo (submodule)

$ cd <top-level>
$ git add <submodule> # this will record the new commits to the submodule
$ git commit

To switch the repo of a submodule (this should not be a common or normal thing to do at all), first edit .gitmodules to point to the new location, then:

$ git submodule sync -- <path of the submodule>
$ git submodule update --recursive
$ git checkout <desired new hash or branch>

The desired output diff is a change in .gitmodules to reflect the change in the remote URL, and a change in / where you see the desired change in the commit hash.

License

See the LICENSE file for licensing information, and the PATENTS.TXT file for information about Microsoft's patent grant.

Mono Trademark Use Policy

The use of trademarks and logos for Mono can be found here.

cocossharp's People

Contributors

alexsorokoletov avatar atsushieno avatar azahmed096 avatar bholmes avatar denis-minchuk avatar doubleday avatar gdwneo avatar gena-m avatar haruair avatar hlywp8 avatar joelmartinez avatar kalitaalexey avatar katiejanekilian avatar kjpou1 avatar migueldeicaza avatar mvdev1 avatar netonjm avatar omd avatar orthographic-pedant avatar oxosi avatar pawelklimczyk avatar picticon avatar rtabbara avatar sergey-mukhamedshin avatar terrajobst avatar therzok avatar tonisson avatar totallyevil avatar totallyeviljake avatar yongweisun avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

cocossharp's Issues

Files not found in CocosSharp.Test.iOS solution

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.

CCLabel won't center

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);

CCSceneResolutionPolicy.ShowAll not behaving correctly

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.

CCLabelBMFont: ContentSize is 0x0 during initialisation

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.

CCScene Layer property can be set

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.

CCSprite: Add TexelToContentSizeRatio

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.

CCTXTileMap: Scrolling issue

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 :-)

Update Nuspec's to support Xamarin unified API

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.

iOS: Viewport not correctly set after orientation change

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.

Android app crashes when started in landscape mode but the app requires portrait mode

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>

CCDrawNode content size is always 0 x 0

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.

CCLayer: Add constructor to specify camera projection

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.

Remove need to set supported orientations in overridden CCApplicationDelegate

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.

Unified CCLabels

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.

Android: Graphics context being destroyed when Pausing/Resuming

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.

Visible bounds not perfectly matching default set by DesignResolutionSize

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.

CCTextFieldTTF isn't working

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

CCBox2dDraw constructor/draw calls don't accommodate for PTM_RATIO

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.

Mac: Full-screen app crashes

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.

API Levels

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?

Remove superfluous CCViewportResolutionPolicy

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;

"CocosSharp for Windows Phone 8" Nuget package doesn't work with WP 8.1 app

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.

cocossharpwp81nugeterror

CCSpriteBatchNode resetting to position (0,0)

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.

CCLabel: offset issue

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.

Add Default Projection property

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.

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.