2.00 In regards to graphic sets...

[namida]

Some points that have come up and/or been thought about by me...

1. I already plan to support, at the very least, standard resolution (ie: what NeoLemmix currently uses) and double resolution (ie: comparable to that of Lemmini) in V2.00n. Possibly higher too. With this being said - should I support storing multiple resolution images in a single graphic set file, or should each graphic set only contain one resolution of images (with all others being resized from that one)? I do realise that if storing multiple resolutions is supported, it's not likely to be used much - double resolution versions of the Orig / OhNo graphic sets already exist (in WinLemm), and I'd probably eventually remaster my custom graphic sets to use it too. Beyond that, it'll probably see very little use.

2. Should the use of multiple graphic sets in a single level be supported? This will most likely require a completely new editor, as expanding the current one to support it would probably be a more difficult task than just writing a new one from scratch. However, in this case, I don't know how willing I'd be to implement support (other than simply importing and converting to NeoLemmix) for other level formats. With that being said, writing a new editor would likely mean I could integrate it into NeoLemmix itself, rather than two seperate applications.

3. Should some object types - eg, pre-placed lemmings, one way arrows, be made a seperate part of the level data, rather than a type of object (which requires them to exist in every graphic set that uses them)?

[Simon]

1. Multiple resolutions in a graphics set: There are people who really care about the tiles' resolution, or who want Genesis-like coloring of the dirt set, etc., even if it doesn't affect physics. Those should make the call. :-) To me, it sounds like overkill. I'd always display what looks/plays best, and not care about making it look like one particular game. Lo-res sets are useful to estimate physics.

2. Mix and match sets: If you were to design things from scratch, I'd heavily advocate mix-and-match. However, you have existing formats to pull through, and existing sets are self-contained; they don't rely on mixing to be usable. This idea arose from question 3 about set-independent gadgets.

3. Independent gadgets: Good, because you have so many different ones.

-- Simon

[namida]

I would think the only ones that could easily (and logically) work as standard, seperate features rather than objects would be pre-placed lemmings, one-way arrows and secret level triggers. *Maybe* pickup skills.

I'd think that, if a major rewrite is occurring anyway, keeping backwards compatibility with existing file formats need only be done on the loading side. I do see it as critically important that "NeoLemmix V2.00n can load levels made for NeoLemmix V1.xxn", ideally I'd like to have "NeoLemmix V2.00n can directly use graphic sets made for NeoLemmix V1.xxn" (with less worrying about other data types, provided an easy way exists to convert them). I'm not overly worried about having "levels created for NeoLemmix V2.00n can be loaded in NeoLemmix V1.xxn"; if they can't, they can't.

[McAleeCh]

Quick question regarding graphic sets - will it be possible to specify the background colour within a graphic set? Some styles - Lemmings 2 Shadow style being the prime example - really don't work very well on the default black background, and would really benefit from having a different background colour. I don't think it's necessary to be able to define this on a per-level basis, but it'd be useful to allow different graphic sets to use different background colours if possible.

[namida]

This is a very frequently requested thing, so yes, it'll be possible. Whether it's on a per-level or per-graphic-set basis, I'm not sure yet, but I'm leaning towards the latter. Exactly how this'd be integrated with multiple graphic set support, I'm not sure, but one possibility is each level having one that's considered its "primary" graphic set (so it takes things such as bridge color, etc from here).

[namida]

Graphic sets is something I'm going to start coding for very soon, so any ideas you have for it in particular, get 'em out in the open now!

Some thoughts I'm considering:

Some objects will no longer be inherently part of a graphic set
The obvious case here is pre-placed lemmings, which will be an inherent feature without requiring a graphic set to explicitly contain a "pre-placed lemming" object. After all, the graphic set's "pre-placed lemming" object is only even used by the editor; the game itself just places a lemming at that point (and doens't use the actual object sprite).

That aside, I'm also considering the same for some other commonplace objects such as pickup skills and one-way arrows. In these cases, the most likely setup will be that default graphics for these exist, with each graphic set having the option to override them with custom ones. This removes the need to especially design these items for graphic sets (or insert them in converted sets that don't contain them), while still allowing graphic sets to customize the appearance of them if desired.

Windows and exits are a tricky issue, especially given that a single graphic set may have more than one of each. The obvious option here is to have "default" ones, which are always usable, while also allowing a graphic set to have its own custom ones (which would generally be the preferred option to use if they exist). Another option may be having a "generic" graphic set which can be used alongside another one (since I plan to support multiple graphic sets in a single level), in cases where a graphic set might not specifically have these objects. Of course no such graphic sets currently exist, but especially in the case of windows, custom graphic sets often don't feature a custom window at all, or if they do, it's just a recolor. As such, a setup that provides a default one might make sense.

Distinguishing between types of objects
Currently, NeoLemmix simply distinguishes between three types of pieces in a level's map - objects, terrain, and steel areas. I'm wondering whether it might make sense to take that one step further, and treat different types of objects seperately. This could have advantages not only for organising, and finding specific object types in the editor, but also with efficiency while running.

Backgrounds
Support for selectable background color is requested fairly often. Support for background images less so, but I have seen questions about it, and we've seen levels (for example, in Lemmings Reunion) where no-effect objects are used to replicate the effect of a background. Having some kind of inherent support for these, rather than hacky workarounds being used, not only is likely to be more efficient, but it can also allow for user options relating to disabling custom backgrounds, which may also be preferable in some cases.

Resolution
At the moment, I'm leaning towards allowing of multiple resolutions in a single graphic set file. In the case of high-res graphics not being present, the low-res ones would simply be zoomed if the user has hi-res settings (perhaps with a filter applied? That could probably be an option rather than a fixed behaviour). In the case of low-res graphics not being present, they would be downsized from the high-res ones in exactly the same way NX1 does. (It should be noted that the low-res image would be important even when using high-res, due to that physics will still work in low-res.) I'll also make sure to futureproof this to potentially allow even higher resolutions at a later date; though initially such will not be supported. Ideally, a graphic set should at least have low-res images, even though support would be there to autogenerate them (perhaps this should be done at creation / conversion time, rather than at runtime?).

Future additions?
If you have an idea that probably doesn't belong in the initial version, but might be considered in the future, it could still pay to drop it now. If there's interest, then even if I don't plan to implement it right away, I can possibly design in such a way it'll be easier to implement it in the future.

[ccexplore]

Some objects will no longer be inherently part of a graphic set<snip>

If you plan to allow a level to use multiple graphics sets, then it seems like pretty much everything can be optional in a set, as the user can mix and match from multiple sets as they see fit.  You can then have a "generic" set that don't actually have any terrain, but have things like pickup skills, one-way arrows, and other "commonplace" objects.

I'm also thinking that instead of graphics set supporting just pre-placed lemmings, maybe they can actually support full modding of all the lemmings animations themselves, if one is ambitious enough to basically create a whole new tribe like in L2.  Then pre-placed lemmings are simply taken from a subset of the lemmings animation graphics.

Distinguishing between types of objects
I'm wondering whether it might make sense to take that one step further, and treat different types of objects seperately. This could have advantages not only for organising, and finding specific object types in the editor, but also with efficiency while running.

I'm not entirely sure I understand what the "efficiency while running" is about, but it certainly make sense as a way to help organize and find specific object types in the editor.

Backgrounds<snip>
Having some kind of inherent support for these, rather than hacky workarounds being used, not only is likely to be more efficient, but it can also allow for user options relating to disabling custom backgrounds, which may also be preferable in some cases.

Definitely, if you support custom background images especially, definitely include a user option to disable them.

Resolution<snip>
Ideally, a graphic set should at least have low-res images, even though support would be there to autogenerate them (perhaps this should be done at creation / conversion time, rather than at runtime?).

Autogenerate at creation/conversion time might be a good idea.  It'd allow the graphics set designer to review the results and make surgical corrections on anything that wound up looking suboptimal.

Will you enforce that the low-res and hi-res terrain be same from a physics perspective?  Or at least have a checker to check for that?

[ccexplore]

Definitely, if you support custom background images especially, definitely include a user option to disable them.

In fact, maybe go a step further and make it a runtime command (mappable to a hotkey of course) to be able to toggle custom background images on and off.  You might also want to consider a similar setting affecting no-effect objects as well.

[namida]

I'm also thinking that instead of graphics set supporting just pre-placed lemmings, maybe they can actually support full modding of all the lemmings animations themselves, if one is ambitious enough to basically create a whole new tribe like in L2.  Then pre-placed lemmings are simply taken from a subset of the lemmings animation graphics.

I had thought about allowing this for packs as a whole, but hadn't considered it on an individual graphic set basis (even though precedents for it do exist, in the form of L2 and Cheapo). That is a good idea.

I'm not entirely sure I understand what the "efficiency while running" is about, but it certainly make sense as a way to help organize and find specific object types in the editor.

Currently all objects run through the same code, even code that isn't nessecary for specific (for example, objects that aren't animated (or triggered objects that aren't currently animating) still get redrawn every frame). If they're divided, it might be posssible to reduce this kind of thing; although exactly how these improvements work.

Autogenerate at creation/conversion time might be a good idea.  It'd allow the graphics set designer to review the results and make surgical corrections on anything that wound up looking suboptimal.

Will you enforce that the low-res and hi-res terrain be same from a physics perspective?  Or at least have a checker to check for that?

The basic plan is that the low-res image is always the one used by the physics, with the high-res one being the one actually displayed if that's what the user's settings call for. While some kind of option would be implemented that could "filter out" pixels that don't match solidity (and perhaps add filler ones where nessecary), it'd ultimately be up to graphic set designers, if including high-res graphics, to make sure they match the low-res ones. A player who favors perfect representation of the level's map (in terms of physics) over eye candy should be using low-res anyway, for this reason.

This is actually the biggest reason for including a low-res option at all, despite that all other engines these days use something more on the 640x320 scale as their minimum - because the physics would be based off the low resolution still. If the physics were going to be any different in hi-res, I'd question whether low-res should even be kept at all. Certianly, if it were the other way around (ie: physics always based off high-res), I wouldn't bother supporting a low-res dispaly option.

[GigaLem]

So uh, a feature to allow the use of multiple sets at once?
Im fine with that

[namida]

So uh, a feature to allow the use of multiple sets at once?
Im fine with that

Yep. The exact details of how it'd work are still to be figured out, but the overall plan is to support a single level using as many graphic sets as nessecary. This would remove the need for graphic sets such as the Epic one, which simply serve as a combination of several other ones. It'll also avoid situations like we had with Cheapo, where there were graphic sets that might contain a few new objects or terrain pieces but mostly copy from other existing ones (since instead, level designers wishing to do this can just use two graphic sets together in their level).

I will stress that just because you can do something doesn't always mean you should, though.

[mobius]

1. If you go with hi-res, I say go all out and forget the low-res. Support only the new stuff because, for one thing having low res graphics mixed with high looks weird imo.

2. Yeah, absolutely. Not only is it cooler to have for making levels [besides the obvious mixing terrain for aesthetic purposes, there are other benefits like not being limited to a certain types of traps or using any kind of eraser pieces. Even for those, like myself, who would rarely mix and match wildly different terrain sets, I have used other mixed pieces just to use for unique erasers.

3. a problem with having things like arrows universal to all sets is you may still have to have 8 or more types of them since each graphic set currently has a different color for it's arrows.

colored Backgrounds personally I don't care about. I like the black background. An image for background is alright but there's a very tiny margin for what makes a good background image and a bad one imo.

[ccexplore]

This is actually the biggest reason for including a low-res option at all, despite that all other engines these days use something more on the 640x320 scale as their minimum - because the physics would be based off the low resolution still. If the physics were going to be any different in hi-res, I'd question whether low-res should even be kept at all. Certianly, if it were the other way around (ie: physics always based off high-res), I wouldn't bother supporting a low-res dispaly option.

Hmm, so what are the reasons to based physics off low-res still?

It may be worth mentioning that the Mac version of Lemmings 1 (+ ONML and Xmas etc.) is one of few (maybe only; I'm not so familiar with how the Windows version handles hi-res) ports that have high resolution graphics (2x) but still low resolution physics.  I disassembled that aspect some time ago and found that it uses a pretty simple algorithm, whereby it looks at a 2x2 grid of hi-res pixels, and treat that block as "has terrain" for physics purposes if at least 2 of the 4 hi-res pixels are terrain.  You can basically think of that as >= 50%, and potentially extend that to even higher resolutions (3x and beyond).

[namida]

The idea was to keep the physics the same as they currently are. But if things are going to be changed up a lot in other ways, then perhaps switching to high-res based physics is a good idea too. The key thing I do insist on is that whatever resolutions may be supported for display, the physics are consistent across all of them. Since I think 4x would be too high to reasonably support while resolutions like 1024x768 are still in use (or for that matter anything less than 1280x800), but 3x is reasonable as a possible near-future addition, 1x is also a logical choice to base physics off. I'm not sure how well a 3x display combined with 2x physics would work, even if the physics are handled seperately from the display (rather than an algorithm like that of Mac).

EDIT: It seems, according to the other topic, that physics at 1x is by far the preferred option. So that's how it's staying, I guess.

[namida]

Semi-related; I decided to experiment a bit with creating hi-res versions of my graphic sets. I started with the obvious easy one; the Psychedelic set.

Here's the first two pieces in both low-res (at 2x zoom), and potential hi-res equivalents. It should be noted that the difference will, in general, be WAY more dramatic for LPII / LPIII graphic sets, than it will for LPIV / Doomsday ones, due to that the LPII / LPIII sets were also made at a time when a 32-color palette was the limit and were never remastered to take advantage of full-color capabilities in newer updates to NX1. Indeed, for the LPIV and Doomsday ones, simply zooming and applying some kind of smoothing will probably be enough for the majority of pieces; whereas LPII and LPIII sets are going to need a lot more work.