[FEATURE REQUEST] List Scrollbar

What do you want to see in Armagetron soon? Any new feature ideas? Let's ponder these ground breaking ideas...
User avatar
takburger
Match Winner
Posts: 600
Joined: Tue Jun 04, 2013 9:34 pm

Re: [FEATURE REQUEST] List Scrollbar

Post by takburger »

Light wrote:
Jonathan wrote:OpenGL itself has no such limitations, if you allow the default framebuffer to change. I know for a fact it's trivial on OS X. You can not only resize the view but also move the context to a different one. Adjust your viewport and move on. There's really no reason that can't happen. But a lot of code doesn't want to deal with it.
Well, it's open source. You could always offer it up.
Image
Durf
Match Winner
Posts: 426
Joined: Mon Jul 30, 2012 10:35 pm

Re: [FEATURE REQUEST] List Scrollbar

Post by Durf »

Split thread?
@ConVicT: Probably should have started a new thread for a new feature. Last thing we need is an unorganized thread full of ideas the devs will have to search through (they won't).

The reason why dynamic (or live) resizing has not been added is probably due to the old ways things used to be done (tron is an old game after all).
Specifically, it's what compguygene mentioned: the virtual "camera" that allows you to see in the 3d environment needs to know how to display what it sees and this is done with the aspect ratio and FOV. The FOV would have to change as the aspect ratio changes or else your view will stretch (FOV depends on aspect ratio, therefore, depends on resolution). Given the speed of today's computers, I don't see why this would be a problem to add in; a newer library might help in cutting out a lot of the work creating this feature (it probably has something built in to handle that), but isn't necessary (I don't think). For something like WebGL, it's mostly built in and I don't have to deal with that nonsense (example: my 3d map previewer, you can resize the window and it will automatically adjust - a new library has modern features).



. . . . .



This topic is about the scrollbar feature.
Jonathan wrote:I figured that's what Durf thought.
Durf wrote:Ideally the developers would be able to implement everything you want exactly how you wanted it (with options for people who want different).
Not too many options. It's the Achilles heel of FLOSS projects. Give everyone little tweaks that don't do much; be unable to choose a good direction and implement it well.
Durf wrote:Realistically, any feature request is appraised and based on it's value it will be allocated a certain amount of the developers' time.
What I was suggesting appeals to efficiency; low cost to the developers while still maintaining the functionality requested (sort of).
Reserve a little bit of space and draw two quads there. Maybe some small infrastructural changes. I don't know how the server browser works, but it's possible it'd be even easier.
^ I'm not sure what you're getting at. You also said earlier "typical programmer's solution" to my earlier post; I never claimed to be a programmer. My responses were made with the thought that we'd be asking someone else to spend their free time on something we (you) want. Beggars can't be choosers; either contribute to the source yourself or come up with realistic options such that the dev won't see it as a waste of their time.

That being said, can we get a dev to post in here regarding the actual topic of this thread? Is it worthwhile to add into 0.4? Numbers or (clickable?) scrollbar?
User avatar
Light
Reverse Outside Corner Grinder
Posts: 1667
Joined: Thu Oct 20, 2011 2:11 pm

Re: [FEATURE REQUEST] List Scrollbar

Post by Light »

Durf wrote:My responses were made with the thought that we'd be asking someone else to spend their free time on something we (you) want. Beggars can't be choosers; either contribute to the source yourself or come up with realistic options such that the dev won't see it as a waste of their time.
It's actually not unrealistic. It's not something that's gonna take a whole lot of work to do, or at least shouldn't. It would also be a much cleaner look than throwing a list of hundreds of numbers up there.
Durf
Match Winner
Posts: 426
Joined: Mon Jul 30, 2012 10:35 pm

Re: [FEATURE REQUEST] List Scrollbar

Post by Durf »

Light wrote:
Durf wrote:My responses were made with the thought that we'd be asking someone else to spend their free time on something we (you) want. Beggars can't be choosers; either contribute to the source yourself or come up with realistic options such that the dev won't see it as a waste of their time.
It's actually not unrealistic. It's not something that's gonna take a whole lot of work to do, or at least shouldn't. It would also be a much cleaner look than throwing a list of hundreds of numbers up there.
I didn't mean to imply that it would be a whole lot of work (in general). When I was saying "realistically", it was in reference to the fact that we're asking someone else to spend their time on something they might not even want themselves. Not referencing the possibility of such a feature.
Durf wrote:Realistically, any feature request is appraised and based on it's value it will be allocated a certain amount of the developers' time.
I agree, it would be cleaner than hundreds of numbers (but the master list barely has 100 servers if that many at all, so my example of 89 is more accurate IMO).
However, I know for a fact that numbers would be an easier option. It's outputting the list of servers anyway, so for each server put a number and increase value of that number.
I'm not against a scrollbar (even clickable), I was just offering something else that does the same thing (sort of) with a much lower cost (time and effort).
I'm actually down for a clickable scrollbar; thing is, if you're going to make a UI change like that, why not others? Why not change the entire UI to be clickable?
It would open the doors for a lot more; but realistically, I'm not so sure the developers are down for such changes.

I'm sure everyone would do everything they can for the game they love (ideally); realistically, not everyone can spend all their time to make the game just how you might want it (pay me money and I would).

There are already some kind of red arrows that show if there are servers listed off screen (can scroll in that direction). So the feature is already partly there..
Either version of this feature is very realistic (very possible); I was just weighing out the options (considering that those requesting features aren't the ones adding in those features). The important bit is
Durf wrote:... such that the dev won't see it as a waste of their time
Overall I'm down for any additions, but sometimes you gotta compromise if you actually want results.
I'm not bashing on a clickable scrollbar option, but I'm presenting these as options for a dev (working on 0.4) to see and consider. It's not like the numbers suggestion is all that bad anyway (it's no scrollbar, I agree it's not pretty, but it gets the job done - function before fashion).
The public requests a feature but it's the dev that has to spend time to work on it - as much as we (players) would like to see things added in, it comes down to the hours available of the dev's spare time. We can't manage their time for them; they decide to work on a feature for the public (how nice of them) which means they are the ones to appraise a feature's worth. If a clickable scroll bar is worth it, then by all means, ditch the numbers idea.

The main reason why I want a dev to post in here is to determine the value (get down to business already):
Durf wrote:That being said, can we get a dev to post in here regarding the actual topic of this thread? Is it worthwhile to add into 0.4? Numbers or (clickable?) scrollbar?
I'll say again: I'm down for a clickable scrollbar (or any addition really). What I'm asking is for an active developer's input on the realization of the implementation of this feature.
More specifically, I was avoiding a flat-out "no" to the feature request by offering a cheaper option. If not "yes" then at least there's this compromise that might satisfy both the users who want to know how far down the list they are, as well as the dev working on it.

@Lucifer, what are your thoughts on the feature request? A scrollbar seems easy enough to add in, but clickable too? Sure it's possible, but is it worth it given the time you're willing to put in (if any) to make this happen? What value do you put on this feature request? (there may be things of more value worth working on first, so I guess what I'm asking is for some clarity on the decision regarding this request - will this be added in?)
User avatar
Light
Reverse Outside Corner Grinder
Posts: 1667
Joined: Thu Oct 20, 2011 2:11 pm

Re: [FEATURE REQUEST] List Scrollbar

Post by Light »

I don't want a clickable scrollbar. Just a visual reference to where you are on the list. I think changing over to a mouse navigated UI is a waste of time personally.
User avatar
Lucifer
Project Developer
Posts: 8640
Joined: Sun Aug 15, 2004 3:32 pm
Location: Republic of Texas
Contact:

Re: [FEATURE REQUEST] List Scrollbar

Post by Lucifer »

Light wrote:
Durf wrote:My responses were made with the thought that we'd be asking someone else to spend their free time on something we (you) want. Beggars can't be choosers; either contribute to the source yourself or come up with realistic options such that the dev won't see it as a waste of their time.
It's actually not unrealistic. It's not something that's gonna take a whole lot of work to do, or at least shouldn't. It would also be a much cleaner look than throwing a list of hundreds of numbers up there.
I want the window to resize, and I also want the scrollbar. ;)

If anybody wants to take a crack at it, try to put it in all menus. One thing that annoys me about the menus is that I don't know how long they are, and I can't easily tell (for the longer ones) when I've wrapped back to the beginning. I'm pretty sure the server browser and the menu base are different classes, so this would have to be implemented twice.

Otherwise, I don't see a reason not to have it, but there is no way you'll be able to interact with it directly.

On a slightly different note: @Light: Ultimately we'll need a clickable UI, but that's a level of rewrite that isn't in the cards right now. I did start the work, though, by creating an EventPump class (or something like that). Assuming the time's there to start in on the 0.5 series after 0.4 gets a release, that'll probably be the first thing I work on. But we'll see, I'm still working on the buildbot, heh.
Image

Be the devil's own, Lucifer's my name.
- Iron Maiden
User avatar
Jonathan
A Brave Victim
Posts: 3391
Joined: Thu Feb 03, 2005 12:50 am
Location: Not really lurking anymore

Re: [FEATURE REQUEST] List Scrollbar

Post by Jonathan »

Durf wrote:The reason why dynamic (or live) resizing has not been added is probably due to the old ways things used to be done (tron is an old game after all).
Specifically, it's what compguygene mentioned: the virtual "camera" that allows you to see in the 3d environment needs to know how to display what it sees and this is done with the aspect ratio and FOV. The FOV would have to change as the aspect ratio changes or else your view will stretch (FOV depends on aspect ratio, therefore, depends on resolution). Given the speed of today's computers, I don't see why this would be a problem to add in; a newer library might help in cutting out a lot of the work creating this feature (it probably has something built in to handle that), but isn't necessary (I don't think). For something like WebGL, it's mostly built in and I don't have to deal with that nonsense (example: my 3d map previewer, you can resize the window and it will automatically adjust - a new library has modern features).
FOV? Seriously? Stop babbling.

I was never too familiar with the menu system, server browser, or video system. It's been a long time since I saw Armagetron and SDL at all. It wouldn't be very efficient to dive in now without the intent to continue working on it. What I can do easily is spread my knowledge. It costs little of my time, and even less of others'. Where it works to supplement their knowledge it saves time.

Do we have any spare mirror neurons?
ˌɑrməˈɡɛˌtrɑn
User avatar
Z-Man
God & Project Admin
Posts: 11585
Joined: Sun Jan 23, 2005 6:01 pm
Location: Cologne
Contact:

Re: [FEATURE REQUEST] List Scrollbar

Post by Z-Man »

It would totally not be hard to implement dynamic resizing. It's not harder than the regular window size change we already allow, and we also already allow custom window sizes.
But: It would still be video mode changes as reaction to events. We still get occasional reports of similar tasks causing various forms of trouble: alt-tabbing, minimizing, switching window/fullscreen mode. And they're mostly totally out of our control, just the OS or driver reacting weirdly to perfectly normal instructions. I'd be careful not to introduce another source.

The server list is essentially just a regular menu with the title row hacked in. Add a fake scrollbar to the regular menus and you get one for the server list.
Durf
Match Winner
Posts: 426
Joined: Mon Jul 30, 2012 10:35 pm

Re: [FEATURE REQUEST] List Scrollbar

Post by Durf »

@Johnathan: I'm sorry you had difficulty understanding. Perhaps you're a visual learner:
Image
In this case the "eye" is the virtual camera.
As you can see, resizing the window (changing the aspect ratio) requires a change in the FOV, or else the image will stretch to fit.
If the aspect ratio remains the same, then you don't need to change either FOV since it is just scaling the image larger.

You can see this "stretch" effect on a monitor with a more modern ratio (like 16:9) and with an old cient (0.2.3.8.2); simply choose a resolution then switch to fullscreen mode.
What happens is the image will play like it's 4:3 but stretch to fit into the 16:9 ratio. Basically what Z-Man mentioned.

I mentioned in my posts that it may not be necessary to deal with any of this anyway - idk how sdl2 is or what the status of 0.4 is regarding resolutions (I know it's better than 0.2). Overall, the underlying issue with dynamic resizing is having to reset the FOV each time the aspect ratio changes; and I wouldn't be surprised if a new library was able to handle that for you. In case it's not, I can help explain some of the more subtle details if need be (I'm sure the devs have this covered) since I've had to deal with this exact issue before.




@Z-Man: I personally have not done anything with the source code. Point me in the right direction and I will add the scrollbar (scrollbars you can't click on should be super easy).
User avatar
Jonathan
A Brave Victim
Posts: 3391
Joined: Thu Feb 03, 2005 12:50 am
Location: Not really lurking anymore

Re: [FEATURE REQUEST] List Scrollbar

Post by Jonathan »

Do you sink in quicksand? I know all about the FOV. There is absolutely no problem there.* Z-Man didn't say anything about it, either. I'm done.

*It would be better to move the far plane a few quanta beyond infinity.

Last words: I gather SDL can resize if you pass it a certain flag, but must recreate the context every time. It may not be horrible with so little to load by modern standards, but it's just immoral to do it during live resizing.
ˌɑrməˈɡɛˌtrɑn
User avatar
Lucifer
Project Developer
Posts: 8640
Joined: Sun Aug 15, 2004 3:32 pm
Location: Republic of Texas
Contact:

Re: [FEATURE REQUEST] List Scrollbar

Post by Lucifer »

Someone asking the same question:
https://forums.libsdl.org/viewtopic.php ... d192ff7524

The documentation linked that describes the event:
http://wiki.libsdl.org/SDL_WindowEvent

Doesn't look too bad. The real issue I'm seeing is there's no begin/end pair of events, which would make it easy to simply blacken the screen during a resize and enable us to only make one single context reset.

@Durf: None of that matters, iirc. The video card handles all of that. ;)
Image

Be the devil's own, Lucifer's my name.
- Iron Maiden
User avatar
Tank Program
Forum & Project Admin, PhD
Posts: 6711
Joined: Thu Dec 18, 2003 7:03 pm

Re: [FEATURE REQUEST] List Scrollbar

Post by Tank Program »

Code: Select all

src/render/rViewport.cpp:65, rViewport::Perspective(REAL fov,REAL nnear,REAL ffar,REAL xshift)
I'm fairly certain that aspect ratio is taken into account. I don't think a dynamic resize is too bad to handle. I think I've done it before with SDL as well.
Image
User avatar
Lucifer
Project Developer
Posts: 8640
Joined: Sun Aug 15, 2004 3:32 pm
Location: Republic of Texas
Contact:

Re: [FEATURE REQUEST] List Scrollbar

Post by Lucifer »

In pygame, using rasterized graphics, i had to make every object that drew aware of the window resolution. So i had to, in the resize event handler, update that information and force a redraw.

In opengl, theoretically all we have to do is force a redraw.
Image

Be the devil's own, Lucifer's my name.
- Iron Maiden
User avatar
aP|Nelg
Match Winner
Posts: 621
Joined: Wed Oct 22, 2014 10:22 pm
Contact:

Re: [FEATURE REQUEST] List Scrollbar

Post by aP|Nelg »

Durf wrote: You can see this "stretch" effect on a monitor with a more modern ratio (like 16:9) and with an old cient (0.2.3.8.2); simply choose a resolution then switch to fullscreen mode.
What happens is the image will play like it's 4:3 but stretch to fit into the 16:9 ratio. Basically what Z-Man mentioned.
it does it pretty well too, but 0.4 looks nicer on a 16:9 screen
Post Reply