Skip to main content

On Sale: GamesAssetsToolsTabletopComics
Indie game storeFree gamesFun gamesHorror games
Game developmentAssetsComics
SalesBundles
Jobs
TagsGame Engines

Ace

5
Posts
1
Topics
1
Following
A member registered 11 days ago

Recent community posts

First off, I applaud Decker’s goal of a small, effective code base and I’m totally fine with how it works. I absolutely adore it!

I’m just curious though if Extended ASCII has been considered.

If it’s viable, perhaps the native Decker fonts don’t support it, but import a font with a special “Extended ASCII” property and maybe Decker can apply the character codes from 128 to 255 to that specific font’s rendering. This would support most of Western Europe. UTF-8 wouldn’t be needed.

However, Extended ASCII is 8-bit versus regular ASCII being 7-bit. I have no idea how Decker deals with font characters internally, but I know that Decker renders characters beyond 127 to a question mark so it deals with Extended ASCII at some level. This also means that Extended ASCII would have to be accepted in string values in Decker’s scripting language.

I apologize if Extended ASCII has already been addressed.


Antics, I know it’s not ideal, but you could make your own font that is all uppercase letters that works with accented characters. For example, type in lowercase and the normal Latin uppercase characters are rendered; use capital letters to render accented letters. If you’re versed with programming outside of Decker, you could write a script to convert normal strings of text into your custom font compliant strings. As long as you don’t need more than 26 accented character variations, it’d work (you could use other keyboard character as well). All caps isn’t bad to read on screen for games like RPGs and such, though it might not be good for visual novel games with large amounts of text.

It’s something to consider, at least.

That is so much nicer to read!

on click do
 f:currfont[]
 each i in range 96
  f[i]:f[i].translate[0,1 1]
 end
 view[]
end

Thank you!

(5 edits)

I find myself wanting to make alternate sizes of the same font or use an existing font to build off of for something entirely new.

I find it efficient to copy the source font, increase the height and then drop the baseline of all glyphs and then edit each glyph as needed.

To accommodate adjusting the baseline of the entire font, I made two buttons that translate all glyphs up and down.

on click do
 f:currfont[]
 i:0
 while i<96
  f[i]:f[i].translate[(0,1) 1]
  i:i+1
 end
 view[]
end

I’m unsure if using a while loop is the best way to access all the glyphs of the current font, but this script seems to work fine. (Font glyphs must range from 0 to 95 though.)

I hope some find this feature useful.

And please let me know if there is a better way to translate an entire font.

Thank you, both of you!

The code worked perfectly.

(1 edit)

I’ve been making several fonts and I believe a 4-directional shift feature of the active glyph image would help immensely (saves having to redraw the entire glyph just to nudge it).

This is a mock-up to illustrate the interface change idea.

image.png

To avoid accidentally losing glyph details, it should wrap the pixels (as one row or column is removed from the edge, it’s added to the opposite side).

If someone would provide the script for each directional button, that would be wonderful. If it seems useful, perhaps this could be an update to the existing font editor deck.

I’ll be sure to share the fonts I make!