I never want to be aggressive, offensive or ironic with my posts. If you find something offending in my posts, read them again searching for a different mood there. If you still see something bad with them, please ask me infos. I can be wrong at times, but I never want to upset anyone.

Hello everyone.I tried to make a test to see how much the "player overlay" thing would have slowed down rendering. To my surprise, it seems to allow even faster rendering! Maybe there is some problem with the way I did the test?I recorded two demos with many bots (and no forcemodel) with dmflags 2048: one spectating to see all players at once (to simulate the "worse scenery"), and one playing (to simulate a more common scenery).Then I used "DO NOT LINK[/b]) h t t p s : / / openarena . wikia . com/wiki/Timedemo]timedemo 1" and then played the demos, looking at the console result at the end. Then I removed the required shaders test pk3 from baseoa and played the same timedemos again. Then I copied the files to another pc and ran the same timedemos also there.

Note: every time I run the timedemo, the result framerate isn't perfectly identical, it may vary by a fraction of fps to a couple of fps... but the difference between "overlay" and "without" is bigger than the simple test-by-test-variation.

The only explaination I can think is the feature being implemented in a way that, even if it doesn't find the required shader, it still does most of the computing related to it (e.g. creating an invisible shell of polygons around the character). If that's the case, then I don't know how to make proper performance tests with it...

Sago, Fromhell... what do you think about this stuff?

« Last Edit: November 10, 2016, 03:23:01 am by Gig »

Logged

I never want to be aggressive, offensive or ironic with my posts. If you find something offending in my posts, read them again searching for a different mood there. If you still see something bad with them, please ask me infos. I can be wrong at times, but I never want to upset anyone.

I never want to be aggressive, offensive or ironic with my posts. If you find something offending in my posts, read them again searching for a different mood there. If you still see something bad with them, please ask me infos. I can be wrong at times, but I never want to upset anyone.

I did another try to make some benchmarking about player overlays feature.This time, results do have more sense (the feature somewhat slows down rendering, it seems), but the limits of the test do not allow to simulate "real" usage...

This time I did do the test with the overlay shader pk3 installed the whole time.I loaded a map having dmflags 2048, set cg_thirperson 1, and recorded a short demo showing only myself, standing still.Then I stopped recording, set dmflags 0 (overlay immediately disappeared) and started recording again, still standing still, without touching anything else.

Then I set timedemo 1 and played back the two demos (still setting cg_thirdperson 1 before launching playback).

Here's the results:High end pcfirst demo: player overlays 759.2 fpssecond demo: without player overlay 793.1 fps

But here there are the limits of this test:- They are not the same exact demo. They should be extremely similar, as I was alone and I did not move at all, but they are not actually the same one. As a further test, I recorded three similar "stand still for a few seconds" demos without changing settings and I played them: they had a change of less than 10 fps each other on the high-end pc. So I can guess the larger fps change in the "overlay/without" demos should be related with the dmflags value change.- I was completely alone. So, it cannot really be representative of the framerate change during actual gameplay. One might expect something like a 6 % more slowdown for each additional player rendered? E.g. if you have one player, enabling the feature slows down by around 6%; if you have 5 players, enabling the feature slows down by around 30%? I suppose things could be more complicated than this (e.g. players are just a part of the rendering).- Player models differ, so I can guess that also their "shells" polycount would differ.

« Last Edit: November 16, 2016, 03:12:36 am by Gig »

Logged

I never want to be aggressive, offensive or ironic with my posts. If you find something offending in my posts, read them again searching for a different mood there. If you still see something bad with them, please ask me infos. I can be wrong at times, but I never want to upset anyone.

I modified the test trying to make it a little more representative.This time, I did it in TDM mode, added four bots to my team, and ordered them to "camp here".They do stand still, although they look around...So, I did take a first demo with dmflags 2048 and then a second demo with dmflags 0...

High end pcplayer overlays 277.3without player overlay 310.7

Low end pcoverlay 79.7without player overlay 94.8

So...x= 277.3 * 100 / 310.7x= 89,25100 - 89,25 = 10,75 % slowdown.

x = 79.7 * 100 / 94.8x= 84,07100 - 84,07 = 15,93 % slowdown

Not as bad as feared...

It's possible that during the test some items which were previously taken by the bots respawned, hence making the framerate of the initial part of the test somewhat faster than the second part!

So, I did another test (same number of bots, although some were not the same models), this time making more time pass before starting recording, and recording without overlays first, then enabling them:

high end pc295 against 267 fpsx= 90.50100 - 90.50= 9.5 % slowdown

low end pc91 fps against 75 fpsx= 82.41100 - 82.41 = 17.59 % slowdown

Results seem to be quite similar to the previous ones...It can be noticed that low-end hardware seems to be more affected than high-end hardware, in percentage...

« Last Edit: November 16, 2016, 04:58:41 am by Gig »

Logged

I never want to be aggressive, offensive or ironic with my posts. If you find something offending in my posts, read them again searching for a different mood there. If you still see something bad with them, please ask me infos. I can be wrong at times, but I never want to upset anyone.

Hello, I'm here again.I know I may become boring, however I did another test. It's just like the previous one, but this time with 20 characters (me + 19 bots camping).... this should give a better idea about real use performances.

Considering this happens with 20 characters in the map, IMHO it's acceptable (hey, we are applying to 20 characters some effects which where thought for being applied to one or two characters at the same time). Don't you think so?

« Last Edit: November 17, 2016, 03:41:38 am by Gig »

Logged

I never want to be aggressive, offensive or ironic with my posts. If you find something offending in my posts, read them again searching for a different mood there. If you still see something bad with them, please ask me infos. I can be wrong at times, but I never want to upset anyone.

well imho it's unacceptableThat's a LOT of cpu being churned out to make two whole teams of players appear red/blue

I do wonder if there may be a different way to apply a such thing, consuming less CPU.... I don't know if it may be possible to apply a shader to change the "tint" of models to make them more blue-ish/red-ish by acting directly on the skin, without having to create a shell of poygons around the model. It would much probably be possible to force a generic colored shader in the place of all shaders/texutres used by the model (similarily for the missing texture placeholders)... but I can guess the result may be uglier than this one.

Quote

I think having maps designed for balanced light levels and decent team skins (NOT brightskins) would do a better more efficient job and that's what i'm having in mind in oa3's design

Third party models (not very used online, I guess) and third party maps (which may be very used also online), which simply are out of our control, would still be an issue...Of course, including maps and models with better visibility with the game is a good thing anyway!

Quote

(also FYI the latest OA engine does have a speedup for bulge deformvertxees adapted from Jedi Outcast, which would be involved with this effect)

This sounds interesting. I might do a comparison with OA 0.8.8 binaries and latest nightly builds binaries, then. Is some setting needed to enable the speedup?

« Last Edit: November 17, 2016, 11:53:07 am by Gig »

Logged

I never want to be aggressive, offensive or ironic with my posts. If you find something offending in my posts, read them again searching for a different mood there. If you still see something bad with them, please ask me infos. I can be wrong at times, but I never want to upset anyone.

Played the same two demos using current engine nightly build (2016-11-16).

high end pcno overlay 140overlay 119x=85100-85=15% slowdown

low end pc: I got more or less the same results that I had with the old binaries... maybe 1 more fps...

It looks like new binaries have got a somewhat better framerate on high end pc....no overlay 128:140=100:x, x=109,38 (9,38% faster with latest binaries)overlay 109:119=100:x, x= 109,17 (9,17% faster with latest binaries)...

Logged

I never want to be aggressive, offensive or ironic with my posts. If you find something offending in my posts, read them again searching for a different mood there. If you still see something bad with them, please ask me infos. I can be wrong at times, but I never want to upset anyone.

However, to give some more infos about this stuff (known as "iconographic"), here's the link with the discussion about it on github:https://github.com/OpenArena/gamecode/issues/8(which ALSO talks about a different matter, optionally disabling kills output to console)

Also people without a github account are invited to express their opinions here on the forum, of course.

I also propose a cvar to control the feature... e.g.0) iconographic kills, separed from chat/warnings (default?)1) text kills, separed from chat/warnings2) text kills, together with chat/warnings (aka classic behavior)3) iconographic kills, together with chat/warnings (maybe not really necessary, however mentioned here in case one wants to cover all possible cases)(Options numbers are just an example.)

PS: what are those "entity used itself" warnings in the first screenshot? :-/

« Last Edit: November 23, 2016, 02:10:49 am by Gig »

Logged

I never want to be aggressive, offensive or ironic with my posts. If you find something offending in my posts, read them again searching for a different mood there. If you still see something bad with them, please ask me infos. I can be wrong at times, but I never want to upset anyone.

II also propose a cvar to control the feature... e.g.0) iconographic kills, separed from chat/warnings (default?)1) text kills, separed from chat/warnings2) text kills, together with chat/warnings (aka classic behavior)3) iconographic kills, together with chat/warnings (maybe not really necessary, however mentioned here in case one wants to cover all possible cases)(Options numbers are just an example.)

The missing options are when someone wants to disable HUD or both HUD and console output. It may go something like this:0) no message1) console (old style)2) text + console 3) icons4) icons + console

Either 3) or 4) would be default.

However, if both the new HUD and console message is shown, we'd have to disable con_notify, so that the message doesn't appear twice on screen. That's a problem since con_notify (the top left screen section) displays other messages, e.g. flag captures.

I'd create separate HUD parts (so they can use icons) for other messages as well, and use con_notify for warnings only in debug mode.

For the four options I supposed in my previous post, I was just referring to the HUD obituary (a single variable for controlling having the obituary in the same "box" of the other notifications -classic way- or in a distinct box -modern way-, AND for controlling having the obituary shown as text only -classic way- or as iconographic -modern way-).

I was not referring to disabling obituary output to console (I thought about it as a different topic, worth of a distinct CVAR to control it. Of course, the console obituary variable should only be "on/off", as the console cannot be splitted and should not contain icons), and I was not thinking about a "no obituary output on HUD at all" because I just did not think about it (also I don't know if that would be useful, however as an additional option it should not be harmful to players).

I tried giving a look to the code, but that part is too complicated to me, due to my ignorance of C. Could you please have some patience with me and try to explain me again what do the various values do the way you implemented it at the moment?

« Last Edit: November 21, 2016, 07:18:27 am by Gig »

Logged

I never want to be aggressive, offensive or ironic with my posts. If you find something offending in my posts, read them again searching for a different mood there. If you still see something bad with them, please ask me infos. I can be wrong at times, but I never want to upset anyone.

cg_obituaryOutput 0 - old style, output only to console (and the top left screen which is console notification)cg_obituaryOutput 1 - text output to lower left, no output to consolecg_obituaryOutput 2 - icon output to lower left, no output to consolecg_obituaryOutput [other values] - no output, should this be an option?

If I leave the console output with 1 and 2, it would just show a duplicate message on screen (top left and lower left), that is, without messing with con_drawnotify or changing con_notifytime..

If text is too fast to keep track of, there is an alternative of having a variable to increase fade time and/or increase the number of lines that display the frag output on the HUD.

Thank you, I think I got the situation now.So, there is the big problem that you cannot write text to console output without also showing it in the upper left corner, unless modifying some low level fuction, right?

Are we sure it's really so hard/risky? Id software really did not foresee a level of "priority" (or a show/hide flag) for a message/warning to be shown in console only and not in the upper left? As example, those tons of text which are shown in console after an initialization (e.g. snd_restart, in_restart), are not shown to the end user only because he sees the map loading screen (instead of the game and its hud) during such initializations?

The combination which is not possible is really the one which should have been the better one...Maybe it may be made a try to check how the result would feel with the "repeated" infos in the hud? Both text in upper left+icons in lower left. Just to test...

PS: changing topic a little.I know I should have said this earlier. Forgive me.This is just a question (I repeat: a question)...Text obituary works this way (X dies, Y attacks):X got Y's rocket (normal kill)X cratered (normal suicide)

Or should it have been this way instead?X <rocket icon> Y (normal kill)X <skull icon> (normal suicide)

I ask this just to use the same logic (x killed by y) for both text and iconographic, to be more intuitive. But I haven't played recent games, so maybe "Y <rocket icon> X" is more "standard" for nowadays players. I'm just asking.

Gg from cell phone (please forgive errors).

Logged

I never want to be aggressive, offensive or ironic with my posts. If you find something offending in my posts, read them again searching for a different mood there. If you still see something bad with them, please ask me infos. I can be wrong at times, but I never want to upset anyone.

Can there be a top-right iconograph obituary? That's where Half-Life (and derivatives) put it, with a 4 line obituary buffer, bumping down the FPS counter/clock/speedometer

In cgame/cg_draw function CG_DrawFragMessage( void ) i have (x, y) variables that set the coordinates, so it could be anywhere on the screen.I set the fade time (which can also be modified) to 7 seconds, the number of seconds to display a single frag message.And in cgame/cg_local.h, FRAGMSG_MAX controls the number of lines shown.

I'd have to look into the right text alignment, especially for top right text output (cg_obituaryOutput 1).

The function may be CG_DrawFragMessage(x, y, fade, msg_max), so that these four parameters could be controlled from ui files and changed to your liking.I haven't yet looked into it.

Are we sure it's really so hard/risky? Id software really did not foresee a level of "priority" (or a show/hide flag) for a message/warning to be shown in console only and not in the upper left? As example, those tons of text which are shown in console after an initialization (e.g. snd_restart, in_restart), are not shown to the end user only because he sees the map loading screen (instead of the game and its hud) during such initializations?

The combination which is not possible is really the one which should have been the better one...Maybe it may be made a try to check how the result would feel with the "repeated" infos in the hud? Both text in upper left+icons in lower left. Just to test...

I can understand that historically all output, both warnings, info, and message relevant to the client were all displayed on the same output. This makes sense.I took one part of what is relevant to the client and took it elsewhere. There are still other messages (player entered the game, flag dropped, etc.).

My idea is that any info relevant to the client should be coded/displayed separately, and controlled from the ui files,and the top left corner is unnecessary and should be used only to display warnings in debug mode, maybe not even that.

You'd have to ask sago007 about how hard/risky it is. I do understand this may be hard to program without breaking the compatibility with older versions.

PS: changing topic a little.I know I should have said this earlier. Forgive me.This is just a question (I repeat: a question)...Text obituary works this way (X dies, Y attacks):X got Y's rocket (normal kill)X cratered (normal suicide)

Or should it have been this way instead?X <rocket icon> Y (normal kill)X <skull icon> (normal suicide)

I ask this just to use the same logic (x killed by y) for both text and iconographic, to be more intuitive. But I haven't played recent games, so maybe "Y <rocket icon> X" is more "standard" for nowadays players. I'm just asking.

Each of us has a different opinion on these things. Maybe we should make a poll out of our player base. I just got here a few weeks ago. I don't want to sound patronizing, but you need some way to settle/agree/have a plan on this thing.

It is not that it is risky as in it can break something. However it increases the coupling between engine and gamecode. That violates the "low in coupling and high in cohesion" principle and makes the code more expensive to maintain. I simply don't think it is worth the price.

If you couple the engine and gamecode to allow a non-critical function then you are on your way to a messy code base.

It is not that it is risky as in it can break something. However it increases the coupling between engine and gamecode. That violates the "low in coupling and high in cohesion" principle and makes the code more expensive to maintain. I simply don't think it is worth the price.

If you couple the engine and gamecode to allow a non-critical function then you are on your way to a messy code base.

So the upper left is just a plain "console output" feedback... One may theoretically foresee some kind of flag to set certain messages as "hidden" in the upper left (which may then be used also for other things, not only obituaries), but that would rely on updated OA3 engine, and would not work (=showing those messages anyway, I guess) with older versions of the engine or with binaries from other ioquake3 branches...And that would be against good programming practices... like the reason it's not possible to show the correct name of the next gametype when a new match is going to start (in case the gametype has been modified), because gamecode does not know about the future value of a "latched" variable and making an exception to pass it to gamecode in this specific case would be making things more complicated and specific-engine-dependent.

I can understand that historically all output, both warnings, info, and message relevant to the client were all displayed on the same output. This makes sense.I took one part of what is relevant to the client and took it elsewhere. There are still other messages (player entered the game, flag dropped, etc.).

My idea is that any info relevant to the client should be coded/displayed separately, and controlled from the ui files,and the top left corner is unnecessary and should be used only to display warnings in debug mode, maybe not even that.

Reading this, my first reaction, as an old times q3a gamer, was "Whaaaaatttt? Why changing something which worked for 17 years?"Then, I thought that it may be a "real" solution to the issue: completely replacing the upper left info area (from just a replica of the last few lines of the console) with a new "info box" (or series of "n" boxes) where the gamecode purposedly writes stuff. That would allow gamecode developers to fine-tune what has to be printed to console and what has to be printed to screen, without making big changes to the engine part. If one decides to follow a such path, the passage from OA 0.x to OA 3.x, with its UI overhaul, would be the best moment to do it (as if to say "now"?).On the other hand, I fear that may mean a lot of work: someone should check the whole gamecode to find out all the text output generated by it[1], and modify the code around every single message to set it as "send to console only/send to infobox n only/send to console + infobox n". A lot of work.There may also be a problem if there are some messages generated by the engine which we may want printed on the HUD for some reason, after the current upper left area is gone: if we don't want to modify the engine for this stuff, I fear such cases (if any) cannot be managed.E.g.: now you may theoretically bind a CVAR name to a button, and the upper left area would tell you its current value (and its "latched" one, if any) every time you press the button. Try binding "g_gametype" or "name" to a key. I suppose that's the engine which does it.... after the changes, I fear that would not work anymore...

So, I ask... is this really worth it? One may just think "if it's not broken, don't fix it"...Iconographic obituary is nice, but I don't like having to renounce to having kills list in console history for it... I lived many years without iconographic and I can continue...PS: I still would like to try a test with the "double output" obituary (iconographic in lower left+text in upper left), just to see how it feels...

[1]Of course, things like "score table", "team overlay box", "health and armor meter" etc. are some kind of "output", too... but they are not related with this stuff at all! I mean to search for the output which currently goes to console.

« Last Edit: November 22, 2016, 05:11:12 am by Gig »

Logged

I never want to be aggressive, offensive or ironic with my posts. If you find something offending in my posts, read them again searching for a different mood there. If you still see something bad with them, please ask me infos. I can be wrong at times, but I never want to upset anyone.

[Reading this, my first reaction, as an old times q3a gamer, was "Whaaaaatttt? Why changing something which worked for 17 years?"Then, I thought that it may be a "real" solution to the issue: completely replacing the upper left info area (from just a replica of the last few lines of the console) with a new "info box" (or series of "n" boxes) where the gamecode purposedly writes stuff. That would allow gamecode developers to fine-tune what has to be printed to console and what has to be printed to screen, without making big changes to the engine part. If one decides to follow a such path, the passage from OA 0.x to OA 3.x, with its UI overhaul, would be the best moment to do it (as if to say "now"?).

It worked for 17 years? Hm..., I don't see this display in modern games. As I've said, my first game would also look like that, having a simple text and just output every bit of info there.Separating that output into multiple boxes would allow for more customization, of fonts, icons, placement on HUD, etc., than just a simple print on screen.

On the other hand, I fear that may mean a lot of work: someone should check the whole gamecode to find out all the text output generated by it[1], and modify the code around every single message to set it as "send to console only/send to infobox n only/send to console + infobox n". A lot of work.There may also be a problem if there are some messages generated by the engine which we may want printed on the HUD for some reason, after the current upper left area is gone: if we don't want to modify the engine for this stuff, I fear such cases (if any) cannot be managed.E.g.: now you may theoretically bind a CVAR name to a button, and the upper left area would tell you its current value (and its "latched" one, if any) every time you press the button. Try binding "g_gametype" or "name" to a key. I suppose that's the engine which does it.... after the changes, I fear that would not work anymore...

So, I ask... is this really worth it? One may just think "if it's not broken, don't fix it"...Iconographic obituary is nice, but I don't like having to renounce to having kills list in console history for it... I lived many years without iconographic and I can continue...PS: I still would like to try a test with the "double output" obituary (iconographic in lower left+text in upper left), just to see how it feels...

[1]Of course, things like "score table", "team overlay box", "health and armor meter" etc. are some kind of "output", too... but they are not related with this stuff at all! I mean to search for the output which currently goes to console.

Perhaps you misunderstood, my intention was never to disable the console output. I only suggested that for the frag messages since they tend to be spammy.That was my original idea in the first place. And right now if they are not disabled in console, they are just printed twice on the screen, which looks ugly to me.If the upper left notification, "the console output feedback" was disabled completely, we could return back the console frag messages (or to satisfy my idea, make a toggle variable cg_obituariesToConsole).

To reiterate, my idea is to disable "the console output feedback", not to disable console output, not to add bunch of code to engine to separate what goes into "the console output feedback" and what does not.

Having infos, warnings, and whatnot, all in the left corner, I doubt you had time to read them all with only a few lines displayed at the time. You'd probably have to look into the console anyway to see if you missed something.

PS: It would require a lot of work, to display all info that the player needs/wants to see on the HUD.