Pages: 1 ... 15 16 [17] 18 19
  Print  
Author Topic: Open Arena Expanded Beta 50  (Read 282739 times)
Gig
In the year 3000
***

Cakes 48
Posts: 4246


WWW
« Reply #400 on: November 07, 2016, 12:37:58 pm »

Thank Sago, your explanation is very appreciated!  Smiley

Ps: So, you can't store a double precision float in a cvar, right?
« Last Edit: November 07, 2016, 12:40:51 pm 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.
Gig
In the year 3000
***

Cakes 48
Posts: 4246


WWW
« Reply #401 on: November 10, 2016, 03:11:42 am »

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!  Huh
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 "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.

Here there are the results:
First demo (spectating in wrackdm17, with 16 bots):
High end PC: 126.6 fps (overlay) - 111.1 (without the pk3)
Low end PC (lower resolution): 33.4 fps (overlay) - 29.4 (without the pk3)

Second demo (actually playing in mlca1, with 16 bots):
High end pc: 222.8 (overlay) - 200.2 (without the pk3)
Low end PC (lower resolution): 69.1 fps (overlay) - 64.5 (without the pk3)

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.
Gig
In the year 3000
***

Cakes 48
Posts: 4246


WWW
« Reply #402 on: November 10, 2016, 03:13:54 am »

WRONG POST, PLEASE DELETE THIS.
Thanks.

(Read the one above, instead).
« Last Edit: November 10, 2016, 03:18:04 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.
sago007
Posts a lot
*

Cakes 61
Posts: 1651


Open Arena Developer


WWW
« Reply #403 on: November 10, 2016, 12:43:57 pm »

Sago, Fromhell... what do you think about this stuff?
It might be the missing shaders that are making it slow.

Ps: So, you can't store a double precision float in a cvar, right?
You could convert it to and from string manually but it would be very inefficient. There are better options.
Logged

There are nothing offending in my posts.
Gig
In the year 3000
***

Cakes 48
Posts: 4246


WWW
« Reply #404 on: November 16, 2016, 02:48:00 am »

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 pc
first demo: player overlays 759.2 fps
second demo: without player overlay 793.1 fps

Low end pc
first demo: overlay 254.8 fps
second demo: without player overlay 272.2 fps

This time, it looks like the feature actually slowed down rendering a little.
So, trying to get some percentages:
759.2:793.1=x:100
x= (759.2 * 100) / 793.1
x= 94,84
100 - 94,84 = 5,16 % slowdown

254.8:272.2=x:100
x= (254.8 * 100) / 272.2
x= 93.60
100 - 93.60 = 6,48 % slowdown

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.
Gig
In the year 3000
***

Cakes 48
Posts: 4246


WWW
« Reply #405 on: November 16, 2016, 03:21:21 am »

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 pc
player overlays 277.3
without player overlay 310.7

Low end pc
overlay 79.7
without player overlay 94.8

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

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

Not as bad as feared...  Smiley

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 pc
295 against 267 fps
x= 90.50
100 - 90.50= 9.5 % slowdown

low end pc
91 fps against 75 fps
x= 82.41
100 - 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.
Gig
In the year 3000
***

Cakes 48
Posts: 4246


WWW
« Reply #406 on: November 17, 2016, 02:36:50 am »

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.

high end pc
no overlay 128 fps
overlay 110 fps
x=85,94
100-85,94=14,06 % slowdown


low end pc
no overlay 34.6 fps
overlay 26.5 fps
x=75.59
100-76,59=23,41 % slowdown

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.
fromhell
Administrator
GET A LIFE!
**********

Cakes 31
Posts: 14480



WWW
« Reply #407 on: November 17, 2016, 10:26:50 am »

well imho it's unacceptable

That's a LOT of cpu being churned out to make two whole teams of players appear red/blue


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

(also FYI the latest OA engine does have a speedup for bulge deformvertxees adapted from Jedi Outcast, which would be involved with this effect)
« Last Edit: November 17, 2016, 10:32:55 am by fromhell » Logged

asking when OA3 will be done won't get OA3 done.
Progress of OA3 currently occurs behind closed doors alone

I do not provide technical support either.

new code development on github
Gig
In the year 3000
***

Cakes 48
Posts: 4246


WWW
« Reply #408 on: November 17, 2016, 10:46:55 am »

well imho it's unacceptable
That'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.
Gig
In the year 3000
***

Cakes 48
Posts: 4246


WWW
« Reply #409 on: November 17, 2016, 11:20:45 am »

(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 morning's test (0.8.8 binaries)
20 characters

high end pc
no overlay 128 fps
overlay 110 fps
x=85,94
100-85,94=14,06 % slowdown

low end pc
no overlay 34.6 fps
overlay 26.5 fps
x=75.59
100-76,59=23,41 % slowdown

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

high end pc
no overlay 140
overlay 119
x=85
100-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.
1pixel
Nub


Cakes 2
Posts: 18


« Reply #410 on: November 19, 2016, 12:47:24 pm »

I still don't know how get UI3 fonts into Linux build, that will take me some time to figure out.

The screenshots for frag (obituary) messages.

The last one with the skulls is when the attacker is known, I don't know how much sense it has in that form, i.e. will people understand what it's about.

We could also add another icon for the skull, gray/white, and maybe different icon for the last image case, something like Gig suggested,
if you all agreed on doing this.
« Last Edit: November 19, 2016, 12:53:41 pm by 1pixel » Logged
sago007
Posts a lot
*

Cakes 61
Posts: 1651


Open Arena Developer


WWW
« Reply #411 on: November 19, 2016, 01:14:12 pm »

I prefer the last one. If the player is killed by another player the attackers name should be there even if it was not a direct kill.
This also matches how the messages are printed in 0.8.8
Logged

There are nothing offending in my posts.
Gig
In the year 3000
***

Cakes 48
Posts: 4246


WWW
« Reply #412 on: November 19, 2016, 04:00:26 pm »

I don't see why "x skull y" may be difficult to understand...

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/warnings
2) 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.
1pixel
Nub


Cakes 2
Posts: 18


« Reply #413 on: November 19, 2016, 04:35:11 pm »

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

I think it has something to do with a small map, lots of players/bots and too little spawns.
Not related to my changes, as it happens without them, but I didn't look into the problem itself.
Logged
1pixel
Nub


Cakes 2
Posts: 18


« Reply #414 on: November 20, 2016, 09:49:06 am »

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/warnings
2) 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 message
1) console (old style)
2) text + console
3) icons
4) 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.
« Last Edit: November 20, 2016, 03:42:00 pm by 1pixel » Logged
sago007
Posts a lot
*

Cakes 61
Posts: 1651


Open Arena Developer


WWW
« Reply #415 on: November 20, 2016, 11:23:59 am »

0) no message
1) console
2) text + console (classic)
3) icons
4) icons + console
I think 3 should be default.
1 should not be an option. Do not mess with com_notify for this.
Printing to console implies that the text is written.
Logged

There are nothing offending in my posts.
1pixel
Nub


Cakes 2
Posts: 18


« Reply #416 on: November 20, 2016, 03:41:26 pm »

0) no message
1) console
2) text + console (classic)
3) icons
4) icons + console
I think 3 should be default.
1 should not be an option. Do not mess with com_notify for this.
Printing to console implies that the text is written.

My mistake, 1) is actually the classic/old style. There seems to be a lot of confusion. I'll make a pull request.so you can look into the code.
Logged
Gig
In the year 3000
***

Cakes 48
Posts: 4246


WWW
« Reply #417 on: November 21, 2016, 02:49:16 am »

I'm sorry guys, I got lost with this stuff.

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.
1pixel
Nub


Cakes 2
Posts: 18


« Reply #418 on: November 21, 2016, 09:03:25 am »

So far it goes like this:

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 console
cg_obituaryOutput 2 - icon output to lower left, no output to console
cg_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.
Logged
fromhell
Administrator
GET A LIFE!
**********

Cakes 31
Posts: 14480



WWW
« Reply #419 on: November 21, 2016, 11:11:17 am »

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
Logged

asking when OA3 will be done won't get OA3 done.
Progress of OA3 currently occurs behind closed doors alone

I do not provide technical support either.

new code development on github
Gig
In the year 3000
***

Cakes 48
Posts: 4246


WWW
« Reply #420 on: November 21, 2016, 11:11:54 am »

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)

Iconographic obituary works this way:
Y <rocket icon> X (normal kill)
<skull icon> X (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.
1pixel
Nub


Cakes 2
Posts: 18


« Reply #421 on: November 21, 2016, 01:18:14 pm »

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.

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?

As fromhell pointed out to me, this output is coded in openarena/engine (so the part about low level function trap function is deprecated info Smiley).

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)

Iconographic obituary works this way:
Y <rocket icon> X (normal kill)
<skull icon> X (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. Grin
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.
Logged
sago007
Posts a lot
*

Cakes 61
Posts: 1651


Open Arena Developer


WWW
« Reply #422 on: November 21, 2016, 02:31:14 pm »

Quote
You'd have to ask sago007 about how hard/risky it is.
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.
Logged

There are nothing offending in my posts.
Gig
In the year 3000
***

Cakes 48
Posts: 4246


WWW
« Reply #423 on: November 22, 2016, 04:57:44 am »

Quote
You'd have to ask sago007 about how hard/risky it is.
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? Huh 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.
1pixel
Nub


Cakes 2
Posts: 18


« Reply #424 on: November 22, 2016, 11:03:38 am »

[Reading this, my first reaction, as an old times q3a gamer, was "Whaaaaatttt? Huh 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.
Logged
Pages: 1 ... 15 16 [17] 18 19
  Print  
 
Jump to: