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.

[namida]

So I kinda went on a remastering rampage earlier and did the entire terrain of the Psychedelic set, as well as the first frame of the exit (I'll probably autogenerate the remaining frames based on this first one, rather than do them manually).

And naturally, I wanted to see how it'd actually look in a level. Since I was too lazy to make the effort to make tweaks to NX1 (or its editor) to output a 2x resolution rendering (note: I completely overlooked the option of "just export it as a SuperLemmini graphic set"), I actually manually copied/pasted this together.

Here's the result. I think this level is well-known enough that I don't need to name it. Note that I haven't touched up the window or the water yet.
(EDIT: And the original low-res (zoomed to 2x size) for comparison.)
(EDIT: Made the hi-res water now, so updated the pic to include that. I was a bit lazy in terms of tiling it, though.)
(EDIT: And the window! So this is probably very close to how Panic Attack will actually look in NX2, if hi-res is used!)

[namida]

After further consideration on the "split objects into many sub-types" idea, I think it's quite pointless to do this for all object types. However, a more-divided approach than just "objects" may be a good idea. (The editor could still categorize them by the exact type.)

Basically, I'm thinking of categorizing them into four types based on the nature of their effects:

1. Active objects. These are the ones that constantly animate, and cause an effect to any lemming that encounters them. For example, exits, water, fire... and for that matter, pretty much anything.
2. Triggered objects. The name is fairly self-explanatory. For example, teleporters, traps.
3. Passive objects. These are objects that do have functions, but these functions are not triggered simply by a lemming encountering the object. For example, windows, receivers.
4. Purely graphical objects. These are the ones that have no impact at all, and are just there for decoration. For example, no-effect objects, backgrounds, moving backgrounds, etc.

I think this covers just about everything. Pre-placed lemmings and one-way-walls might seem hard to classify... but then, I intend for these to no longer be treated as objects (but instead as features of the level in their own right, similar to steel areas).

One question is how two-way teleporters would fit into such a framework, as they have features of both Triggered and Passive objects. One possibility is to consider teleporters (of all forms) a 5th, distinctive type; in some ways this would be easier for coding too.

[namida]

After putting more thought into this, especially concerning odd types such as two-way teleporters, I'm thinking that the best way to handle it is simply to make only the following divisions:

1. Windows
2. Everything else

(With backgrounds, pickup skills, one-way walls and pre-placed lemmings being entirely seperate; backgrounds still being an item specific to a graphic set, and the next two having default graphics which a graphic set can override with custom ones. A graphic for pre-placed lemmings is unnessecary; instead, the actual lemming sprites should be used to represent these in the editor.)

Another thing I'm wondering is, should it be okay for the low-res and hi-res versions of an object to have a different number of frames, provided that the number of frames has no impact on physics (which is true for pretty much everything except for multi-use traps and teleporters).

[namida]

Here's a potential high-res pickup skill graphic (based upon the Psychedelic set color theme). Any thoughts?

Any "generic" one (ie: for graphic sets that don't contain custom pickup skill graphics) will probably just be a less-colorful version of this.

EDIT: Zoomed it to double-size to make it more visible.

[namida]

For objects - should non-rectangular trigger areas be supported? I'm thinking not just circles (like Cheapo had), but essentially allowing arbitrary shapes. I doubt this would see much use, mind you. (I'm also not entirely sure how I'd go about implementing it while still supporting trigger area pixels outside of the object's graphic, other than by using a fixed buffer zone; at least on the editor side of things. Which, mind you, I don't have to worry about for a while yet.)

I haven't done much more on this lately due to having a busy couple of weeks, but after a bit of a coding marathon today, I've now more or less got the behind-the-scenes code for handling object and terrain data (on the graphic set side) made. At this point, it'd still be fairly easy to make the above change, if it does occur.

Another thing I was wondering about is whether or not to support foreground objects - like backgrounds, but they appear in front of the lemmings. Also like with backgrounds, an option would exist to disable those; but it'd be there for those who like the eye candy.

[namida]

Also - in regard to multiple resolutions in a graphic set file. In the event that the desired resolution does not exist, any input (especially from those experienced with multi-resolution graphics handling) on what's the best to pick as an alternative option to resample to the desired resolution?

Currently, I'm going with the following:
1. Look for an exact match. (ie: if a 3x resolution image is desired, and the graphic set has one, it'll use that)
2. Look for the highest-resolution image that's larger than, and an integer multiple of, the desired resolution. (ie: if a 3x resolution image is desired, and a 6x resolution image exists, it'll resample from that - even if 7x exists)
3. Look for the highest-resolution image that's larger than the target. (ie: if a 3x resolution image is desired, and 5x is the largest, it'll resample from that)
4. Look for the highest-resolution image that's an integer factor of the desired resolution. (ie: if a 4x resolution is desired, and a 2x resolution image exists, it'll resample from that - even if 3x exists)
5. If all else fails, simply find the highest-resolution image that exists and resample from that. (ie: if 5x is desired, and the file contains 2x and 3x, it'll resample from the 3x)

I'm wondering if I shouldn't bother with the integer multiples, or if at least 1x should be excluded from step 4. I'd run some tests, but that'd mean I'd have to first make some various higher-resolution (beyond 2x) versions of graphics, which I really don't want to do, especially just for the sake of testing. It should also be noted that in practice, I somewhat doubt we'll see anything higher than 2x in the near-future (especially considering that if we go much beyond that, the frame rates and physics based off 1x will start to look very choppy) - it's just making more sense to me to implement support for it now, rather than try and add it in later.

In terms of progress; I've pretty much fully implemented the code needed for the objects (in the programming sense) to represent terrain pieces and objects (in the Lemmings sense). Other aspects of graphic sets aren't so developed yet, but I have built a framework that allows very easily adding support for extra formats. While there will be a native NeoLemmix 2 format, it is very likely thanks to what I've done here that NX2 will also be able to directly use graphic sets from almost any other major engine (including NX1, DOS, Lemmini and Cheapo; and heck, I might even be able to work in a directory tree / millions-of-seperate-files format, since some people seem interested in such an option - though I'll stress it will never be intended as the primary format). Though I would recommend properly converting them, of course. It might even be possible in the future - although it's not something I plan to do right away - to allow adding extra formats simply by dropping in a DLL file.

(Needless to say, I'll probably implement something very similar for level loading, too. I don't think it'll be so important, or useful, for other data beside these two.)


By the way, generic pickup skill graphics - for ALL skills now. Well, except Swimmer, as I haven't made hi-res lemming sprites for that yet. (I could've sworn I did make them, but the files that do or don't exist in my project folder disagree with me on that one.)

EDIT: Added the generic low-res ones alongside them, for comparison. (These are the normal NX1 ones, except rearranged into the official NeoLemmix skill order (technical reasons why they weren't in that order before), and recolored to match the generic palette.)

I've also almost entirely created a hi-res version of the Psychedelic style now, too. The only things left to touch up are the one-way fields, the trap, and the teleporter/receiver. Once that's done, I might see if I can whack together some quick code to auto-generate hi-res images, so that you can see what several levels look like. I don't know if I'll be in too much of a rush to redo any more graphic sets, though... it's a lot of effort and not particularly fun. xD

EDIT: Okay, nice! I've now created all the graphics (aside from the Swimmer pickup skill) for a high-res version of the Psychedelic set.

[namida]

I'll also mention - I've added right from the start the ability to support any number of arbitrary resolutions in a graphic set. Obviously this depends on a graphic set file format also supporting it (currently, no formats support more than one, unless it's as multiple seperate-but-related files such as how WinLemm handles it), but that's not a huge issue.

With that being done, it really makes sense to design NX2 to support arbitrary resolutions for display from the start too. So looks like that's what I'll be doing. But do keep in mind I certianly don't plan to make resources for higher resolutions than 2x, so attempting to run it higher (unless someone does make resources) will be relying on automatic resampling.

It's also written so that a graphic set does not have to include a low-res image; if none is present, it'll simply resample a hi-res one. This is done once and cached, not done every time the image is referred to, so it shouldn't have any impact on speed outside of when initially loading the graphic set.

[geoo]

One thing I was wondering about: With what you propose I can still play single resolution, but scaled up to cover the whole screen, right? Not just a small 320x200 window.
I think personally I would stick to single resolution for the original tile sets anyway, I don't know the appeal that some people see in the higher resolution versions. I just hope there's an easy way to delete the high-res versions from a graphics set if I want to use low-res in combination with hi-res items (like the pickup skills you posted).

Scaling down generally looks ok, no matter from what resolution to which.
Scaling up looks like crap if you don't scale up to an integer multiple, especially if you use pixel repetition for the scaling algorithm.

The Lix community level pack shows that different styles are rarely combined in one level. Mostly "foreign" terrain pieces are used as decoration, for erasing terrain or because the style misses e.g. steel pieces. Thus I see not really a reason to allow mixed graphic sets if that means huge efforts to implement. On the other hand I see at the moment no reason to disallow mixing separately stored terran pieces from the file tree.

It just ran a script over the community pack, and not taking into account eraser pieces, 163/240 levels actually use tiles/objects from at least 2 different styles. A lot more often than it might appear on first glance. I guess the usage is more subtle, and when used, it's done in such a way that the tiles fit well and look nice. I believe often it's also objects being borrowed, as you don't always have equivalents in all tilesets.
Mixing tilesets is desired (see Epic tilesets for Lemmini/Lemmix), and excessively used in Lix.

And yeah, assigning numbers to tilesets doesn't scale well, and every tileset designer has to run through you as number assigning authority. Keep the numbers for the currently existing tilesets if you want to support legacy levels, and refer to them by names internally and externally for anything that isn't legacy support.

[Nepster]

It just ran a script over the community pack, and not taking into account eraser pieces, 163/240 levels actually use tiles/objects from at least 2 different styles. A lot more often than it might appear on first glance. I guess the usage is more subtle, and when used, it's done in such a way that the tiles fit well and look nice. I believe often it's also objects being borrowed, as you don't always have equivalents in all tilesets.
Mixing tilesets is desired (see Epic tilesets for Lemmini/Lemmix), and excessively used in Lix.

Interesting; when I went through these levels per hand, I noticed only about 30 levels really using different tiles and a few more for decoration. Could you please run the script again ignoring objects (e.g. almost all levels with water and many levels with traps are counted, because those objects are mostly concentrated in one or two styles in Lix).

[geoo]

Taking out all objects, there are still 90 (86 if we also take out steel) levels that use terrain pieces from at least two different styles. Note that images/geoo/steel is not counted as a separate style in my script.