Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[MaXMC]

Hi,

I've searched the forums but haven't found this suggested before.

This should be very easy to implement and very usefull.
The different lists in the game have a hard-coded lenght (Build menu 15 items, Unit list 19 items for example).

I'm running the game at 1280x1024 which gives me 64 rows to play with, Why not make every list 20+(FULLGRID_X-25)/2 So for me that would make my lists 40 rows.
Explanation on how I arrived at -24: Interface border is 2 rows, 1 row for options and 1 row for space between options and top, this is 5 reserved rows, which leaves 20 usable rows in minimum game resolution.

Someone running 80x25 would get 20+(25-24)/2=20  rows on their lists. Once this is done, the game can be played in any resolution and the higher resolution is used for something good.

Examples:
80x25 game = 25 rows = 20 rows on any list
80x50 game = 33 rows
80x64 game (1280x1024) = 40 rows
100x75 game (1600x1200) = 45 rows

Comments? Suggestions?

[Omnibus]

I second this.  It's a great idea.

[chucks]

I like this one, but...

This should be very easy to implement and very usefull.

Never assume that you know how easy or hard a feature will be to develop.  Not lashing out at you, but people outside development teams saying how easy a feature is to code is a huge pet peeve of mine.

[CobaltKobold]

Spoiler: "on easy-to-implement" (click to show/hide)

Maybe. Some features are blessedly easy to put in; this could be as simple as changing one line (per list/menu code. If the build menu is properly code-reused, then it would be one, else, it could be ugly.) I'd say something about the case where your initial menu length is longer than the number of elements, but this case should be handled ust as one can page through build menu to last and it has only a partial page, rather than doing less than a full page-down.

That said, at least the building menus should be sufficiently single-piece to do something to simply, as t heir contents are static-oh wait, magma buildings, I guess not static.

If you weren't able to scroll it singly, I could imagine it being coded for it to be difficult to add these- as "Cpage1, Cpage2" menus being hardcoded somehow.

Others, not so much, thanks to having to populate the list, which could also need modifying to fetch the proper number instead of the current fullpage, depending on how it's presently coded. Stocks list, for instance, clearly doesn't enumerate each sub-type of object until you look at it- see the huge delay when you look at "stone", for instance.

On topic: X is horizontal. I do think that having the lists be so dratted small on one side when you're using 168 columns is silly.

I only count 4 columns reserved potentially- borders, and between main/menu/map. Six if you're including blackspace on either side of menu. For rows, there's no technical reason for a blank line in the menus, it just looks a bit less busy, so currently I think there's only two reserved rows, four  (These, too, technically could be removed, but it'd look muc hworse than removing the blackspace border in menu.)

Spoiler: "On interface tweaks/arc position" (click to show/hide)

Whether we'll get real interface updates that make use of larger grids, I don't know, as they don't actually do much to the game, just change how you use it- this is the reason the interface arc is (fairweather) last, along with that if you change features along the way, you need to tinker with the interface to add them anyway, so you should get something clunky before people think of "Hey, this is what we could use with these features", and do it all at once.