Amiblitz3 new version

@Wanderer
The game looks cool. Always like good GFX stuff. Done by your or somethink other ? Maybe have some beta-binary for tests ?:)

@unimon

The problem it that PED assumes the NORMAL, BOLD and ITALIC Version of a fix-font to be the same width.
Actually, this is required to make sense in a programming language Editor, since you want all characters exactly in a 2D Matrix.

I can recommend Lucida Console from Windoze, it is really good for programming, because it has quite large letters compared to it total height and is rendered quite clear.

Yours (kind of Courrier?): ________ Lucida Console (14pix):

@kas1e

The gfx is mostly done by myself. The house scribbles are from a drawing artist.
There is no demo yet. This is just a scenery I set up in Amiblitz3's MapEdit. The editor will be included in future releases and provides an easy interface to use the Maps in your game. (e.g can render any area and layer of the map into any given RastPort).
It can be used for simple maps, but also for quite complex maps, including displacement maps for pseudo 3D. But it is not finished yet, that's why no real release.

@Wanderer

It's Bitstream Vera Sans Mono, and the odd thing is that the characters of the bold and oblique types have the same pitch when displayed in the TypeManager program.

The problem appears to be something to do with the antialiasing, I switched it off to experiment and the editor layout is then correct.

@broadblues

Vera Sans Mono looks on AfA OS with Anti-Aliasing ok:

OS4: _______________________ Afa OS:


/*
... obsolete text deleted ...
*/

P.S.: Ok, I found the reason.
The "normal" and "italic" version of Vera Sans Mono are 1 pixel more narrow on OS4 than the "bold" version.
On AfA OS, all versions have the width of the bold version.
The Texteditor PED estimates the possitions according the width of the "normal" version.

Conclusion: This is hard to fix (how to fix this at all?)
Solution: use another font that has the same width on all versions.

@Wanderer:
another workaround by bernd? i wonder if this is really needed. since i use afa_os i have the feeling that text has usually wider kerning. it causes at least some more or less slight layout incompatibilities between mui and zune rendering. i think he should get rid of it if possible.

@Wanderer

Changing the stacks seems to help - doing a quick test AmiBlitz compiles what it should compile.
Regarding the font behavouier: I switched to standard "courier", know it looks o.k., but AmiBlitz/PED is the only program that behaves this way in os4.1 (as far as i know) - so what are you doing what others don't?

Yeah, Lucida Console is pretty nice for programming, but it's just strange that the previous version of AmiBlitz didn't show this problem, but the new version does when using the same font (DejaVu sans mono/14)...

@All

Let me explain.

The "unusual" stuff that PED does is to mix Bold, Italic and Normal Fonts in the same FIXFONT textdisplay, while assuming that all characters have the same width.

For Softstyle, this is true for all fonts. PED used Softstyle in previous versions. (Softstyle = load ONE font, and do the different style by bitmap-manipulation, e.g. by blitting two times the font by 1 pixel shifted for simulating bold).

Recently, I added the feature that PED opens the font directly with the styles set, means opening THREE Fonts, one for normal, one for bold and one for italic. This allows the Font engine to render different Bitmaps from different Outlines => smoother and more realistic results. However, it seems like that in that case, not all Fonts Versions share the same pixel-Width.
I guess many programs get into trouble if that happens, it is just rarely used.

I dont think that Bernd hacked anything in AfA Font rendering, you can set the Kerning manually in the True-Type Manager program. I only guess that the rendering engine decides for a different pixelwidth in the normal version, that all.
OS4 is the one who doesn't behave consistantly, depending if AA is switched on or off. Does that make sense? nah!

So to avoid this problem on OS4:

- switch "bold tokens" off in IDE Preferences

or

- choose a font that has the same width in all versions, shouldn't be too hard.

Fixing this in PED is kind of problematic. Any suggestions are welcome how to handle such a problem.

@Wanderer
#13
It is correct that the simple demo give a reaper hit, while the 100Hz demo runns smoothly without any trouble? That would give us a hint what might be wrong, since the two progs are almost identical.

I'm glad there was something to review! I would like to see AB3 be successful. I'm a basic user, though I use SDLBasic all the time, I wouldn't mind looking into programming with AB3.

@Wanderer
Quote:
ok-ok. just wanted to go sure. anyways i do care more for afa_os behaviour then for os4 atm.

@Wanderer

Quote:

That might be easier said than done. If the extra width is due to the boldness needing more space under antialiasing, (or at least the algorithm presuming it does) then all fonts might suffer from this. Especially as they seem to work with antialiasing off. Sounds like abug to me.

If it's abug you probably shoudn't try to work arround it at all, but given that bold and noraml are the same size under afa perhaps if you took the font width from the bold font instead? That wouldn't be perfect as the alignments might still be a little out but at least all the characters would be displayed.

Your other option of switching off bold tokens would seem more sensible in the short term.

[edits]spellings and a missing n't[/edit]

@broadblues

I added a secutiry check to PED. If the font widths are not the same, it will use the softstyle version of the normal font. That should be a reasonable workaround.

@Wanderer

That's a great solution, thanks :) Will we be able to download the updated PED by itself?