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.
The end of the maintenance branch
Moderator: Moderators
Re: The end of the maintenance branch
@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.
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.
Re: The end of the maintenance branch
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.
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.
Re: The end of the maintenance branch
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.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.
This is from memory hence why I haven't created an issue yet.
Re: The end of the maintenance branch
@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:
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
I wonder where does `/home/buildbot/lib/` content stem from?
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'
[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
Re: The end of the maintenance branch
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
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
Re: The end of the maintenance branch
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..
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..
Re: The end of the maintenance branch
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.
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.
Re: The end of the maintenance branch
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?
Is there a sort of compatability layer for chili and other widgetry?
Re: The end of the maintenance branch
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.
Re: The end of the maintenance branch
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?
Re: The end of the maintenance branch
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.
Re: The end of the maintenance branch
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.
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.
Re: The end of the maintenance branch
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.
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.
Re: The end of the maintenance branch
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.
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.
Re: The end of the maintenance branch
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.
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.
Re: The end of the maintenance branch
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.
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.
Re: The end of the maintenance branch
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.
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.
Re: The end of the maintenance branch
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
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.
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
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.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.
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.