2.00 In regards to graphic sets...

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