Messages

1

Support / Re: Getting fonts to look perfect

« on: May 11, 2013, 04:42:34 am »

I'm not sure if it's possible to get the characters to look exactly the way I want at lower font sizes.  At larger fonts they do look correct.  Which makes sense since each glyph contains more pixels to get all the detail out of it.  I probably will just have to tinker around and find the optimal settings in BMFont Generator by super sampling at smaller font sizes.

(Extra reading for anyone interested: http://blog.felixbreuer.net/2011/07/27/fonts.html )

unikron are you familiar with the issue I was referring to before about bilinear filtering causing glyphs to get cut off at the top and bottom?  Probably nothing you can do with 2dtoolkit regarding this.  BMFont gives the coordinates of the glyph, and enabling bilinear filtering in unity will alter the texture given by bmfont without reconfiguring the xml coordinates in the bmfont, thereby making some of the characters look cut off.

2

Support / Getting fonts to look perfect

« on: May 10, 2013, 11:33:57 pm »

I've followed the tutorial for preparing fonts. I'm using BMFont to take a .ttf font I've downloaded to create the bitmap font used by 2d toolkit.  I can't get it to look exactly as it is advertised on the site I downloaded it from.  This seems to be a problem with any font I try.   Here is an example and I attached an image to show you what I'm seeing in game.

http://www.theleagueofmoveabletype.com/fanwood

I have a feeling it has to do with how BMFont is outputting the font.  I've tried various different settings including font smoothing, super sampling, render from truetype outline, but can't seem to get it just right.

Some of the basics that I made sure of in Unity:
1. TextMesh (x,y) positions fall on whole numbers.
2. Using Point filtering in the sprite collection for my fonts.  (Should the source texture for the separate bitmap fonts also be set to Point?)  I actually think bilinear filter made it look better, but enabling this resulted in characters tops/bottoms getting cut off by a couple pixels.
3. I'm using tk2d Camera and I ticked the checkbox for "use tk2d camera".
4. Mip maps are not getting generated

I'm not building to a device by the way.  I'm seeing these results in the Game window in Unity.  Also, when I view the font .ttf in a different font program designed for testing out fonts, they do look perfect.  Could the tk2d shader I've selected on the atlas material also be affecting it?

3

Support / Multiple font sizes for a single font

« on: May 04, 2013, 04:48:40 am »

Should I be using a single font for various font sizes?  I'd export my font in a fairly large size using bmfont generator, then I would scale down the font (by scaling the textmesh) to the desired size.  The other alternative is to export two different fonts for the two sizes I want.  Which is the recommended approach?

4

Support / Re: Lighting and Draw Call Count

« on: April 04, 2013, 07:24:17 am »

That lighting add-on sounds interesting.  Will definitely look into it when it's ready.

The normal lighting path isn't THAT bad. It may be 3 draw calls for 1 sprite, but it'll be the same number for all batched sprites which are affected by the same light. So 3 draw calls for 100 sprites using the same material, illuminated by the same number of lights, too. Depending on your needs you could further optimize this using vertex lights only to speed things up further.

The problem is that I'm not getting 3 draw calls for 100 sprites.  It's 300 draw calls for 100 sprites.

Do I need to have a pro license to get the batching to work in this case?  I noticed in the player settings it says "Static batching requires Pro License"

Edit: Also, the light I'm using is per-pixel lighting.  When I switch it to vertex lighting it batches.

5

Support / Re: Lighting and Draw Call Count

« on: April 03, 2013, 01:43:57 pm »

iPad

6

Support / Re: Lighting and Draw Call Count

« on: April 03, 2013, 05:44:09 am »

With deferred rendering, am I going to run into issues with semi transparent sprites?  I've read that deferred rendering speeds up the rendering of geometry with multiple lights, but is sometimes avoided when dealing with transparency.

I'm fine tuning my scene to see how the lights are affecting the sprites. Each sprite in the scene is taking up 3 draw calls.  Each and every tile in the scene!  I even removed all my lights except for one, and still 3 draw calls per sprite.  I've also tried baking the lights into the level tiles and the number of draw calls per tile goes down to 1, but still 1 per tile is too much.  Trying to get them to batch together.

7

Support / Lighting and Draw Call Count

« on: April 01, 2013, 02:52:07 am »

Started creating a level for a 2d game I'm working on.  The view is a top down perspective and the ground is made up of many many sprites, all in the same sprite collection.  Before I added lighting to the scene, the draw calls were ~30.  Once I added lighting it jumped to ~300. 

The shader used on the sprite collection is tk2d/LitBlendVertexColor.  The scale on each of the sprites has not been altered in the transform component (they have been altered in the tk2dsprite component).  A bunch of the sprites are rotated.  The z values are all different so that draw order of the sprites is handled properly.

Changing the shader instantly drops the draw call count.

Any idea how to get that back down?  Is this unavoidable if I want lit sprites?

8

Support / Re: Couple of problems(rendering and flipping)

« on: March 30, 2013, 05:12:46 pm »

Awesome!  Thanks

9

Support / Re: Couple of problems(rendering and flipping)

« on: March 22, 2013, 12:34:52 am »

No need to create the hack for me.  I will just create sprite collections with double sided render meshes. When I'm ready to build and deploy I can switch it back if I need to.

Thanks

10

Support / Re: Couple of problems(rendering and flipping)

« on: March 21, 2013, 09:20:36 pm »

The problem with flipped sprites is actually expected behaviour - what happens when a sprite is flipped is that its drawn the opposite way around. Unity then thinks the "front" of the sprite is actually on the opposite side to what is seen on screen. This is "fixable" by inverting all the polygons, but this is not foolproof - it will break when the sprite is flipped using the Unity transform widget. The "fix" also requires additional resources to store the inverted indices, and will increase the amount of data written - its far more efficient when it doesn't have to do it. I can advice on what to do to change it, but I recommend against doing that for code used in the game.

This issue makes level creation a little bit more cumbersome if you are flipping sprites a lot.  I have a few different tiles I'm using to make the ground for a level and to vary the look of it, since I'm repeating the same tile, I will flip the tile horizontally. Since it's no longer selectable in the scene view I can no longer quickly select it to place it exactly where I want it.  Any updates to this since this was posted 1 year ago?  Only thing I can think of to quickly select it is inverting the editor camera to select those flipped tiles by hitting the X-axis at the top right of the scene window, and then hitting the z-axis.  This will show the scene I was just looking at from the other side and I can now select all the flipped tiles.  This isn't really that ideal though!