Official Everybody Edits Forums

Do you think I could just leave this part blank and it'd be okay? We're just going to replace the whole thing with a header image anyway, right?

You are not logged in.

Advertisement

Hello, visitor! These forums are run off of the revenue generated from these ads. If you'd like to support us, please whitelist us or consider donating:

#176 2019-08-06 20:03:31, last edited by PiotrGrochowski (2019-08-06 20:04:30)

PiotrGrochowski
Member
From: Poland (born in 8 №v 2004)
Joined: 2016-04-27
Posts: 654

Re: ByteArray's weekly development vlogs!

LukeM wrote:
PiotrGrochowski wrote:

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:

The GUI text is done using the browser's inbuilt text rendering engine, so yes, it currently uses hinting //ee.failforums.me/img/smilies/smile 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
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 //ee.failforums.me/img/smilies/smile"
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.

Offline

#177 2019-08-06 20:03:57

Raphe9000
Member
Joined: 2015-03-16
Posts: 1,533

Re: ByteArray's weekly development vlogs!

ByteArray wrote:

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.


Raphe9000.gif

Thank you to HG, Nebula, and PiotrGrochowski
Moderator of Everybody Edits under our new owner, Kira peace AK712

Offline

Wooted by:

#178 2019-08-06 20:09:36

PiotrGrochowski
Member
From: Poland (born in 8 №v 2004)
Joined: 2016-04-27
Posts: 654

Re: ByteArray's weekly development vlogs!

Raphe9000 wrote:

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.

Offline

#179 2019-08-06 20:20:21

Raphe9000
Member
Joined: 2015-03-16
Posts: 1,533

Re: ByteArray's weekly development vlogs!

PiotrGrochowski wrote:

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.


Raphe9000.gif

Thank you to HG, Nebula, and PiotrGrochowski
Moderator of Everybody Edits under our new owner, Kira peace AK712

Offline

#180 2019-08-06 21:27:08

LukeM
Dev Team
From: England
Joined: 2016-06-03
Posts: 2,810
Website

Re: ByteArray's weekly development vlogs!

PiotrGrochowski wrote:
LukeM wrote:

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 //ee.failforums.me/img/smilies/smile"
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 //ee.failforums.me/img/smilies/smile

Offline

#181 2019-08-07 07:09:05, last edited by PiotrGrochowski (2019-08-07 14:16:07)

PiotrGrochowski
Member
From: Poland (born in 8 №v 2004)
Joined: 2016-04-27
Posts: 654

Re: ByteArray's weekly development vlogs!

LukeM wrote:
PiotrGrochowski wrote:
LukeM wrote:

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 //ee.failforums.me/img/smilies/smile"
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 //ee.failforums.me/img/smilies/smile

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

So, a block like this then.

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:
rjSpijE.png

"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.

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.

Raphe9000 wrote:
PiotrGrochowski wrote:

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.

Offline

#182 2019-08-07 07:52:23

Gosha
Member
From: Russia
Joined: 2015-03-15
Posts: 5,834

Re: ByteArray's weekly development vlogs!

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

Offline

#183 2019-08-07 07:58:47, last edited by PiotrGrochowski (2019-08-07 09:12:18)

PiotrGrochowski
Member
From: Poland (born in 8 №v 2004)
Joined: 2016-04-27
Posts: 654

Re: ByteArray's weekly development vlogs!

Gosha wrote:

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.

Offline

#184 2019-08-07 12:46:21

Raphe9000
Member
Joined: 2015-03-16
Posts: 1,533

Re: ByteArray's weekly development vlogs!

Off topic color stuff
PiotrGrochowski wrote:

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.


Raphe9000.gif

Thank you to HG, Nebula, and PiotrGrochowski
Moderator of Everybody Edits under our new owner, Kira peace AK712

Offline

#185 2019-08-07 13:10:46

PiotrGrochowski
Member
From: Poland (born in 8 №v 2004)
Joined: 2016-04-27
Posts: 654

Re: ByteArray's weekly development vlogs!

Raphe9000 wrote:
Off topic color stuff
Off topic color stuff

I'm known as "haslo" in EE.

Offline

#186 2019-08-07 17:29:33

PiotrGrochowski
Member
From: Poland (born in 8 №v 2004)
Joined: 2016-04-27
Posts: 654

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.

Offline

#187 2019-08-07 18:49:30, last edited by LukeM (2019-08-07 18:53:33)

LukeM
Dev Team
From: England
Joined: 2016-06-03
Posts: 2,810
Website

Re: ByteArray's weekly development vlogs!

PiotrGrochowski wrote:
LukeM wrote:

"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)
Block_generic.png2, 3, 5
Block_factory.png3, 4, 5
Block_halloween2011.png2
Block_sci-fi.png1, 2, 3, 4
Block_prison.png
Block_plastic.pngall
Block_industrial.png2, 3, 4, 5, 6, 7, 11, 12, 13, 14
Block_halloween2015.png1, 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.

PiotrGrochowski wrote:

"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.

PiotrGrochowski wrote:

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.

Offline

#188 2019-08-07 19:02:06

PiotrGrochowski
Member
From: Poland (born in 8 №v 2004)
Joined: 2016-04-27
Posts: 654

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.

Offline

#189 2019-08-07 19:18:51

LukeM
Dev Team
From: England
Joined: 2016-06-03
Posts: 2,810
Website

Re: ByteArray's weekly development vlogs!

PiotrGrochowski wrote:

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.

Offline

#190 2019-08-08 06:46:06, last edited by PiotrGrochowski (2019-08-08 17:14:27)

PiotrGrochowski
Member
From: Poland (born in 8 №v 2004)
Joined: 2016-04-27
Posts: 654

Re: ByteArray's weekly development vlogs!

LukeM wrote:
PiotrGrochowski wrote:

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?

LukeM wrote:
PiotrGrochowski wrote:

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.

Offline

#191 2019-08-12 17:07:32

ByteArray
Dev Team (Formerly TechnoWolf99)
From: United States
Joined: 2015-02-17
Posts: 114

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.)! //ee.failforums.me/img/smilies/big_smile

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. //ee.failforums.me/img/smilies/smile

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. //ee.failforums.me/img/smilies/wink


— Joshua Stone (aka ByteArray), lead developer of Everybody Edits & EE Universe. —

Offline

#192 2019-08-12 18:29:51, last edited by mikelolsuperman (2019-08-12 18:29:59)

mikelolsuperman
Member
From: North Korea
Joined: 2016-06-26
Posts: 1,633
Website

Re: ByteArray's weekly development vlogs!

ByteArray wrote:

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
BhC68b8.png

Signature made by Nebula

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

Offline

Wooted by:

#193 2019-08-14 19:16:07

PiotrGrochowski
Member
From: Poland (born in 8 №v 2004)
Joined: 2016-04-27
Posts: 654

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.

Offline

#194 2019-08-14 22:47:43

ByteArray
Dev Team (Formerly TechnoWolf99)
From: United States
Joined: 2015-02-17
Posts: 114

Re: ByteArray's weekly development vlogs!

PiotrGrochowski wrote:

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. //ee.failforums.me/img/smilies/smile


— Joshua Stone (aka ByteArray), lead developer of Everybody Edits & EE Universe. —

Offline

Wooted by:
ByteArray1565819263759040

Board footer

Powered by FluxBB

[ Started around 1566114006.3747 - Generated in 0.200 seconds, 16 queries executed - Memory usage: 1.78 MiB (Peak: 2.16 MiB) ]