Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Messages - ccexplore

Pages: [1] 2 3 ... 377
General Discussion / Re: Simon blogs
« on: June 22, 2020, 10:05:15 am »
There's no harm in posting the problem here; as the saying goes, two (or more) heads can be better than one.  But I also think you are actually already the person on the forum who's most well-versed in the theory and practice of software design and architecture.  So ideally you'd want to get advice from someone who's even better at this, and hence a more programming-oriented forum or channel is probably the way to go.

But even if you end up solving the problem through purely outside advice, I certainly wouldn't mind hearing about the solution here. ;)

[aside: your previous post about keeping sentences terser has made me actually took the time to review and edit my writing above accordingly]

Engine Bugs / Suggestions / Re: [DISC][PLAYER] Remove timer on nuke
« on: June 22, 2020, 09:40:01 am »
The proposed "timer bypass" nuke activation (ie. rewind 5 seconds, nuke, fast forward 5 seconds) is a neat tool in the same way replay editing is (and really, it is an example of replay editing under the hood).  But some of the observable side effects (such as cases Simon mentioned) will probably look too confusing to the uninitiated to be left as the default.  It feels more like an advance feature like replay editing, that may be better off only invoked on demand for those in the know.  Maybe something as simple as holding Shift key while invoking nuke via any input method.

I should note that I haven't played much custom levels let alone those that require nuke solutions, my experience is heavily biased towards challenge solutions.  In those cases at least, timing the nuke is often just a small part of the overall work needed to plan things out.  Much more effort tends to be spent on things like planning release rate changes, timing certain skill assignments, finding certain key lemmings to divert from the overall stream, etc.  Still, every little bit helps.  Then again, given it literally is no more than rewind-nuke-fastforward, it is already achievable today manually; the convenience of having the sequence carried out with one keystroke is nice but not that essential.

Engine Bugs / Suggestions / Re: [DISC][PLAYER] Remove timer on nuke
« on: June 19, 2020, 10:32:53 pm »
I don't doubt that there are ways to make interesting nuke solutions.  But it's also worth pointing out that if your solution requires nuking in its current timed form, you are then also effectively bringing back the element of timed bombers into the level solution, an element that had been excised in all other contexts in NeoLemmix.

Of course, things like release rates and timed levels can be used in bad ways, but they can also be used in good ways and so ultimately we still keep them around in NeoLemmix.  Perhaps the same goes for the timer in nuking?

NeoLemmix Main / Re: Giving feedback on custom packs
« on: June 19, 2020, 09:57:23 pm »
It seems like there's an unfortunate misunderstanding at play with the recent happenings here.  I've reread Dullstar's review a number of times, and as far as I can tell, the only point made during the review about the sprites specifically, was that neutrals and athletes look exactly the same as regular lemmings when usually they are colored differently, and it is helpful, even vital, to many people to be able to clearly tell which lemming is which kind when they can all appear at the level at the same time.  This is no different from board games like chess and checkers using different colors to depict which player a gamepiece belongs to.  I don't see this as somehow translating to a demand to redesign the current sprites completely.  I do think it's maybe a bit unfortunate that so many sentences were spent during the review on that one problem that is an understandable oversight.

Dullstar did then mention in another topic the possibility of an in-game option that would allow playing levels using the default sprites instead of custom ones.  The primary intention is to deal with cases where the custom sprites present problems for certain players such as difficulty telling the different kinds of lemmings apart.  It was effectively a proposed workaround and not even a particularly agreed-upon one--WillLem quickly suggested two other ways the situation can be handled without such a proposed option.  It'd be like if you got a chess set where all the pieces are one color, and people are talking about the best way in that case and other similar circumstances, to tweak the pieces slightly so that you can actually tell which piece belongs to which player.

I think where things got a bit off-track was when Dullstar also started talking about cases where he worry sprites being designed to be misleading.  But from past context, I believe the intent there is only talking about that possibility in general/in theory, and not meant to be directed specifically at the levels he reviewed earlier.  If anything that was more a reference to WillLem for example, who had actually made a little bit of a splash in the still-recent past of exploring uses of misleading/"unfair" visuals as part of the experience of playing a NeoLemmix level.  For better or worse, some people here gets very worried about misleading visuals being used in level designs (even if in some cases only as a theoretical possibility, rather than having actual examples out there already), and sometimes this kind of concern gets incorporated into the details of various suggestions for improving the NeoLemmix player and/or editor.

I can see how taken all together, the various posts Dullstar made within the same time frame, could unfortunately be not too difficult to get misread as some kind of directed passive-aggressive dig.  But it is not the actual intention I think.  I hope one can look past all this and not become too discouraged by a single person's review, opinions and reactions.

NeoLemmix Main / Re: Giving feedback on custom packs
« on: June 19, 2020, 01:31:16 pm »
I agree it's a fair point especially for those who are new to creating levels, that the feedback should probably be coached in more encouraging tones.  It certainly helps to end on a more positive note if nothing else.

At the same time though, we need to be mindful not to also discourage people from either giving any feedback, or to make them feel like they can't be honest with their feedback.  Balance is important but from what's said so far, it feels like everyone has very different ideas of where that balance actually lies.

The poll is probably a good idea, it's certainly pretty efficient in soliciting quick feedback, as it often takes more effort to write any detail feedback whether good or bad, a poll by comparison is much less work for everyone involved.  Though even with a poll, early results especially may still not always be as positive as one might like, and worse, it's going to outside of any single person's control.  And you also don't get to learn precisely what is working and not working for people--for example if it's "not my cup of tea", which aspects specifically aren't?  The poll won't tell you.

Speaking of art, consider that many visitors strolling through a modern art museum, some are bound to make fun of one or more works they encountered.  This is the flipside to "art is subjective".  Usually the artists aren't too fazed by this though (and in some cases for some works, may even expect this).  I think just as there are ways to improve the dialog on the feedback giver's end, there are also ways on the feedback taker's end to reel in unbalanced feedback.  If you're struggling to find the positives in some feedback, challenge the feedback giver to clarify whether there's anything they do enjoy about the levels, things that they'd like to continue to see.  I'd also encourage everyone to not assume the worst in people or take things too personally.  Language is tricky, written language even more so, and being overly negative can often be unintentional.  Give people benefit of the doubt and talking things out I believe can ultimately help clear things up and reach a better understanding for everyone involved.  And learn to become more comfortable with different views.  In the end even in worst case, it's just one person's feedback no matter what.  Someone may never like fish just because, it doesn't mean fish is bad in general or that you should stop cooking fish for everyone else either.

Engine Bugs / Suggestions / Re: [DISC][PLAYER] Remove timer on nuke
« on: June 19, 2020, 12:10:49 pm »
I think namida's suggestion is not to remove the "assign lemming by lemming" aspect of nuking, only that they explode immediately upon getting bomber instead of after counting down 5 seconds.  So there's still the same delay between the first lemming and the last, but the first lemming explodes (or "oh no") pretty much immediately when nuke is invoked, versus 5 seconds afterwards like today.

It seems like most existing nuke solutions should still work with this change by simply initiating the nuke 5 seconds later.  To be clear it's not 100% equivalent--initiating the nuke also cuts off any yet-to-enter lemmings from entering, and use of cloners on lemmings that are already in countdown is no longer possible.  And possibly a few other details I can't think of right now.  But these sorts of details are not typically used or required in nuke solutions.

That might work assuming we require recoloring support versus fully custom sprites.

Please can you rephrase this, I'm not sure what you mean.

Doesn't NeoLemmix still support the option of explicitly providing different sprites graphics for the different states like athletes and neutrals, instead of only specifying a recoloring scheme?  Or is recoloring the only supported way now to handle athletes and neutrals now?  It's been a while so I no longer remember.

That said, though: there's no way to force the levels themselves to look different according to player preferences

Actually there kind of is one, and you asked for it--the ability to select high resolution vs low resolution graphics.

Terrain affects how the lemmings walk and move, and therefore is very limited in how it can be changed.  Objects have somewhat more flexibility, but are still impacted by the fact that different objects of the same type still often have differently sized trigger areas, and for triggered traps even the number of frames matter as to how exactly they interact with a bunch of lemmings passing by.  The lemmings sprites on the other hand are completely interchangeable without affecting how the level plays out, in that way it's a lot more like music and sound.

EDIT: Also... all a player needs to do to force the default sprites is to open the theme.nxtm file and change LEMMINGS from "whoever_whatever" to "default." So, it currently is possible via this workaround anyway.

That's a fair point and might be good enough solution for the occasional times when this is needed, although it takes a little work to find out which style is being used.  It also means having to repeat this if multiple styles reference the same lemmings sprites.  Perhaps a better way is to overwrite the sprite graphics files themselves with the default ones, fixing it for all styles that refer to the same sprites.

This workaround also makes the defaulting of sprites style- or graphics-specific, which I think is how the proposed option would likely be used--not to force every style to all use the default, but just the few ones that are problematic.  Indeed, if we were to implement an option I would've strongly suggested also making it toggle via hotkey so that you can easily turn it on and off on the fly, so that you only use it when it's needed.

Anyway, considering namida's previous stances on similar options, I anticipate him favoring the workaround than implementing an option.  The disallowing of missing recoloring still sounds good though.

That said, I'm strongly against the idea of anything that bypasses or overrides something a content creator has spent a lot of time working on - particularly the sprites.

And I'm generally reflexively against the idea of limiting user choices.  First of all, it was the content creator's problem that led to this in the first place.  I think it's fair that the player has a way around the problem in the meantime, after all it can take time to fix sprites.  The other alternative is, the player simply doesn't play the affected levels at all!  Talk about bypassing something the content creator spent a lot of time working on!

Keep in mind that once the sprites are fixed, the player is likely to go back to the intended sprites again.

Also, I can't rule out in other cases. maybe the player has personal objections about the sprites and cannot fully enjoy the levels while using them.  It may not be what the content creator intended, but neither is the content creator's intent (hopefully?) to annoy the user or to cause the user to not play the level at all altogether.  In the same way that a player may mute sound and music, I think the content creator needs to be respectful of the user's wishes.

A better solution might be to automatically vet custom spritesets, and only allow those that provide recolourings to be playable in the Player. A simple error message such as "No specified sprite recolourings" would make it so that content creators couldn't even playtest the spriteset until the necessary recolourings had been specified.

That might work assuming we require recoloring support versus fully custom sprites.  It might greatly reduce the need for the proposed option, although there may be other cases where the option is wanted for non-recoloring-related reasons.  In theory there could be recoloring enabled, but the color choices involved are still bad such that you can't really see the effects of recoloring.  So I can still see doing both rather than just one of the two.

Ok, I've had a chance to start looking at the NeoLemmix versions of levels, and finally got a clearer understanding of what's happening.  To summarize, so far where I've looked, NeoLemmix is handling things all as expected.  It's just that sometimes the steel that looks like is completely hidden, actually had tiny bits of exposed pixels, and vice versa.

I'm going to start editing my earlier reply post to account for what the actual differences are as seen in NeoLemmix.  I'll make it clear when I've finished the edits there.  Sorry for the confusion and the apparently unwarranted digs at NeoLemmix regarding steel handling. :XD:

Aside:  can user customize the colors used for clear physics mode?  At least in the editor?  The light gray vs dark gray for terrain vs steel is utterly horrible contrast for spotting the kinds of things Minim is pointing out, so much for "clear".  :XD:  The old Lemmix editor uses blue for steel which wouldn't have this problem.

As for Taxing 21, I can't find what steel you are referring to?  The visible ones forming the walls of the "pit" where the exit lies, I don't see any overlaps with terrain?

It is one of the long pieces on the exit platform overlapping the middle steel block on the left side. Given that access is mostly blocked by the fire's trigger area, leaving as is isn't a bad idea.

I see.  So another case where NeoLemmix doesn't seem to honor no-overwrite when deaiing with steel overlapping with non-steel.  As a matter of principle this should be fixed or worked around.  The steel plate is fully visible and should therefore be functionally steel throughout its entire square area.

I don't remember myself modifying the spike traps. ??? This might be a case of two users downloading different versions of these levels.

You're right, that was an unwarranted assumption.  Anyway, it was the level taken from attachments in the first post of the challenge thread.  I believe you only updated the skillset of each level.  I guess the level itself originally came from the formerly-official set of levels that namida used to maintain but no longer?  Wonder who made the edits then.

@Minim:  can you remind me where you are downloading the NeoLemmix conversion you looked at, so I can check things out for myself?  Also, do you think your post above (and then my reply here) might be better suited moved to Proxima's "NeoLemmix versions of original levels for challenges" topic?

Thanks for the due diligence. :thumbsup: Regarding for the examples you mentioned so far, I've checked the original levels in Lemmix level editor, and would eventually like to see the same NeoLemmix levels you were looking at to compare.  With that in mind, comments so far (w/o seeing the actual NeoLemmix levels):

edit:  in process of updating replies here, now that I've actually had a chance to look at the NeoLemmix levels in question.  Updated sections will be marked [updated].  Sections not yet updated should be disregarded for now, as they may not actually reflect the reality of the NeoLemmix levels in question.  Sorry for the confusion.

Sunsoft 16

[updated]Huh, that's an interesting arrangement, didn't notice the very irregular treatment they've done with the steel.  It's really hard to tell visually whether there's actually a gap in the steel and whether it can be breached with sufficient fencer uses.

Personally I'm leaning towards just having regular, fully square steel blocks there matching the steel areas in the original level (ie. resulting in no breachable gaps).  Admittedly that will kill off the level for new-skills challenge (not involving extreme utilization of nuking).  But I'm not really opposed to the other way either.  I'm now more convinced to change it to regular, fully square steel blocks and not allow the possibility of breaching through that small gap.  It's not possible in the original (since the steel areas fully cover that part of the level), but with the given skills, the gap in NeoLemmix definitely looks exploitable, and at the same time I don't get a strong sense that there was ever any intent for breaching through that area to be a viable solution.

Mayhem 2 "The Boiler Room" is another annoying example. It has steel pixels guarding the exit pillar and inside the blue wall.

[updated] Interesting find!  So apparently, it looks like the level designer used the steel plate graphics to fill up the natural tiny dents in the pillar and the wall in question, so that it's perfectly vertical without dents.  Technically bits of steel plates are exposed through the dents being filled, but the intent is clear, they were never meant to be real steel (and had no steel areas in the original level, obviously).  The rest of steel that's obscured by the pillar/wall graphics remain non-steel as intended.

This needs to be fixed.  Thankfully I believe it's easy enough to do so by replacing the use of steel plates with, say, the gray circle terrain graphic, to perform the same job of filling up those tiny dents.

Fun 24/Mayhem 3 is an unusual one. It has a steel "Tongue" lurking beneath the floating platform near the bottom.

[updated]  Good eye! :thumbsup: It was really hard to spot even in CPM thanks to its poor choice of colors for terrain vs steel. :XD: There is no tongue of any kind in the original because the steel areas actually don't align perfectly with terrain (as is typical, due to the multiples-of-4 technical requirement).  In the original level the entire bottommost row of pixels of the floating pool are terrain (ie. not covered by the steel areas), even though their pixels do all come from the steel plates.

While I agree the "tongue" is really tiny and at a location that's probably not very exploitable, it's really weird to be there and should be fixed.  Given how small it is, I don't believe it'll be hard to get rid of the tongue.

It's also ironically a prime counterexample to the current system's supposed virtue (not that I'm opposed to it, but counterexamples like this needs to be highlighted nonetheless, to illustrate it's not always that simple).  The system presumes that what-you-see-is-what-you-get and therefore more honest.  But I'd wager that no human eyes would've spotted that tiny tongue of apparently exposed steel there without help from CPM.  So for most people what they think they see is not quite actually what they are getting.

Fun 27/Taxing 22: The steel beneath the starting platform is overwritten by slime.

[updated]Thanks to the acid, I'm reasonably sure there is no meaningful exploit of the steel being no longer extending all the way to the bottom.  That said, as a side effect that does open the possibility of exposing the right edge of the acid object via terrain removal, though that's not something you'd naturally do for any typical challenge solutions.

So I can go either way, and laziness suggests leaving it as-is.

Fun 29/Mayhem 9 & Mayhem 28: Steel overlapped diagonally by the pyramid and past the exit platform respectively, but because it's so visually obvious, we should leave these ones.

[updated]Agree, let's leave those as-is, especially for the pyramid in Fun 29/Mayhem 9.

Mayhem 8: Steel bits lurking right above and to the right of the exit platform, but it's a clear path to the exit so.

[updated]Interesting.  Obviously no functional steel areas there in the original level.  The steel are barely visible, and clearly the level designer was merely exploiting the few exposed red pixels of the left/bottom edges of the steel plates, in order to simulate the effect of a red glow of the exit's flames against the gray rocks.

I'd almost go as far as examining whether to try replacing all the steel plates there with other terrain (plus eraser pieces) to end up with the exact same pixels color-wise to get the same visual effect, but without using any steel plates, so that there is no odd-looking functional steel there at all.  That said, the amount of exposed and therefore functional steel is so small, it's unlikely to be exploitable for anything, so probably fine to leave them all in?

Tricky 9/Mayhem 6: Steel overlapped on the left edge.

[updated]That's quite isolated and out of the way.  Seems fine to leave it as-is (so the rocks remove the functional steel where it overlaps), it seems preferable visually, compared to making the entire steel plate be drawn on top of the rocks.

Mayhem 12 & Taxing 21: Left sides particularly.

[updated]I can go either way with Mayhem 12, even visually, since most of the steel in the level (except for the area you noted) are actually drawn fully on top of rocks.  It's another case where the overlapping terrain removing some of the steel doesn't seem very exploitable so leaving as-is seems fine, though it's not so clear in this case whether even visually it matters.

As for Taxing 21, it's really hard to imagine that tiny bit of overlap is intended even visually, it really feels like the level designer forgot to set no-overwrite to the non-steel to keep it behind the steel plate.  I'm inclined to fix it so it doesn't take out any of the steel, just like there's no irregularities in the original level with steel areas.

Mayhem 15/Tricky 10: A few pixels from the left steel block are overlapped, but lemmings can't access this thanks to the fire's trigger area

[updated  Interesting, so apparently the steel plate on the left pillar is misaligned one pixel to the left.  Normally for any other purposes I would move the steel block one over, but for challenge purposes I'm tempted to leave the misalignment as-is so it matches how the level really was in the original.

In the original, the steel area nevertheless still extends past the full width of the pillar.  To preserve that in NeoLemmix while also preserving the misalignment of the steel plate, I'm considering adding a second steel plate there (behind the one that's already there, but in front of the pillar's terrain)

The little bit of terrain that actually ate away a tiny part of the steel plate, that seems like a mistake to me given an almost identical setup is done for the stuff between the middle and right pillars, but in that setup the terrain remains fully behind the steel and does not affect it.  I'd want to fix it.

Taxing 16 & 24: Some of the steel on the ramp is overwritten. Also for 24: The water beneath the chains is off-centre by a pixel to the left.

Tricky 28: Right side "platform"

Sounds like yet more cases of NeoLemmix not respecting no-overwrite with its handling of steel plates overlapping with other terrain.  In the original all the steel plates in question are fully visible and not obscured by any other terrain as far as I can tell.

Fun 21/Mayhem 26

Seems ok and not very exploitable to let the terrain remove some of the functional steel.  I also see some steel-plates-used-as-eraser-pieces which shouldn't be treated as functional steel.

Finally, interestingly in the original level, there is a bare steel area (ie. not overlapping with any actual steel plates) spanning from left of the bridge all the way past the exit).  I believe it's there to (try to) prevent the player from bombing out the terrain resulting in visually exposing the edges of the water object there.  (Although given the original game's poor steel handling, I'm pretty sure you can still set things up to bomb away enough terrain to expose the water object's edges, despite the added steel areas.)  There's no good way to put visual steel plates there to achieve that function in NeoLemmix without adversely affecting the visuals, so I think I'd rather leave it as-is with no steel there in NeoLemmix, even if it means you can, indeed, bomb out terrain and expose the edges of the water object. :-\

Mayhem 18

Taxing 2

Again, a quick glance looks ok to leave things as-is and let terrain remove some of the functional steel.

Tricky 4/Taxing 7

The shape formed by the steel plates is a key visual element, so definitely should leave as-is, once all the mosses are removed so the "ship" isn't so full of cracks. :P

on Taxing 4 the trigger area for the right spikes trap doesn't overlap the wall unlike the one on the left, allowing climbers to climb all the way up. However, there are no climbers in this level anyway so not sure.

Actually, at least looking at the DOS version, the left trap's trigger is still 1 pixel away from the wall, so I think both walls are climbable (except for lack of climbers given to the level).  That said, it does feel like this is begging for a slight adjustment in the traps' positions so their trigger areas do touch the walls.

Looking at the version you created a while back for the "new skills" challenge, it looks like you did fix the positions of the spike traps?  However, I also noticed you replaced the spike traps with the smaller versions.  While that would match the abnormally small trigger areas in DOS version, it should be noted that on SNES (and therefore probably Amiga, though I haven't tested yet), the regular "big" spike traps do have larger trigger areas that are more in line visually with the spikes.  It seems NeoLemmix had also fixed the large spike traps so their trigger areas basically match Amiga versions.  So I'd say we shouldn't replace the spike traps with the "small" versions.  The abnormally small trigger area in DOS is arguably a bug, it's certainly misleading relative to the visuals of the spikes.

Okay so, it didn't take long for this to get out of control - to the point where the SAME person posted three different L1 conversions, simply to reflect the slight differences between three official ports.

Well, I think they also come with music specific to the port.

I have no immediate use of any of them myself and certainly won't be playing most of them anytime soon, but like Proxima said, there seems to be little harm in them existing?  AFAIK they aren't labeled as "official" or anything like that either.

Levels for other engines / Re: [SUPERLEMMINI] Ron Stard's Rodents
« on: June 17, 2020, 10:58:53 am »
(I haven't confirmed it, but it looks like the DOS version's basher check is done either at a lower row of pixels or a bit farther out from the lemming.)

DOS version checks 4 pixels all of which are 6 pixels above ground level (ie. if y is at the pixel of terrain the lemming is standing on top of, then y-6 with smaller y being closer to the top).  The 4 pixels are from x+8 to x+11 where x is at the pixel of terrain the lemming is standing on.  If at least 1 of those 4 pixels are terrain, then the basher continues, otherwise it stops.  Furthermore, this check is only done after odd number of strokes; after an even number of strokes the basher will always continue on regardless of how little terrain is in front.  (This means outside of interruptions due to eg. steel or falling, a basher always bashes an odd number of strokes before stopping.)

I hadn't tested Amiga's mechanics as much, nor do I remember the details off top of my head now.  I'm guessing it checks x+9 to x+12 since the basher stroke in Amiga extends 1 pixel farther out compare to DOS, but I suppose it could also be x+8 to x+11 (which would then effectively be x+9 to x+11 in most cases, since x+8 is part of the removed terrain on Amiga).  I think it's still y-6--that's easy to check, it's exactly how many pixels you need to dig down on flat ground before you can bash without stopping.  I want to say the "skip check on even stroke" also applies but I could be mistaken (Mac is only version I know for sure doesn't skip the check, but it also does y-5 instead of y-6).

General Discussion / Re: WillLem's Blog
« on: June 17, 2020, 07:07:41 am »
It's a pretty broad category anyway, both video game puzzles as well as even traditional non-digital puzzles.  Tetris definitely leans quite heavily on luck and action though, in particular those are the sole elements of the game's difficulty curve.

Engine Bugs / Suggestions / Re: [PROPOSALS][PLAYER] New menu design
« on: June 15, 2020, 07:18:18 pm »
I'm also not sure how well that would work with video capturing software -- my guess is "not very well".

NeoLemmix is currently very difficult to work with video capturing software, unless you run it fullscreen, which just simply isn't my preference. Watch any of my recent LPs - the game screen is always either just a bit too small (on 1x zoom) or just a bit too big (on 2x zoom). I don't think enlarging the menu will have any impact on this either way.

That's probably not what Proxima meant.  I think he's specifically talking about having two different sizes being problematic during video capture, since often the captured video can only be of one frame size throughout.  If NeoLemmix handles the two different sizes by resizing the window, then the capture software will likely capture stuff outside the window when window gets resized to the smaller size.  Even if capturing software doesn't do that, when NeoLemmix window is at the smaller size the capturing software will still likely fill the rest of the frame with black bars so that the video frames' dimensions remain constant throughout.  Conversely, if NeoLemmix resizes the smaller game screens also to match the wider width of the menu screen, that's less problematic for video capture, but may then leave certain screens like the pre-level/post-level screens looking too wide with too much empty space on the side.

It can be tricky to have the same layout look good in both the 16:9 widescreen aspect ratio as well as the 4:3 ratio, both of which are still in common use (though the latter perhaps more with older monitors).  Some PC games actually change their layout based on whether it's widescreen or not.

WillLem's layout looks "weirdly stretched" probably partly because it's wider than even the 16:9 ratio.  If we keep the 400 vertical dimension, the horizontal dimension should be only around 711 to match 16:9.

Pages: [1] 2 3 ... 377