Permalink
Browse files

GS window title: change State to Slot, minor limiter simplification

  • Loading branch information...
1 parent 31813c2 commit abdb8266b66db9d8bb2be7284cc216d6fa004714 @avih avih committed Oct 7, 2015
Showing with 4 additions and 4 deletions.
  1. +4 −4 pcsx2/gui/FrameForGS.cpp
@@ -564,15 +564,15 @@ void GSFrame::OnUpdateTitle( wxTimerEvent& evt )
gsDest[0] = 0; // No need to set whole array to NULL.
GSgetTitleInfo2( gsDest, sizeof(gsDest) );
- const wxChar* limiterStr = L" (Unlimited)";
+ const wxChar* limiterStr = L"-unlimited";
if( g_Conf->EmuOptions.GS.FrameLimitEnable )
{
switch( g_LimiterMode )
{
case Limit_Nominal: limiterStr = L""; break;
- case Limit_Turbo: limiterStr = L" (Turbo)"; break;
- case Limit_Slomo: limiterStr = L" (Slomo)"; break;
+ case Limit_Turbo: limiterStr = L"-turbo"; break;
+ case Limit_Slomo: limiterStr = L"-slowmo"; break;
}
}
@@ -591,7 +591,7 @@ void GSFrame::OnUpdateTitle( wxTimerEvent& evt )
const u64& smode2 = *(u64*)PS2GS_BASE(GS_SMODE2);
- SetTitle( pxsFmt( L"State %d | Speed%ls: %3d%% (%.02f)%ls | %ls-%ls | %s",
+ SetTitle( pxsFmt( L"Slot %d | Speed%ls: %3d%% (%.02f)%ls | %ls-%ls | %s",
States_GetCurrentSlot(),
limiterStr, lround(per), fps,
cpuUsage.c_str(),

51 comments on commit abdb826

@refractionpcsx2
Member

any reason you got rid of the capital on turbo and slomo? looks a little less correct/pretty IMO.

@ssakash
Member
ssakash commented on abdb826 Oct 7, 2015

don't really like the new format compared to the older ones. that parenthesis for Turbo , Unlimited and Slomo suited well :(

I like the change of state -> slot though.

@DisorderIy
Contributor

Wouldn't "Limiter: Off" be better? Saves space, and a "limiter" set to "unlimited" is a bit redundant. Also, yeah, the capitalization should be kept, because it looks messy without it.

@avih
Member
avih commented on abdb826 Oct 7, 2015

any reason you got rid of the capital on turbo and slomo? looks a little less correct/pretty IMO.

It looked weird to me to have two capitalized words one after the other, e.g. Speed-Turbo: ... but I don't feel strongly about it at all, Just let me know if you prefer both capitalized.

don't really like the new format compared to the older ones. that parenthesis for Turbo , Unlimited and Slomo suited well :(

You mean in general? or just the parenthesis thing? If in general, give more details please. Do note that except for the removed UI part, you can get exactly the same information that you had before, just in cleaner, shorter, and hopefully better organized form.

As for the parenthesis, I removed them for two main reasons (other than slightly shorter length):

  • It looks cleaner and less "busy" IMO.
  • Displaying Speed (Turbo): 345% (195.04) might cause people to make an incorrect specific association between Turbo to 195.04. The way I ended up with is less likely to cause people to make this incorrect association IMO.

Wouldn't "Limiter: Off" be better?

Better than what? The current setup is that it's added to the Speed section, so displaying Speed-off: ... doesn't make much sense IMO, but Speed-unlimited: ... explains exactly what the mode is.

I'm 100% open to suggestions to improve it further or revert some of the changes. Just try to be specific with the concerns.

@willkuer
Contributor

The new title bar is much more condensed. I would prefer parentheses for the limiter options but probably a native speaker should decide.

It belongs more to the other commit but as the discussion is here: Why have you changed the order? Is the new order preferable for troubleshooting or for higher end user usability? I guess there was some consideration why and how to change the order...

@avih
Member
avih commented on abdb826 Oct 7, 2015

The new title bar is much more condensed.

So is this better or worse? Also, don't know about "much", spaces were removed in exactly two places:

  • Output mode, e.g. Interlaced (Frame) was changed to frame-i
  • The part where the limiter mode is now adjacent to the Speed word without spaces.

I would prefer parentheses for the limiter options but probably a native speaker should decide.

I noted my reasons for removing the parenthesis, but if most people think other than me, by all means let's return them. (not yet though, let's first make sure most, or at least many people prefer with parenthesis).

Why have you changed the order?

The other commit has the reasons detailed at the commit message:

  • More important items first
  • Easier to look at, less busy to the eye
  • Shorten it. A long line makes it harder to find the info you need.

So the order became:

  • Save state slot is the only thing which people actually need to see. So it goes first.
  • Then most people are interested in how fast it runs, and the limiter mode, if there is one. Hence the speed+limiter is next.
  • The CPU statistics is not very interesting when all runs fine, but if the speed is not sufficient, next they would want to see which part is affecting the speed.
  • The output mode (interlaced etc) is technically really not interesting to users, but I left it there since I want to find an overall combined solution to how we display the output mode and deinterlace mode (if one is required and used).
  • The GSdx info doesn't really have too much interesting info. It basically doesn't change and pretty much stays the way you configured it. It's nice to have though, and that's why it's there.

If you have specific concerns about ordering, or suggestion for other ordering, shoot.

@willkuer
Contributor

I like that it is more condensed and unnecessary letters are removed. I think the titlebar is quite confusing for new users so we probably don't need to avoid to use abbreviations instead of full text as in both cases they won't understand it.

Somehow I oversaw your detailed description of ordering. It mostly makes sense except for the hardware/software mode trigger f9 that can effect gsdx settings. But I guess nobody will die if he has to look to the end to be sure which mode he is currently using.

The savestate function is more like a hack and shouldn't be used that much and is unknown to some new members. So maybe first place in the line disrespects importance of elements but as you said it is the only place where the current state is mentioned. So maybe it is correct as it is. I would rather move savestates to the log console though.

@avih
Member
avih commented on abdb826 Oct 7, 2015

except for the hardware/software mode trigger f9 that can effect gsdx settings. But I guess nobody will die if he has to look to the end to be sure which mode he is currently using.

Agreed on both. Also, currently the HW/SW is part of the "section" which GSdx provides as a single unit - which includes the mode, resolution and deinterlace mode, so for now, I can't move just the HW/SW mode to a different place without moving the entire GSdx "unit".

I would rather move savestates to the log console though.

The slot is already displayed at the console when you change it. So your suggestion is to completely remove it from the title?

@willkuer
Contributor

Yes. But that might be my personal preference. In principle the same is valid for other elements as limiter and deinterlacing mode as well. I have the feeling that quasi static information belongs to the console and not to the title bar where only frequent changing information can be displayed in-place.

I would actually only show the gsdx version (for troubleshooting), fps counter and cpu times for threads in the titlebar and move everything else into the console and preferably show it (not implemented in gsdx) as well as HUD element on the screen on change events. If you like you can have a look into zerogs. Titlebar is quite clean. All quasi-static information is in the console and as HUD element available.

@refractionpcsx2
Member

Going roughly back to the original topic. I think I prefer it with the capital, the small letter looks a bit odd to me as it is essentially the start of the sentence where "Speed" would be the header", they are not directly connected.

As for what it displays I think the headings should be

Unlimited > Max
"" > Capped (or Limited)
then Slowmo and Turbo as they are.

That will keep the amount of space taken up down a little and be descriptive of what mode it is in.

In regards to the save slot, yeh remove it from the title, I don't think people really want it there for when they are using full screen it is useless anyway. What people really want is like ZeroGS where you get a temporary message pop up in the GS window telling you if you are cycling states or saving/loading.

GSdx version isn't much use as it rarely changes, especially during development if people are using GIT builds, just saying "GSdx" at the top is fine. so the way I see the bar it should be

GSdx OGL/HW | 640x480p | Speed: 100 (60.00) | Limit: Capped | EE 100% | GS 100% | VU 100%
GSdx OGL/HW | 640x448i | Speed: 300 (180.00) | Limit: Max | EE 100% | GS 100% | VU 100%

and that's it, nothing else is needed up top.

@avih
Member
avih commented on abdb826 Oct 7, 2015

First of all, 200% agreed that some of the info would be so much nicer as HUD or temporary OSD. Once we have a system for that, I agree we should redo the title bar.

However, for now we don't have HUD or OSD, so let's focus on what we can do with the title as long as that's the case.

In general, I think the guidelines for what we put title are:

  • Stuff which could be useful to have at the title, ordered by importance for most users.
  • But we have a length limitation so we can't put there everything.
  • As long as we still have room left at the title, I don't think we should remove items just because they're not useful to some. If we're running out of room, then remove the items which are least useful to most people.

Specifically for the suggestions:

  • removing save slot: I would miss it a lot at the title. I save/load and switch slots often, and it's much easier to observe at the title IMO. In fullscreen the title is invisible anyway, so it doesn't hurt anyone that it's there. But I'd be fine with moving it back to the end of bar. Also, if other than me no one finds it useful at the title and we're running out of room, sure, let's remove it.
  • The output+deinterlace modes (the output is e.g. Interlaced (Frame) and the deinterlace mode if e.g. bob bff) are highly tied together and also really important when the content is actually interlaced and requires deinterlacing (especially when one has to cycle few deinterlace modes to find a proper one). As I mentioned earlier, I want to combine them in a useful way[*], but since some of the info is at PCSX2 and some of it is at GSdx, I still didn't do that. I do have plans though. For now, I suggest we keep it as is.
  • limiter: restore to its own "section" as before but replace "None" with "Capped", well, I think it's important to know the "mode" only when it's not in "normal" mode. But sure, go ahead and restore it.

[*] A possible approach, for instance, would be to add p or i to the GSdx resolution, and if i then also add the deinterlace mode. E.g. 640x480p or 640x480i (bob bff), since we only care about deinterlace mode only when the content is interlaced, but we don't care when it's progressive.

@refractionpcsx2
Member

A possible approach, for instance, would be to add p or i to the GSdx resolution, and if i then also add the deinterlace mode. E.g. 640x480p or 640x480i (bob bff), since we only care about deinterlace mode only when the content is interlaced, but we don't care when it's progressive.

Yeah I think that's a fair compromise for it, keeps it compact but provides the required info. "auto" may look a bit ambiguous however, so we will need to possibly do something about that.

removing save slot: I would miss it a lot at the title. I save/load and switch slots often, and it's much easier to observe at the title IMO. In fullscreen the title is invisible anyway, so it doesn't hurt anyone that it's there. But I'd be fine with moving it back to the end of bar. Also, if other than me no one finds it useful at the title and we're running out of room, sure, let's remove it.

Is this not a lilypad hack anyway? So it should be toggleable depending on user preference. I'm quite happy to leave it up to the user but not have it forced on.

limiter: restore to its own "section" as before but replace "None" with "Capped", well, I think it's important to know the "mode" only when it's not in "normal" mode. But sure, go ahead and restore it.

Maybe, but showing something is more user friendly than nothing at all. When I mentioned that I didn't think about the possibility that "Limiter:" might not be showing either :P

Stuff which could be useful to have at the title, ordered by importance for most users.

Agreed, I think the 2 most important things are speed followed by resolution, everything else from a user perspective could be negotiable depending on the person. However i feel the importance is Speed > Resolution > Limiter > Renderer (although) i like this being at the start) > Usage Stats.

@avih
Member
avih commented on abdb826 Oct 7, 2015

Is this not a lilypad hack anyway? So it should be toggleable depending on user preference. I'm quite happy to leave it up to the user but not have it forced on.

It was[*] a lilypad hack for many years, but already part of PCSX2 since some years now. The lilypad hack is also buggy since it can't track the slot change when you saved/loaded a different slot via the main menu, or if you reconfigured the KB shortcuts to use anything other than F2/Shift-F2. Also, when the lilypad hack is enabled, it adds (lilypad) to the title such that you know it's buggy.

Maybe, but showing something is more user friendly than nothing at all. When I mentioned that I didn't think about the possibility that "Limiter:" might not be showing either :P

Just play with it, and change it however you think it's best. I promise I won't change it back later without you wanting to :)

I think the 2 most important things are speed followed by resolution

I agree about speed, but even while I personally really like the resolution to be displayed, TBH I don't see the value it brings to most users. But anyway, I didn't remove the resolution. You did in your suggestion/example :)

[*] was, because yesterday also I updated lilypad to disable all the hacks which are useless for PCSX2 (they're still enabled if you use it with a PS1 emulator though). This includes the "save state title" hack, as well as the screensaver hack and the fullscreen exit on escape hack.

@refractionpcsx2
Member

But anyway, I didn't remove the resolution. You did in your suggestion/example :)

No I didn't, in either :)

I agree about speed, but even while I personally really like the resolution to be displayed

I know some people don't care, mainly those who want authentic emulation, but the majority of users like to flex their e-peen by how massive they can make the resolution and show it off (presuming we use the multiplied scaled resolution that is). When in native it's of little concern to the user really, it was more useful from a dev perspective than anything else.

@avih
Member
avih commented on abdb826 Oct 7, 2015

Ah, agreed then :) (did you just edit your example few comments up? or did I actually didn't see the resolution earlier while it was there??!?)

@willkuer
Contributor

At least he added the second line... :P

@refractionpcsx2
Member

I may or may not have edited :P I did it earlier though before your last post, not after just to make you look like a douche xD

[testing by avih]
Just kidding. It was to make you look like a douch!

@avih
Member
avih commented on abdb826 Oct 7, 2015

From now on I'm gonna quote ref on everything :p (though I think ref and I do have permission to edit eachother's comments :p )

I'm a banana

@refractionpcsx2
Member

Yep we do :P

@avih
Member
avih commented on abdb826 Oct 7, 2015

:)

@avih
Member
avih commented on abdb826 Oct 7, 2015

Seeing how much different opinions there are here, I think I'll try to turn it into a template where anyone could set it up in whatever way which suites him. It will take some thinking though, and the GSdx part might still stay for now as its own "unit". But I like this idea.

@refractionpcsx2
Member

That's certainly an option, a bit like MSI Afterburner and such where you can have what sensors you want on :)

@karasuhebi
Contributor

don't really like the new format compared to the older ones. that parenthesis for Turbo , Unlimited and Slomo suited well :(

I like the change of state -> slot though.

This is basically how I feel. The parenthesis used for the limiter states suited them well. Definitely better than a single hyphen with no spaces. I understand why you did it and I sort of agree that users might make an incorrect assumption on correlation but I still like how it looked before with the parenthesis. I 100% agree with the state -> slot change though. That's perfect.

I have the feeling that quasi static information belongs to the console and not to the title bar where only frequent changing information can be displayed in-place.

I basically completely agree with this. Information like the current saved state slot is nice to have in the title bar but the only information that's required up there IMO is constantly changing information like usage and speed. I'm not saying I want to take everything off the title bar, I'm just saying I agree that it doesn't need to be there. If someone (@gregory @gabest11) can figure out a way to have GSdx have an OSD like ZeroGS does, stuff like changing save slots can be shown there temporarily. I think that's actually even better than having it in the title bar since if you're playing in full screen, you can still see it.

I would actually only show the gsdx version (for troubleshooting), fps counter and cpu times for threads in the titlebar and move everything else into the console

So basically just remove the slot number and the frame/field-p/i indicator is what you're saying. That won't save much space.

I'm assuming by "GSdx version" you mean which renderer is being used? Sadly as @avih stated all the GSdx info is dumped in there as one unit so you can't pick and choose what to show and where to put it, at least not yet. It's just "Renderer | Native Resolution | Deinterlacing Mode" and that's it. No choice there. I disagree with what you're suggesting anyway though. GSdx renderer is not the only thing that we need for troubleshooting. Knowing the deinterlacing mode is useful at times as well. If I remember correctly, Jak & Daxter crashes if you have the deinterlacing mode set to anything but 'Off'.

preferably show it as HUD element on the screen on change events. If you like you can have a look into zerogs. Titlebar is quite clean. All quasi-static information is in the console and as HUD element available.

If I understood this correctly, it's basically what I said above. Have all the quasi-static information show up in an OSD. There's not much to show there, just slot changes and maybe deinterlacing mode. That won't clean up the title bar much.

In regards to the save slot, yeh remove it from the title, I don't think people really want it there for when they are using full screen it is useless anyway. What people really want is like ZeroGS where you get a temporary message pop up in the GS window telling you if you are cycling states or saving/loading.

Yep, I agree with this.

First of all, 200% agreed that some of the info would be so much nicer as HUD or temporary OSD. Once we have a system for that, I agree we should redo the title bar.

I agree. Let's keep all the OSD talk for when that glorious day comes when we actually have an OSD implemented into GSdx (hint hint @gabest11). For now let's keep discussing what needs to be moved around or removed from the title bar.

GSdx version isn't much use as it rarely changes, especially during development if people are using GIT builds, just saying "GSdx" at the top is fine. so the way I see the bar it should be

I think @willkuer meant renderers here, not GSdx versions. Not sure though.

If we're running out of room, then remove the items which are least useful to most people.

What does 'running out of room' mean? Are we talking about the default size of the GS window? Because I made my window bigger (and 16:9) a long time ago so I have all the room in the world up there.

removing save slot: I would miss it a lot at the title. I save/load and switch slots often, and it's much easier to observe at the title IMO. In fullscreen the title is invisible anyway, so it doesn't hurt anyone that it's there. But I'd be fine with moving it back to the end of bar. Also, if other than me no one finds it useful at the title and we're running out of room, sure, let's remove it.

I agree. Keep it. I'd even go as far as saying keep it at the beginning.

[*] A possible approach, for instance, would be to add p or i to the GSdx resolution, and if i then also add the deinterlace mode. E.g. 640x480p or 640x480i (bob bff), since we only care about deinterlace mode only when the content is interlaced, but we don't care when it's progressive.

That would be the ideal solution. I completely agree with this. I definitely don't like the way it is now where it shows up as frame-p or field-i. That's not very intuitive IMO. Why do we even need the frame/field thing in the first place? Isn't it always fields for interlaced and always frames for progressive?

"auto" may look a bit ambiguous however, so we will need to possibly do something about that.

We could just add "auto" at the end in parenthesis so people know that the deinterlacing mode was picked automatically. So it would look like 640x480i (bob bff - auto) or 640x480i (bob bff) (auto).

However i feel the importance is Speed > Resolution > Limiter > Renderer (although) i like this being at the start) > Usage Stats.

I think Limiter should be right after speed since they are related. Also I don't think Resolution is that important to the user that it would be before Limiter. It could go either way but IMO Limiter should be next to Speed.

When in native it's of little concern to the user really, it was more useful from a dev perspective than anything else.

Yep, I think it's more of a dev thing. Although I'd argue to leave it unless we really need the space since I did find it really interesting to look at it from time-to-time. I wasn't even aware that games were able to change resolution on the fly until I saw it happen in the title bar.

Seeing how much different opinions there are here, I think I'll try to turn it into a template where anyone could set it up in whatever way which suites him.

Cool idea! I really like it. Although I think you should find away to make sure certain things stay in the title bar no matter what, like the different usage percentages and the renderer being used. That really helps with troubleshooting other people's problems in the forum sometimes.

@avih: If you decide to keep the state of the limiter as part of the Speed section (which I would vote against, I prefer having Limiter by itself) I would change "Unlimited" to "Unbound" since technically the speed is not unlimited, it's unbound. We're not binding your speed to a certain number but it's still being limited by how much your computer can handle. Also "Unbound" is shorter than "Unlimited" :) I might be totally off here though. What do you think? I also like @refractionpcsx2's suggestion of changing it to "Max" though since that is shorter.

@avih
Member
avih commented on abdb826 Oct 8, 2015

Knock yourselves out ;)

This keeps the title identical to what it was before, but the new template system can be used to address all the concerns which were raised here. The gsdx info and the cpu usage are still each a single unit (and the UI part is still only visible in devel/debug builds), but other than those, all the text, values, ordering, capitalizations, etc are fully configurable.

@refractionpcsx2 I assign you to coordinate the template's default values at AppConfig.cpp and push whatever you think most people would like ;)

The rest, you can now make a contest of the prettiest title of them all :)

@karasuhebi
Contributor

Yay! Thanks @avih! That's awesome. :) Now I get to (almost) have the title bar I want!

Now if we can get @gabest or @gregory38 to split the info GSdx sends to PCSX2 for the title bar, that would be great. I'd like to be able to do things like remove the "GSdx" text from the title bar (seems redundant. We only need the renderer being used) and things like displaying the output mode (p or i) next to the resolution. I'd also like for GSdx to not say "Auto" but actually show which deinterlacing mode its using. Who knows if GSdx's method of picking deinterlacing modes is even good! :P

The gsdx info and the cpu usage are still each a single unit (and the UI part is still only visible in devel/debug builds), but other than those, all the text, values, ordering, capitalizations, etc are fully configurable.

Does that mean they stay in the title bar no matter what? :D

@avih
Member
avih commented on abdb826 Oct 8, 2015

Does that mean they stay in the title bar no matter what? :D

No, if you don't want to, just don't put ${cpuusage} or ${gsdx} at TitleTemplate.

@karasuhebi
Contributor

Well it's not that I don't want them there, it's that I want them to ALWAYS be there. And it's not really for me, it's more just to make sure end-users don't remove them. Both of those are useful pieces of information when troubleshooting problems on the forums.

@avih
Member
avih commented on abdb826 Oct 8, 2015

things like displaying the output mode (p or i) next to the resolution

I said earlier that I have plans for it. Patience.

@avih
Member
avih commented on abdb826 Oct 8, 2015

OMG, my system is soooooooooooo fast!

State 0 | Speed-unlimited: 1000000% (500000.01) | EE: 43% | GS: 4% | frame-i | GSdx D3D11 HW | 640x512 | None

@refractionpcsx2
Member

Nice speedz! with room to spare! :P

@willkuer
Contributor

Uh.. thats actually a problem. The titlebar is now no reliable troubleshooting information. If people download 'perfect settings emulation hack ultimate speed'-inis from the web that are just changing the mask to a fake one it could be problematic.. People would believe they have all the time constant full speed...

@avih
Member
avih commented on abdb826 Oct 8, 2015

We'll cross that bridge when we come to it. And yes, it was a joke, but also to demonstrate a point.

@avih
Member
avih commented on abdb826 Oct 8, 2015

People would believe they have all the time constant full speed...

Also, why would these people need to troubleshoot anything if they believe it runs at full speed? It's the ultimate placebo :)

@refractionpcsx2
Member

Also, why would these people need to troubleshoot anything if they believe it runs at full speed? It's the ultimate placebo :)

When it doesn't feel like full speed :P Usually cos they have both the speedhack sliders on Max lol

@avih
Member
avih commented on abdb826 Oct 8, 2015

Usually cos they have both the speedhack sliders on Max

Well, we've warned them it might cause fake fps... so there's some faking for you right there :)

@Sarania
Contributor
Sarania commented on abdb826 Oct 8, 2015

Configurable. Very nice.

Yeah I'm sure somebody will figure out a way to cause problems with it, but then they always do, don't they? If we left every feature out that could cause problems we wouldn't have any features at all

@karasuhebi
Contributor

If we left every feature out that could cause problems we wouldn't have any features at all

Yeah but we could at least try to avoid potential hurdles. For example what I said above about locking certain elements in the title bar so they're always present. I believe it's quite helpful to always know which renderer an end-user is using and what their resource usage is.

But since all of this is .ini-only at the moment and isn't being shown to the end-users in the GUI, I think we're fine for now. The point @willkuer brought up does concern me though. There's always going to be those people who distribute their own "super awesome builds" and shit like that. -_-

@avih
Member
avih commented on abdb826 Oct 8, 2015

Guys, let's not make it a bigger problem that it is (not). At any time anyone could recompile PCSX2 and put whatever at the titlebar, or add whatever spyware and call it the ultimate version etc, as with every other open source project. We only made it configurable to users who want to tweak the INI. Reckless people who distribute stupid packages would still be reckless even without our help. So if you're only concerned with people who distribute pcsx2 but can't/won't compile it themselves, well.. let's wait for this day to come before we start worrying.

@Sarania
Contributor
Sarania commented on abdb826 Oct 8, 2015

I agree with avih (if I didn't make it clear above)

@avih
Member
avih commented on abdb826 Oct 12, 2015

GSdx OGL/HW | 640x480p | Speed: 100 (60.00) | Limit: Capped | EE 100% | GS 100% | VU 100%
GSdx OGL/HW | 640x448i | Speed: 300 (180.00) | Limit: Max | EE 100% | GS 100% | VU 100%

and that's it, nothing else is needed up top.

So..

@refractionpcsx2 I assign you to coordinate the template's default values at AppConfig.cpp and push whatever you think most people would like ;)

@refractionpcsx2 ?

@refractionpcsx2
Member

Sorry, haven't got around to it yet :P I'll try and remember to do it tonight

Did we come to an agreement on if the Saveslot should be up there as well or not?

@refractionpcsx2
Member

OK what do people think of this?

gsdxtitle

Since the UI seems to eat CPU these days (not sure when that happened, I'm pretty sure that's a bug) I'm going to leave UI in release builds turned on until that's sorted.

Edit: NVM, it's disabled in release anyway.

@avih
Member
avih commented on abdb826 Oct 12, 2015

Hmm.. I like that the CPU usage is at the end.

As for interlaced, I'm guessing that's ${omodei} right? if yes, on its own it's not enough to really indicate that the content is interlaced. See this comment of mine, basically only Interlaced (frame) is actually interlaced from the games which I tested. Specifically for instance, GOW2 and SoTC have Interlaced (field) but as far as I can tell are not actually interlaced.

That being said, I'm not really sure how much it would matter for users, and I can still add ${omodef} on my local setup and I still plan to handle it better in GSdx, so overall, no objection here.

@avih
Member
avih commented on abdb826 Oct 12, 2015

Since the UI seems to eat CPU these days (not sure when that happened, I'm pretty sure that's a bug)

Interesting. I didn't notice it. So maybe leave it on for now, also in release builds?

@refractionpcsx2
Member

I'm just testing if it does it in release builds from my code or if it is only dev versions that do it as recent builds on the buildbot (before it was removed) seem okay.

@refractionpcsx2
Member

As for interlaced, I'm guessing that's ${omodei} right? if yes, on its own it's not enough to really indicate that the content is interlaced. See this comment of mine, basically only Interlaced (frame) is actually interlaced from the games which I tested. Specifically for instance, GOW2 and SoTC have Interlaced (field) but as far as I can tell are not actually interlaced.

This is true, but most people have no concept of frame or field, but most games are frame or field interlaced modes. Maybe we could just lie and say it's progressive? :P

@avih
Member
avih commented on abdb826 Oct 12, 2015

Maybe we could just lie and say it's progressive? :P

That's my plan for GSdx when I'll add it as i or p to the resolution :)

@refractionpcsx2
Member

wxString omodef = (smode2 & 2) ? templates.OutputFrame : templates.OutputField;
wxString omodei = ((smode2 & 1) && !(smode2 & 2)) ? templates.OutputInterlaced : templates.OutputProgressive;

Problem solved! :p

In other news, UI usage is about 20% or so in release builds, so something has happened since build 1229

@avih
Member
avih commented on abdb826 Oct 12, 2015

You cheater you :) maybe add another "combined" mode as ${omodec} and use only this one at the default template? It could take the textual values from templates.OutputInterlaced and templates.OutputProgressive so it wouldn't require more textual definitions.

@refractionpcsx2
Member

Well this would work, isn't much cleaner tho :P

wxString omodec = ((smode2 & 3) == 1) ? templates.OutputProgressive : omodei;

@refractionpcsx2
Member

I think I've found the UI problem, It's as plain as the nose on my face. It's not reporting the UI usage at all, notice it's direct relation to the EE usage?

Edit: Fixed anyway

Please sign in to comment.