Official Everybody Edits Forums

PiotrGrochowski

Member

From: Poland (born in 8 №v 2004)

Joined: 2016-04-27

Posts: 1,118

Re: ByteArray's weekly development vlogs!

▼PiotrGrochowski wrote:

▼PiotrGrochowski wrote:

The more I look at the Basic blocks the less I like them. Compared to the crisp, shiny graphics in EE, in EEU they look dull as the lighting and shading is hard to see (though this might because I am just watching a YouTube video). This, in addition to the thinner outlines make the smileys stick out more than they need to. The dots on the corners of the original make the lighting pop out more. [...]
https://i.imgur.com/dFSZEHM.png

I understand your concerns, but I think Alex did a good job with the basic blocks. To me, they retain what's good about the originals while being completely original. Here's what they look like currently:
https://i.imgur.com/kld3t8n.png

how about TrueType graphics for actual scalability?

if the svg files are not shared then it's impossible for users to make fanmade ttf versions!

Just thought I'd add, one of the big advantages for SVGs for us is that they scale consistently. Personally one of the reasons I don't like the way fullscreen EE looks currently is that, even though there is no blurriness at all, it changes the proportions of blocks quite a lot.

Personally I'd prefer a system like we have currently, which although it is slightly blurry at certain zooms, is far clearer than bitmap scaling, and preserves the original block's proportions much better.

What do you mean by "they scale consistently"?

"Personally one of the reasons I don't like the way fullscreen EE looks currently is that, even though there is no blurriness at all, it changes the proportions of blocks quite a lot." That's because EE uses nearest neighbor, a form of "bitmap scaling".

TrueType isn't "bitmap scaling", it involves hinting which is made by the font designer, and it can involve your "preserves the original block's proportions", at least to the nearest pixel accuracy (using fractional pixels of course results in blur, defeating the purpose of hinting). Although the textures for ttf can be bitmap, they can just as well be vector, avoiding texture upscaling artifacts. And your preference for unhinted graphics is your opinion; there could be a setting to enable/disable hinting, possibly separately for GUI text as well. Speaking of GUI text, hopefully we get the option to customize the font to any system font.

I just mean that if you for example had a brick block or something, the bricks would always have the same width (even if it meant that that width was a fractional number of pixels), while with nearest neighbor / hinting you'd often get some of the blocks being different sizes, which ends up looking weirder than slightly less crisp edges.

I was just comparing hinting to nearest neighbor because when it comes to square blocks with lots of parallel lines, they generally act very similarly, both snap the lines to nearest pixel accuracy and end up distorting the original block's proportions. (When it comes to curved edges hinting is generally a lot better, but in most situations in a game like EE they work very similarly)

▼PiotrGrochowski added:

https://forums.everybodyedits.com/viewt … 73#p757973 shows how scalable EEU could look like, in two different resolutions. You have already stated your opinion on block hinting. How about the rest of the GUI, that is, the GUI text? What do you think of the scalability of that? The zoom level of GUI text could be also customizable in the settings.

Also, think about the zoom level of 4.166666666666667%. That's 1 pixel per block. Should there be any differences between the rendering of this zoom level and the rendering of the minimap? How would smileys, coins and switches be handled at this zoom level, compared to the minimap?

The GUI text is done using the browser's inbuilt text rendering engine, so yes, it currently uses hinting We haven't discussed much about whether the GUI scale should be modifiable, but it does change size automatically to keep in proportion with the rest of the game window.

As for the one pixel per block zoom level thing, blocks will probably be rendered pretty similarly to how they are rendered when converting to a minimap colour, but there are several things we don't plan on appearing on the minimap, I believe that coins were one of them (and the minimap definitely won't be animated like coins would be if the game window were made very small).

Fractional block sizes for hinting are complicated. In the example pictures of scalable EEU, the block sizes are rounded to the nearest pixel, resulting in the zoom level being rounded along with it; also, the view area for the default zoom is always 40 blocks horizontally and 30 blocks vertically, leading to the remaining space (like sidebars?) absorbing the sizing error. It might or might not be a better option to prioritize sidebar width over the viewing area in blocks when the block sizes are rounded to the nearest pixel.

"lots of parallel lines".
You mean something like this

This is actually the worst case scenario. Trying to snap the stem widths to full pixels either leads to stripe distortion like in nearest neighbor, or the block width gets severely distorted (a 35×35 block would become 24×35 or the first/last stripe absorbs the remaining error). If a block like this actually existed in EEU, the type designers would probably give up on hinting to avoid distorting everything. I don't think that many blocks will exhibit this worst case scenario. The TrueType brick example is not even close to that; hinting really does perform much better than nearest neighbor, and I mean it.

"The GUI text is done using the browser's inbuilt text rendering engine, so yes, it currently uses hinting "
How about the version for Microsoft Windows, if there ever will be one, like there is for standard EE? There's no browser involved there. Hopefully it will use the standard Win32 renderer, that is, the GDI. And will we get the ability to customize the GUI text font to any system font?

---

I'm known as "haslo" in EE. Also, I refuse to play EEU.

Raphe9000

Member

Joined: 2015-03-16

Posts: 1,864

Re: ByteArray's weekly development vlogs!

We're aiming for somewhere in the middle—for a lot of these basic materials, it makes sense to have a nice variety of colors. For metal blocks, I'm not sure if we'd expand the options later on or not, but it wouldn't be to cover a full rainbow of colors. For some packs we have planned, their definitely won't be a full range of colors.

Definitely wouldn't expect a full range of color. When it comes to stuff like this, a smaller palette can still work with the right colors. On a minimalist level, the metal pack looks quite redundant with its current colors since there are 3 blocks that can fall under orange and three that can fall under gray. This is not a bad thing (and is really quite a good thing) since metals have a smaller color range and therefore look more different with less color variation than something like plastic, but I think that a few more blanket colors would work like blue and green (colors that together encompass lime, green, cyan, blue, and indigo). Rose is just a good metal type because it is the most identifiable color used for metal not seen here (though it too would help encompass purple, magenta, pink, and red. Are these a make or break deal? No. Do I care one way or the other? Not really. Do I think it could make a good segue into optional expansions to basic packs in the future? Absolutely.

Kentiya, Koya, and you surely know way more about this than I do, but I think that limited color palettes for things like this work amazingly as long as one color can easily be substituted with another. For example, a very small palette that surprises me with its versatility is vermilion, lime, cyan, magenta, and gray. Vermilion works as red, vermilion, and orange; lime works as yellow, lime, and green; cyan works as green, cyan, and blue; magenta works as purple, magenta, and red; gray works as black, white, and gray. Now I hate vermilion and lime, but they make good colors in these instances due to being tertiary colors and therefore good substitutes for both primary and secondary ones. EE is approaching its upper limit when it comes to its amount of base colors, and I have to admit that despite really liking the feature. Because of this, I only expect true essentials to get the full-palette treatment. Metal is not a true essential, but I wouldn't be surprised if adding a few more colors to it would stop the game from needing certain blocks. What immediately comes to mind is that blue metal looks like underwater metal, crystal formations, ice, and just normal ore for decorating underground settings with cooler colors.

No matter what, EEU looks really nice, and I don't want it to appear that I am criticizing it in anyway since I like everything I see.

PiotrGrochowski

Member

From: Poland (born in 8 №v 2004)

Joined: 2016-04-27

Posts: 1,118

Re: ByteArray's weekly development vlogs!

For example, a very small palette that surprises me with its versatility is vermilion, lime, cyan, magenta, and gray. Vermilion works as red, vermilion, and orange; lime works as yellow, lime, and green; cyan works as green, cyan, and blue; magenta works as purple, magenta, and red; gray works as black, white, and gray. Now I hate vermilion and lime, but they make good colors in these instances due to being tertiary colors and therefore good substitutes for both primary and secondary ones.

isn't "lime" an HTML color for 00FF00, which according to this color namer is the Bright Green? isn't Bright Green close to Bright Cyan? and how does cyan work as a blue if those hues are very different? isn't purple a dark shade of magenta? I'm so confused...

---

I'm known as "haslo" in EE. Also, I refuse to play EEU.

Raphe9000

Member

Joined: 2015-03-16

Posts: 1,864

Re: ByteArray's weekly development vlogs!

isn't "lime" an HTML color for 00FF00, which according to this color namer is the Bright Green? isn't Bright Green close to Bright Cyan? and how does cyan work as a blue if those hues are very different? isn't purple a dark shade of magenta? I'm so confused...

Lime is green and yellow usually on the yellow side. I was gonna use chartreuse, but I thought lime was slightly more versatile since chartreuse looks very much like bright green. Cyan and blue are very similar in many contexts since cyan contains blue. I generally can't tell cyan from a lighter blue, but those are just my color sensitivities. Magenta is commonly either pink and purple or red and purple. Another name for magenta is fuchsia.

LukeM

Member

From: England

Joined: 2016-06-03

Posts: 3,009

Website

Re: ByteArray's weekly development vlogs!

▼LukeM wrote:

▼PiotrGrochowski wrote:

▼PiotrGrochowski wrote:

The more I look at the Basic blocks the less I like them. Compared to the crisp, shiny graphics in EE, in EEU they look dull as the lighting and shading is hard to see (though this might because I am just watching a YouTube video). This, in addition to the thinner outlines make the smileys stick out more than they need to. The dots on the corners of the original make the lighting pop out more. [...]
https://i.imgur.com/dFSZEHM.png

I understand your concerns, but I think Alex did a good job with the basic blocks. To me, they retain what's good about the originals while being completely original. Here's what they look like currently:
https://i.imgur.com/kld3t8n.png

how about TrueType graphics for actual scalability?

if the svg files are not shared then it's impossible for users to make fanmade ttf versions!

Just thought I'd add, one of the big advantages for SVGs for us is that they scale consistently. Personally one of the reasons I don't like the way fullscreen EE looks currently is that, even though there is no blurriness at all, it changes the proportions of blocks quite a lot.

Personally I'd prefer a system like we have currently, which although it is slightly blurry at certain zooms, is far clearer than bitmap scaling, and preserves the original block's proportions much better.

What do you mean by "they scale consistently"?

"Personally one of the reasons I don't like the way fullscreen EE looks currently is that, even though there is no blurriness at all, it changes the proportions of blocks quite a lot." That's because EE uses nearest neighbor, a form of "bitmap scaling".

TrueType isn't "bitmap scaling", it involves hinting which is made by the font designer, and it can involve your "preserves the original block's proportions", at least to the nearest pixel accuracy (using fractional pixels of course results in blur, defeating the purpose of hinting). Although the textures for ttf can be bitmap, they can just as well be vector, avoiding texture upscaling artifacts. And your preference for unhinted graphics is your opinion; there could be a setting to enable/disable hinting, possibly separately for GUI text as well. Speaking of GUI text, hopefully we get the option to customize the font to any system font.

I just mean that if you for example had a brick block or something, the bricks would always have the same width (even if it meant that that width was a fractional number of pixels), while with nearest neighbor / hinting you'd often get some of the blocks being different sizes, which ends up looking weirder than slightly less crisp edges.

I was just comparing hinting to nearest neighbor because when it comes to square blocks with lots of parallel lines, they generally act very similarly, both snap the lines to nearest pixel accuracy and end up distorting the original block's proportions. (When it comes to curved edges hinting is generally a lot better, but in most situations in a game like EE they work very similarly)

▼PiotrGrochowski added:

https://forums.everybodyedits.com/viewt … 73#p757973 shows how scalable EEU could look like, in two different resolutions. You have already stated your opinion on block hinting. How about the rest of the GUI, that is, the GUI text? What do you think of the scalability of that? The zoom level of GUI text could be also customizable in the settings.

Also, think about the zoom level of 4.166666666666667%. That's 1 pixel per block. Should there be any differences between the rendering of this zoom level and the rendering of the minimap? How would smileys, coins and switches be handled at this zoom level, compared to the minimap?

The GUI text is done using the browser's inbuilt text rendering engine, so yes, it currently uses hinting We haven't discussed much about whether the GUI scale should be modifiable, but it does change size automatically to keep in proportion with the rest of the game window.

As for the one pixel per block zoom level thing, blocks will probably be rendered pretty similarly to how they are rendered when converting to a minimap colour, but there are several things we don't plan on appearing on the minimap, I believe that coins were one of them (and the minimap definitely won't be animated like coins would be if the game window were made very small).

Fractional block sizes for hinting are complicated. In the example pictures of scalable EEU, the block sizes are rounded to the nearest pixel, resulting in the zoom level being rounded along with it; also, the view area for the default zoom is always 40 blocks horizontally and 30 blocks vertically, leading to the remaining space (like sidebars?) absorbing the sizing error. It might or might not be a better option to prioritize sidebar width over the viewing area in blocks when the block sizes are rounded to the nearest pixel.

"lots of parallel lines".
You mean something like this
https://i.imgur.com/SumJeXS.png
This is actually the worst case scenario. Trying to snap the stem widths to full pixels either leads to stripe distortion like in nearest neighbor, or the block width gets severely distorted (a 35×35 block would become 24×35 or the first/last stripe absorbs the remaining error). If a block like this actually existed in EEU, the type designers would probably give up on hinting to avoid distorting everything. I don't think that many blocks will exhibit this worst case scenario. The TrueType brick example is not even close to that; hinting really does perform much better than nearest neighbor, and I mean it.

"The GUI text is done using the browser's inbuilt text rendering engine, so yes, it currently uses hinting "
How about the version for Microsoft Windows, if there ever will be one, like there is for standard EE? There's no browser involved there. Hopefully it will use the standard Win32 renderer, that is, the GDI. And will we get the ability to customize the GUI text font to any system font?

With the parallel lines example I was thinking of blocks where there are multiple layered borders and/or lots of evenly spaced 'ridges' along the block. A lot of blocks in EE are like this, and I guess although it doesn't perform *that* badly with the brick example you gave, the borders around the bricks do noticably jump from fairly thick (e.g. in the 40x40 graphic) to really thin (e.g. in the 32x32 graphic), and that would be exaggerated with the smaller brick graphics.

As for the GUI text in the desktop version, we're likely to use something to run JS natively, such as Electron or PWAs, so we're still probably going to be using a built in text rendering engine with hinting

PiotrGrochowski

Member

From: Poland (born in 8 №v 2004)

Joined: 2016-04-27

Posts: 1,118

Re: ByteArray's weekly development vlogs!

▼LukeM wrote:

▼PiotrGrochowski wrote:

▼PiotrGrochowski wrote:

The more I look at the Basic blocks the less I like them. Compared to the crisp, shiny graphics in EE, in EEU they look dull as the lighting and shading is hard to see (though this might because I am just watching a YouTube video). This, in addition to the thinner outlines make the smileys stick out more than they need to. The dots on the corners of the original make the lighting pop out more. [...]
https://i.imgur.com/dFSZEHM.png

I understand your concerns, but I think Alex did a good job with the basic blocks. To me, they retain what's good about the originals while being completely original. Here's what they look like currently:
https://i.imgur.com/kld3t8n.png

how about TrueType graphics for actual scalability?

if the svg files are not shared then it's impossible for users to make fanmade ttf versions!

Just thought I'd add, one of the big advantages for SVGs for us is that they scale consistently. Personally one of the reasons I don't like the way fullscreen EE looks currently is that, even though there is no blurriness at all, it changes the proportions of blocks quite a lot.

Personally I'd prefer a system like we have currently, which although it is slightly blurry at certain zooms, is far clearer than bitmap scaling, and preserves the original block's proportions much better.

What do you mean by "they scale consistently"?

"Personally one of the reasons I don't like the way fullscreen EE looks currently is that, even though there is no blurriness at all, it changes the proportions of blocks quite a lot." That's because EE uses nearest neighbor, a form of "bitmap scaling".

TrueType isn't "bitmap scaling", it involves hinting which is made by the font designer, and it can involve your "preserves the original block's proportions", at least to the nearest pixel accuracy (using fractional pixels of course results in blur, defeating the purpose of hinting). Although the textures for ttf can be bitmap, they can just as well be vector, avoiding texture upscaling artifacts. And your preference for unhinted graphics is your opinion; there could be a setting to enable/disable hinting, possibly separately for GUI text as well. Speaking of GUI text, hopefully we get the option to customize the font to any system font.

I just mean that if you for example had a brick block or something, the bricks would always have the same width (even if it meant that that width was a fractional number of pixels), while with nearest neighbor / hinting you'd often get some of the blocks being different sizes, which ends up looking weirder than slightly less crisp edges.

I was just comparing hinting to nearest neighbor because when it comes to square blocks with lots of parallel lines, they generally act very similarly, both snap the lines to nearest pixel accuracy and end up distorting the original block's proportions. (When it comes to curved edges hinting is generally a lot better, but in most situations in a game like EE they work very similarly)

▼PiotrGrochowski added:

https://forums.everybodyedits.com/viewt … 73#p757973 shows how scalable EEU could look like, in two different resolutions. You have already stated your opinion on block hinting. How about the rest of the GUI, that is, the GUI text? What do you think of the scalability of that? The zoom level of GUI text could be also customizable in the settings.

Also, think about the zoom level of 4.166666666666667%. That's 1 pixel per block. Should there be any differences between the rendering of this zoom level and the rendering of the minimap? How would smileys, coins and switches be handled at this zoom level, compared to the minimap?

The GUI text is done using the browser's inbuilt text rendering engine, so yes, it currently uses hinting We haven't discussed much about whether the GUI scale should be modifiable, but it does change size automatically to keep in proportion with the rest of the game window.

As for the one pixel per block zoom level thing, blocks will probably be rendered pretty similarly to how they are rendered when converting to a minimap colour, but there are several things we don't plan on appearing on the minimap, I believe that coins were one of them (and the minimap definitely won't be animated like coins would be if the game window were made very small).

Fractional block sizes for hinting are complicated. In the example pictures of scalable EEU, the block sizes are rounded to the nearest pixel, resulting in the zoom level being rounded along with it; also, the view area for the default zoom is always 40 blocks horizontally and 30 blocks vertically, leading to the remaining space (like sidebars?) absorbing the sizing error. It might or might not be a better option to prioritize sidebar width over the viewing area in blocks when the block sizes are rounded to the nearest pixel.

"lots of parallel lines".
You mean something like this
https://i.imgur.com/SumJeXS.png
This is actually the worst case scenario. Trying to snap the stem widths to full pixels either leads to stripe distortion like in nearest neighbor, or the block width gets severely distorted (a 35×35 block would become 24×35 or the first/last stripe absorbs the remaining error). If a block like this actually existed in EEU, the type designers would probably give up on hinting to avoid distorting everything. I don't think that many blocks will exhibit this worst case scenario. The TrueType brick example is not even close to that; hinting really does perform much better than nearest neighbor, and I mean it.

"The GUI text is done using the browser's inbuilt text rendering engine, so yes, it currently uses hinting "
How about the version for Microsoft Windows, if there ever will be one, like there is for standard EE? There's no browser involved there. Hopefully it will use the standard Win32 renderer, that is, the GDI. And will we get the ability to customize the GUI text font to any system font?

With the parallel lines example I was thinking of blocks where there are multiple layered borders and/or lots of evenly spaced 'ridges' along the block. A lot of blocks in EE are like this, and I guess although it doesn't perform *that* badly with the brick example you gave, the borders around the bricks do noticably jump from fairly thick (e.g. in the 40x40 graphic) to really thin (e.g. in the 32x32 graphic), and that would be exaggerated with the smaller brick graphics.

As for the GUI text in the desktop version, we're likely to use something to run JS natively, such as Electron or PWAs, so we're still probably going to be using a built in text rendering engine with hinting

"there are multiple layered borders and/or lots of evenly spaced 'ridges' along the block"

So, a block like this then.

"A lot of blocks in EE are like this". I think you should give me an example of one or something.

"the borders around the bricks do noticably jump from fairly thick (e.g. in the 40x40 graphic) to really thin (e.g. in the 32x32 graphic)"
This is unavoidable when hinting. 1 or 2 pixels or otherwise it gets blurry.
Here is the pretty much the same thing happening with the hinting of Arial:

"and that would be exaggerated with the smaller brick graphics"
This one is a bit more complicated. It's a tradeoff between having fractional widths and positioning and blur everywhere, and having everything optimized to the pixel grid. The type designer isn't forced to strictly choose one or the other for the entire font when hinting; the type designer could choose to snap a particular feature to a full pixel, then the thickness of a line could be fractional, etc.

Also, with hinting, the graphics end up not being strictly 24×24. TrueType graphics with hinting are just as optimized for 24×24 as they are for 23×23 or 25×25.

Note that the snapping performed for 24×24 isn't hard-wired into the font, that's why fonts are software, not hardware! When rendering a 23×23 block, a different set of optimizations would be done for stuff like the row heights. The design can be adjusted and finetuned by the font designer as opposed to being hard-wired for 24×24 optimization, and then hinted to become optimized at all possible sizes.

isn't "lime" an HTML color for 00FF00, which according to this color namer is the Bright Green? isn't Bright Green close to Bright Cyan? and how does cyan work as a blue if those hues are very different? isn't purple a dark shade of magenta? I'm so confused...

Lime is green and yellow usually on the yellow side. I was gonna use chartreuse, but I thought lime was slightly more versatile since chartreuse looks very much like bright green. Cyan and blue are very similar in many contexts since cyan contains blue. I generally can't tell cyan from a lighter blue, but those are just my color sensitivities. Magenta is commonly either pink and purple or red and purple. Another name for magenta is fuchsia.

80FF00 (a Bright Chartreuse, although this hue name is not used by the color namer) should be the color in between 00FF00 (Bright Green) and FFFF00 (Bright Yellow). However, it looks closer to Bright Green, and the reason is the interesting way human perception works. In sRGB, each channel isn't a linear scale. They did this because humans are more sensitive to differences in darker colors. However, Bright Green and Bright Yellow are both bright colors, so this doesn't apply, and the distorted scale of sRGB causes this to happen.

Bright Cyan does contain the blue channel, but it also contains the green channel. Bright Blue doesn't contain the green channel. And the green channel is the one that humans are the most sensitive to!

Look how very different those two colors are (Bright Cyan and Bright Blue):

████████████████
████████████████
████████████████
████████████████

"Magenta is commonly either pink and purple or red and purple."
What? WWhhaatt?? I don't get it? What the? Aefiahnfiuwbx? This is so confusing. All I know is that Magenta is a hue in between Blue and Red, and Violet is in between Blue and Magenta, and Rose is in between Magenta and Red.

For reference, here is an HTML5 graph of all the colors used by my color namer; it is based on HSV:

          Red    Orange  Yellow  Green    Cyan   Azure    Blue   Violet Magenta   Rose
        ████████████████████████████████████████████████████████████████████████████████
        ████████████████████████████████████████████████████████████████████████████████
  Pale  ████████████████████████████████████████████████████████████████████████████████
        ████████████████████████████████████████████████████████████████████████████████
        ████████████████████████████████████████████████████████████████████████████████
        ████████████████████████████████████████████████████████████████████████████████
  Dull  ████████████████████████████████████████████████████████████████████████████████
        ████████████████████████████████████████████████████████████████████████████████
        ████████████████████████████████████████████████████████████████████████████████
        ████████████████████████████████████████████████████████████████████████████████
 Bright ████████████████████████████████████████████████████████████████████████████████
        ████████████████████████████████████████████████████████████████████████████████
        ████████████████████████████████████████████████████████████████████████████████
        ████████████████████████████████████████████████████████████████████████████████
  Dark  ████████████████████████████████████████████████████████████████████████████████
        ████████████████████████████████████████████████████████████████████████████████



        ████████        ████████        ████████        ████████        ████████
        ████████        ████████        ████████        ████████        ████████
        ████████        ████████        ████████        ████████        ████████
        ████████        ████████        ████████        ████████        ████████
         Black         Dark Gray        Mid Gray       Light Gray        White

(If this is rendered incorrectly by your system, this picture shows the correct rendering.)

---

I'm known as "haslo" in EE. Also, I refuse to play EEU.

Gosha

Member

From: Russia

Joined: 2015-03-15

Posts: 6,211

Re: ByteArray's weekly development vlogs!

why do we care about the scale again if blocks will be 24x24 pixels?

PiotrGrochowski

Member

From: Poland (born in 8 №v 2004)

Joined: 2016-04-27

Posts: 1,118

Re: ByteArray's weekly development vlogs!

why do we care about the scale again if blocks will be 24x24 pixels?

Think about it, would a user playing EEU in a 640×480 window LIKE having 24×24 blocks? Yeah, EEU should be device independent, and therefore a scalable UI is the way to go. Not to mention, even at a 1200×900 (?) resolution where the blocks are by default 24×24, a user would still sometimes like to zoom in or zoom out. I myself would like to play EEU in a 640×480 window on my 1366×768 screen and I hate when games are fullscreen.

---

I'm known as "haslo" in EE. Also, I refuse to play EEU.

Raphe9000

Member

Joined: 2015-03-16

Posts: 1,864

Re: ByteArray's weekly development vlogs!

▼Off topic color stuff

80FF00 (a Bright Chartreuse, although this hue name is not used by the color namer) should be the color in between 00FF00 (Bright Green) and FFFF00 (Bright Yellow). However, it looks closer to Bright Green, and the reason is the interesting way human perception works.

Hence why I chose the yellower lime.

Bright Cyan does contain the blue channel, but it also contains the green channel. Bright Blue doesn't contain the green channel. And the green channel is the one that humans are the most sensitive to!

Look how very different those two colors are (Bright Cyan and Bright Blue):

They look quite similar to me, about as similar as red and orange (and orange is a color that looks so close to red English didn't even have a language for it, hence why gingers are known to have red hair). That being said, the biggest difference I see is that the blue you used is dark. If you used light blue, it would be harder to tell it apart. And whilst cyan is equal blue and green, many different shades of cyan still known as cyan exist. Azure works well too if you wish, as the color I really wanted was the lesser known capri. Lime is more well known than chartreuse, but capri is not more well known than cyan or azure.

What? WWhhaatt?? I don't get it? What the? Aefiahnfiuwbx? This is so confusing. All I know is that Magenta is a hue in between Blue and Red, and Violet is in between Blue and Magenta, and Rose is in between Magenta and Red.

For the definition I use (and the main one Wikipedia uses), Magenta is a tertiary color; in RGB, it's secondary; in CMYK, it's primary.

Think about it, would a user playing EEU in a 640×480 window LIKE having 24×24 blocks? Yeah, EEU should be device independent, and therefore a scalable UI is the way to go. Not to mention, even at a 1200×900 (?) resolution where the blocks are by default 24×24, a user would still sometimes like to zoom in or zoom out. I myself would like to play EEU in a 640×480 window on my 1366×768 screen and I hate when games are fullscreen.

That's the big thing I see with vector graphics in EEU since playing even the original EE in fullscreen sucked due to the scaling.

PiotrGrochowski

Member

From: Poland (born in 8 №v 2004)

Joined: 2016-04-27

Posts: 1,118

Re: ByteArray's weekly development vlogs!

▼Off topic color stuff

80FF00 (a Bright Chartreuse, although this hue name is not used by the color namer) should be the color in between 00FF00 (Bright Green) and FFFF00 (Bright Yellow). However, it looks closer to Bright Green, and the reason is the interesting way human perception works.

Hence why I chose the yellower lime.

Bright Cyan does contain the blue channel, but it also contains the green channel. Bright Blue doesn't contain the green channel. And the green channel is the one that humans are the most sensitive to!

Look how very different those two colors are (Bright Cyan and Bright Blue):

They look quite similar to me, about as similar as red and orange (and orange is a color that looks so close to red English didn't even have a language for it, hence why gingers are known to have red hair). That being said, the biggest difference I see is that the blue you used is dark. If you used light blue, it would be harder to tell it apart. And whilst cyan is equal blue and green, many different shades of cyan still known as cyan exist. Azure works well too if you wish, as the color I really wanted was the lesser known capri. Lime is more well known than chartreuse, but capri is not more well known than cyan or azure.

What? WWhhaatt?? I don't get it? What the? Aefiahnfiuwbx? This is so confusing. All I know is that Magenta is a hue in between Blue and Red, and Violet is in between Blue and Magenta, and Rose is in between Magenta and Red.

For the definition I use (and the main one Wikipedia uses), Magenta is a tertiary color; in RGB, it's secondary; in CMYK, it's primary.

▼Off topic color stuff

"Hence why I chose the yellower lime."
And there's the problem, "lime" is HTML for 00FF00, which is Bright Green. I don't get it.

"That being said, the biggest difference I see is that the blue you used is dark. If you used light blue, it would be harder to tell it apart. And whilst cyan is equal blue and green, many different shades of cyan still known as cyan exist. Azure works well too if you wish, as the color I really wanted was the lesser known capri. Lime is more well known than chartreuse, but capri is not more well known than cyan or azure."

What do you mean by "light blue"? This color name is not used by my color namer so I don't get what you mean.

"For the definition I use (and the main one Wikipedia uses), Magenta is a tertiary color; in RGB, it's secondary; in CMYK, it's primary."

"Magenta as a tertiary color" refers to the RYB (red yellow blue) color system. Unlike sRGB it isn't a specific defined system so it is meaningless. "purple" is HTML for 800080 which in the HSV terms of my color namer is the Dark Magenta, so for all intents and purposes purple is not a distinct hue from magenta; they have the exact same hue.

---

I'm known as "haslo" in EE. Also, I refuse to play EEU.

PiotrGrochowski

Member

From: Poland (born in 8 №v 2004)

Joined: 2016-04-27

Posts: 1,118

Re: ByteArray's weekly development vlogs!

How would the EEU physics work if the player happened to be inside a block? Does the player get stuck, like in Everybody Edits? Does the player automatically move to the right, like in Super Mario Bros? Does the player instantly move to the Euclidean-closest location not occupied by a block?

---

I'm known as "haslo" in EE. Also, I refuse to play EEU.

LukeM

Member

From: England

Joined: 2016-06-03

Posts: 3,009

Website

Re: ByteArray's weekly development vlogs!

▼LukeM wrote:

▼LukeM wrote:

▼PiotrGrochowski wrote:

▼PiotrGrochowski wrote:

The more I look at the Basic blocks the less I like them. Compared to the crisp, shiny graphics in EE, in EEU they look dull as the lighting and shading is hard to see (though this might because I am just watching a YouTube video). This, in addition to the thinner outlines make the smileys stick out more than they need to. The dots on the corners of the original make the lighting pop out more. [...]
https://i.imgur.com/dFSZEHM.png

I understand your concerns, but I think Alex did a good job with the basic blocks. To me, they retain what's good about the originals while being completely original. Here's what they look like currently:
https://i.imgur.com/kld3t8n.png

how about TrueType graphics for actual scalability?

if the svg files are not shared then it's impossible for users to make fanmade ttf versions!

Just thought I'd add, one of the big advantages for SVGs for us is that they scale consistently. Personally one of the reasons I don't like the way fullscreen EE looks currently is that, even though there is no blurriness at all, it changes the proportions of blocks quite a lot.

Personally I'd prefer a system like we have currently, which although it is slightly blurry at certain zooms, is far clearer than bitmap scaling, and preserves the original block's proportions much better.

What do you mean by "they scale consistently"?

"Personally one of the reasons I don't like the way fullscreen EE looks currently is that, even though there is no blurriness at all, it changes the proportions of blocks quite a lot." That's because EE uses nearest neighbor, a form of "bitmap scaling".

TrueType isn't "bitmap scaling", it involves hinting which is made by the font designer, and it can involve your "preserves the original block's proportions", at least to the nearest pixel accuracy (using fractional pixels of course results in blur, defeating the purpose of hinting). Although the textures for ttf can be bitmap, they can just as well be vector, avoiding texture upscaling artifacts. And your preference for unhinted graphics is your opinion; there could be a setting to enable/disable hinting, possibly separately for GUI text as well. Speaking of GUI text, hopefully we get the option to customize the font to any system font.

I just mean that if you for example had a brick block or something, the bricks would always have the same width (even if it meant that that width was a fractional number of pixels), while with nearest neighbor / hinting you'd often get some of the blocks being different sizes, which ends up looking weirder than slightly less crisp edges.

I was just comparing hinting to nearest neighbor because when it comes to square blocks with lots of parallel lines, they generally act very similarly, both snap the lines to nearest pixel accuracy and end up distorting the original block's proportions. (When it comes to curved edges hinting is generally a lot better, but in most situations in a game like EE they work very similarly)

▼PiotrGrochowski added:

https://forums.everybodyedits.com/viewt … 73#p757973 shows how scalable EEU could look like, in two different resolutions. You have already stated your opinion on block hinting. How about the rest of the GUI, that is, the GUI text? What do you think of the scalability of that? The zoom level of GUI text could be also customizable in the settings.

Also, think about the zoom level of 4.166666666666667%. That's 1 pixel per block. Should there be any differences between the rendering of this zoom level and the rendering of the minimap? How would smileys, coins and switches be handled at this zoom level, compared to the minimap?

The GUI text is done using the browser's inbuilt text rendering engine, so yes, it currently uses hinting We haven't discussed much about whether the GUI scale should be modifiable, but it does change size automatically to keep in proportion with the rest of the game window.

As for the one pixel per block zoom level thing, blocks will probably be rendered pretty similarly to how they are rendered when converting to a minimap colour, but there are several things we don't plan on appearing on the minimap, I believe that coins were one of them (and the minimap definitely won't be animated like coins would be if the game window were made very small).

Fractional block sizes for hinting are complicated. In the example pictures of scalable EEU, the block sizes are rounded to the nearest pixel, resulting in the zoom level being rounded along with it; also, the view area for the default zoom is always 40 blocks horizontally and 30 blocks vertically, leading to the remaining space (like sidebars?) absorbing the sizing error. It might or might not be a better option to prioritize sidebar width over the viewing area in blocks when the block sizes are rounded to the nearest pixel.

"lots of parallel lines".
You mean something like this
https://i.imgur.com/SumJeXS.png
This is actually the worst case scenario. Trying to snap the stem widths to full pixels either leads to stripe distortion like in nearest neighbor, or the block width gets severely distorted (a 35×35 block would become 24×35 or the first/last stripe absorbs the remaining error). If a block like this actually existed in EEU, the type designers would probably give up on hinting to avoid distorting everything. I don't think that many blocks will exhibit this worst case scenario. The TrueType brick example is not even close to that; hinting really does perform much better than nearest neighbor, and I mean it.

"The GUI text is done using the browser's inbuilt text rendering engine, so yes, it currently uses hinting "
How about the version for Microsoft Windows, if there ever will be one, like there is for standard EE? There's no browser involved there. Hopefully it will use the standard Win32 renderer, that is, the GDI. And will we get the ability to customize the GUI text font to any system font?

With the parallel lines example I was thinking of blocks where there are multiple layered borders and/or lots of evenly spaced 'ridges' along the block. A lot of blocks in EE are like this, and I guess although it doesn't perform *that* badly with the brick example you gave, the borders around the bricks do noticably jump from fairly thick (e.g. in the 40x40 graphic) to really thin (e.g. in the 32x32 graphic), and that would be exaggerated with the smaller brick graphics.

As for the GUI text in the desktop version, we're likely to use something to run JS natively, such as Electron or PWAs, so we're still probably going to be using a built in text rendering engine with hinting

"there are multiple layered borders and/or lots of evenly spaced 'ridges' along the block"

So, a block like this then.

https://i.imgur.com/6XUVoUf.png

"A lot of blocks in EE are like this". I think you should give me an example of one or something.

"the borders around the bricks do noticably jump from fairly thick (e.g. in the 40x40 graphic) to really thin (e.g. in the 32x32 graphic)"
This is unavoidable when hinting. 1 or 2 pixels or otherwise it gets blurry.
Here is the pretty much the same thing happening with the hinting of Arial:
https://i.imgur.com/rjSpijE.png

I guess I was thinking of these sorts of blocks: (can't really be bothered to crop a load of images myself so I'll just link the wiki images and give the positions)
2, 3, 5
3, 4, 5
2
1, 2, 3, 4

all
2, 3, 4, 5, 6, 7, 11, 12, 13, 14
1, 2, 4
etc

I get that there isn't really a way around having the weird border jump with hinting, this is one of the reasons I prefer SVGs, hinting looks great for fonts, but I don't really think it works well when you want to preserve the aesthetic of a block.

"and that would be exaggerated with the smaller brick graphics"
This one is a bit more complicated. It's a tradeoff between having fractional widths and positioning and blur everywhere, and having everything optimized to the pixel grid. The type designer isn't forced to strictly choose one or the other for the entire font when hinting; the type designer could choose to snap a particular feature to a full pixel, then the thickness of a line could be fractional, etc.

Also, with hinting, the graphics end up not being strictly 24×24. TrueType graphics with hinting are just as optimized for 24×24 as they are for 23×23 or 25×25.

https://i.imgur.com/vJj28pY.png

Note that the snapping performed for 24×24 isn't hard-wired into the font, that's why fonts are software, not hardware! When rendering a 23×23 block, a different set of optimizations would be done for stuff like the row heights. The design can be adjusted and finetuned by the font designer as opposed to being hard-wired for 24×24 optimization, and then hinted to become optimized at all possible sizes.

SVGs are generally pretty good at removing blur, browsers have pretty sophisticated rendering engines that end up keeping things looking fairly crisp. When I switch from SVG scaling to bitmap scaling on my 1050p monitor, SVG scaling looks significantly better, to the point that I personally prefer that look to the slightly crisper look of an explicitely hinted graphic.

How would the EEU physics work if the player happened to be inside a block? Does the player get stuck, like in Everybody Edits? Does the player automatically move to the right, like in Super Mario Bros? Does the player instantly move to the Euclidean-closest location not occupied by a block?

Currently when you un-god on top of a block you fall through it (although you collide with blocks next to it). We think this generally makes the game a lot easier to control, as un-godding into a one block wide gap is now incredibly easy instead of it taking several tries and a lot of frustrated key tapping in EE. We're currently fairly undecided on what should happen in other scenarios though, so we'll likely just try a few and see which feels best through play-testing.

PiotrGrochowski

Member

From: Poland (born in 8 №v 2004)

Joined: 2016-04-27

Posts: 1,118

Re: ByteArray's weekly development vlogs!

"I guess I was thinking of these sorts of blocks: (can't really be bothered to crop a load of images myself so I'll just link the wiki images and give the positions)"
https://wiki.everybodyedits.com/images/ … neric.png2, 3, 5
https://wiki.everybodyedits.com/images/ … ctory.png3, 4
https://wiki.everybodyedits.com/images/ … n2011.png2
https://wiki.everybodyedits.com/images/ … ci-fi.png1, 2, 3, 4
https://wiki.everybodyedits.com/images/ … prison.png
https://wiki.everybodyedits.com/images/ … tic.pngall
https://wiki.everybodyedits.com/images/ … trial.png2, 3, 4, 5, 6, 7, 11, 12, 13, 14
https://wiki.everybodyedits.com/File:Bl … n2015.png1, 2
etc

Still, it isn't that absolute worst case with many 1 pixel thick features next to each other. And it isn't necessary to use outlines and hinting for every single feature; textures might as well work sometimes.

"SVGs are generally pretty good at removing blur, browsers have pretty sophisticated rendering engines that end up keeping things looking fairly crisp. When I switch from SVG scaling to bitmap scaling on my 1050p monitor, SVG scaling looks significantly better, to the point that I personally prefer that look to the slightly crisper look of an explicitely hinted graphic."

Keep in mind, there are actually many bitmap scaling algorithms out there. What bitmap scaling algorithms have you tested? Have you heard somewhere on the Internet that web browsers have advanced rendering engines, as opposed to the relatively simple oversample 4× or 6× and then downscale with box filter?

---

I'm known as "haslo" in EE. Also, I refuse to play EEU.

LukeM

Member

From: England

Joined: 2016-06-03

Posts: 3,009

Website

Re: ByteArray's weekly development vlogs!

Keep in mind, there are actually many bitmap scaling algorithms out there. What bitmap scaling algorithms have you tested? Have you heard somewhere on the Internet that web browsers have advanced rendering engines, as opposed to the relatively simple oversample 4× or 6× and then downscale with box filter?

I compared the best looking image we could get from rendering at a nice multiple of the width then rescaling (and we tried several methods and scaling algorithms) to rendering at the final size using SVGs directly.

PiotrGrochowski

Member

From: Poland (born in 8 №v 2004)

Joined: 2016-04-27

Posts: 1,118

Re: ByteArray's weekly development vlogs!

Keep in mind, there are actually many bitmap scaling algorithms out there. What bitmap scaling algorithms have you tested? Have you heard somewhere on the Internet that web browsers have advanced rendering engines, as opposed to the relatively simple oversample 4× or 6× and then downscale with box filter?

I compared the best looking image we could get from rendering at a nice multiple of the width then rescaling (and we tried several methods and scaling algorithms) to rendering at the final size using SVGs directly.

What are the actual results?

How would the EEU physics work if the player happened to be inside a block? Does the player get stuck, like in Everybody Edits? Does the player automatically move to the right, like in Super Mario Bros? Does the player instantly move to the Euclidean-closest location not occupied by a block?

Currently when you un-god on top of a block you fall through it (although you collide with blocks next to it). We think this generally makes the game a lot easier to control, as un-godding into a one block wide gap is now incredibly easy instead of it taking several tries and a lot of frustrated key tapping in EE. We're currently fairly undecided on what should happen in other scenarios though, so we'll likely just try a few and see which feels best through play-testing.

What happens when the player is inside of a block, but at the bottom of the world? Is the player stuck? Does the player's y position overflow to the top of the level? Can the player jump in this scenario?

---

I'm known as "haslo" in EE. Also, I refuse to play EEU.

ByteArray

Member

From: United States

Joined: 2015-02-17

Posts: 158

Re: ByteArray's weekly development vlogs!

Alright, well yesterday's video primarily focused on some new graphics we have in EE Universe! I've added three new smileys (meh, sad, & surprised), and tweaked the original two. Alex has also finished the new coin animation! As per usual there's the possibility of slight refinements here and there. Another development on the graphics side of things is that Minisaurus has rejoined the graphics team, and has been making good progress on a bunch of concepts for different smiley accessories (hats, eyewear, etc.)!

Luke is also ready to start hooking up his new database and user account systems into the actual game, and that'll take us much closer to being ready to launch the closed beta. He's also been working on attempting to get EE back up and running, so if all goes well you should hopefully be able to play EE again very soon.

One thing I forgot to mention in the video was that we've also been working on the new logo for EE Universe, and I think you guys will like it! We'll most likely wait to reveal it until the closed beta launch.

---

former lead-dev on EE/EEU, 2018—2020
(aka Criobite, Joshua Stone, TechnoWolf99, & LightWolf)

mikelolsuperman

Member

From: North Korea

Joined: 2016-06-26

Posts: 1,683

Website

Re: ByteArray's weekly development vlogs!

One thing I forgot to mention in the video was that we've also been working on the new logo for EE Universe, and I think you guys will like it! We'll most likely wait to reveal it until the closed beta launch.

No more comic sans?

---

Blue is my favourite color

Signature made by Nebula

I also like lasagna, but not when it's blue

PiotrGrochowski

Member

From: Poland (born in 8 №v 2004)

Joined: 2016-04-27

Posts: 1,118

Re: ByteArray's weekly development vlogs!

Wait a minute; if the minimap color is determined by the average of the pixels of the 24×24 rendering, won't that mean that the EEU-mineral blocks (the ones that have the colors: 000000, 0000FF, FF0000, FF00FF, 00FF00, 00FFFF, FFFF00, FFFFFF) have to be completely their color?

---

I'm known as "haslo" in EE. Also, I refuse to play EEU.

ByteArray

Member

From: United States

Joined: 2015-02-17

Posts: 158

Re: ByteArray's weekly development vlogs!

Wait a minute; if the minimap color is determined by the average of the pixels of the 24×24 rendering, won't that mean that the EEU-mineral blocks (the ones that have the colors: 000000, 0000FF, FF0000, FF00FF, 00FF00, 00FFFF, FFFF00, FFFFFF) have to be completely their color?

We can technically enter whatever color we want for minimap colors, but the average make sense most of the time just like in EE. I don't know for sure that we'll have full saturation colors for a mineral block equivalent—we'll decide on that when we get to that point.

---

former lead-dev on EE/EEU, 2018—2020
(aka Criobite, Joshua Stone, TechnoWolf99, & LightWolf)

ByteArray

Member

From: United States

Joined: 2015-02-17

Posts: 158

Re: ByteArray's weekly development vlogs!

Well, last week was definitely a bit of a crazy one. I started off working on finishing the new EEU logo, coaching Minisaurus on the art style we're going for, and working on some of my own projects. But just after EE was brought back online, we quickly realized there were still quite a few compromised worlds with obscene images in them that slipped by Luke's previous attempts at eradicating them.

So we updated the game to prevent minimaps from rendering at all while I got to work processing the worlds to locate every single one. It required a bunch of complicated techniques to narrow down the list of potentially compromised worlds out of the around 1.6 million worlds in EE (including a lot of duplicates they created of random worlds). After doing a few passes of a variety of different methods for detecting them, I found a total of just under 9,000 worlds, and sent Luke that data to restore them all to a previous backup.

At this point I'm fairly confident that we've caught all of the worlds, but considering the sheer magnitude of the number of worlds there's a small chance of finding a couple of stray ones. I'm really hoping that won't be the case, and I'll be doing a few more passes over everything just to be sure.

---

former lead-dev on EE/EEU, 2018—2020
(aka Criobite, Joshua Stone, TechnoWolf99, & LightWolf)

ByteArray

Member

From: United States

Joined: 2015-02-17

Posts: 158

Re: ByteArray's weekly development vlogs!

Okay, so Sunday's video was primarily about the progress that's been made on implementing spawn points, working on new smileys, and Luke's progress with integrating the new account and database systems! Things are definitely coming together, and although dealing with getting EE back up and resolving the situation with compromised worlds delayed things a little, we're getting back into things and making good headway towards starting the closed beta phase.

---

former lead-dev on EE/EEU, 2018—2020
(aka Criobite, Joshua Stone, TechnoWolf99, & LightWolf)

peace

Member

From: admin land

Joined: 2015-08-10

Posts: 9,226

Re: ByteArray's weekly development vlogs!

giv eme a predixcted date you think amdoen wiht CB EEU

---

thanks hg for making this much better and ty for my avatar aswell

ByteArray

Member

From: United States

Joined: 2015-02-17

Posts: 158

Re: ByteArray's weekly development vlogs!

Hey guys! So, last week I didn't end up posting about my vlog on here. That was mostly just because it wasn't focused on EEU for the most part, and it seemed weird to post here (it mostly talked about the short film my brothers and I are making as a sequel to our previous one).

But anyway, this week's video primarily focused on two things: that I've started implementing the new "zones" system, and that accounts are now set up using external authentication like Google & Facebook.

▼Last week's video...

I'll be wrapping up the zones functionality over this week, so you'll get to see them in action next week! And now that the backend systems for accounts and world saving are finished, I'll be working on the frontend UI for those as well. Luke is of course now working on fixing the issues we've found with the physics, so we're definitely in the final stretch to finally launch the closed beta!

---

former lead-dev on EE/EEU, 2018—2020
(aka Criobite, Joshua Stone, TechnoWolf99, & LightWolf)

ByteArray

Member

From: United States

Joined: 2015-02-17

Posts: 158

Re: ByteArray's weekly development vlogs!

So—late posting here again, just been busy wrapping up multiple things. Anyway, last week I primarily worked on finishing the implementation of the zones system in EEU! There were still a couple of things that overlapped with this week, such as making Edit Zones give players limited edit rights.

But that's all done now, and I'm starting on creating the new login interface and everything that goes along with that since Luke has everything with the accounts and authentication fully functional internally. Once that's done, I'll work on wrapping up the various smaller tasks that need completed before the closed beta launch. And if all goes well, we might be able to launch around the end of the month!

---

former lead-dev on EE/EEU, 2018—2020
(aka Criobite, Joshua Stone, TechnoWolf99, & LightWolf)

peace

Member

From: admin land

Joined: 2015-08-10

Posts: 9,226

Re: ByteArray's weekly development vlogs!

we might be able to launch around the end of the month!

*gets hyped* IM READY

---

thanks hg for making this much better and ty for my avatar aswell