The end of the maintenance branch - Page 8

The end of the maintenance branch

Discuss the source code and development of Spring Engine in general from a technical point of view. Patches go here too.

Moderator: Moderators

Post Reply
abma
Spring Developer
Posts: 3701
Joined: 01 Jun 2009, 00:08

Re: The end of the maintenance branch

Post by abma »

ok, i've tagged 105.0 from maintenance and deleted it. I did not downgrade the buildbot workers. so the 105.0 linux builds will require glibc >= 2.29 as i'm to demotivated to dowgrade the buildbot workers, sorry. IMHO its better to release with "high" requirements than no release.

happy new year!
User avatar
ivand
Posts: 242
Joined: 27 Jun 2007, 17:05

Re: The end of the maintenance branch

Post by ivand »

I understand your frustration. One particular troll almost ruined my motivation to contribute to spring, other smaller ones spread decay here and there in small amounts to paint it all black. I'm actually surprised how lenient their treatment is. IMO moderation at springrts should be way stricter than it is.

I wish 105 was released with older deps in mind, but we have what we have. Thanks for making it happen, better late than never.

P.S. I haven't been slacking either: https://github.com/beyond-all-reason/sp ... reason:BAR
abma
Spring Developer
Posts: 3701
Joined: 01 Jun 2009, 00:08

Re: The end of the maintenance branch

Post by abma »

ivand wrote: 01 Jan 2021, 17:45 P.S. I haven't been slacking either: https://github.com/beyond-all-reason/sp ... reason:BAR
this seems to be based on the maintenance branch: how do we get this into the develop branch?

it looks like the roadmap is wrong and 106.0 will be a continuation of the maintenance branch? if not, the develop branch should merged into the BAR branch.

(sorry if i missed something, its difficult for me to follow because of many interruptions with different topics)
User avatar
ivand
Posts: 242
Joined: 27 Jun 2007, 17:05

Re: The end of the maintenance branch

Post by ivand »

The transition or BAR branch as a possible bleeding edge of it is based on the maintenance indeed. The reason is simple: it's not possible to "dumb down" the develop to run on low OpenGL profiles.

Instead the maintenance is getting new GL capabilities mostly in Lua space, so games could migrate their widget/gadget code to these GL primitives. Later on the same "new GL" code can be added to the develop too so switching between the two is more or less easy.

P.S. For now I've switched to a feature branch https://github.com/beyond-all-reason/sp ... O?expand=1 that involves some additional changes to the engine code. Mostly they enable the way to completely bypass the way the maintenance/transition engine draw things and instead draw stuff from Lua in a modern way. In particular I rewrote that VBOs are now assigned per model (same way as the develop does, used to be per-piece and it was too granular), exposed model VBOs to Lua, collected the most common matrices (bind pose matrices, unit matrices, piece matrices, etc) into a GPU buffer, that is accessible from any widget/gadget. Now I'm thinking through the system to do the indexing of the matrices data. In any case even now with static indexing one can draw any model from the widget. Such drawing bypasses the engine (old style) drawing completely: no display lists, no embedded matrices stack, no gl_Vertex, etc.
Image the left robot is a unitDef drawn in that new way.

I expect to finish that branch within a few days or weeks, test it and then perhaps collect relevant commits and put together a PR.
Attachments
screen02023.png
(4.07 MiB) Not downloaded yet
User avatar
ivand
Posts: 242
Joined: 27 Jun 2007, 17:05

Re: The end of the maintenance branch

Post by ivand »

Drawn in one go without any CPU roundtrip

P.S. Note it's completely different from the above. Above it was a static unitdef, but here it's a unit. But both are drawn using the same mechanism.

P.P.S. Now the code is wired to unitID/featureID/unitDefID/featureDefID.
User avatar
ivand
Posts: 242
Joined: 27 Jun 2007, 17:05

Re: The end of the maintenance branch

Post by ivand »

@abma, the commits on the BAR branch keep piling up and since this branch dragged several contributors other than myself, the question of pulling the changes back becomes quite important. Have a look at the current diff: https://github.com/spring/spring/compar ... reason:BAR it's already massive enough that no sane one-step review is possible. At least I talked to @gajop and he confirmed that.

With that in mind I'd like to discuss the merge strategy (provided it's still wanted by spring/spring owners).
* First we can just merge it in one big chunk minus some minor local changes I did for BAR like removing outdated AIs. This makes review hardly a possibility but represents the easiest way as far as I'm concerned.
* The second strategy would be to review code by functional parts, but since spring is tightly coupled I may well see the scenarios where the PRs are non-atomic. E.g. they might contain parts of the unrelated code and might not even compile because of external dependencies to be covered in further PRs. Despite parts being non-atomic, the code can be sanely reviewed by senior peers.

Separately I'd like to note that I did substantial modifications to CMakeLists to get the compilation going and expose the tuning params I wanted for Github builds, so spring shepherds better make up their mind if they want to migrate builds (and issues) infra to Github or stay where they are. In the later case I cannot guarantee the code from PRs will compile the same way or at all it's getting compiled in my environment.

P.S. The code has been mostly verified, but I'll admit some parts received very limited if any testing, so it's mostly good for devs only to do first baby steps in migration.
abma
Spring Developer
Posts: 3701
Joined: 01 Jun 2009, 00:08

Re: The end of the maintenance branch

Post by abma »

i guess reviewing will be teamwork...

still the biggest issue is, that it is based on the maintenance branch.
User avatar
ivand
Posts: 242
Joined: 27 Jun 2007, 17:05

Re: The end of the maintenance branch

Post by ivand »

I've never claimed it'll be based off something other than the maintenance. Because unlike the develop where the support for the old ways was specifically purged, the maintenance can run both old and the new code. Also see the very first post of this topic.

Your answer doesn't give much clarity how to approach this nor if you are willing to give up on buildbot and thus if I should include CMakeLists changes. I guess you would want to discuss it with whoever left active and come back with some guidance how to proceed.

P.S. would be nice if you were Discord accessible, even through a bridge to Matrix as we tend to discuss such matters with the rest in the real time.
abma
Spring Developer
Posts: 3701
Joined: 01 Jun 2009, 00:08

Re: The end of the maintenance branch

Post by abma »

then we have a big problem. i always claimed that the "develop" branch will and should be continued and the maintenance branch beeing dropped: kloot has/had the same stance afaik.

not sure how we can continue: suggestions welcome. suggest a roadmap please / correct the existing one.

as i read the first post, you suggest to create 106.0 from "transition" and then drop transition and continue "develop" as it is, right?
User avatar
ivand
Posts: 242
Joined: 27 Jun 2007, 17:05

Re: The end of the maintenance branch

Post by ivand »

Don't think we have any problem here. :P
We discussed it extensively in this topic and in one of the github PRs and I'm sure Kloot got my intents right.

Yes, port widgets to GL4 API gradually while being on transition then switch engines (assuming the develop gets the same API, which is perfectly doable). As an example BAR now uses all old widgets, except for one I ported to GL4. Once porting is complete we can switch. The primary advantage here is that you don't need to put your game on pause for half-year or whatever time it takes to port all widgets because both old-GL and new-GL widgets remain operational.
Post Reply

Return to “Engine”