The end of the maintenance branch - Page 6

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
User avatar
ivand
Posts: 197
Joined: 27 Jun 2007, 17:05

Re: The end of the maintenance branch

Post by ivand »

PicassoCT wrote: 18 Oct 2020, 21:57 So the problem is us gamedevs, who need to rewrite our stack partially?
Yes, modern OpenGL requires that unfortunately. Game-side you can put together a small Lua lib that would abstract common vertex types and attach basic shaders.
abma
Spring Developer
Posts: 3655
Joined: 01 Jun 2009, 00:08

Re: The end of the maintenance branch

Post by abma »

@ivand:

as i have few time and i don't see a future for 32bit builds atm, i guess its time to get rid of them. this solves some disk space issues / buildbot worker resource issues, too. When looking forward IMHO we can't deal well with 32 bit crash reports i guess. So setting up springlobby x64 + linux64 buildbot worker is next on my todo list.
User avatar
ivand
Posts: 197
Joined: 27 Jun 2007, 17:05

Re: The end of the maintenance branch

Post by ivand »

abma wrote: 19 Oct 2020, 11:10 as i have few time and i don't see a future for 32bit builds atm, i guess its time to get rid of them.
I think it's a great decision. I discussed it briefly with Kloot once and he was leaning towards doing the same. I hope hoko and gajop don't mind too.
abma wrote: 19 Oct 2020, 11:10 this solves some disk space issues / buildbot worker resource issues, too.
I heard your stance re: public services loud and clear, but this exactly what public services are good for: they take the infra pain out, so you can focus on the matters, other than upgrading OSes or dealing with disk space.
User avatar
Beherith
Moderator
Posts: 4983
Joined: 26 Oct 2007, 16:21

Re: The end of the maintenance branch

Post by Beherith »

abma wrote: 19 Oct 2020, 11:10 @ivand:
So setting up springlobby x64 + linux64 buildbot worker is next on my todo list.
x64 springlobby sounds like absolute wonder! Thank you for your work, abma!
gajop
Moderator
Posts: 3040
Joined: 05 Aug 2009, 20:42

Re: The end of the maintenance branch

Post by gajop »

abma wrote: 19 Oct 2020, 11:10 @ivand:

as i have few time and i don't see a future for 32bit builds atm, i guess its time to get rid of them. this solves some disk space issues / buildbot worker resource issues, too. When looking forward IMHO we can't deal well with 32 bit crash reports i guess. So setting up springlobby x64 + linux64 buildbot worker is next on my todo list.
I thought there might be some issues with windows 64bit pr-downloader engine download mechanism. It doesn't download or extract the engine correctly and it's why spring-launcher still uses the 32bit version.

This is from memory hence why I haven't created an issue yet.
User avatar
ivand
Posts: 197
Joined: 27 Jun 2007, 17:05

Re: The end of the maintenance branch

Post by ivand »

@abma, I noticed my github build of linux-64 engine is built with shared libs only, so I wanted to follow the official build example and set "-DPREFER_STATIC_LIBS:BOOL=1" for cmake to link it mostly statically, unfortunately it didn't go well at all. During the "make all" stage I'm getting tons of linker error. Some examples:

Code: Select all

/usr/lib/gcc/x86_64-linux-gnu/10/../../../x86_64-linux-gnu/libtiff.a(tif_zstd.o):function ZSTDVSetField: error: undefined reference to 'ZSTD_maxCLevel'
/usr/lib/gcc/x86_64-linux-gnu/10/../../../x86_64-linux-gnu/libtiff.a(tif_webp.o):function TWebPCleanup: error: undefined reference to 'WebPPictureFree'
/usr/lib/gcc/x86_64-linux-gnu/10/../../../x86_64-linux-gnu/libtiff.a(tif_lzma.o):function TIFFInitLZMA: error: undefined reference to 'lzma_lzma_preset'
/usr/lib/gcc/x86_64-linux-gnu/10/../../../x86_64-linux-gnu/libtiff.a(tif_jbig.o):function JBIGDecode: error: undefined reference to 'jbg_dec_free'
/usr/lib/gcc/x86_64-linux-gnu/10/../../../x86_64-linux-gnu/libIL.a(libIL_la-il_mng.o):function iLoadMngInternal: error: undefined reference to 'mng_display'
I certainly have "-dev" versions of aforementioned libs installed on the build host (zstd, mng, etc), still it doesn't pick them up. Looks like something is missing. Do you do any prep step to remedy issues like this?

[Added later] I'll be more specific maybe:
https://buildbot.springrts.com/#/builders/6/builds/10 logs show that it uses

Code: Select all

-DIL_IL_HEADER:PATH=/home/buildbot/lib/include/IL/il.h -DIL_INCLUDE_DIR:PATH=/home/buildbot/lib/include -DIL_IL_LIBRARY:PATH=/home/buildbot/lib/lib/libIL.a -DIL_LIBRARIES:PATH=/home/buildbot/lib/lib/libIL.a -DILU_LIBRARIES:PATH=/home/buildbot/lib/lib/libILU.a -DPNG_PNG_INCLUDE_DIR:PATH=/home/buildbot/lib/include -DPNG_LIBRARY_RELEASE:PATH=/home/buildbot/lib/lib/libpng.a -DJPEG_INCLUDE_DIR:PATH=/home/buildbot/lib/include -DJPEG_LIBRARY:PATH=/home/buildbot/lib/lib/libjpeg.a -DTIFF_INCLUDE_DIR:PATH=/home/buildbot/lib/include -DTIFF_LIBRARY_RELEASE:PATH=/home/buildbot/lib/lib/libtiff.a -DZLIB_INCLUDE_DIR:PATH=/home/buildbot/lib/include -DZLIB_LIBRARY_RELEASE:PATH=/home/buildbot/lib/lib/libz.a -DBZIP2_INCLUDE_DIR:PATH=/home/buildbot/lib/include -DBZIP2_LIBRARIES:PATH=/home/buildbot/lib/lib/libz.a -DGLEW_INCLUDE_DIR:PATH=/home/buildbot/lib/include -DGLEW_LIBRARIES:PATH=/home/buildbot/lib/lib/libGLEW.a -DLIBUNWIND_INCLUDE_DIRS:PATH=/home/buildbot/lib/include -DLIBUNWIND_LIBRARY:PATH=/home/buildbot/lib/lib/libunwind.a -DCURL_INCLUDE_DIR:PATH=/home/buildbot/lib/include -DCURL_LIBRARY:PATH=/home/buildbot/lib/lib/libcurl.a -DOPENSSL_INCLUDE_DIR:PATH=/home/buildbot/lib/include -DOPENSSL_SSL_LIBRARY:PATH=/home/buildbot/lib/lib/libssl.a -DOPENSSL_CRYPTO_LIBRARY:PATH=/home/buildbot/lib/lib/libcrypto.a
I wonder where does `/home/buildbot/lib/` content stem from?
User avatar
ivand
Posts: 197
Joined: 27 Jun 2007, 17:05

Re: The end of the maintenance branch

Post by ivand »

Thanks @abma, manual compilation of dependencies seems to work, however I didn't manage to make it work in a generic way by means of pkg-config.
I'm willing to take a few lessons how to integrate pkg-config & cmake.

P.S. Actually it doesn't. I'm getting a lot of linker errors about the libs that are not built here: https://github.com/spring/spring-lxc/bl ... ic_libs.sh
User avatar
PicassoCT
Journeywar Developer & Mapper
Posts: 10344
Joined: 24 Jan 2006, 21:12

Re: The end of the maintenance branch

Post by PicassoCT »

Eh, sorry to bother- but if one wanted to develop a future safe game- against which branch should one develop?
I looked at the network graph on github.
I tried to look for a branch forking from develop, but there is only maintenance, then transition, then bar.
Develop not merged into that.

Sorry, if that was answered earlier in depth..
User avatar
ivand
Posts: 197
Joined: 27 Jun 2007, 17:05

Re: The end of the maintenance branch

Post by ivand »

I wouldn't encourage to follow BAR version of the engine. It's untested in the fields and we generally aim it to serve as a testing ground for the improvements that would then hopefully go into the official transition branch ( though I also integrated a few convenience means like https://github.com/spring/spring/pull/535 ).

Overall when choosing the engine flavor there is quite something to consider:
* maintenance has huge accrued GL assets (widgets/gadgets/libs/UI/shaders) and it's very lenient to potato GPUs.
* transition is supposed to stay compatible to the maintenance, while gracefully introducing new GL concepts. As far as existing game is concerned one should not notice any difference between the maintenance and transition no matter how bad their GPU is. That said in order to start using the new GL the support for shaders and modern GL is mandatory.
* develop simply won't run on old GL drivers/GPU. It's very fast and the only engine streamlined for future.

Needless to say maintaining three engine versions is a big effort and I personally prefer that the focus is put on the transition and develop.
User avatar
PicassoCT
Journeywar Developer & Mapper
Posts: 10344
Joined: 24 Jan 2006, 21:12

Re: The end of the maintenance branch

Post by PicassoCT »

So if i have a game, that has no great player base yet- transition it is?

Is there a sort of compatability layer for chili and other widgetry?
User avatar
ivand
Posts: 197
Joined: 27 Jun 2007, 17:05

Re: The end of the maintenance branch

Post by ivand »

I'm afraid for now I have no good news on that front. Transition API is not finalized, thus none of the porting work started yet.
User avatar
PicassoCT
Journeywar Developer & Mapper
Posts: 10344
Joined: 24 Jan 2006, 21:12

Re: The end of the maintenance branch

Post by PicassoCT »

It would be great to have a way to download current builds of the transition and develop against that. Where do i get one? Or even better, could we host a 105.0 battleroom with the abc-game?
abma
Spring Developer
Posts: 3655
Joined: 01 Jun 2009, 00:08

Re: The end of the maintenance branch

Post by abma »

PicassoCT wrote: 02 Nov 2020, 21:35 It would be great to have a way to download current builds of the transition and develop against that. Where do i get one? Or even better, could we host a 105.0 battleroom with the abc-game?
atm there is only a win64 build available: https://api.springfiles.com/?springname ... transition

springlobby win64 is experimental, but maybe works for you: https://springlobby.springrts.com/dl/de ... -win32.zip

see https://github.com/springlobby/springlobby/issues/977 for progress.
User avatar
ivand
Posts: 197
Joined: 27 Jun 2007, 17:05

Re: The end of the maintenance branch

Post by ivand »

The current transition only has LuaMatrix, a matrix manipulation API stand-alone from OpenGL's implementation (gl.Translate,Rotate,Scale,Push/Pop,Load) etc. This the way modern OpenGL operates (core profile removed matrix manipulation lib).

In the same time I must warn that the interface is not stable yet, moreover I'm still contemplating about an alternative interface based on hiding underlying implementation under the hood of the existing (gl.Translate,Rotate,Scale,Push/Pop,Load) calls because it's the way the develop does it currently. The final decision on the direction is pending real life code and UX testing.
abma
Spring Developer
Posts: 3655
Joined: 01 Jun 2009, 00:08

Re: The end of the maintenance branch

Post by abma »

so, springlobby x64 on windows seems to work fine: my next step is to upgrade the linux64 buildbot worker to a newer gcc.

When should springlobby x64 be released? It will "migrate" all windows users to a x64 engine and so be a harmful step (again).

I'm a bit undecided in which order i should do these steps:

1. upgrade the buildbot worker linux64 to gcc 10.2
2. remove linux32 + windows32 buildbot worker
3. release springlobby win64

any thoughts about this? i plan to announce the migration to win64 a few days before springlobby win64 is released.
User avatar
ivand
Posts: 197
Joined: 27 Jun 2007, 17:05

Re: The end of the maintenance branch

Post by ivand »

Hard to say.
Probably #3, though biggest games I'm aware of seem to converge on using chobby.
#2. I have nothing against 32 bit builds, except they don't work for modern spring games. You can leave build-bots intact if you consider not doing "harmful step (again)" is important.
#1. Is explored territory by now, give me a ping if you happen stumble upon something.
User avatar
Hoi
Posts: 2913
Joined: 13 May 2008, 16:51

Re: The end of the maintenance branch

Post by Hoi »

Spring has been "behind" for too long.

A big renovation is needed. I haven't posted in nearly 8 years but posting to voice my support for shaking things up.

We should be fine with breaking compatibility with legacy games, legacy 32-bit systems, legacy OpenGL.
Legacy mindsets have to go with that.

It will be awesome to see a modern version of spring. If everything is merged and transitioned, the old ballast shaken off, that might actually motivate me, and others, to contribute to development.

Game devs should be accepting of this process, and the potential breaking that it will do to their games.
This might be the course of action which can make spring popular again.
Thanks everyone who is working on this.
User avatar
PicassoCT
Journeywar Developer & Mapper
Posts: 10344
Joined: 24 Jan 2006, 21:12

Re: The end of the maintenance branch

Post by PicassoCT »

I guess you are right.
Then again, the amount of "can we keep this alive" speaks volumes for the success spring is & was. You dont get legacy problems with out a legacy.
User avatar
ivand
Posts: 197
Joined: 27 Jun 2007, 17:05

Re: The end of the maintenance branch

Post by ivand »

Thanks Hoi!

A short update: currently I'm dealing with bugs that occur in very specific setups. Systems, I and other beta testers have, do not reproduce the bug, but I hope to get hold of someone I can troubleshoot the issue with.
raaar
Metal Factions Developer
Posts: 874
Joined: 20 Feb 2010, 12:17

Re: The end of the maintenance branch

Post by raaar »

There haven't been any maintenance builds since 1553.

Are the devs deliberately inactive or is there something broken in the process?

On github there are several open PR, some are months old.
https://github.com/spring/spring/pulls
Spring has been "behind" for too long.

A big renovation is needed. I haven't posted in nearly 8 years but posting to voice my support for shaking things up.

We should be fine with breaking compatibility with legacy games, legacy 32-bit systems, legacy OpenGL.
Legacy mindsets have to go with that.

It will be awesome to see a modern version of spring. If everything is merged and transitioned, the old ballast shaken off, that might actually motivate me, and others, to contribute to development.
I'm one of the game devs that kept going and uses legacy stuff (.fbi, .tdf files, 3do, lua gl stuff that requires the maintenance branch). I may adapt to some things but not others, it depends...I see many flaws on the engine that seem unrelated to gl stuff.

Software developers have these urges to rebuild things from scratch. They'll have a burst of productivity, post pretty pictures, generate hype, then run into troublesome stuff again and again and run out of steam over time and eventually give up.

The skeptical me thinks that, at best, this would end up replacing a set of half-finished pieces of software with significant issues with another.
Post Reply

Return to “Engine”