hyperion
-
Posts
894 -
Joined
-
Last visited
-
Days Won
2
Posts posted by hyperion
-
-
erm
ERROR: Failed to link program 'shaders/glsl/model_common.vs'+'shaders/glsl/model_common.fs': error: fragment shader varying v_normal not written by vertex shader
... and both shaders have white space errors added
-
2 hours ago, DanW58 said:
"as is u", I think u and v are in fact unit-vectors, and are so in my revised code, namely CFixedUnitVector2D<WORLD>.
going by the calculation of the scalar of Multiply() it's safe to assume length of u being 1. So u being a unit vector is in all likelihood true. Thou there is no v in your excerpt.
2 hours ago, DanW58 said:"Multiply is a scalar multiplication denoting...", 100% agreed, but it's not what I see in the code.
radius of structure + gap + radius of unit, how is this not adjusting length of u (assumed to be 1) to the distance between centre of building and spawn point?
3 hours ago, DanW58 said:"Rotate is a matrix multiplication...", well, there is no matrix multiplication going on in that line of code I showed, though I agree 100% that rotation of a vector can be achieved by matrix multiplication. It can also be achieved by quaternion multiplication, but that takes more code.
In vector math a rotation is a matrix multiplication. How it's implemented is not that important. In the special case of 3 dimensions quaternions can be used for simpler representation, different performance characteristics and being less susceptible to rounding issues. More or less code is really not relevant. In case of 2 dimensions even cleaner than quaternions is using complex in polar form, ie. multiply with e^(i*scalar_in_radians). The expression in Rotate() having PI there suggest it evaluates to scalar_in_radians which is sufficient to describe a rotation.
4 hours ago, DanW58 said:"pos += u is the translation of pos..", EXACTLY. I think that pos is initially initialized to initialPos which my current theory says is the center of the spawning building, and that this line of code takes us from there to the exact place in the periphery where the next spawn will happen. If all of this is correct, my confusion could be due to the comment on the line of code being about a rotation of a vector about to be added TO the center of the building, not a rotation of the center of the building itself...
yes, u is being rotated, u' being scaled and pos translated by u''. pos should be the centre of the building and pos' the spawn point of the unit. The comment suggest that there was some partitioning of the full circle happening before and how unwinding is done here, with some gibberish around it. At least that's how I read it.
-
3 hours ago, DanW58 said:
A position is NOT a vector, mathematically. A position is a position whether there is a frame of reference or not, whereas a vector is a position relative to another position, possibly an "origin", in a specific frame of reference. The confusion is more than just semantics.
A vector is a tool which can be used to describe a position, speed, impulse, force, spin, translation and whatever else I haven't mentioned. There is no position without a frame of reference. You use the term point when in fact you mean position, location (less formal) and to a lesser extent cartesian coordinate.
4 hours ago, DanW58 said:A vector can be added to a position to obtain another position
Two vectors can be added to describe the translation of a position.
4 hours ago, DanW58 said:A vector can be divided in half
Multiplying a vector with a scalar is still a vector.
As for your question, without checking the code:
pos is a vector as is u, Rotate is a matrix multiplication denoted by a scalar for the the normal vector, Multiply is a scalar multiplication denoting the scaling of the vector. pos += u is the translation of pos (denoting a position, likely the center of the structure spawning the unit) by u'.
Yes, the comment is sub par.
-
On 27/01/2021 at 8:55 PM, Stan` said:On 27/01/2021 at 8:14 PM, hyperion said:
Option to disable rendering of corpses and projectiles on the ground. Not rendering possibly thousands of objects likely helps quite a lot.
Was done. But apparently it costs too much performance doing that see https://code.wildfiregames.com/D2936
An option to removing projectiles immediately and removing corpses as soon as the falling to ground animation is played is sufficient. Some people are even willing to disable shadows which is far worse from my point of view. This is fine as a brute force method, perfectly fine to ignore the I want to see exactly 362 corpses and no more crowd. Though removing the thousands of pebbles no one sees in large scale slinger battles might make sense for everyone.
On 27/01/2021 at 8:55 PM, Stan` said:On 27/01/2021 at 8:14 PM, hyperion said:Use of vulkan instead of opengl.
Too many users would not be able to play the game anymore...
It might or might not be early for requiring vulkan. However it would anyway take a year or two before 0ad would have migrated even if you started right now. If someone was willing to take up this task I'd suggest you welcome it whether ifdefed, runtime switchable or straight transition. This is a game about ancient warfare and not ancient hardware.
Also there is quite a bit of work that can be done towards vulkan while still using opengl.
On 27/01/2021 at 9:55 PM, wraitii said:Quote- One I don't like to see personally. Let units have no obstruction so the pathfinder has it easy.
Unit pushing (D1440) does something like that in a saner manner, but it needs a lot more work to be mergeable.
Nice idea, though the units gathering in the video look hilarious.
-
Some ideas:
- Option to disable rendering of corpses and projectiles on the ground. Not rendering possibly thousands of objects likely helps quite a lot.
- Render very low poly replacements at a certain distance. A thousand tris for something the size of a few pixels is not worth it.
- Option to allow rendering at lower resolution and then scale up. Probably rather useful for 4k users.
- Use of vulkan instead of opengl.
- Decouple observers, if they can't keep up it's their problem alone.
- Possibly move some components to C++ to increase execution speed and to reduce interaction between native code and interpreter. The latter probably is a major bottleneck in 0ad. Sure this reduces the ease of modding to some extent.
- One I don't like to see personally. Let units have no obstruction so the pathfinder has it easy.
-
2 hours ago, wraitii said:
Well, you would rather obviously see if they've got new fancy armour or not
Ha, let's introduce a tech "armour polish", faking increased stats.
-
1
-
-
2 hours ago, wowgetoffyourcellphone said:
I actually wonder why a player should be able to see this kind of information about their enemies.
Yeah, good point. Maybe make it part of the bribe mechanic to get this info.
-
1
-
-
11 hours ago, wraitii said:
I draw inspiration from other games, because I haven't really done the research, and they have, and for example Age of Empires 3, for its Definitive Edition, removed the 'click to see stats' interface and just put them on the unit directly: https://static.ageofempires.com/aoe/wp-content/uploads/2020/10/Definitive_100_Musketeer-2048x1152.jpg
If the stats in this screenshot fully represent the unit, then the underlying model is simpler than 0ad. In that case it sure is nice to get away without click to see stats. I just think displaying half truths is worse than click to see. What we can also see here the gui is optimized for 16:9 FullHD.
-
1
-
-
1 hour ago, wraitii said:
One problem is that our minimum supported resolution is 1024 × 768, which doesn't really leave much more room. The UI is already big at those scales. I am considering moving the commands to another panel for wider screens, e.g. maybe to the right of the buildings, where you don't risk misclicking them so much.
I think they should remain (possibly optionally) visible though, because beginners won't necessarily know about them.The right panel is currently 10x4 icons and could be changed to auto collapse if not enough space to 4x1 each of the 4 opening a submenu - preselect, build, research, train. Not saying this is the best solution but at least the room argument would no longer work.
I fully agree with you that the preselect actions should be available via gui by default in some way.
About the resolution of 1024 × 768, the last time I bought one of those monitors was in the 90'. Rather than absolute pixel one should consider screen format a primary concern and have properly working scaling in place.
1 hour ago, wraitii said:Yes, but there is debate regarding what a "key number" is and isn't. I think we could also make it an option. My approach above is a trade-off, it shows _something_ instead of nothing (Armour in particular is important, because HP really isn't the end of the story).
Armour are currently 5 values - hack, pierce, crush, fire, poison
Worse for attack, even without weapon switching - hack, pierce, crush, fire dmg, fire interval, fire duration, poison dmg, poison interval, poison duration, range, attack interval, counter boni
This obviously won't reasonably fit. My take, instead of showing half the truth better to not show at all.
2 hours ago, wraitii said:I think there is an argument to make that this acts as a tutorial: it shows new players what information is important. Those that care can always look into the details. Further, this will help us declutter the tooltips, possibly making it easier to read the relevant information when you need.
For beginners I'd say those numbers are rather useless. Far better to have a page which roughly tells in prosa which unit to use for what purpose. Numbers only start to matter once you can play somewhat competitive and have a good understanding how those numbers interact, but by then you likely already know them by heart.
I know there is no definitive answer how to go about it and I appreciate that you take the time thinking about how to improve the current situation which is tedious and difficult to say the least.
-
1
-
-
Why limit yourself to the current panels? Putting preselect actions into a separate one probably beats stuffing them into the right panel which is already overloaded for different purposes. As they all have a hotkey attached it might even be desirable to have a menu option to not display said panel at all.
About numbers, there are to many for them to be listed all. So except for the most important and dynamic ones like resource carried the rest is probably better hidden behind a redirection like a tooltip or pop-up menu and the gained space used for other things or given back to the viewport.
-
I had no issue with the Romans, haven't tried with Persians. So I'd say same issue. Likely cause: non square obstruction
-
I can simply bind the hotkey to send SIG_STOP/SIG_CONT via window manager
, so I'm fine with postponing. But then please add the screen saver inhibition thingy to the TODO list.
-
3 minutes ago, wraitii said:
The reason for the change, by the way, is that:
- pausing the music breaks the victory sound in SP (could be done differently)
- The game auto-pauses when you open the struct-tree (and a bunch of other things), which is annoying since it cuts the music.
I see, well, pausing the simulation and explicitly pausing the game are strictly speaking not the same.
6 minutes ago, wraitii said:It does, but on A23 that doesn't pause the music, nor on A24.
Never relied on background pause, so personally don't care
9 minutes ago, wraitii said:I don't think I'm going to consider this a major use case, to be honest
. You could just disable music then.
Well, the phone call could also be an internet call, was just making up an example here. I don't use pulse by the way.
-
Over the house coloured red, seems built-in screenshots feature ignores cursor. Haven't even noticed.
-
Hope a screenshot will do, no recorder installed on this machine.
-
In A23 using the hotkey pause the music was paused as well, which allowed me to for instance take a phone call or do some other work which depends on sound. A simple example could be watch a video on a different virtual desktop.
"Background pause" refers to the window having lost focus? If so this IMHO should behave as I stated in the OP.
-
1
-
-
Pausing the game should mute the game. In an ideal world it also shouldn't inhibit the screen saver while paused.
-
With r24769 and Seleucids if I try to place a house beside another house while holding Ctrl for snapping I get the "House cannot be built on another building or resource" error.
Edit: Only happens along one axis.
-
Just a quick glance, so might have missed some of the quirks involved.
- Why not use alignas instead of padding?
- Are there enough vector3D "alive" that an additional bool actually matters?
- L (length) seems to be singed, so why using zero for maybe invalid instead of <0 for invalid?
- You are over commenting quite a bit me thinks.
-
7 hours ago, nifa said:
i think most convenient would be if the units just do whatever is faster, capture or destroy..
This perfectly demonstrates the issue. If it's desirable to be able to quickly take out any buildings with basically any unit, as is the case with capture-delete, the correct thing to do would be to make structures simply a lot more brittle. Capture-delete just destroys the immersion for me.
Btw, ranged units not running to the front and getting in the way of sieges can be considered one of the favourable behaviour changes of this mod. Sure this is a matter of taste and priority, I don't expect everyone to agree.
-
1
-
-
1 hour ago, Stan` said:
That's because AMD cards don't seem to support 16 samples. Only Nvidia does.
Might make sense to query max samples and only present msaa options available by hardware/driver in the menu then.
-
There is certainly something doggy going on - card vega11, driver amdgpu, switching to msaa16 I get:
WARNING: Wrong MSAA sample count: msaa16.
-
Another release:
- fix default of capturing after unloading when rally point is a building (noticed by @FeiLongbay)
- Add three minutes ban on deleting after capture
- Adds a diff of all changes on top of A23 to the archive for easier study by others
-
1
-
1 hour ago, FeiLongbay said:
I have not been able to set a rally point that is different than just the move rally point. E.g. in the base game if I right click rally point on an enemy building then ungarrison, my spear cav runs over and tries to capture. If I hold ctrl and right click on a building, the rally point does not even register and my cav ungarrisons at the front of the building. I thought I might have to change the autorallypoint from ctrl to a random key "k", but I still had the same issues.
(In my example, I assume that setting a rally point on an enemy building is the same as setting it on an enemy bolt/catapult because I don't know a map that starts with siege.)
I can reproduce the capture instead of attack after unload, obviously unload to attack buildings I only do with sieges if at all so I didn't run into this myself. If the rally point is a building the behaviour is unexpectedly strange. Guess could be considered buggy.
1 hour ago, FeiLongbay said:I see the capture delete meta as analogous to an ancient scenario where troops came into the city and they started to raze the buildings. If the city didnt send troops and waterboys to save the building it would be destroyed. Making the capture any more expensive would make warfare before stage III irrelevant because garrisoning in the cc, sentry towers, barracks, houses is much more cost effective than the attacker sending troops all the way across the map.
"set-on-fire" could indeed be added as another entity/unit action. The structure then would receive fire damage over time. This would be easy in A24 as there fire damage over time is already implemented. However, I see this a complementary to the ban on outright delete a structure recently captured.
Fragment shader quick questions
in Game Development & Technical Discussion
Posted
Here, trailing spaces on empty lines, eg. line 59 and 171 in model_common.fs. Don't know what editor you use but should be configurable to at least highlight those. Also git will yell at you.