Nez: free, open source 2D framework

[mpeg88]

Hi! Sorry for such long time.

Konaju answered for me I see. I knew this because it was mentioned somewhere else here. So I dont really know in practice how big is this problem that everything static is held in memory after you quit monogame app on Android but I know for sure that it's draining my phone mercilesly to 10% of battery unless I terminate the game process myself in another app.

I have created couple of subsystems for my game (managers and so on) that were build upon singleton or static logic because it would seem natural. Then I encountered the problem on Android. However I ended up rewriting most of managers to normal classes and drastically reduced static use. Now I can say that I minimized battery drainage but in my opinion there is still something wrong or I'm doing it wrong....

Anyway this is why I was concerned with all this. Thanks !

[Nullz]

Well there is a lot of static classes in just .NET, try removing as many dll's as you can from the project and see if that makes any difference.

[KonajuGames]

know for sure that it's draining my phone mercilesly to 10% of battery unless I terminate the game process

Threads in an Android app are not paused when the app is backgrounded. This is unlike iOS that automatically pauses all threads in an app when that app is backgrounded. The openal-soft library we use in MonoGame has been updated to a newer version that allows the mixer thread to be paused when the app is backgrounded. If you have any other long-running threads in your game, it is up to you to pause them when the activity is paused.

[nivrig]

I'm getting a NullReferenceException in Nez.Core constructor where it sets Content.RootDirectory = "Content"; because Content is null.

I'm on OSX, building for DesktopGL, using the latest Nez [23031a2] and its embedded MonoGame 3.6.0.121. I see it with the Nez.Samples as well as my own (empty) project.

Posting here because it seems more like a MonoGame problem, but I'm not sure. I can't update the MonoGame version because I don't know how to build the PCL (kinda new to .NET/C#/MonoGame here!) that Nez embeds.

Any suggestions?

[SOLVED]

My DesktopGL project of course needed to reference the DesktopGL version of MonoGame, not the generic PCL version. Told you I was kinda new to this.

[prime31]

You got it! The PCL used by Nez is a fake. It's totally empty and is there only so Nez can compile itself into a DLL. Your main project should always reference the real MonoGame DLLs.

[nivrig]

Can you target non-GL platforms with Nez eg: Windows Mobile? I guess maybe I'd need to pull the Nez effects source into my own content project and recompile them for the correct target, or add ANGLE libs?

[lozzajp]

How well does this work with MonoGame.Extended?

I only ask because of things like both having Tiled map support in the pipeline tool.

Is there any conflict or is it simply you get two choices of importers in the tool?

[prime31]

@nivrig Nez is a PCL so it will work anywhere. If you use the built in shaders than you will need to rebuild them for DirectX though. The source for all of them is included in the root of the repository.

@lozzajp everything is namespaces in both Nez and MG.Extended so they will work fine together.

[nivrig]

I'm having some problems with Nez on iOS.

With some test code to log touches and gestures I get the following output from a base MonoGame (ie: no Nez) iOS build for a tap on simulator and device:

Touch id:2 state:Pressed position:{X:177 Y:319} pressure:0 prevState:Invalid prevPosition:{X:0 Y:0} previousPressure:0
Touch id:2 state:Moved position:{X:177 Y:319} pressure:0 prevState:Pressed prevPosition:{X:177 Y:319} previousPressure:0
Touch id:2 state:Moved position:{X:177 Y:319} pressure:0 prevState:Pressed prevPosition:{X:177 Y:319} previousPressure:0
Touch id:2 state:Released position:{X:177 Y:319} pressure:0 prevState:Moved prevPosition:{X:177 Y:319} previousPressure:0
Tap

With the same test code and Nez I get the following:

Touch id:2 state:Moved position:{X:39 Y:200} pressure:0 prevState:Pressed prevPosition:{X:39 Y:200} previousPressure:0
Touch id:2 state:Moved position:{X:39 Y:200} pressure:0 prevState:Pressed prevPosition:{X:39 Y:200} previousPressure:0
Touch id:2 state:Moved position:{X:39 Y:200} pressure:0 prevState:Pressed prevPosition:{X:39 Y:200} previousPressure:0
Touch id:2 state:Moved position:{X:39 Y:200} pressure:0 prevState:Pressed prevPosition:{X:39 Y:200} previousPressure:0

ie: the Pressed and Released states are missing and the Tap gesture isn't picked up. Other gestures behave similarly.

The Nez touch control component I'm using is here (github). It wraps the exact same code as the basic MonoGame app that works.

Also, if I try to launch the Nez app on device I get a Null Reference at the following location (works on simulator):

What am I doing wrong?

Using MonoGame 3.5.1 from NuGet.

[prime31]

Have a look at the Input class. That is the only code anywhere in Nez that does anything at all with touch.

[nivrig]

Got it The Nez Input class processes touches and gestures in to its own internal lists, so there's nothing left on the MonoGame TouchPanel queues.

Using Input.currentGestures instead of a TouchPanel.ReadGesture() loop, for example, lets me get the correct gestures.

[Miguel_Lara]

Hi Prime31,

I started playing with your 2d Framework and I am finding some LibGDX and some Cocos2d-X influences in your library, which is great because I am familiar with both... Was your library inspired by those 2 frameworks or it is just me????
If it is, that should make the learning curve a little easier for me.

Also, I created a Particle Editor for Windows that is based on the way Particle Designer works, and I was going to create a little runtime so I could import the .plist particles that my Particles Architect generates, in the monogame framework and the libgdx framework.... But you already implemented it.... Thanks a lot for that, you saved me a lot of time.
Now, would you mind if I peek thru your implementation so I can code a little importer for .plist particles for LibGDX framework?

Anyway, thank you for all your hard work.

Miguel.

[prime31]

There is indeed some libGDX, Cocos, Unity and other influence in the API of Nez. If you know either of them it will give you a jump start but Nez is still quite a bit different so there will be some new stuff to learn as well.

Feel free to go to town with any of the code in there. It's up on GitHub for just that reason!

[Codaku]

Great framework definitely gonna base my next game off this.

[Eendhoorn]

I recently started looking into Nez. I've been using Unity the last 2 years but I just cannot bear it anymore and want to move back to monogame.

One thing that disappointed me a bit is how closed the TiledMap is. I plan to write an in-game tilemap editor but still wish to use your TiledMap class, since it is tightly integrated with utils like the pathfinder.
It would be cool if the the tilemap was an all-purpose tilemap that just so happens to have a great tiled import/export.

Other than that it all seems great, the quake-ish console and the entity inspector are awesome additions!

[prime31]

What specifically were you not able to do with the TiledMap classes? The class was written specifically for Tiled editor maps (as the name implies) but all of its create* methods were made public so that they are accessible from the outside.

As for the pathfinding code, it is all interface based so you can fill in the interface any way that you want. Nez provides 2 concrete implementations of grid graphs (WeightedGridGraph and UnweightedGridGraph) that use a TiledMap to keep things simple but if you look at the classes they access the TiledMap only in the constructor. You could very easily replace that with any data format you want.

Note also that everything is open source so you are certainly free to grab the source and change it however you see fit. Nez isn't trying to be Unity and providing only one way to do things ("the Unity way or the highway"). It is purposely a more open ended framework.

[Eendhoorn]

Wow quick response haha.

Yeah I thought it was quite weird how everything seemed highly flexible, except for the tiledmap.

I'm trying to set up the tiledmap without importing anything from tiled, for now I just wanted to see if I could display a single tile;

Entity tilemap = createEntity( "tilemap" );

TiledMapComponent tilesC = tilemap.addComponent( new TiledMapComponent( new TiledMap( 0, 10, 10, 16, 16 ) ) );
tilesC.tiledMap.createTileset( content.Load<Texture2D>( "tilesheet" ), 0, 16, 16, true, 0, 0 );
tilesC.tiledMap.createTileLayer( "default", 10, 10, new TiledTile[ 100 ] ).visible = true;

TiledTile tile = new TiledTile( 0 );
tilesC.tiledMap.getLayer<TiledTileLayer>( "default" ).tiles[ 0 ] = tile;

However, because the field tileset inside TiledTile is marked internal I cannot set it externally. I also thought it was strange there was no "SetTile" function. I could easily add one myself, but it made it seem like the class was only supposed to be used for tiled imports.

I must confess that I did not look any further than the constructor for the PathFinder, but seeing that it required the TiledMap made me guess that they were tied together.

And yeah, I love working with open source again haha.

[prime31]

If anything is too protected feel free to swap it to public and send over a pull request. I believe the tileset field gets populated for you so you might not need it to be public. A setTile method will probably be a good one to add so that you don't have to fully initialize your array with tiles at creation time.

[Eendhoorn]

Sure! I'm a bit busy with the launch of my current project, but once that calms down I'll see if I can dive in a bit deeper.

[Eendhoorn]

Is there any preferred way to communicate between components? I'd like to avoid referencing other components, since you never know which components an entity possess. Other ECS used a messaging system where you can subscribe to an event type, but I can't seem to find a dedicated messaging system like this in Nez.

And another small unrelated question while I'm at it; Is there any way to set the pivot point for a transform component? When I'm rotating a sprite it always seems to rotate from the top center, no matter what the sprite's localOffset or origin is.

I'm not sure if this is the best place to ask all these questions, so let me know if I'm at the wrong place for this.