Nez: free, open source 2D framework

I really couldn’t find a way to achieve that, the problem is that I need proper culling and also the UI to behave correctly according to the screen, so I’m going to just use another Scene for that, it’s not the end of the world and I could even run it in another thread, if anybody is interested in the code I’ve abandoned, here you go: https://gist.github.com/Alan-FGR/838bae004e59a0ecc5925fab4b3cd229 it works quite OK, but there are problems with culling and debug drawing, culling I guess could be resolved with a separate camera, but debug drawing would need changes in Debug.render so it renders to a render target of our choice.

Here’s how I solved it in the end: https://gist.github.com/Alan-FGR/211ec75246fb7f506d85128017d097d4

Multiple scenes work perfectly, had to remove transition support though :stuck_out_tongue:

Have problems building pipeline tools. It can’t find Microsoft.Xna.Framework.Content.Pipeline namespace. Wasn’t able to find Ioniz.Zlib as well, but I’ve solved it myself by downloading appropriate assembly.

https://pastebin.com/raw/B2jmzLTM

I am having some issues with slopes using the TiledMapMover. Often, when my entity is moving from a normal tile up a slope tile, sometimes the entity can’t move forward. Basically, the entity will keep trying to move right but won’t move any distance, as if it is running into a wall. Sometimes it will eventually start moving up the slope, but I am unsure what the TiledMapMover sees as different, where sometimes the entity is blocked, others it’s not.

Also, are there any constraints to make slopes work correctly? For example, does the width and/or height of the bounding box need to be less than the width/height of a tile? Is there a max velocity to be able to move successfully up a slope? I noticed that there is a colliderHorizontalInset, and colliderVerticalInset, do these need to be changed depending on the relative size or speed of an entity relative to the tile width/height?

Thanks in advanced!

The only constraint is that your Entity’s Collider width must be less than the width of a tile. If you have a fast moving Entity you should break up the movement into pieces that are less than a tile width/height and just to multiple checks in a row with them.

The constraints fixed a lot of the issues! However,there is still one thing that is not working. For slopes at least 2 tiles high, there are some cases where the edge of the entity collides with the tile horizontally adjacent to the slope tile before the entity has ascended to the tile above it. This causes the entity to get stuck as a wall tile is preventing horizontal movement. I think the issue is related to line 259 on TileMapMover.cs

            if (direction.isHorizontal() && collisionState._lastGroundTile != null && collisionState._lastGroundTile.isSlope() && _collidingTiles[i].isSlope())

The last && piece only ignores a collision tile in horizontal movement if it is also a slope tile. I removed the last &&, changing the line to

             if (direction.isHorizontal() && collisionState._lastGroundTile != null && collisionState._lastGroundTile.isSlope())

And it fixed the issue. The only problem is that this creates a side effect, where if your slope leads directly to a wall, the entity will go be able to go through the wall (as the above code exempts all horizontal collisions while on a slope), which messes everything up. This case is easy to avoid, but I think the best solution may be to determine if the tile is adjacent to a slope tile and exempt those tiles from horizontal movement, but I haven’t come up with the best way to do that yet. I can probably provide pictures/examples if it would be useful to illustrate the issue.

Does the source for https://www.youtube.com/watch?v=EBY5KlbPwSk exist somewhere? One would think it’d be a sample but I can’t seem to find it anywhere.

That demo was most definitely not production worthy code. It was just a big mess of a Table with a bunch of controls tossed in.

A bad example would still be better than no example. :smiley:

1 Like

Hey, apologies if this has already been mentioned (I did a search, but couldn’t find an answer). From my understanding based on the videos and skimming through the source for the Tiled map related source files, there’s no support for tileset collisions, correct?

I ask because currently I’m building my Tiled maps with a 16x16 size, but some of the tiles are 32x32 (to get around the constraints of Tiled map sizes when using multiple sized tiles). Therefore when generating a collision layer through Nez, it only generates a collision box of 16x16 in the base point of the tile sprite (which I can see making sense). But to then get around this limitation, I would use the Tileset specific collision editor, however it doesn’t appear to be supported.

From what I can tell, my options in this case would be to A) Manually draw on collisions to the tilemap with objects (not ideal), or to use 2 different TIled maps, one for each grid size, and overlay them (even less ideal).

I’m just wondering if there’s any support for something like this that I’ve missed with Nez, or if you have any plans to support the tileset collision editor in the future?

Thanks!

Generating collision data for multiple tile sizes isn’t supported out of the box but you could certainly do something like that. I would just have a look at the current collision generation code then right after loading the Tiled map just add your double sized Colliders with a similar snippet of code.

Alternatively, a wholly different approach could be to go with something akin to the TiledMapMover which doesn’t use Colliders at all. It just uses the raw tile map data instead.

Perfect, thank you for the swift response! I’ll do some digging into your suggestions and see what I can do.

Hi! I’m just getting started with Monogame + Nez, so apologies if I missed something obvious.

I’m trying out the deferred lighting with pixel art, but it seems to be blurring the screen. Is there a way to disable blur with deferred lighting?

Im not sure about the specifics of your situation.

You can try to set the sampler state to point or point and clamp (clamps really about edges)), either in your shader or directly from your Draw method.

GraphicsDevice.SamplerStates[0] = new SamplerState() { Filter = TextureFilter.Point /* , AddressU = TextureAddressMode.Clamp , AddressV = TextureAddressMode.Clamp*/ };

Note. typically you define the states at the start of your game1 then just set it when you need to.

Dunno if that will work for deffered rendering i never tryed to do it yet.

Thanks for the reply!
I tried add the code you provided, but it didn’t change anything. If it helps, I’m already using the PointClamp samplerstate when drawing, so I think the issue just has to do with how the lighting is done in Nez, maybe.

Have you compared your code to the deferred lighting in the Nez.Samples repo? It is a good base to use as you’re starting point.

Yeah, I used the deferred lighting sample scene to get it set up in my own scene. I just tried running the sample scene as well, but it has the same issue with blurring, and there is a border of discolored pixels rendered around the edge of the screen, but it is not as visible because of the higher resolution i think? In my own project, I am use a 640x360 virtual screen size, and letting it be scaled up by the pixel perfect screen resolution.

I’m having terrible luck getting Nez’s content importers and processors recognized in the Pipeline Tool for 3.7.1625. I’m on a Mac. Any help would be awesome. :slight_smile:

With the TiledMapMover (or in general) is there any way to detect whether something is colliding with a wall or floor without moving it? For example, if you create a new entity and its position makes its Box Collider exist inside a wall, is there any way to tell?

The TiledMapMover isnt really made for just doing overlap checks. It works with movement and edge detection. the TiledMapComponent however gives you the option in the constructor to create regular Colliders for any given layer. You can then do standard collision checks with any Collider or directly with the SpatialHash via the Physics class.