Light wrote:Well, it's open source. You could always offer it up.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.
[FEATURE REQUEST] List Scrollbar
Re: [FEATURE REQUEST] List Scrollbar
Re: [FEATURE REQUEST] List Scrollbar
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.
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?
@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.
^ 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.Jonathan wrote:I figured that's what Durf thought.
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:Ideally the developers would be able to implement everything you want exactly how you wanted it (with options for people who want different).
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.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).
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?
Re: [FEATURE REQUEST] List Scrollbar
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 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.
Re: [FEATURE REQUEST] List Scrollbar
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.Light wrote: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 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.
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).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.
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
Overall I'm down for any additions, but sometimes you gotta compromise if you actually want results.Durf wrote:... such that the dev won't see it as a waste of their time
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):
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.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?
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?)
Re: [FEATURE REQUEST] List Scrollbar
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.
- Lucifer
- Project Developer
- Posts: 8640
- Joined: Sun Aug 15, 2004 3:32 pm
- Location: Republic of Texas
- Contact:
Re: [FEATURE REQUEST] List Scrollbar
I want the window to resize, and I also want the scrollbar.Light wrote: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 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.
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.
- Jonathan
- A Brave Victim
- Posts: 3391
- Joined: Thu Feb 03, 2005 12:50 am
- Location: Not really lurking anymore
Re: [FEATURE REQUEST] List Scrollbar
FOV? Seriously? Stop babbling.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).
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
Re: [FEATURE REQUEST] List Scrollbar
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.
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.
Re: [FEATURE REQUEST] List Scrollbar
@Johnathan: I'm sorry you had difficulty understanding. Perhaps you're a visual learner:
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).
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).
- Jonathan
- A Brave Victim
- Posts: 3391
- Joined: Thu Feb 03, 2005 12:50 am
- Location: Not really lurking anymore
Re: [FEATURE REQUEST] List Scrollbar
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.
*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
- Lucifer
- Project Developer
- Posts: 8640
- Joined: Sun Aug 15, 2004 3:32 pm
- Location: Republic of Texas
- Contact:
Re: [FEATURE REQUEST] List Scrollbar
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.
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.
- Tank Program
- Forum & Project Admin, PhD
- Posts: 6711
- Joined: Thu Dec 18, 2003 7:03 pm
Re: [FEATURE REQUEST] List Scrollbar
Code: Select all
src/render/rViewport.cpp:65, rViewport::Perspective(REAL fov,REAL nnear,REAL ffar,REAL xshift)
- Lucifer
- Project Developer
- Posts: 8640
- Joined: Sun Aug 15, 2004 3:32 pm
- Location: Republic of Texas
- Contact:
Re: [FEATURE REQUEST] List Scrollbar
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.
In opengl, theoretically all we have to do is force a redraw.
Re: [FEATURE REQUEST] List Scrollbar
it does it pretty well too, but 0.4 looks nicer on a 16:9 screenDurf 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.