NeoLemmix Update: V10.12.XX [GSTool V10.12.13 released]

[GigaLem]

I welcome this feature with open arms
I do like the idea of personal bests, Maybe a record table in the player will work too?

[namida]

I take it "+13f" is the number of frames beyond an integer number of seconds?

It is. And yeah, I like your suggestion of changing to centiseconds; I'll implement that.

NeoLemmix actually has kept track of these for a while, but there were a couple of bugs that I only noticed now (with lemmings saved, it won't remember your best unsuccessful attempt, only successful ones; with best time, for example, if a level required 30 lemmings but you saved 35, it would count based on when the 35th lemming exited, not when the 30th lemming exited). And there was no obvious way to display them - there was a key you could press on the preview screen, but I don't think many people were aware of it.

[namida]

Player V10.12.13 update and Flexi V10.12.14 update released.

Main thing to note with the new player is there's no longer an -alt version, as some changes in this should remove the need for one. There's a few other tweaks; check the first post for full changelogs (and download links) for both of these updates.

The only change from the last experimental version of the player is that times on the postview screen are displayed with centiseconds, not frame counts.

[IchoTolot]

Now it seems I have the ingame all-around blackedge that's around the level game area even in the menus and pre/postview screens (fullscreen mode).

This seems kinda ugly to be honest. Is there a possibility to zoom the menu screens to real fullscreen size again and make these black edges disappear?

[namida]

The main goal with this is so that the menu screens and the in-game take up the same amount of screen area, rather than in-game taking up slightly less. I'll see what I can do to offer an option for the old method, though.

(EDIT: Have added such an option for the next update.)

[IchoTolot]

The main goal with this is so that the menu screens and the in-game take up the same amount of screen area, rather than in-game taking up slightly less. I'll see what I can do to offer an option for the old method, though.

(EDIT: Have added such an option for the next update.)

I would even argue to make this the default option.

The black menu edges seem weird and new people might think that something is working wrong here. It is also somewhat weird for recordings.

Maybe make a poll

[namida]

To those who are used to the existing layout, it may seem weird. These people are more likely to see that there's an option, as they'll be around when the version with the option is released.

New users, on the other hand, might find it weirder that menus take up the entire fullscreen area, but in-game has the borders. It might seem more consistent to them for all screens to take up the same amount of on-screen space.

Stretching the image to take up the entire screen area can also cause some degree of distortion. I have added some options that will help address this to some extent, but for obvious reasons it cannot be addressed completely except by not using the "use entire screen area" option. This is even more true now that the menu screens use the same width-to-height ratio as in-game (16:10), whereas previously they used one that was much closer to 16:9 (which is also the ratio for most widescreen resolutions).

[Nepster]

I agree with IchoTolot that the black border is not perfect. However adding another option is not the solution, because it doesn't actually fix the core issue: It just migitates the problem on some screens, while it persists on others (namely when actually playing a level). So I would prefer to have one full-screen option, which behaves as follows:
- Menu screens are resized to use either the full height or full width of the screen, while keeping the ratio of 16:10.
- For game screens, we use the maximal zoom and then fill the border with a larger part of the level. So for example on a 1024x768 screen, we would use a zoom factor of 3 and instead of a 960x480 image of the level with a 960x120 image of the skill bar, we use a 1023x648 image of the level area (which is a 341x216 part of the level, zoomed by 3) and a 1023x120 image of the skill bar (which is the usual skill bar with some empty space on both sides).

Unfortunately I suspect that this would not be straight-forward to implement, though I know not nearly enough about the screen output and user input code to make a qualified statement in that regard.

[namida]

It would be a fair bit of work, but not on the level of near-total rewrite. The main question is how to handle levels that are too small to make use of additional area. Lix handles this by putting a border (in a color very distinct from the background black) in the unused area, while the skill panel still takes up the entire width. This is somewhat ugly. It is also less practical for NeoLemmix, where level backgrounds are not always the same color. Not expanding the skill panel when this happens would then mean the user interface varies based on the level size, so this is not ideal either.

Stretching the skill panel by a non-integer multiple is also going to produce some somewhat ugly results. The alternative to ugly results is to use a TLinearResampler on them, which looks much nicer but requires much more processing power. An option for this exists in current code (newer than the V10.12.14 release) with existing zoom mechanics, with seperate options for menu screens and in-game (there is no seperate option for the skill panel vs the gameplay area); this defaults to on for menus, and off for in-game. On my PC, in-game performance is the same at normal speed with or without it, but fast forward is significantly slower than normal. I suspect that applying this only to the skill panel will reduce, but not entirely eliminate, this issue. More complex solutions involving pre-rendering the resampled graphics may exist, at a cost of much higher memory usage. This is probably the optimal solution, but also the most work.

[Nepster]

The main question is how to handle levels that are too small to make use of additional area.

How about a 2-pixel wide white border and then the non-level color beyond?

Stretching the skill panel by a non-integer multiple is also going to produce some somewhat ugly results.

I would stretch the skill panel by an integral value, center the resulting panel horizontally and then fill the remaining space left and right by some empty background.

The alternative to ugly results is to use a TLinearResampler on them, which looks much nicer but requires much more processing power.

I don't think this will be a problem for menus, and with the method above we only need to zoom by integral values while playing a level. So there shouldn't be performence problems with my suggestions above, should there?

[namida]

Your previous post implied a non-integer resize for the skill panel - 1023x128 (which I assume you meant rather than x120, as this keeps proportions) is a 3.19x zoom. Of course, now that I think about it, you could just as easily have meant 960x120, which is a 3x zoom exactly.

Linear resampler on the menu screens causes some slight slowdown of the fade (I have made some changes to minimize the impact of this, and at any rate the resampler can be turned off), as well as to the speed of text scrolling on the main menu screen (not a huge concern).

[namida]

A further question that arises on this - why should such options be restricted to fullscreen mode? And, how would the options be provided for windowed mode? (In particular, I suspect that adjusting during gameplay might be very difficult to implement, meaning the obvious of "make the window resizable" might not be the way to go.)

[namida]

Released an editor update that greatly improves the piece selection menu, as well as fixes the object rotation copy/paste bug.

The option to use Fencer skills is still hidden. Those who I've told how to unlock it; it's still unlocked the same way in this update.

EDIT: Sorry, there were a couple of bugs with the improvements to the piece selection window in the initial upload. I've reuploaded now with (hopefully) all of these bugs fixed, as well as one other minor bug that's been around since day one but I never noticed until now.

[namida]

Ugh, discovered some more bugs with the new code. Uploaded a -B hotfix that deals with them.

[namida]

Mass replay checking is broken in the new player version. Will try and get a hotfix later today to address this; in the meantime here's a download link for the previous version (V10.12.12-C) where it's working; there are no physics changes in the new version so replays that work on one will work on the other:

http://www.neolemmix.com/old/NeoLemmix101212.exe