The end of the maintenance branch - Page 9

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: 3798
Joined: 01 Jun 2009, 00:08

Re: The end of the maintenance branch

Post by abma »

ivand wrote: 23 Mar 2021, 19:33 As far as "main" spring is concerned probably yes, but within the community I'm at right now we have different planning horizon and roadmap items come and go in weeks.
ok. so its sth. like "wait for BAR release(s)". Very likely i'll be busy in the next weeks with migrating springrts.com to a new server, so lets see. :-)

ivand wrote: 23 Mar 2021, 19:33 Thanks for cpack ref. Never heard of it, will have a look. My question however was more near-sighted. You mentioned the code duplicated the existing build routines and I was referring to these code parts and what they can be substituted with.
i.e.:

https://github.com/beyond-all-reason/sp ... d.yml#L461
https://github.com/spring/spring/blob/d ... dle.sh#L23

nothing really bad, but duplicate code makes future changes difficult.
ivand
Posts: 310
Joined: 27 Jun 2007, 17:05

Re: The end of the maintenance branch

Post by ivand »

https://github.com/beyond-all-reason/sp ... d.yml#L461
https://github.com/spring/spring/blob/d ... dle.sh#L23

nothing really bad, but duplicate code makes future changes difficult.
Oh you mean this one... This one is deliberate: I wanted most of the scripting be explicitly mentioned in the build.yaml.

When I was agreeing with your statement I meant:
https://github.com/beyond-all-reason/sp ... #L397-L435
This one looks truly redundant and this is something `make install` or alike usually do. I think I missed something standard that should do it, but back in the day I had no time to figure it out so I hardcoded everything.
abma wrote: 23 Mar 2021, 21:15 so its sth. like "wait for BAR release(s)".
More or less, I don't mind sending a PR, but looks like you are not too interested w/o clear goal (which isn't yet clear for myself). I also have better things to do than to do PRs that will not be accepted.
abma
Spring Developer
Posts: 3798
Joined: 01 Jun 2009, 00:08

Re: The end of the maintenance branch

Post by abma »

so, close to a year is gone since the initial post in this thread:

any complains if the current development branch is released as 106.0?

this maybe allows some "small" game to use it and provide some feedback.

"compatibility" code still can be added to 107.0 when needed.
User avatar
PicassoCT
Journeywar Developer & Mapper
Posts: 10450
Joined: 24 Jan 2006, 21:12

Re: The end of the maintenance branch

Post by PicassoCT »

MOSAIC is not a small game, i have the biggest dev to player ratio of all spring games.
ivand
Posts: 310
Joined: 27 Jun 2007, 17:05

Re: The end of the maintenance branch

Post by ivand »

My perspective is following:

No one has been able to move to the develop branch and I don't see anyone will.
AFAIK BAR is the only game working on moving rendering to GL4 and despite the efforts we are far from completion yet: It's the reality that the current accrued assets such as widgets will stay not migrated probably for years. Therefore I see no value in releasing the develop as any numbered release. At least in the current circumstances.

My initial strategy was to enable optimized GL4-like rendering capabilities via Lua API. This task is more or less completed. The new API enables very efficient rendering submissions. See viewtopic.php?f=13&t=43644 as example.

The refined mid-term strategy is to replace rendering subsystems of the current engine with GL4 code one by one. The code from the develop might be used as reference implementation where applicable. You probably have seen prototype class implementation of GL4 UnitDrawer: download/file.php?mode=view&id=11377 that enabled 10x FPS improvement. The plan is to continue this route and integrate such changes one by one while keeping the rest of the code intact.

I propose to integrate the current BAR branch (~280 commits ahead of 105) as 105+/transition/106/whatever the name you like. Currently it's 99% if not 100% backward compatible with 105.

Moving on I'll be replacing various drawer subsystems as outlined above. Such changes will require adjustments on game side (for example GL4 unit drawer will require changes to custom unit shading framework obviously), but the scale of doing such changes should be manageable.
gajop
Moderator
Posts: 3051
Joined: 05 Aug 2009, 20:42

Re: The end of the maintenance branch

Post by gajop »

The way I see it killing maintenance was a bad idea - it killed the only usable branch of spring/spring.

And as ivand said, develop isn't usable and makes no sense to release. The only reasonable way of going further is the BAR way: backward compatible progressive transition.
ivand wrote: 11 May 2021, 09:59I propose to integrate the current BAR branch (~280 commits ahead of 105) as 105+/transition/106/whatever the name you like. Currently it's 99% if not 100% backward compatible with 105.
I can agree with this but only if you move development from byar/spring to spring/spring. Otherwise merging is pointless as no one can maintain it.

PS: byar/spring could be kept as a mirror for making GH releases if abma still can't be convinced to turn it on for spring/spring
PS2: I'd go a step further and just stop merging stuff to develop. It's a huge pain to cherry-pick commits into it. I'd rather take a look at develop and see if anything can be salvaged for transition.
ivand
Posts: 310
Joined: 27 Jun 2007, 17:05

Re: The end of the maintenance branch

Post by ivand »

I agree with everything you proposed @gajop
abma
Spring Developer
Posts: 3798
Joined: 01 Jun 2009, 00:08

Re: The end of the maintenance branch

Post by abma »

gajop wrote: 11 May 2021, 13:05 PS: byar/spring could be kept as a mirror for making GH releases if abma still can't be convinced to turn it on for spring/spring
you don't need to convice me for that. i'm pro gh actions, but: the current code for gh is very bad as it added a lot of duplicate code. this needs to be fixed before its useful.
And as ivand said, develop isn't usable and makes no sense to release
can you be more specific? yes, existing lua opengl code is broken, but AFAIK its not possible to move to GL4 without breaking and rewriting the affected lua code.
ivand
Posts: 310
Joined: 27 Jun 2007, 17:05

Re: The end of the maintenance branch

Post by ivand »

abma wrote: 11 May 2021, 13:26 you don't need to convice me for that. i'm pro gh actions, but: the current code for gh is very bad as it added a lot of duplicate code. this needs to be fixed before its useful.
I'm all in for improvements. But I would say what I did is the pinnacle of my capabilities. I have no devops background, nor I am a CMake expert, so I did what I could given the resources and it serves the purpose.
abma wrote: 11 May 2021, 13:26 can you be more specific? yes, existing lua opengl code is broken, but AFAIK its not possible to move to GL4 without breaking and rewriting the affected lua code.
The difference is that with gradual approach a game can use both old and new GL API and thus GL widgets/gadgets can be migrated one by one. With the develop one needs to move them all to GL4 API in one go, the approach no game can afford. The develop itself needs quite some polish as several things are broken and/or missing.
Manmax
Posts: 78
Joined: 19 May 2011, 13:57

Re: The end of the maintenance branch

Post by Manmax »

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

Wow, i did realize the games run on such old software lol
raaar
Metal Factions Developer
Posts: 1094
Joined: 20 Feb 2010, 12:17

Re: The end of the maintenance branch

Post by raaar »

on MF we can't switch to either BAR or develop engines as some players don't meet the GL4 requirement yet.


Either way, it seems to me that the best course of action would be to move/rename the currently inactive develop branch and merge the BAR branch's code into the new develop branch.

The maintenance branch shouldn't have been deleted either. I see lots more branches, some which haven't had any commits in more than a decade!

I've done some basic testing with BAR.104.0.1-1878-ge59d4e2 and it doesn't seem to break anything else (3do compatibility is still there), so lazy transitions are possible. It'd be nice if we got a new official version with some of the BAR engine improvements before compatibility with some legacy stuff is broken.
ivand
Posts: 310
Joined: 27 Jun 2007, 17:05

Re: The end of the maintenance branch

Post by ivand »

raaar wrote: 15 May 2021, 21:00 on MF we can't switch to either BAR or develop engines as some players don't meet the GL4 requirement yet.
Each game leader decides if they want performance or stay compatible with every calculator class PC
raaar wrote: 15 May 2021, 21:00 Either way, it seems to me that the best course of action would be to move/rename the currently inactive develop branch and merge the BAR branch's code into the new develop branch.
BAR branch merge is in process. The review is ongoing. As sad as it sounds, but looks like the develop branch will need to be archived and used as reference.
raaar wrote: 15 May 2021, 21:00 The maintenance branch shouldn't have been deleted either. I see lots more branches, some which haven't had any commits in more than a decade!
It's deleted, but codebase is almost same in transition (+GL4 Lua additions).
raaar wrote: 15 May 2021, 21:00 I've done some basic testing with BAR.104.0.1-1878-ge59d4e2 and it doesn't seem to break anything else (3do compatibility is still there), so lazy transitions are possible.
As I said in the very first posts in this topic. Thansition/BAR branch is nearly 100% compatible with 105.
raaar wrote: 15 May 2021, 21:00 It'd be nice if we got a new official version with some of the BAR engine improvements before compatibility with some legacy stuff is broken.
it is my plan. Release some stable version that can run existing GL4 widgets and be used to develop new ones before gradually removing old stuff.
ivand
Posts: 310
Joined: 27 Jun 2007, 17:05

Re: The end of the maintenance branch

Post by ivand »

While the review is in progress, I've updated https://springrts.com/wiki/Roadmap (the way I see it)
raaar
Metal Factions Developer
Posts: 1094
Joined: 20 Feb 2010, 12:17

Re: The end of the maintenance branch

Post by raaar »

minor nitpick : why not "105.0 -> 106.0 -> 107.0" instead of "105.0 -> 105.1 -> 106.0"?
ivand
Posts: 310
Joined: 27 Jun 2007, 17:05

Re: The end of the maintenance branch

Post by ivand »

Dunno why people are so fixated on numbers, they are easiest to change :lol:

Generally it's to underline the fact 105 and BAR branch 105.1 are supposed to be compatible and only bring additional capabilities, while 106 will have some manageable API changes.
abma
Spring Developer
Posts: 3798
Joined: 01 Jun 2009, 00:08

Re: The end of the maintenance branch

Post by abma »

ivand wrote: 24 May 2021, 22:35 Dunno why people are so fixated on numbers, they are easiest to change :lol:
105.1 would mean it syncs to 105.0 which i guess isn't true: several stuff relies on that. Also a lot of people would assume that 105.1 is sync compatible to 105.0. i've changed 105.1 to 106.0 on the "Roadmap" page. And i would say its not this easy as a lot of stuff will break when you change numbering system. i.e. the path cache folder / filename relies on a correct version beeing set.
abma
Spring Developer
Posts: 3798
Joined: 01 Jun 2009, 00:08

Re: The end of the maintenance branch

Post by abma »

wrt roadmap:

for me it looks like "develop" needs to be renamed to sth. like opengl4test and transition needs to be renamed to develop. not sure how to find a conclusion here: would be nice when kloot posts his opinion.
ivand
Posts: 310
Joined: 27 Jun 2007, 17:05

Re: The end of the maintenance branch

Post by ivand »

abma wrote: 24 May 2021, 23:34 wrt roadmap:

for me it looks like "develop" needs to be renamed to sth. like opengl4test and transition needs to be renamed to develop. not sure how to find a conclusion here: would be nice when kloot posts his opinion.
I agree, it's time to pronounce the develop too unreachable for current games and salvage best out of it.
Though based on https://github.com/spring/spring/pull/552 I expect Kloot to have different view.
Master-Athmos
Posts: 916
Joined: 27 Jun 2009, 01:32

Re: The end of the maintenance branch

Post by Master-Athmos »

I have a sidenote concerning the unit / feature custom shading framework that I want to mention:
Would it be possible to include weapon projectiles too? This would be handy not just for bigger rockets like nukes having a nice PBR shaded look but it also would be handy for weapon FX in general as of right now things basically come down to a rather ugly hard-coded lightning effect, billboards in terms of (beam)lasers or flame throwers, projectiles that show a textured 3D object (e.g. a missile) or the hardcoded plasma ball projectile. It's possible to spice things up with the limited CEG options which have the problem of stuttering around at the SIM fps rate though in addition to their numerous general limitations. Here it would be a blast if the custom shading framework would include at least the 3D model projectile part. This would not only allow for PBR shaded objects but with the entire shader range (including geometry shaders) available all kind of effects would be possible. It of course would be even better to also include e.g. the laser weapon so you have the information of e.g. the emitting and final point. Imagine being able to create custom effects like SUCH A FLAMETHROWER but I don't know how much work this would need on the C++ code in order LUAfy the information the shader would need...

So if there is a possibility to also affect projectiles and not just units and features, that would be great as it has the potential to greatly enhance the weapon visuals. There of course is the possibility to use LUPS for stutter free effects but that's like doing the same thing with extra steps and I'm not entirely sure if actual 3D object rendering is possible (i.e. beyond things like the santa hats which are just primitives created directly via OpenGL commands and not a dedicated 3D object of its own like an s3o)...
Post Reply

Return to “Engine”