[0.12.29] [kovarex] Tables render incorrectly in full screen mode

[JasonC]

Tables are rendered with extra cell spacing in full screen mode compared to windowed mode.

The following table style:

Code: Select all

data.raw["gui-style"].default[ITEM_TABLE_STYLE] = {
	type = "table_style",
	parent = "table_style",
	cell_padding = 0,
	horizontal_spacing = 0,
	vertical_spacing = 0
}

Renders like this in windowed mode (this table has colspan=20, and has a checkbox with a solid background image in every cell):



And like this in full screen mode:



The windowed mode table has 0 spacing between cells, as specified. The full screen mode table has a larger spacing which seems to be incorrect wrt the style. This offset is consistent; for example here is the default slot_table_style in windowed mode:



And fullscreen mode:



This behavior is not limited to mod GUI's. The tool belt and chest/inventory windows also have additional spacing between cells in full screen mode, although the effect appears less pronounced for some reason.

Windows 7 64-bit, "normal" graphics quality, 1440 x 900.

[Klonan]

Thanks for the report,

Can confirm in 0.12.30 too
Toolbelt/crafting gui has 1 px gap in window mode,
And has 2px gap in fullscreen

[kovarex]

Thanks for the report,

Can confirm in 0.12.30 too
Toolbelt/crafting gui has 1 px gap in window mode,
And has 2px gap in fullscreen

This is not the bug, as 1px can easily stretch to 2px in full screen.

I tried to reproduce the original bug, but without success, when I left 0 vertical/horizontal_spacing and cell_padding, there were never gaps.
Can you provide the save with the table and log file?

[kovarex]

Ah, I get it now, it has an checkbox in, but the checkbox isn't scaled now, so the checkbox image leaves a space, this should be fixed in 0.13

[JasonC]

Ah, I get it now, it has an checkbox in, but the checkbox isn't scaled now, so the checkbox image leaves a space, this should be fixed in 0.13

Well the checkbox scaling behavior changed in 0.12.31 (or was it 0.12.30, I forget now), so actually there's another problem on top of this problem. I don't think I could really provide you with a useful sample mod because of the new issues compounding it, but I will try to put something minimal together, and send you the log with it.

I'd say the easiest way to recreate would be to just start a new game and look at the toolbelt and player inventory tables on windowed and fullscreen mode. I guess, from what you say, the tables are scaled but the slots aren't. But if Klonan could recreate (and myself, and at least one other person on IRC) but you can't, it could be tricky... My GUI scaling was set to default/100%, dunno if that has an effect.

If the 0.13 fix will be to scale the buttons, are you sure this is the right approach? You're basically going to be scaling e.g. 32x32 buttons to 33x33 or 34x34. Unless you've enabled interpolation when scaling in 0.13, then won't the quality suffer? (you can already see this behavior now, e.g. the module icons with their perfect 45-degree rasterized lines look pretty gnarly if you put them on a button whose size is off by a couple of pixels).

Unless you add higher quality scaling I kind of wonder if scaling is even the right thing to do to begin with; maybe if Factorio was vector-based, but the desire for scaled GUIs isn't really compatible with the desire for high quality and the requirement of e.g. non-text buttons to have their pixel-accurate borders be part of their sprite (shameless plug for related request). Personally, I feel like if you go out and spend the money on, say, a 19" 4K display, you either accept that your pixels are small, or question why you spent that money on that monitor in the first place. But, ya know...

There seems to be a lot of weirdness with GUI stuff regarding spacing, borders, scaling, etc., I think it would be better in the long run to step back, take a look at the whole thing, and come up with a comprehensive set of solutions. Right now there's kind of this pattern of confusion/inconsistency -> missing features requiring hacks -> random fixes breaking the hacks -> frustration -> giving up. Even if this particular table spacing issue is not a bug, it does seem indicative of a bigger set of weird things.

Personally, I'm actually having a really hard time with these reports, because in many cases there is more than one issue contributing to the visible problem - the GUI seems to be an extremely complex web of quirks - and the last couple experimental updates have also changed a lot of the behaviors. I'll try my best but I'm having trouble constructing minimal examples, so... sorry about that.

Is there a blog post, etc. somewhere about some of the GUI changes planned for 0.13? Or do you have notes you could share? This would at least let me know what current issues I could safely ignore without reporting here or trying to decipher, and it'd make it easier for me to give better reports.

[kovarex]

I'd say the easiest way to recreate would be to just start a new game and look at the toolbelt and player inventory tables on windowed and fullscreen mode. I guess, from what you say, the tables are scaled but the slots aren't. But if Klonan could recreate (and myself, and at least one other person on IRC) but you can't, it could be tricky... My GUI scaling was set to default/100%, dunno if that has an effect.

As I said, this is not a bug, this is how it should behave now. Everything is scaled even the table spacing (it is multiplicative, so 0 stays 0, but 1 can become 2), just the slots are not scaled now, as the icons would look shitty. Once we have 64X64 icons of everything, we will scale even the slots.

There seems to be a lot of weirdness with GUI stuff regarding spacing, borders, scaling, etc., I think it would be better in the long run to step back, take a look at the whole thing, and come up with a comprehensive set of solutions. Right now there's kind of this pattern of confusion/inconsistency -> missing features requiring hacks -> random fixes breaking the hacks -> frustration -> giving up.

But why would u hack checkboxes for this? I don't get it.

Personally, I'm actually having a really hard time with these reports, because in many cases there is more than one issue contributing to the visible problem - the GUI seems to be an extremely complex web of quirks - and the last couple experimental updates have also changed a lot of the behaviors. I'll try my best but I'm having trouble constructing minimal examples, so... sorry about that.

We would like to make it consistent and understandable, there are some changes to the gui in 0.13, but these are mainly solving different kind of problems (how to stretch some element in a composition to match the empty space).

[kovarex]

I tried to make table with button slots for the test, I set the table spacing to 0, and there were never ever gaps between individual slots, fullscreen, or windowed mode.

[JasonC]

But why would u hack checkboxes for this? I don't get it.

Rather than explaining why, I have a challenge for you. You have:

• An image, with a transparent background, whose contents you "don't know", e.g. a game icon you have no control over, or an icon you've made that you may want to change in the future.
• A button, where you want to put the image on it, and use a default/click/hover style consistent with the game (which you also have no control over, gui.png could change at any update).

Now put the image on that button. Centered, good quality. Can you show me an example of how to do this, without having to make a full spritesheet with your icon superimposed on click/hover/default borders and backgrounds? If I ever visit Prague, I'll bet you a beer that you can't.

See also the quirk list in the "How to" link in my signature / the guide I linked to above.

Currently hacking checkboxes to use the check as the icon and the background as the border is the only way to keep your icons independent of your borders, and center your icons, and (pre-0.31) avoid poor quality scaling. There is no other way (well almost; another hack is to put two buttons in the same place, one with the border/background, one with the icon -- but then handling click/hover changes becomes difficult if not impossible). It's a systemic issue; it's a combination of multiple missing things that lead to the necessity of that hack.

Note that "multiple missing things" might just be documentation: For example, if there actually is already a clean way to do this (which would be a relief), it's not in the docs, and it's not in any of the existing game styles, and so nobody knows what it is (which is effectively the same as "mods can't do it").

It's the only way for mods to do it, mind you. The game seems to have no problem, like the toolbelt, inventory, other slots, etc. But that functionality; placing an icon over an existing border/background, isn't available to mods right now.

A few example use cases of that are e.g. Test Mode, my Toy Box mod, Advanced Logistics System, all those mods that dynamically generate styles from item prototypes in data-final-fixes, etc. Another example use case is a mod where all the graphics are yours, but you want to keep your workload manageable by keeping your icons and default/click/hover background and border spritesheets separate, so you don't need to redo every single graphic for a style change. Or a mod where all graphics are yours but you want to combine it with the current game version's gui.png look without having to redo your graphics if the game's look ever changes or another graphics pack is installed. The current missing features subtley force mod writers into complicated positions.

PS Feel free to PM me on espernet (JasonC) if you get as frustrated as I do communicating on forums.

[JasonC]

I tried to make table with button slots for the test, I set the table spacing to 0, and there were never ever gaps between individual slots, fullscreen, or windowed mode.

Here I've attached an example mod, save, and the log. Here are some example results on my machine, 0.12.32:



The left side is the example mod's GUI (re: the previous post, these graphical buttons are the image with the background/border hard-coded into the spritesheet; the checkbox hacks complicate this example too much). The right side is the tool belt. The top is windowed, the bottom is full screen. The difference in spacing between the windowed and fullscreen can be seen here. This is only an example of horizontal spacing differences but the same effect does exist vertically.

The scaling of the stock text button sizes themselves makes sense to me. I also now understand why the table spacing scaling happens although I don't like it; personally I like precise control over GUI element metrics (in some cases I definitely find it desirable to e.g. maintain a non-scaled, precise spacing between elements just to maintain a tight look, even though there are other situations where scaling of spacing is desirable), but I get that it's not a bug. At this point the only purpose of the attached examples is for the completeness of this report.

Also, my graphics settings:

[kovarex]

So you are basically looking for a picture-slot gui element, or image element.

Using the custom button style to have picture slots is quite hackish already, as the picture in the style was always meant to represent the gui element, not some picture in it.

As I said, our long term goal is to be able to scale everything as.

• Big resolution displays just require the stuff to be bigger.
• Scaling just some things, but not scaling other things breaks the compositions and ratios.

So I have a proposition:

I will make this addition for 0.13 and I will do these 2 things:

• Custom image specification (would work similarly as fonts), every image specification would use the same object system as any other moddable object, including name, type etc.
• Picture button (derived from button and similar to it), which would be a button, with picture on it, the picture would be specified using name that would point to the custom image.
• ImageWidget, because why not, if we already have the images.

Would it solve the problems?

[kovarex]

- Added sprite-button gui element, works the same way as button, but it can have sprite property assigned, which refers to the sprite identifier.
- Custom sprites can be defined in lua data definition (type = sprite, the rest is sprite definition).
- Sprite identifier can either point to custom definition from the data, or have form "<type>/<id>", type can be (item, entity, recipe and technology), for example button.sprite = "item/iron-plate"

This should make things easier in 0.13

[JasonC]

So I have a proposition:

I will make this addition for 0.13 and I will do these 2 things:

• Custom image specification (would work similarly as fonts), every image specification would use the same object system as any other moddable object, including name, type etc.
• Picture button (derived from button and similar to it), which would be a button, with picture on it, the picture would be specified using name that would point to the custom image.
• ImageWidget, because why not, if we already have the images.

Would it solve the problems?

This would solve the problems we talked about here and definitely will make things easier. It looks like you already made the changes, but I have an alternate proposition. There's another use case for images; in the case of e.g. Advanced Logistic System the images aren't buttons; they're just images. They're essentially image labels. So consider this instead of sprite buttons or any new widgets in general:

• Switch checkboxes and any other GUI elements to take graphical sets instead of plain images (buttons already take *_graphical_sets in their styles) (partial feature request), and add this support to labels.
• Add a working and consistent scalable property to all GUI elements which, if true, disables scaling for that element.
• Add a new image type (along side composition and monolith) that can layer images (feature request).
• For things with captions (labels, buttons, etc.) just draw the text over top of any background image as is done now.

What do you think of this instead? There's a few other details that would need to be worked out if this makes sense, in particular centering images (involves the "align" property) and the possibility of per-image scaling (involves honoring the "*-no-scale" priorities maybe) -- I have ideas but I want to keep this post short-ish.

This way, you don't add new widgets (I think this could be the start of a slippery slope of too many widgets in the future), you get image powers on buttons, labels, and any other creative uses (in the future too for new GUI elements we don't have yet) with a consistent API, and you get pixel-accurate control over the sizes of all widgets if you want them. Plus, philosophically (if you're into that sort of thing), text and image buttons are both "buttons", text and image labels are both "labels", and so you're not creating separate conceptual widgets for what's essentially the same GUI control with different types of content on it.

This accomplishes the same thing as sprite buttons, but also a lot more, and also leaves the opportunity open for a lot of flexibility in the future for uses we can't foresee yet. Plus it makes the API a bit more consistent, the *_background vs *_graphical_set is already kind of confusing. It does everything the sprite button changes does, makes pixel-accurate control manageable and optional, and implicitly adds image support to any widget now and in the future that supports background images. It also makes it simple to adjust the size of widgets without having to redo their graphics; e.g. consider the flexibility and convenience of a button with a "layered" background image that consists of a monolith (the image) on top of a composition (the background and border). As a bonus it might give you more consistent rendering logic for all the elements.

Those changes you made look exciting, and thanks; but even though you already made them would you consider something like the above instead? I think it is a more elegant and flexible approach and nails multiple birds with ... less stones than birds. Even if it is a bit more work, it does a lot more things, and it's probably better in the long run than adding new special-purpose widgets.

Sorry it took so long to reply, I wanted to give it some thought.

[JasonC]

By the way:

- Sprite identifier can either point to custom definition from the data, or have form "<type>/<id>", type can be (item, entity, recipe and technology), for example button.sprite = "item/iron-plate"

In terms of solving problems I'm not sure if this particular change is necessary, since button.sprite = item.type.."/"..item.name isn't much different than whatever.filename = item.icon.

Also it might actually make mod code slightly more verbose; if the prefix differs depending on the item type, e.g., "inserter/smart-inserter", then you have a couple extra string concatenations to do and a tiny bit more information to track (e.g. item.type .. "/" .. item.name everywhere, or passing item.type around to functions along with item.name if your implementation is structured that way). Not a big deal, but I'd still probably just prefer to grab icon filenames myself even if this interface were present. Note, by the way, that this kind of stuff is, at least currently, generally done in data-final-fixes rather than in control, where you're working with data.raw.

Also just out of curiosity, how would sprite IDs interact with the spritesheet position and offset properties, and other incompatible properties, already in the API? E.g. what happens if you do

Code: Select all

{
   sprite = "item/iron-plate", -- used to be sprite = "my_own_graphic.png" but changed for version 85 of this mod
   width = 20,
   height = 20
   x = 9,
   y = 31
}

That said it is, at least theoretically, a more modular API than copying icon filenames. And it could also work into the proposal above as well if you e.g. let monoliths take sprite identifiers.

[kovarex]

This would solve the problems we talked about here and definitely will make things easier. It looks like you already made the changes, but I have an alternate proposition. There's another use case for images; in the case of e.g. Advanced Logistic System the images aren't buttons; they're just images. They're essentially image labels. So consider this instead of sprite buttons or any new widgets in general:

• Switch checkboxes and any other GUI elements to take graphical sets instead of plain images (buttons already take *_graphical_sets in their styles) (partial feature request), and add this support to labels.

Sounds reasonable, added to our tasks.

• Add a working and consistent scalable property to all GUI elements which, if true, disables scaling for that element.

As I said, we actually want to remove the scalable property eventually, as we want everything to be scalable without opt-out option. With the high-resolution retina displays, it is a problem when people can't scale things.

• Add a new image type (along side composition and monolith) that can layer images (feature request).

Why would you need this, once you have the picture button?

- Sprite identifier can either point to custom definition from the data, or have form "<type>/<id>", type can be (item, entity, recipe and technology), for example button.sprite = "item/iron-plate"

In terms of solving problems I'm not sure if this particular change is necessary, since button.sprite = item.type.."/"..item.name isn't much different than whatever.filename = item.icon.

Also it might actually make mod code slightly more verbose; if the prefix differs depending on the item type, e.g., "inserter/smart-inserter"

Not it doesn't work like that, for entity icons is always just entity, so it would be "entity/smart-inserter" for entity icon, or "item/smart-inserter" for item icon (which are the same currently, but doesn't have to be and not all entities have corresponding item.

Also just out of curiosity, how would sprite IDs interact with the spritesheet position and offset properties, and other incompatible properties, already in the API? E.g. what happens if you do

Code: Select all

{
   sprite = "item/iron-plate", -- used to be sprite = "my_own_graphic.png" but changed for version 85 of this mod
   width = 20,
   height = 20
   x = 9,
   y = 31
}

No, this is not the way it can be used. the "Item/iron-plate" can be currently only used, when setting the picture of the sprite-button element. It can't be used inside lua definitions, it wouldn't make any sense to me.

[JasonC]

• Add a new image type (along side composition and monolith) that can layer images (feature request).

Why would you need this, once you have the picture button?

Well, what I proposed was an alternative to the picture button, and I think it is a better option.

So, no picture buttons. Layered images on regular buttons instead. Then you implicitly get picture buttons, picture labels, and picture anything else all for the price of one new image type. The rest of the points in my list are things that would be needed to support that (also, I specifically added those things based on observations I've made about current behaviors, it was a carefully chosen list -- everything in it would have to happen to make this work well).

Then you wouldn't have to create a new picture button widget. You could use the existing button. And you wouldn't have to create any new picture vs. text widgets, you'd get that power on all of them.

It'd involve undoing the picture button work you did yesterday and doing this instead (again, sorry about the late reply). Having a layered image type not only provides the functionality of the new picture button you just added (making it unneeded), but adds a ton of functionality to other widgets as well (such as labels, and widgets that haven't even been conceived of yet that may come in the future). Does that make sense?

[kovarex]

• Add a new image type (along side composition and monolith) that can layer images (feature request).

Why would you need this, once you have the picture button?

Well, what I proposed was an alternative to the picture button.

So, no picture buttons. Layered images on regular buttons instead. Then you implicitly get picture buttons, picture labels, and picture anything else all for the price of one new image type. The rest of the points in my list are things that would be needed to support that (also, I specifically added those things based on observations I've made about current behaviors, it was a carefully chosen list).

Then you wouldn't have to create a new picture button widget. You could use the existing button. And you wouldn't have to create any new picture vs. text widgets, you'd get that power on all of them.

It'd involve undoing the picture button work you did yesterday and doing this instead (again, sorry about the late reply). Having a layered image type not only provides the functionality of the new picture button you just added (making it unneeded), but adds a ton of functionality to other widgets as well (such as labels, and widgets haven't even been conceived of yet that may come in the future). Does that make sense?

I think that you don't understand what I mean by picture button. The difference is, that you can specify and/or change the picture runtime, not in the data definition.

Code: Select all

/c game.local_player.gui.top.add{type="sprite-button", name="test", sprite="item/iron-plate"}
/c game.local_player.gui.top.test.sprite = "duck" -- lets change the picture to duck

For the layered style, I mean, if you want to have specific background under a label, you can just create a flow or frame with that background and put the label on it, can't you?

[JasonC]

- Sprite identifier can either point to custom definition from the data, or have form "<type>/<id>", type can be (item, entity, recipe and technology), for example button.sprite = "item/iron-plate"

Not it doesn't work like that, for entity icons is always just entity, so it would be "entity/smart-inserter" for entity icon, or "item/smart-inserter" for item icon (which are the same currently, but doesn't have to be and not all entities have corresponding item.

Hm, but in data-final-fixes, the game doesn't know that things in e.g. data.raw.inserter[] are entities or items yet, right? From my understanding and chat conversations, the game can't actually tell that data.raw.inserter[]'s contents are items, entities, etc., until after the game parses them into LuaWhateverPrototypes and makes them accessible in control.lua via game.item_prototypes, etc.

So how would you be able to coalesce all item prototypes into "item/" in the data-* scripts? The stuff isn't parsed into actual prototypes at that point, is it?

Or are you proposing that sprite IDs in styles be set at runtime via control.lua (after data.raw has been properly parsed into items, entities, etc.)?

[JasonC]

I think that you don't understand what I mean by picture button. The difference is, that you can specify and/or change the picture runtime, not in the data definition.

Ah, I understand now. Hm, well, it's neat... but I don't see this as being much benefit over just dynamically generating the styles in the situations we're talking about, at least. Similar code, different places. I still think it's a good idea but it doesn't impact the issues here.

For the layered style, I mean, if you want to have specific background under a label, you can just create a flow or frame with that background and put the label on it, can't you?

The ability to put backgrounds on flows and frames is news to all of us. I'll give this a shot, but it's still a hack (e.g. you have a table, then you put a flow in each cell with a background and a single label in each of those flows... it's messy but it doesn't have to be). It'd be nice to get rid of the necessity for hacks, that's the goal of the changes you made already and also the ones I proposed -- most of what we're talking about can already be done with tricks, but then you have things like the recent checkbox scaling behavior changes that break all those tricks, that's what's not good, that's the kind of thing that should be avoided.

The layered image type sort of accomplishes this as a side-effect; it lets labels be labels, buttons be buttons, etc. Philosophically, a frame holds components, a flow determines their positions - putting background images in them to workaround not being able to put images on widgets is asking for trouble.

Btw, I only speak for myself but I'm totally willing to wait until a few (or many) updates into 0.13, or even 0.14, for this kind of stuff. I'd rather see a consistent, predictable, and flexible system than have the features implemented quickly, there's no rush here. There's already more than enough stuff in 0.13 to be excited about!

PS About "scalable" - Sure. If you're moving for scaling to be mandatory, though, then instead of my proposal for a working scalable property, instead consider implementing higher quality scaling of images with interpolation (unless it's there already, in which case, how do I enable it?). That'd also give good results. That was my primary motivation for making scaling optional; the quality - because on "normal" displays (not insanely high dpi) you run into a lot of situations where e.g. a 32x32 graphic is scaled to 33x33 or something, and it's ugly.

[kovarex]

Our plan is to have 64X64 icons for everything eventually, so scaling it shouldn't be a problem.

[JasonC]

Well (unrelated to scaling), I do think the layered-image-for-all-widgets approach is the way to go, but I understand that there's also a ton of other stuff going on right now. Thanks for the changes, they will definitely be useful.