The end of the maintenance branch
Moderator: Moderators
Re: The end of the maintenance branch
The end of the maintenance branch has happened! Time to uncork champagne!
Re: The end of the maintenance branch
what?!
I hope this wasn't deliberate...
we lack a guide for how to convert the GL calls that no longer work for ones accepted by the develop engine.
several of MF players use toasters with performance issues, i doubt they'll be compatible with GL 4.0+, so this will cause problems on my player base even if the GL stuff is converted with no bugs.
I hope this wasn't deliberate...
we lack a guide for how to convert the GL calls that no longer work for ones accepted by the develop engine.
several of MF players use toasters with performance issues, i doubt they'll be compatible with GL 4.0+, so this will cause problems on my player base even if the GL stuff is converted with no bugs.
Re: The end of the maintenance branch
That awkward moment when one needs to explain their failed joke:raaar wrote: ↑04 Dec 2020, 18:22 what?!
I hope this wasn't deliberate...
we lack a guide for how to convert the GL calls that no longer work for ones accepted by the develop engine.
several of MF players use toasters with performance issues, i doubt they'll be compatible with GL 4.0+, so this will cause problems on my player base even if the GL stuff is converted with no bugs.
I was just playing around with the caption of the topic and the situation with the buildbot releases.
P.S. Of course I notified everyone I know (Kloot, abma, gajop) about this incident same minute I noticed it happened.
Re: The end of the maintenance branch
yes, thanks for reporting. I know you're half-joking about the celebration .
My annoyance is directed at the ones responsible, not the messenger.
My annoyance is directed at the ones responsible, not the messenger.
Re: The end of the maintenance branch
More than a year ago, Spring was at the greatest challenge yet. Kloot(?) made an ultimatum for players to use newer engine or he'd stop developing it. At the same time, both the latest release and the in-development engine were incompatible with the toasters or operating systems used by half the player-base. The spring lobby admin and moderation teams thus had an impossible choice on their hands: nudge players into using newer versions and decimate the player base or face the impending halt of engine development.
Back when I was still active, I didn't like that we were losing both and further alienating all the different groups of people. But nowadays, looking from outside, this is actually rather amusing. Keep at it, boys! :D :D
Re: The end of the maintenance branch
It's been a while since I reported anything. The work continues in the background, right now in the private BAR branch (testing is mostly done in the game called BAR). As I was mentioning before BAR branch was supposed to serve as a testing battleground and sure it has been.
Only with live testing I was able to track down several critical bugs with the new code and eliminate them eventually. The testing engine was also briefly tested by our friends from Zero-K in place of the standard latest maintenance. It ran mostly smoothly.
The testing so far has only concerned the same GL primitives that exist in the maintenance and new primitives getting updated by the engine in the background. The new Lua API hasn't been tested by anyone except me locally yet.
After some initial testing we are going to test it much more extensively and cautiously enable new API in widgets/gadgets as we go. Doing so will likely require fixing bugs again and improving error reporting/corner cases handling.
After that stage I have a very ambitious idea to implement engine side, retained rendering, which I call DrawTask API myself. Having flexible DrawTasks will allow to not use very costly Lua side pull style rendering and move to "push the task" mode instead.
I'm not yet sure about exact timing, but after completing DrawTasks or before even starting it I'm planning to collect my GL related improvements and contribute them back to the main spring repo as a PR.
Stay tuned and don't let the recent trolls invasion discourage you.
Only with live testing I was able to track down several critical bugs with the new code and eliminate them eventually. The testing engine was also briefly tested by our friends from Zero-K in place of the standard latest maintenance. It ran mostly smoothly.
The testing so far has only concerned the same GL primitives that exist in the maintenance and new primitives getting updated by the engine in the background. The new Lua API hasn't been tested by anyone except me locally yet.
After some initial testing we are going to test it much more extensively and cautiously enable new API in widgets/gadgets as we go. Doing so will likely require fixing bugs again and improving error reporting/corner cases handling.
After that stage I have a very ambitious idea to implement engine side, retained rendering, which I call DrawTask API myself. Having flexible DrawTasks will allow to not use very costly Lua side pull style rendering and move to "push the task" mode instead.
I'm not yet sure about exact timing, but after completing DrawTasks or before even starting it I'm planning to collect my GL related improvements and contribute them back to the main spring repo as a PR.
Stay tuned and don't let the recent trolls invasion discourage you.
Re: The end of the maintenance branch
Sounds great :) I really admire how much work you (and other people) have been putting in the whole "BAR universe" (engine development, maps, game content, ...)!
As far as I understood ivand's (and others) changes compared to the maintenance branch will break the existing mods/games. Just to get a better feeling (please do not start another flame war): How much effort is it to make an existing mod/game compatible with the changes?
I would love to see the "classic TA mods" like BA migrate as well.
As far as I understood ivand's (and others) changes compared to the maintenance branch will break the existing mods/games. Just to get a better feeling (please do not start another flame war): How much effort is it to make an existing mod/game compatible with the changes?
I would love to see the "classic TA mods" like BA migrate as well.
Re: The end of the maintenance branch
It's more complex than simple yes/no. It's worth elaborating, especially given the amount of deceit spread around by a few individuals.submarine wrote: ↑09 Dec 2020, 17:57 As far as I understood ivand's (and others) changes compared to the maintenance branch will break the existing mods/games. Just to get a better feeling (please do not start another flame war): How much effort is it to make an existing mod/game compatible with the changes?
My intent is to keep the transition branch (and the BAR branch as a superset of what's currently available in the transition branch) compatible with the maintenance (aka 104.0.1+). Now what does compatible mean? It means that if the games keep using existing maintenance's OpenGL API (aka old API) it will continue to work as before. The new capabilities are offered as add-on. Those GPUs that cannot support these add-ons, will just not run them silently.
That said there will be no compatibility in case a game moved to new OpenGL API and a player's GPU cannot support it (say hello to dated Intel embedded "GPU"). It's simply nearly impossible to make a compatibility layer in a generic/performant way (yes, I tried, see GLAL). For such players the game can provide game-side alternative rendering path (via old API).
Another story is our (the forward looking part of community) eventual goal: the develop engine. It's almost complete and even if the original devs stay dormant, I'll be able to complete it myself. Also it is significantly faster than the maintenance as far as rendering. I have some hopes it can even be sync compatible to maintenance/transition/BAR branch. The develop eradicated all traces of old GL API, so only "modern" GPUs will be able to run. I'm quoting modern, because the required version of OpenGL for develop (which we will most certainly be able to downgrade) - OpenGL 4.4 is dated by 2013 year. The migration will take anyway couple of years at best, so by 2022-2023 this OpenGL version will be around for a decade.
Me too, but my personal position that in the end it's up to the game wardens to decide whether they want to move forward in the graphics while risking to lose some part of the players or keep offering the 20 years old game look with the full player base.I would love to see the "classic TA mods" like BA migrate as well.
BA is an odd duck. Their lead "dev" produces zero lines of code annually and enjoys the public image of being mistreated, while the migration to the supported/104+ status would take for someone like me around 1 day of work.
- Silentwings
- Posts: 3720
- Joined: 25 Oct 2008, 00:23
Re: The end of the maintenance branch
Split out (as best I could) a line of discussion that went off-topic, to viewtopic.php?p=596162#p596162
Re: The end of the maintenance branch
so, finally i get it at least to the step where it compiles with some changes: https://github.com/spring/spring-lxc/co ... d48a793a1a
i've used debian 11 to have gcc 10, so possible this breaks some more stuff as the abi of libc etc possible aren't compatible any more.
i guess we have it to name "game-braking release" or sth. linke that
i've used debian 11 to have gcc 10, so possible this breaks some more stuff as the abi of libc etc possible aren't compatible any more.
i guess we have it to name "game-braking release" or sth. linke that
Re: The end of the maintenance branch
he lives!
While new maintenance builds are still broken, please restore the 1553 maintenance build files on the https://springrts.com/dl/buildbot/default/maintenance/.
It should not have been automatically cleaned up with no replacement.
While new maintenance builds are still broken, please restore the 1553 maintenance build files on the https://springrts.com/dl/buildbot/default/maintenance/.
It should not have been automatically cleaned up with no replacement.
Re: The end of the maintenance branch
We use GCC 10 in BAR branch with no issues.
Overall, please make a stable release already, no one is going to continue working on the maintenance branch, it's time to call it and release it on some stable platform like github.
Overall, please make a stable release already, no one is going to continue working on the maintenance branch, it's time to call it and release it on some stable platform like github.
Re: The end of the maintenance branch
ok, i can do this. Thats create 105.0 from maintenance + drop the maintenance branch, right?
I'll try to so on monday: break-day!
Re: The end of the maintenance branch
Enthusiastic by @abma move I'm posting some proofs new GL is up and running:
The map extension relies fully on OpenGL 3/4 core features with no old GL (*).
8 extension plates are rendered by means of instanced rendering.
(*) - except for the Fog, which I'm going to replace with core profile version in the next BAR branch build.
The map extension relies fully on OpenGL 3/4 core features with no old GL (*).
8 extension plates are rendered by means of instanced rendering.
(*) - except for the Fog, which I'm going to replace with core profile version in the next BAR branch build.
- Attachments
-
- screen01999.png
- (3.51 MiB) Not downloaded yet
Re: The end of the maintenance branch
"create 105.0 from maintenance" <--- good
"drop the maintenance branch" <--- does this mean people will be unable to fix stuff on 105.0.1+ that's gl 3 compatible if serious issues are found 1 month after the release? if so, BAD
Re: The end of the maintenance branch
Someone fixing maintenance is illusion and clutching at straws. Just have a look at recent github activity.
The recent maintenance is battle tested by many games. You simply won't find any better candidate to release as 105/stable.
P.S. the maintenance branch continues its existence in its direct descendant - the transition branch.
- Silentwings
- Posts: 3720
- Joined: 25 Oct 2008, 00:23
Re: The end of the maintenance branch
Split discussion of buildbots and autodeletion of builds to viewtopic.php?f=12&t=42606.