Poll

What's your preference for the *default* method of handling object frames? (note that both will be *supported* either way)

A strip containing multiple frames
3 (60%)
A seperate image file for each frame
2 (40%)

Total Members Voted: 5

Author Topic: 2.00 *New* terrain/objects-related discussion topic  (Read 12323 times)

0 Members and 1 Guest are viewing this topic.

Offline namida

  • Administrator
  • Posts: 12398
    • View Profile
    • NeoLemmix Website
2.00 *New* terrain/objects-related discussion topic
« on: October 10, 2015, 11:42:34 AM »
It's pretty clear that - no matter how sure I am that a proper binary format is preferable to NeoLemmix's design - some people are never going to give up on insisting that their way, and only their way, is supported. As much as I'd rather do it the way I prefer, and the way that I see working best for NX2 - more than this, I would rather avoid a situation where development stalls forever (or worse, I decide I've had enough of the arguments and cancel the project) over debate regarding how to use graphic sets. So - fine, directory structure it is. And no, no other formats will be supported, except semi-automated conversion (not direct use) of legacy formats.

Now that that's out of the way, let's try and at least have a reasonable discussion on how they'll be implemented, and what features should be supported. Also - how exactly, under such a framework (since I think if we're going to go for this structure, we may as well abandon any notion of a "graphic set" beyond as a way to categorize pieces into seperate sub-folders), should features that are usually tied to the graphic set - such as brick color, one-way arrow graphics, etc be handled? Should they be specified on a per-level basis, or should there be "header" type files which contain different combinations of these? Etc.
My Lemmings projects
2D Lemmings: NeoLemmix (engine) | Lemmings Plus Series (level packs) | Doomsday Lemmings (level pack)
3D Lemmings: Loap (engine) | L3DEdit (level / graphics editor) | L3DUtils (replay / etc utility) | Lemmings Plus 3D (level pack)

Offline namida

  • Administrator
  • Posts: 12398
    • View Profile
    • NeoLemmix Website
Re: 2.00 *New* terrain/objects-related discussion topic
« Reply #1 on: October 10, 2015, 01:06:08 PM »
My preliminary thoughts on how to lay this out:

<Main graphic "set" directory>
Folders here should reflect the author of a graphic set. Some names may be "reserved" (not enforced in any way, but usage discouraged so that they can be used for specific purposes - eg. "Official", "Cheapo", etc).

<Within these folders>
Folders here should reflect the graphic sets themself. eg. "Dirt". Styles of the same names from different authors could be combined by default in the editor - somewhere in the metainfo should specify which ones are the base set and which are addons, perhaps also which author's style is being added to (to avoid oddities occuring when, say, Alice makes "Grass" style, Bob adds to it, Carol makes her own "Grass" style that's completely unrelated, and Doug (yeah, I don't know what the 4th name in this series is) adds to that one).

<Within these folders>
Terrains and objects - possibly divided into two seperate subfolders? Individual pieces would be identified by "<Author>/<Style>/<Piece>".

Terrains
- Images for each resolution. (What's the best naming system to differentiate?) Only one resolution is required.
- Optional: Physics mask, which shows which pixels are solid, non-solid, steel, etc. If not found, autogenerates based on the 1x resolution image, or if that isn't found, from downscaling the smallest one.

Objects
- Images for each resolution. Same naming system would be used as for terrains. Again, only one resolution is required.
>>> should there be some kind of choice here, where it can either be a strip, or seperate images for each frame? The former would require explicitly specifying how many frames.
- Trigger area mask.
- Metadata; eg. trigger area type, the offset from the image of the trigger area mask image (to allow for negative position trigger areas; just in case); trigger point (for receivers, etc), etc.

Gadgets (one-way arrows, pickup skills, etc)
- Images for each resolution. Only one needs to exist.

General graphic set metadata
- A single file of course. Anything that relates to the set as a whole.


Note: Don't worry for now about "how will old levels work with this?". I have a plan for that, and can discuss it more closer to when I'm coding level loading / saving / handling.
« Last Edit: October 10, 2015, 02:07:13 PM by namida »
My Lemmings projects
2D Lemmings: NeoLemmix (engine) | Lemmings Plus Series (level packs) | Doomsday Lemmings (level pack)
3D Lemmings: Loap (engine) | L3DEdit (level / graphics editor) | L3DUtils (replay / etc utility) | Lemmings Plus 3D (level pack)

Offline geoo

  • Administrator
  • Posts: 1473
    • View Profile
Re: 2.00 *New* terrain/objects-related discussion topic
« Reply #2 on: October 10, 2015, 02:09:39 PM »
Quote
Individual pieces would be identified by "<Author>/<Style>/<Piece>".
I think this is a good way to do it, yeah.
You have an interesting point about multiple people having graphics sets of the same name. Allowing the meta-info file for a graphics set to specify a graphics set which this set is an extension to allows to maintain authorship for each individual tile. In lix right now, if you add a tile to someone else's tile set it will go into the original creator's folder and not in yours.

Quote
Images for each resolution. (What's the best naming system to differentiate?) Only one resolution is required.
Considering your point about the pre-extensions in like, e.g. tile.S.png specifying a steel tile, I wonder if this could be all avoided by rather than sticking to naming schemes, there could just be folders called "1x", "2x", "mask", "meta-info". For most terrain tiles, you'd only have one resolution, no mask and no meta-info, so just dumping a bunch of pictures in the 1x or 2x folder would give you a working tile set sans objects. meta-info would contain text files specifying if a tile is steel or whatever else it can be, and defaults to non-steel/whatever is most common if no meta-info is present.

Quote
Should there be some kind of choice here, where it can either be a strip, or seperate images for each frame? The former would require explicitly specifying how many frames.
In lix the former is used and the number of frames is auto-detected as there's a border around each frame. Not sure if this is the best way to handle it. The number of frames can be written into the meta-info file which has to exist anyway. I think eidcut can convert a strip into a sequence of images, but some authors might prefer one, some the other, so supporting both might be handy. For the list of separate images, should then a subfolder of "1x" exist, named like the object, that contains all its frames? And should those frames follow a numbering scheme, or should each of the images be specified in the meta-info file?


Some other questions:

Alpha handling, how to determine what is solid and what isn't? If full alpha pngs are going to be supported, this is an interesting question that also pertains to LixD. Should a mask actually belong to a terrain piece? I was wondering, if full alpha blending is supported for level design, then overlaying a lot of low-alpha (almost transparent) regions will give a high-alpha (almost opaque) region which would still be non-solid as none of the original regions were solid. Should just a bitmap for the whole level be created internally, anything pixel that, at the end, has alpha-value >= 0.5 is solid, and anything that has alpha value < 0.5 becomes non-solid, and maybe even overwritten with the background color to reduce ambiguity for the player? I don't know what the best solution for alpha handling is.

If a graphics set exists for 2x, and the masks are inferred from the images, and now someone adds new 1x tiles, this might change physics. (Not sure if this is ever gonna happen, I mean who would downscale 2x images for this?) Should the graphics set meta-info file allow to specify which resolution to infer the masks from, so that in this case it would infer from the 2x imagery instead the newly added graphics?

Tiles that are partially steel: As mentioned in another topic, do we really need this? One use I can see though is VGASpec levels that use steel, as mentioned somewhere. It's a bit cumbersome for these, but I can't think of a workaround that doesn't introduce new functionality (like a traditional steel area tile or something).

How, internally, should a level refer to a terrain piece/object it uses? Straight-forward answer: base path. (E.g. namida/forest/trunk, and the game infers that the image is in namida/forest/1x/trunk.png, the meta-info in namida/forest/meta-info/trunk.txt, etc). This works a lot more nicely in a text based level format as such paths are variable length of course.

Should sub-folders be supported for organizing tile sets better? For instance, my construction tile set has sub-folders for concrete blocks, wall pieces, metal rods, so the main folder doesn't flow over. Is this desirable? Implementation-wise it shouldn't be too much harder if tiles are referred to as described in the previous paragraph. If folders are used for different resolutions and meta-info however, and some tiles are in the main construction folder and some in the concrete, wall folders, the main folder would contain "1x", "2x", "mask", "meta-info", "concrete", "wall", the latter two having different semantics from the former 4 which seems a bit unelegant.

Offline Nepster

  • Posts: 1829
    • View Profile
Re: 2.00 *New* terrain/objects-related discussion topic
« Reply #3 on: October 10, 2015, 02:20:11 PM »
Overall this sounds sensible. Some thoughts resp. questions nevertheless (none really important):

1) Perhaps have the name of the graphic set first and subfolders for various authors. Graphic names feel somehow more important than authors, so they should go first. And then Alice could indicate her folder as the main one by including the general graphic set metadata file; all other folders (that may not include a general metadata file!) are automatically seen as addons without need to specify this.

2) I see no need to separate the objects from the terrain pieces by introducing subfolders.

3) Depending on our decision on "arbitrary trigger areas vs. only rectangular ones", maybe one does not need specific trigger area masks, but can include this info in the general metainfo file.

4) Strips for objects have the advantage to reduce the number of files in the folder and one cannot accidentally delete one of the frames in the middle. Number of frames, size of object, ... can go into the metainfo file.

5) In what respect are one-way-walls different from all other objects, so that they need extra handling?

6) Do we need to add things like the hatch, pick-up skills, ... to each style folder, even if they are the same each time? Perhaps one can have one folder "General" for such objects, which are included automatically in every style.

7) What information would the general graphic set metafile store exactly?

PS: Written while geoo was posting and not adapted wrt. his arguments.

Offline namida

  • Administrator
  • Posts: 12398
    • View Profile
    • NeoLemmix Website
Re: 2.00 *New* terrain/objects-related discussion topic
« Reply #4 on: October 10, 2015, 02:50:31 PM »
I'll come back to your post geoo - most of Nepster's questions I can answer quite quickly so I'll cover those now.

Quote
1) Perhaps have the name of the graphic set first and subfolders for various authors. Graphic names feel somehow more important than authors, so they should go first. And then Alice could indicate her folder as the main one by including the general graphic set metadata file; all other folders (that may not include a general metadata file!) are automatically seen as addons without need to specify this.

7) What information would the general graphic set metafile store exactly?

The reason is in case, for whatever reason, two authors make entirely different sets with the same name. And the connection to Q7 here - one thing it would contain is which author's set it's an addon to. Of course, because of the ability to combine multiple graphic sets (or rather, discarding them as anything beyond a categorization scheme for pieces), there's no reason it really matters, other than editor interface.

Quote
2) I see no need to separate the objects from the terrain pieces by introducing subfolders.

If the whole point of a folder structure is to make it easier to modify / improve, then shouldn't it be kept tidy by keeping the two seperate?

Quote
3) Depending on our decision on "arbitrary trigger areas vs. only rectangular ones", maybe one does not need specific trigger area masks, but can include this info in the general metainfo file.

This is possible. But I think arbitrary areas is the way to go - even rectangular ones can be abused, and good reasons to use arbitrary ones have been presented, eg. circular buzzsaws, diagonal lasers.

Quote
4) Strips for objects have the advantage to reduce the number of files in the folder and one cannot accidentally delete one of the frames in the middle. Number of frames, size of object, ... can go into the metainfo file.

That's true, but it can be convenient to work on each frame as a seperate image. Perhaps both methods should be supported?

Quote
5) In what respect are one-way-walls different from all other objects, so that they need extra handling?

They're not being treated as objects. Think of them as more like steel areas from L1, or like Cheapo's implementation of one-way walls. In this regard; they aren't objects as such, just a graphic. Although - I did just get an idea as I wrote this; perhaps they can simply be implemented as resizable objects?

Quote
6) Do we need to add things like the hatch, pick-up skills, ... to each style folder, even if they are the same each time? Perhaps one can have one folder "General" for such objects, which are included automatically in every style.

No. Essentially, the idea of a "graphic set" will only be a way to group pieces together; a level can arbitrarily mix-and-match them. Even before deciding to go with this structure, since use of multiple graphic sets in one level was a planned feature, no graphic set would need to have those pieces, because a level author could just use them from another set. With that being said, I do plan to have a "default" set containing objects of most types, apart from ones that tend to be specialised.
My Lemmings projects
2D Lemmings: NeoLemmix (engine) | Lemmings Plus Series (level packs) | Doomsday Lemmings (level pack)
3D Lemmings: Loap (engine) | L3DEdit (level / graphics editor) | L3DUtils (replay / etc utility) | Lemmings Plus 3D (level pack)

Offline namida

  • Administrator
  • Posts: 12398
    • View Profile
    • NeoLemmix Website
Re: 2.00 *New* terrain/objects-related discussion topic
« Reply #5 on: October 10, 2015, 03:18:26 PM »
Quote
Considering your point about the pre-extensions in like, e.g. tile.S.png specifying a steel tile, I wonder if this could be all avoided by rather than sticking to naming schemes, there could just be folders called "1x", "2x", "mask", "meta-info".

That's a workable idea.

Quote
For the list of separate images, should then a subfolder of "1x" exist, named like the object, that contains all its frames?

Not sure what you're meaning here?

Quote
And should those frames follow a numbering scheme, or should each of the images be specified in the meta-info file?

I think this is a case where being numbered is perfectly fine. Having to specify them in the meta-info file is an inconvenience.

Quote
<alpha blending>

Yeah, I'm not entirely sure on it either. A user option can be provided to erase any misleading pixels; using this would ultimately be the best option to avoid confusion (at some eye-candy cost). Exactly how to handle mask autogeneration when alpha is involved is something I'm not entirely sure about either.

Quote
If a graphics set exists for 2x, and the masks are inferred from the images, and now someone adds new 1x tiles, this might change physics. (Not sure if this is ever gonna happen, I mean who would downscale 2x images for this?) Should the graphics set meta-info file allow to specify which resolution to infer the masks from, so that in this case it would infer from the 2x imagery instead the newly added graphics?

This sounds like a shortcut with potentially nasty results, which could be avoided by enforcing use of a mask (at least when a 1x image is not present). Perhaps NX2 should auto-generate a mask the first time it encounters a piece without one? However, this could raise problems if the piece is a WIP and the user doesn't realise this has happened.

Quote
Tiles that are partially steel: As mentioned in another topic, do we really need this? One use I can see though is VGASpec levels that use steel, as mentioned somewhere. It's a bit cumbersome for these, but I can't think of a workaround that doesn't introduce new functionality (like a traditional steel area tile or something).

Steel areas for this purpose become very tedious to place if the steel isn't straight-edged. One perhaps tidier workaround would be to create a "subset" images of the main one, only containing the steel parts, and place that over the top of the main one (and it could then be marked as steel).

Quote
Should sub-folders be supported for organizing tile sets better? For instance, my construction tile set has sub-folders for concrete blocks, wall pieces, metal rods, so the main folder doesn't flow over. Is this desirable? Implementation-wise it shouldn't be too much harder if tiles are referred to as described in the previous paragraph. If folders are used for different resolutions and meta-info however, and some tiles are in the main construction folder and some in the concrete, wall folders, the main folder would contain "1x", "2x", "mask", "meta-info", "concrete", "wall", the latter two having different semantics from the former 4 which seems a bit unelegant.

The obvious thing to come to mind would be to not allow subfolders in a folder that has pieces in it. However, this seems unnessecerially restrictive.
My Lemmings projects
2D Lemmings: NeoLemmix (engine) | Lemmings Plus Series (level packs) | Doomsday Lemmings (level pack)
3D Lemmings: Loap (engine) | L3DEdit (level / graphics editor) | L3DUtils (replay / etc utility) | Lemmings Plus 3D (level pack)

Offline Nepster

  • Posts: 1829
    • View Profile
Re: 2.00 *New* terrain/objects-related discussion topic
« Reply #6 on: October 10, 2015, 03:39:29 PM »
Quote
...namida's answers to my questions...
All of them good points, but concerning one-way-walls: Perhaps I misunderstood somthing, but I thought the main idea was to separate the visual display of arrows from the mechanic-wise important area the OWW covers. So we have:
a) An area indicating where the terrain should be a OWW, which is stored in each .lvl-file. How one defines this area in the editor might very much depend on how you want to save this area in the level file, but this is totally independant of the question which style to use or how to store any graphic files, no?
b) Visual display of arrows: This is a set of pictures, together with a meta-info file stating "These are left/right/down arrows for OWW" (and other relevant things) and only this has to be stored in some style folder. These "objects" are then displayed on the OWW.
How to associate the OWW-area in the editor to the correct graphic set also depends on how OWW areas are stored within the level file, imo.

Quote
If a graphics set exists for 2x, and the masks are inferred from the images, and now someone adds new 1x tiles, this might change physics. (Not sure if this is ever gonna happen, I mean who would downscale 2x images for this?) Should the graphics set meta-info file allow to specify which resolution to infer the masks from, so that in this case it would infer from the 2x imagery instead the newly added graphics?
This sounds like a shortcut with potentially nasty results, which could be avoided by enforcing use of a mask (at least when a 1x image is not present). Perhaps NX2 should auto-generate a mask the first time it encounters a piece without one? However, this could raise problems if the piece is a WIP and the user doesn't realise this has happened.
And what happens if the user deletes this NX2-generated mask at some time after adding the 1x image? It might be noted, that the same issue may occur if 2x tiles are added later. Who guarantees that the terrain displayed there fits the terrain mask generated by the 1x tile?

Offline geoo

  • Administrator
  • Posts: 1473
    • View Profile
Re: 2.00 *New* terrain/objects-related discussion topic
« Reply #7 on: October 10, 2015, 03:42:20 PM »
Quote
For the list of separate images, should then a subfolder of "1x" exist, named like the object, that contains all its frames?

Not sure what you're meaning here?
If there's an animated object, say, water, in a tile set, say forest, at 1x resolution. Should its animation frames be forest/1x/water/0.png, forest/1x/water/1.png and so on with meta-info forest/meta-info/water.txt, or would you propose a naming convention like forest/1x/water_0.png, forest/1x/water_1.png and so on? Then how would you determine if this is a list of individual objects/tiles, or all belonging to the same objects? I guess the meta-info could indicate that there's such a thing called water, and it has a certain number of frames, following the default naming scheme (i.e. water_0.png and so on).

Offline namida

  • Administrator
  • Posts: 12398
    • View Profile
    • NeoLemmix Website
Re: 2.00 *New* terrain/objects-related discussion topic
« Reply #8 on: October 10, 2015, 03:52:41 PM »
Quote
a) An area indicating where the terrain should be a OWW, which is stored in each .lvl-file. How one defines this area in the editor might very much depend on how you want to save this area in the level file, but this is totally independant of the question which style to use or how to store any graphic files, no?

Correct.

Quote
b) Visual display of arrows: This is a set of pictures, together with a meta-info file stating "These are left/right/down arrows for OWW" (and other relevant things) and only this has to be stored in some style folder. These "objects" are then displayed on the OWW.
How to associate the OWW-area in the editor to the correct graphic set also depends on how OWW areas are stored within the level file, imo.

Essentially, the one-way wall (mechanics wise) is placed like a steel area (non-autosteel). The graphic is then applied to those areas - the way I'm seeing it at the moment, the choice of graphic is done either per one-way area (in which case, it could simply be an object that allows resizing, but is only applied to specifically-marked terrain), or per level.

Quote
And what happens if the user deletes this NX2-generated mask at some time after adding the 1x image? It might be noted, that the same issue may occur if 2x tiles are added later. Who guarantees that the terrain displayed there fits the terrain mask generated by the 1x tile?

The core design rule is - physics remain the same regardless of resolution. In that regard, the mask must remain the same regardless of resolution. So, it is up to the designer to ensure the higher-resolution image matches the mask.

Quote
If there's an animated object, say, water, in a tile set, say forest, at 1x resolution. Should its animation frames be forest/1x/water/0.png, forest/1x/water/1.png and so on with meta-info forest/meta-info/water.txt, or would you propose a naming convention like forest/1x/water_0.png, forest/1x/water_1.png and so on? Then how would you determine if this is a list of individual objects/tiles, or all belonging to the same objects? I guess the meta-info could indicate that there's such a thing called water, and it has a certain number of frames, following the default naming scheme (i.e. water_0.png and so on).

The first idea here makes sense - although would it not be better to use (using the same example) forest/water/1x/0.png?
My Lemmings projects
2D Lemmings: NeoLemmix (engine) | Lemmings Plus Series (level packs) | Doomsday Lemmings (level pack)
3D Lemmings: Loap (engine) | L3DEdit (level / graphics editor) | L3DUtils (replay / etc utility) | Lemmings Plus 3D (level pack)

Offline Simon

  • Administrator
  • Posts: 3860
    • View Profile
    • Lix
Re: 2.00 *New* terrain/objects-related discussion topic
« Reply #9 on: October 11, 2015, 03:24:09 AM »
Only some loose ideas for now.

I assume NL2 can be set to display 1x graphics, even if there is no 1x tile, and the game will downscale the wanted nx tile appropriately. I also assume that the mask is a 1x image.

I feel like the game shouldn't ever autogenerate 1x tiles or masks in the data dir. It should downscale to 1x while loading a tile that lacks a 1x version. If no mask is given, the game should infer regions from the downscaled image with a standard rule, but not write any of this to the data dir.

1x is special. Maybe don't make a subdirectory for 1x, and put whatever would have gone in the 1x directory into the parent directory. Maybe make the 1x directory nonetheless, for consistency.

I believe forest/water/1x/0.png is slightly better than forest/1x/water/0.png. We can put meta-info that's independent from scaling into a file forest/water/meta.txt. It matches my mental model better: Tilesets have tiles, tiles have properties and occasionally come in several resolutions.

I have no idea whether people like it better to edit anims with all frames in one file, or with each frame in a separate file. I'm only used to having them all in one file, that makes for fast color replacement, transparency settings etc. that apply to all frames.

Do you support nesting directories arbitrarily deep, or do you expect that dirs at a certain nesting level are always tiles?

-- Simon

Offline namida

  • Administrator
  • Posts: 12398
    • View Profile
    • NeoLemmix Website
Re: 2.00 *New* terrain/objects-related discussion topic
« Reply #10 on: October 11, 2015, 03:37:57 AM »
Quote
I feel like the game shouldn't ever autogenerate 1x tiles or masks in the data dir. It should downscale to 1x while loading a tile that lacks a 1x version. If no mask is given, the game should infer regions from the downscaled image with a standard rule, but not write any of this to the data dir.

In this case, should a guideline exist that the creator of a tile should always provide a physics mask if a 1x resolution image does not exist? Or do you think the best method is to specify which resolution to autogenerate it based on (using 1x as a default - or in the absence of a 1x image, the lowest-resolution (or maybe highest-resolution?) image that is supplied)?

Quote
I have no idea whether people like it better to edit anims with all frames in one file, or with each frame in a separate file. I'm only used to having them all in one file, that makes for fast color replacement, transparency settings etc. that apply to all frames.

In my experience, making modifications to existing ones is easier with all-in-one file, but depending on the type of object, creating an entirely new one is often a much tidier process with seperate files for each frame. This is why I'm wondering if ultimately, it may be worth supporting both.

Quote
Do you support nesting directories arbitrarily deep, or do you expect that dirs at a certain nesting level are always tiles?

The first two levels would have special handling, due to the fact that same second-level names (with different first-level ones) can be treated as addons rather than standalone sets. Beyond that, I'm not sure what the best way to handle this is - as geoo mentioned, it could be untidy if say, the main folder contains some pieces (and thus has "1x" "2x" etc subfolders) but also has subfolders that contain more pieces. One possible solution (and IIRC I suggested this already) is a scheme where a folder either contains pieces or contains subfolders (ie: it cannot contain pieces as well as containing subfolders). Equally possible is not enforcing this at a technical level (instead just treating the "keyword" names to not treat as subfolders), and simply making it a guideline for creators.
My Lemmings projects
2D Lemmings: NeoLemmix (engine) | Lemmings Plus Series (level packs) | Doomsday Lemmings (level pack)
3D Lemmings: Loap (engine) | L3DEdit (level / graphics editor) | L3DUtils (replay / etc utility) | Lemmings Plus 3D (level pack)

Offline Simon

  • Administrator
  • Posts: 3860
    • View Profile
    • Lix
Re: 2.00 *New* terrain/objects-related discussion topic
« Reply #11 on: October 11, 2015, 10:11:34 PM »
Guideline for masks: Haven't thought about it enough, will reserve answering for later.

Do you want to make subdirectories for every tile, even if it is a single image in one resolution without mask?

I haven't thought about it since much, but there's this idea: Assume a set comes in only one resolution. It can be awkward to have myset/piece00/1x/tile.png, myset/piece01/1x/tile.png, and so on. Reason: Each subdir would have only one image, and many programs are good at thumbnails for all images in a given dir, but rarely recurse through subdirs.

This again suggests something closer to geoo's directory structure (myset/1x/piece00.png, myset/1x/piece01.png, ...), or thinking it through anew.

Maybe don't enforce such a structure, and scan the pathname for /2x/ instead. If it is found, it's a 2x piece, if nothing is found, it's a 1x piece.

Anticipate what will happen most of the time, and allow that to be straightforward.

Maybe I'm worrying too much, and the nested dirs are OK with only 1 file inside. It's a cosmetical idea. Requiring one directory per tile, even if it's a most trivial tile, can be interesting, too.

Directories that mix both tiles and subdirs: If the rules become easier without such mixed dirs, feel free to forbid mixed dirs.

-- Simon
« Last Edit: October 11, 2015, 11:00:44 PM by Simon »

Offline geoo

  • Administrator
  • Posts: 1473
    • View Profile
Re: 2.00 *New* terrain/objects-related discussion topic
« Reply #12 on: October 11, 2015, 11:01:43 PM »
Implementation-wise the myset/piece00/1x/tile.png is cleaner.

But for a graphics set designer it's more convenient to have one folder with all the images. Most tiles won't have meta info or anything like that, so having to navigate into another folder for that is not that much of an issue I think, unlike having to navigate into a new folder for each new tile (and creating those in the first place).

The structure also lends itself to natural nesting. Only obtaining the identifier from the image path is a little less straight forward as the '1x' or whatever resolution is available has to be cut out in the middle of the path, rather than just truncated from the end.
Allowing to sort tiles into subfolders thematically creates the following issue (depending on how objects are implemented): if objects in the 1x/2x/... subfolder are represented as a folder containing the individual frames rather than a single image with all frames, as then the only way to distinguish it from a subfolder of tiles is looking for corresponding meta-info. This meta-info file will have to exist, so it's always possible to distinguish, but implementation-wise a bit more complicated. For the graphics set designer though it should be obvious what is a folder of terrain and what are the frames of an object.

Offline namida

  • Administrator
  • Posts: 12398
    • View Profile
    • NeoLemmix Website
Re: 2.00 *New* terrain/objects-related discussion topic
« Reply #13 on: October 12, 2015, 04:05:07 AM »
Alright, I've finished modifying the graphic set / piece handling code to exclusively suit a folder-based structure. (Tidied up a few other things at the same time.) I haven't yet implemented saving or loading; since we're still discussing the exact implementation, I'll first work on replacing the existing rectangular trigger area code with code that allows for arbitrary areas.

If we go back to the idea of seperating terrain and objects - perhaps one way to avoid mess in this regard is to have entirely seperate folder trees for the two. In other words, the structure would be:

<author>
..<set>
....TERRAIN
......<piece.png, piece.ini, etc>
......<piece.png, piece.ini, etc>
......<piece.png, piece.ini, etc>
....OBJECT
......<piece.png, piece.ini, etc>
......<piece.png, piece.ini, etc>
......<piece.png, piece.ini, etc>
....GADGET
......<piece.png>
......<piece.png>
......<piece.png>


I am starting to question at what point dividing it up will go against the idea that a folder structure is supposed to be friendlier to the content creators (but then again, since I never really understood that idea in the first place...), though - having to navigate through a hundred different folders seems a lot less user-friendly to me, than having a proprietary format with a tool that can quickly pull out the relevant image. But I do think that keeping terrain and objects seperate, at some level, is a logical decision either way.

Within these folders - I'm thinking the best idea (ignoring any questions of sub-categorization - the more I think about that, the more I'm questioning if we really need it, since there's no reason you couldn't just have a couple of related "sets") is to keep the metadata (including mask images) in the main folder, with subfolders being used exclusively for the various resolution images. I don't know that I like the idea of keeping a 1x image in the main folder rather than a 1x resolution subdirectory, primarily because this would imply that a 1x image is obligatory and only the other resolutions are optional (when in reality, the only requirement is that one resolution is provided - it doesn't nessecerially have to be 1x).
My Lemmings projects
2D Lemmings: NeoLemmix (engine) | Lemmings Plus Series (level packs) | Doomsday Lemmings (level pack)
3D Lemmings: Loap (engine) | L3DEdit (level / graphics editor) | L3DUtils (replay / etc utility) | Lemmings Plus 3D (level pack)

Offline namida

  • Administrator
  • Posts: 12398
    • View Profile
    • NeoLemmix Website
Re: 2.00 *New* terrain/objects-related discussion topic
« Reply #14 on: October 12, 2015, 05:28:21 AM »
Eh, I kinda ended up doing things in the exact opposite order of what I suggested. Although I didn't code anything for handling the graphic loading/saving yet, I came up with a sample folder structure - based on the low and hi res pairs of psychedelic set that I've made. Sample graphic set folder attached.

Note the following:
1. I still intend to support arbitrary trigger areas. However, since I see rectangles as still being the most common case, I've also allowed these to be defined in the metadata text file. My idea is that in the case that both are present, the image should override - however maybe also a warning should be generated if a single piece specifies a trigger area via both methods?
2. Note the difference between "trigger area" in some objects, and "trigger point" in others (the window and the receiver). This is because any object that can receive a lemming will use a point, not an area - which is important when it comes to objects that can do both - ie: two-way teleporters and single-object teleporters.
3. My idea of handling masking for terrain pieces is that - if no mask is present, it autogenerates it based on which pixels are or aren't transparent (how to handle semitransparency is not yet determined), by default from the 1x image, but perhaps the metadata (perhaps a graphic-set-global setting should be allowed here, so it doesn't have to be specified per-image) can specify to use a different resolution, in cases where the author has no intent of creating 1x images (which is fair enough, since they can be autogenerated from the 2x ones - but there needs to be some way to ensure that physics won't change if a 1x image is later added, which is why I'm thinking require either (a) a mask, (b) a 1x image, or (c) an explicit specification to use a different resolution to auto-generate masks).
4. Note how three of the stairs images specify an "offset" for the 2x image. This is because the leftmost column in them is intended to be displayed one pixel to the left of the terrain piece's position. An alternative might be to modify the graphic set itself to account for this (by repositioning the graphic in the 1x image), then patching old-format levels when loading / converting them. EDIT: I am indeed thinking that modifying the graphic set itself (and patching old levels when loading) is the better option.
5. The "brick_pink" and "brick_yellow" pieces are indeed new; they don't exist in the current version of the Psychedelic set. But they're also quite logical additions, seeing that brick_red and brick_green already existed, and bricks_4x4 and bricks_2x2 include yellow and pink pieces as well as red and green ones.

The contents may be freely used for any purpose, including in other engines.
« Last Edit: October 12, 2015, 08:57:58 AM by namida »
My Lemmings projects
2D Lemmings: NeoLemmix (engine) | Lemmings Plus Series (level packs) | Doomsday Lemmings (level pack)
3D Lemmings: Loap (engine) | L3DEdit (level / graphics editor) | L3DUtils (replay / etc utility) | Lemmings Plus 3D (level pack)