Hi,

If you have 4 sprites; obj1, obj2, obj3 and main, and you position obj3 to obj2, and obj2 to obj1, and obj1 to main.

How come obj3's position doesn't change when obj2's origin point OR image size is changed?

For example, if obj2 and obj3 are 32x32px big, and their origin points are both 0x0, then changing obj2's origin point to 0x1 SHOULD move obj3 down by one pixel, but it doesn't.

Why is this?

Bump?

Hi,

I'd like to do a classic, grid-based dungeon crawler in first person perspective, and I'd really like to be able to either skew sprites or use a 3D plugin or effect to achieve the effect of a first person perspective.

Does anyone know how this can be done? I tried using the mode7 effect plugin, but it doesn't have any documentation.

Ideas?

Ashley yeah, it's just a simple JPG export to illustrate the original image size, in response to a different question. The original image is in PNG format and has an alpha transparent backdrop.

However, the characters are aligned to the upper left corner in each character cell, despite otherwise being properly spaced. Are you suggesting that this is the source of the problem?

I can't try it out right now, but I will as soon as possible.

Ashley I'm already using transparent background and transparent spaces between each character. You can see it yourself when looking at the fontset image I just pasted. It seems that it's not working as you are suggesting. :-/

Bump.

Ashley

Sorry, my last post didn't make much sense. I meant to say that I'd like for the SpriteFont plugin to work with full fluid letterbox scaling rather than integer scaling. Integer scaling creates a lot of letterboxing, which unfortunately completely ruins the immersion that I'm trying to create with my project. At the same time I also need to be able to use a bitmap font since system fonts are too volatile.

Any chance of seeing a fix for this bug anytime soon?

EDIT:

Edge fringing or "bleeding" is a normal result in computer graphics when using floating point positioning or scaling, and is not at all specific to Construct 2. It's important to ensure your sprite sheet has at least one transparent pixel between characters to ensure that bleeding does not occur.

I've actually played around a lot with this glitch since it has existed for quite some time, and even attempted to add a ridiculous amount of spacing in the bitmap font sheet as you suggested, but unfortunately this doesn't fix the problem. The glitch will appear no matter what. :-/

Thanks for the reply Ash.

Pixel rounding makes no difference, but switching from letterbox scaling to letterbox integer scaling fixes the issue.

However, I was hoping to be able to use letterbox scaling without integer, since I don't want any letterboxing.

In other words, is there a way to fix the glitch when using integer scaling?

Thanks again.

Well, even if you are able to count newlines there still doesn't seem to be a way to remove the top line, or is there?

Yeah I'm still working on it, but if you need help you can hit me up on IRC.

I thought that the power-of-two-principle was more about performance enhancement when it comes to Construct 2, but it's a good guess. Maybe Ashley can confirm?

When you add it in to Construct, click on the SpriteFont, and look at the properties. Tweak these slightly (character width, etc).

Look at the h in your image above. It is picking up a line of pixels beside it. I assume it's a capital H, or maybe even a border.

I already explained that this is wrong.

It's not picking up pixels from other characters because the spritefont is upscaled from an original 1:1 scale bitmap image.

This is a glitch, not a SpriteFont configuration issue.

Do you mind if we see a capx or a sprite sheet?

Sure, here's a JPG copy of the original image:

<img src="https://copy.com/WT00FdgYYC4s/c2_spritefont_sheet.jpg" border="0" />

The sprite sheet image's resolution is 261x64px with each character having a 9x16px resolution, and the black background color is replaced with alpha transparency in Construct 2