wraitii

@gameboy Could you share the commands.txt of that replay?

Hello @gameboy, this is a know issue: https://trac.wildfiregames.com/ticket/4420#comment:7 It will be fixed in the upcoming days.

Uncertainty can be a guiding light.

That's still an open question at the moment. Moderator's note: This comment, whilst a valid response to an on-topic remark, resulted in an off-topic stream of posts that were relocated here.

Hey @wowgetoffyourcellphone, these are getting reported here and I'm trying to keep a list here. The latest changes do need recompilation, but they also need some bug fixing which will be done this week or so.

Thanks @gameboy for reporting the issue, which is now fixed. Sounds like a good idea, actually.

Indeed, I think we ought to lift that limitation but it sounds harder to do (also D270 is kinda related).

I think we would all appreciate if everybody could calm down and keep on topic (borg's mod, in fact). Further off-topic discussion may be hidden or deleted and insults could lead to temporary bans.

I never understood why we limited women to only some buildings when it's possible to plop them with soldiers and build them with women. No that topic specifically, I'd commit a diff right away.

I'm repeating myself but that looks like the scissoring issue :p . We don't clear the reflection/refraction textures, so here the texture is rendered with the old data, so it's not (necessarily) red.

Did you ever upload that to Phabricator?

I'm going to try and flesh out the above proposition more, I think it's a worthwhile idea.

Interesting points about the history and Age of the Aegean, thanks to both of you . Overall I think we did kinda lose ourselves in this civ business. I remember the "AoM like branching" discussions. I guess it would be an interesting idea for a game representing more of history? I'll agree with your that I'm going game first, history second, but some people do feel more at ease with the reverse.

Regardless, thanks for noticing this

All of the above look like the old scissoring issue to me, where the water isn't correctly being refreshed and so it shows red.

I don't believe 0 A.D. is signed with a developer ID, so that sounds like the old "right-click > Open" process would still work for us. We might at some point consider enrolling in the developer program (99$/y) and try getting signed, and I guess notarized. Would have to understand what this entails exactly, but we could distribute 0 A.D. on the Mac App Store which might give us an increased presence on Mac OS. Might also not.

Is the "more visible" still in effect after the fixing commit? I think what you're running into is the water scissoring code being broken, something which I've always felt was beyond me to fix (it's geometry and I suck at geometry).

@gameboy Are you sure that you aren't using any mods? It certainly looks like you are, as nobody else is getting these gamma ramps error (from what we can tell). @Angen Any chance you could check if this redness happened before the rP22297 commit? I think they should.

I think that might be the water refraction clipping?

I think you would have a bit of trouble writing an AI that pretends to be a player, though with some good C++ modding it's probably doable. Indeed however currently there's no way for the AI to get visibility information, it assumes everything is visible all the time, so you will run into trouble with unitAI not agreeing to your orders (as there are some visibility checks in unitAI that would succeed for you all-seeing AI and fail for your AI-as-a-player) At the moment, implement LOS for AI is quite complicated.

Hey gameboy, that's related to me merging D359 yesterday. You can fix it by de-activating fancy effects as it turns out I can reproduce this (didn't notice yesterday, unluckily). Edit - I'm interested in other people reporting SQL/GL error, by the way, as testing these shaders things is annoying at best.

I think we should consider OpenGL deprecated going forward, too. Mac OS has done so, so the only useful thing is OGL 2 for legacy systems support. Vulkan / Vulkan+MoltenVK are probably the systems of the future for us.

The renderer isn't bad, it's actually fairly well designed (except for the GUI). It's just quite coupled with OGL2, which isn't the best coupling for 2019 . Also agreed pithing pinging Vlad' on this, he's probably more knowledgeable than I am about the renderer.

With things like arrows, I think triangles are a lesser concern than draw calls. 60 polygons is nothing in 2019, but 60 draw calls is something. Reducing the # of polygons would help, possibly after instancing of some kind, but it won't fundamentally speed things up right now imo.

Those are definitely the pros and con... "Bit more work" is I feel a bit of an understatement though. Modern graphics are complex affairs, and we already don't have much workforce. I don't think we can make an AAA level RTS graphics engine - and that's kinda what we're talking about here. The dependency problem is a big issue because most "probably won't fail" projects have grown a bit too big. Things like godot or Ogre are complete and modern, but we can't really easily adapt our current code to them. Smaller projects have a more uncertain future, or don't support all of our three platforms, and such. Regardless, the renderer abstraction is probably something we'll need to do anyways, so it's a good first step.