Dev meeting minutes 2017-07-07

Dev meeting minutes 2017-07-07

Minutes of the meetings between Spring developers are archived here.
abma
Spring Developer
Posts: 3540
Joined: 01 Jun 2009, 00:08

Dev meeting minutes 2017-07-07

Post by abma » 10 Jul 2017, 06:53

Present: jK, hokomoko, Kloot, abma

Opengl 4.1 / release

<Kloot>let's start with the elephant in the room
<hokomoko>ok
<hokomoko>opengl?
<Kloot>might as well
<abma>hokomoko: yes
<hokomoko>woohoo
<hokomoko>Kloot my understanding of your view is according to this: https://springrts.com/mantis/view.php?id=5620#c17895
<hokomoko>in general, as I see it, you want to make spring better and more modern, which is mutually exclusive with retaining backward compatibility with everything
<Kloot>indeed
<Kloot>I do get the sentiment of wanting to maintain that compability, it's noble but imo misguided
<Kloot>things that remain stagnant tend to wither and die, from cultures to empires to rts engine hobby projects
<hokomoko>my view is rather more pessimistic
<hokomoko>I believe that RTS is becoming less and less popular, that we won't see any new big games being started in spring and that our best course of action is to have the most fun we can with what we have
<hokomoko>what's even worse, is that there isn't a single graphically strong person in the community atm
<abma>maybe a short summary from my point of view. with the current enforcement to opengl 4.1 i can't run spring as the (os) gfx driver for my card only supports opengl 3.1. i'm using debian which has an older mesa version which will be updated at some point with the current release.
<abma>so my question here is: is there an "instant" benefit when we force opengl 4.1?
<Kloot>abma: no "instant" benefit, it'll take work which will have to be done piece by piece between releases
<hokomoko>for instance, check the LOD system. entirely unused.
<hokomoko>there's no one to make the models
<hokomoko>so if you make PBR and fancy new stuff, yes the engine will be more modern, but I don't think it will see any use
<hokomoko>as to withering, definitely yes
<hokomoko>at the moment we're heading there
<hokomoko>the only question is the speed
<Kloot>well, imo part of the reason is that people wouldn't feel attracted to make games in an obsolete engine
<Kloot>the existing ones for the most part date back many many years
<hokomoko>I definitely agree with what you say
<hokomoko>I'm just not convinced that:
<hokomoko>1) we have the manpower to modernise spring
<hokomoko>2) people will come once spring is modern
<Kloot>now you can be fatalistic and say "that's life" but I don't want to give up so easily
<hokomoko>a small bit of information btw, FreeSpace 2 had a similar choice a few months ago
<hokomoko>they decided to use Core profile instead of compat, and basically require GL3
<Kloot>there's no way to predict 2), but new folks definitely won't come if we keep the status quo
<hokomoko>how much are you willing to sacrifice in order to find out?
<Kloot>is there much left to sacrifice? it seems to me the writing is on the wall already
<hokomoko>kinda
<hokomoko>I have a suggestion though
<hokomoko>some sort of a compromise
<hokomoko>I think it'd be fair to give the current players/games a stable version with backward compatibility
<hokomoko>unmaintained
<hokomoko>so if someone wants to backport patches, it's their problem
<hokomoko>after that, spring advances into the new age and gives 0 fucks
<Kloot>backward meaning 104.0 with GL3 requirement or even lower?
<hokomoko>I'm ok with GL3
<abma>can't we just remove the restriction and readd it when features are used which require it?
<Kloot>abma: that's already the case
<abma>atm it mostly has drawbacks. without any benefit its difficult to have acceptance from players or game devs
<hokomoko>hmm? where are we using GL4
<Kloot>decaldrawer, but I meant GL3 features
<hokomoko>ah yes
<hokomoko>these are used
<Kloot>anyway I can accept a GL3 minimum for 104.0 if the release is planned soonish
<hokomoko>well, what do we need to do before release?
<hokomoko>abma_irc no chance for builders upgrade, right?
<Kloot>there is crap on the roadmap, dunno how relevant
<abma>seems unrealistic
<hokomoko>so, the SDL crap will be done and the rest isn't important I guess
<hokomoko>French people are pissed for ages that they can't draw on the map or something
<hokomoko>other than the roadmap?
<abma>the hard work basicly is done, it have currently more issues with setting the vms up. for organizational reasons i have to run the x32 / x64 as one vm
<hokomoko>I see
<abma>there a lot of possibilites to do so (chroot / docker / etcetc)... but it has to be done.
<hokomoko>Kloot can we RC and feature freeze at the moment?
<abma>i don't see any real release blocker, too
<Kloot>I think so, don't see major bugs left to fix and I have no features in the pipe
<hokomoko>good
<hokomoko>I have a small perl thing that I need to do for SPADS before 104.0 release
<hokomoko>but I can probably do it this weekend or something
<abma>ah, the unitsync stuff?
<hokomoko>ya
<hokomoko>I promised :S
<hokomoko>so 104.0 RC1 with GL3 asap?
<abma>+1 :)
<Kloot>+1
<hokomoko>superb
<hokomoko>next item


Why mempools?
<hokomoko>fragmentation
<hokomoko>spring.reload needs this pretty much
<hokomoko>now for discord
<abma>yeah, that was answered some time later after i added it as topic
<abma>Kloot: the commit messages when mempool was added werent this clear why it was added
<abma>(IMO)
<Kloot>perhaps, but the dozens of ZK reports should have been if you followed them
<Kloot>all with OOM's as common theme
<abma>yeah, i/others noticied this, too... but a bit late
<Kloot>also mempools are really gamedev 101
<abma>so thats no real issue, it was just missing understanding why it was done
<hokomoko>k

Discord and lobby chat
<hokomoko>nowadays I'm using discord almost exclusively to monitor the lobby chat, so I'm very skewed
<abma>there is also webchat
<abma>https://springrts.com/webchat/
<hokomoko>that's what I'm using atm
<hokomoko>but I have discord on my phone
<hokomoko>also
<abma>i'm a bit undecided about discord, the benefits aren't this big for the spring community imo
<hokomoko>discord allows me to converse with both spring and ZK servers without using two apps
<hokomoko>I think the benefit of keeping in touch with the ZK part are big
<abma>yep
<abma>i really dislike the discord thing: how it was added without any notice
<hokomoko>fair enough
<abma>also its unclear if with our current TOS its allowed to do it at all
<abma>at least some note must be added
<hokomoko>agreed
<hokomoko>so the solution should be to limit 3rd party logging to some channels?
<Kloot>I haven't followed that controversy but services with draconian TOS'es, while convenient, are imo not a good idea to rely on heavily
<hokomoko>the ToS isn't too draconian imo, more of a cover our asses
<hokomoko>abma this points the options nicely viewtopic.php?p=582505#p582505

<abma>wrt discord
<abma>announce a ToS change starting in a week from now / afterwhich channels can only be bridged/logged if they have an appropriate warning
<abma>i'm personally really against the discord thing at all... but i guess there a lot of people who wants it
<abma>Kloot [LCC]jK: any opinion on this? else i'm done, too
<Kloot>announcing the change in advance sounds good
<Kloot>in general it would be nicer not to have two separate universes but that bridge seems crossed
<hokomoko>indeed
<abma>so, thanks a lot for your time! :)


Donations
<abma>ah: kloot: wrt donations. i guess we received nothing?
<abma>if so, i guess i/we should try to bump it a bit more with the release?!
<abma>i'll do a spring test round... it seems we are already back in business :)
<Kloot>nope, check bitref
<abma>ok
<abma>Kloot: bitcoin address is still valid? maybe thats most important :D
<Kloot>I didn't delete the wallet so no worries
<abma>ok
0 x

abma
Spring Developer
Posts: 3540
Joined: 01 Jun 2009, 00:08

Re: Dev meeting minutes 2017-07-07

Post by abma » 10 Jul 2017, 07:00

wrt discord: https://github.com/ZeroK-RTS/Zero-K-Inf ... ssues/1765

updated TOS for uberserver will follow.

site note: we have already a webchat: https://springrts.com/webchat/
0 x

gajop
Moderator
Posts: 3022
Joined: 05 Aug 2009, 20:42

Re: Dev meeting minutes 2017-07-07

Post by gajop » 10 Jul 2017, 08:20

I was really happy to see new dev meeting minutes, and I hope there will be more of them in the near future.
You should be more optimistic with the future of Spring though :roll:
If you think that the RTS genre is dying, you can always help make Spring better for making GSGs, city/base builders, turn based games, and similar. I think we are rather suitable for that, although I know some people that may disagree :wink:

I don't see why you guys are discussing Discord. What does that have to do with engine development?
It's also bizarre to see this topic taking so much attention after we've had https://springrts.com/wiki/MelBot for nearly a decade.

Can we have some discussion about new engine features? Is anything planned/wanted? OpenGL restrictions are fine and all, but they seem pointless to enforce unless there are things using them (and even the GL4 decal system is unfinished the last I checked).
0 x

abma
Spring Developer
Posts: 3540
Joined: 01 Jun 2009, 00:08

Re: Dev meeting minutes 2017-07-07

Post by abma » 10 Jul 2017, 09:04

I don't see why you guys are discussing Discord. What does that have to do with engine development?
It's also bizarre to see this topic taking so much attention after we've had https://springrts.com/wiki/MelBot for nearly a decade.
#sy is the development channel of spring and Nightwatch bridges it to zero-k and discord. Melbot/irc doesn't store chats as default, so this is a huge difference.
gajop wrote: Can we have some discussion about new engine features? Is anything planned/wanted? OpenGL restrictions are fine and all, but they seem pointless to enforce unless there are things using them (and even the GL4 decal system is unfinished the last I checked).
it comes to "pull requests are welcome".
0 x

gajop
Moderator
Posts: 3022
Joined: 05 Aug 2009, 20:42

Re: Dev meeting minutes 2017-07-07

Post by gajop » 10 Jul 2017, 09:19

abma wrote:#sy is the development channel of spring and Nightwatch bridges it to zero-k and discord. Melbot/irc doesn't store chats as default, so this is a huge difference.
It's really not, as Melbot retransmits everything. Any third party can separately create a logger bot on IRC, and as it doesn't connect to the Spring infrastructure, it doesn't have to abide by server TOS and can freely log data.
Storing doesn't matter, sharing (retransmitting does), and it's important to be clear there.

I've read your TOS update on https://github.com/spring/uberserver/issues/217 and I agree with it. It treats IRC, Discord and any other potential network as equals. I assume that #moddev and #sy will not be +s nor +p, and that it will be possible to set (and read) +s and +p on channels using the lobby API.
abma wrote:it comes to "pull requests are welcome".
So, like "no plans, we're agile"? :p
0 x

abma
Spring Developer
Posts: 3540
Joined: 01 Jun 2009, 00:08

Re: Dev meeting minutes 2017-07-07

Post by abma » 10 Jul 2017, 09:33

gajop wrote:It's really not, as Melbot retransmits everything. Any third party can separately create a logger bot on IRC, and as it doesn't connect to the Spring infrastructure, it doesn't have to abide by server TOS and can freely log data.
Storing doesn't matter, sharing (retransmitting does), and it's important to be clear there.
1. a note about melbot exists in the topic of #sy that it retransmits
2. ircnet / freenode TOS basicly disallow such bots

the issue is not that chat could / can be logged, the issue is that it is logged by default and all history can be read by someone who wasn't in the channel. He just needs to login at discord and then can browse all historical data. Maybe better in short: discord publishes all chats to the public. Without it, you need to be logged in. They have no policy about deleting chats / logs afaik.
0 x

hokomoko
Spring Developer
Posts: 575
Joined: 02 Jun 2014, 00:46

Re: Dev meeting minutes 2017-07-07

Post by hokomoko » 10 Jul 2017, 09:36

Our Plans:
1) Feature freeze until 104.0 (RC is nigh)
After that:
2) Kloot plans to overhaul rendering and enable newer tech (GL4)
3) I'm not sure if I'll have the time, but I hope to do serialization of lua so we have real save/load

What plans did you have in mind?
1 x

gajop
Moderator
Posts: 3022
Joined: 05 Aug 2009, 20:42

Re: Dev meeting minutes 2017-07-07

Post by gajop » 10 Jul 2017, 09:54

hokomoko wrote:1) Feature freeze until 104.0 (RC is nigh)
I've read this in the log, but more info like this is welcome.
hokomoko wrote:Kloot plans to overhaul rendering and enable newer tech (GL4)
I'd like to know what things in particular are planned to change. "Rendering" is just way too broad, and doesn't allow me to simultaneously plan the SpringBoard editing tools. Some features were once mentioned in a list in the "OpenGL 4" mantis issue before, but I'd like to see concrete things.
hokomoko wrote:3) I'm not sure if I'll have the time, but I hope to do serialization of lua so we have real save/load
This is again useful information. I would like to see if you can make the serialization available as an API, perhaps similar to my s11n lib? Serializing the entire state is of course probably enough for basic save game support, but also partial state serialization (such as per-unit or per-feature) would be useful for many things.
hokomoko wrote:What plans did you have in mind?
Generally I'd like to learn what engine devs intend to do or are in the process of doing. Not so much as to checkup on them, but to have an idea where the engine is going and how I can work in parallel.

To give my example of my future engine work plan as a contributor:
1) Expose control over more things to Lua as needed.
2) Expose/refactor the existing code for (new) map (procedural) generation so it is usable/customizable via Lua. Hokomoko is aware of this idea, but generally the plan is to allow content (maps, games) create arbitrary map generation, probably by specifying script files which are invoked before heightmap/diffuse is loaded. I'm leaving the specifics out atm.
0 x

hokomoko
Spring Developer
Posts: 575
Joined: 02 Jun 2014, 00:46

Re: Dev meeting minutes 2017-07-07

Post by hokomoko » 10 Jul 2017, 09:58

gajop wrote:This is again useful information. I would like to see if you can make the serialization available as an API, perhaps similar to my s11n lib? Serializing the entire state is of course probably enough for basic save game support, but also partial state serialization (such as per-unit or per-feature) would be useful for many things.
I don't think partial serialisation is possible with the current architecture. It's pretty much all or nothing. I highly doubt there'll be an engine solution for that.
A lua ~solution is possible though.
0 x

Super Mario
Posts: 814
Joined: 21 Oct 2008, 02:54

Re: Dev meeting minutes 2017-07-07

Post by Super Mario » 10 Jul 2017, 17:35

"Rts genre is dying"
People literally say the same thing regarding click and point adventure games and space simulations in the past.
It's a niche genre, there is nothing wrong with that. You just need good size amount of costumer loyalist when making a niche game and setting a reasonable budget.

Here are my suggestions:
-If manpower is an issue than you need to actively look for new blood. Too many people working on open source projects falsely assume that people will come to help work on their project when it's barely heard of in the first place. This is not a well known engine despite having an article on wikipedia.
- the engine is created to serve the needs of the game, not the other way around. Prime example of not following this is Cyrtek and their crysis games. I keep telling fanboys that the first game is essentially a tech demo made to showcase their engine, despite being good. The game went mutliplatfornm because A) the CEO are notorious for chasing bandwagons B) to (again) showcase their engine. Now we have a same company that didn't pay their employees for MONTHS while the majority of the engine developers migrate to starcitizen. That how bad it was and still is.
-Spring engine is indirectly competing with other engines, most noticeably unreal and unity engines in terms of getting a potential game developer interest. If you want people to develop games on the spring engine then you must offer something that the other engines don't have, something that is a MUST HAVE to draw in game developers.
-What you can accomplish as an unpaid volunteer compare to a full time employee is typically very small (unless you have a lot of time on your hands). There are people out there willing to finance the spring engine development. Consider you finance options.
-Try considering duel license the engine in similar way to how qt does it. The reason being is that the gpl is not ideal language to many people looking to commercialize their game.
0 x

Super Mario
Posts: 814
Joined: 21 Oct 2008, 02:54

Re: Dev meeting minutes 2017-07-07

Post by Super Mario » 10 Jul 2017, 18:27

edit: never mind, see thread in general discussions.
Last edited by Super Mario on 10 Jul 2017, 19:10, edited 1 time in total.
0 x

gajop
Moderator
Posts: 3022
Joined: 05 Aug 2009, 20:42

Re: Dev meeting minutes 2017-07-07

Post by gajop » 10 Jul 2017, 18:38

Sure, go ahead. Those are not features though, just some optimizations.
0 x

Super Mario
Posts: 814
Joined: 21 Oct 2008, 02:54

Re: Dev meeting minutes 2017-07-07

Post by Super Mario » 10 Jul 2017, 19:00

gajop wrote:Sure, go ahead. Those are not features though, just some optimizations.
edit: see new thread in general discussions.
0 x

raaar
Metal Factions Developer
Posts: 805
Joined: 20 Feb 2010, 12:17

Re: Dev meeting minutes 2017-07-07

Post by raaar » 11 Jul 2017, 07:10

when asked about the benefits of changing to openGL 4.1:
[quote=Kloot]Instancing, tessellation, compute shaders, async drawcalls, VAO's, PBR, ... crap that any decent midrange card is capable of these days but we have no access to.

It's like asking "what's the benefit of shaders?" when all you know is the FFP. [/quote]

what does that mean exactly? What impact will those have on performance? What kind of effects will they allow?

GoogleFrog's description says his data shows that nearly half the ZK user base doesn't seem to support it. That's worrying.

Do the users with ubuntu linux generally support opengl 4.1? There seem to be issues with gpu drivers on those, even on recent versions:
https://askubuntu.com/questions/900950/ ... p-question
https://askubuntu.com/questions/713586/ ... opengl-4-1

And why must it be one or the other? I wonder how hard will it be to have a fallback for non-compatible cards.
0 x

gajop
Moderator
Posts: 3022
Joined: 05 Aug 2009, 20:42

Re: Dev meeting minutes 2017-07-07

Post by gajop » 11 Jul 2017, 08:10

raaar wrote:
Kloot wrote:Instancing, tessellation, compute shaders, async drawcalls, VAO's, PBR, ... crap that any decent midrange card is capable of these days but we have no access to.
what does that mean exactly? What impact will those have on performance? What kind of effects will they allow?
Most of those concepts can be googled, and generally they either bring performance boosts, graphical enhancements or new capabilities.
raaar wrote: GoogleFrog's description says his data shows that nearly half the ZK user base doesn't seem to support it. That's worrying.
We're still waiting on the latest update of the ZK population, but anyway, I don't think we should cater to outdated systems forever.
raaar wrote:Do the users with ubuntu linux generally support opengl 4.1?
yes

Code: Select all

~ glxinfo | grep "OpenGL version"
OpenGL version string: 4.5.0 NVIDIA 375.39
0 x

User avatar
zwzsg
Kernel Panic Co-Developer
Posts: 7014
Joined: 16 Nov 2004, 13:08

Re: Dev meeting minutes 2017-07-07

Post by zwzsg » 11 Jul 2017, 20:07

Would migrating to newer OpenGL automagically makes every Spring game look better?

Are there game devs with the will, time, and competence, to take advantage of newer OpenGL to make a pretty flagship game?

Maybe it's an egg and chicken problem, but it's important to identify who'll make the pretty assets to go with the pretty engine.



Unity is popular not because of performance, but because of the ease of use and massive amount of tutorial, tools, and third party libraries & asset packs. Our wiki's is pretty good (though Löve2D's wiki better), so I am not sure how to improve on that front. Maybe better tools? mapconv and UpSpring haven't been touched in ages for instance.
0 x

dansan
Server Owner & Developer
Posts: 1190
Joined: 29 May 2010, 23:40

Re: Dev meeting minutes 2017-07-07

Post by dansan » 12 Jul 2017, 08:37

Would it help with the discussion about OpenGL versions, if I analyse the replays (which do not include ZK!)? The data that can be found in them is:

Code: Select all

CPU:  Intel i7-7700K CPU @ 4.20GHz
CPU cores:  4 / 8
RAM:  32727MB
GPU:   GeForce GTX 1080 Ti
GPU VRAM:   11264MB
1732x1150:24bit @59Hz (windowed)
OS:  Windows

CPU cores:  6 / 12
GPU:   GeForce GTX 770
GPU VRAM:   2048MB
2560x1420:24bit @59Hz (windowed)
OS:  Linux

CPU cores:  1 / 4
GPU:   Intel Graphics 550
1440x786:32bit @60Hz (windowed)
OS:   Darwin 16.6.0 Darwin Kernel Version 16.6.0: Fri Apr 14 16:21:16 PDT 2017; root:xnu-3789.60.24~6/RELEASE_X86_64 x86_64
Not all games seem to produce such a luamsg however. I've seen it in BA and EvoRTS, not in TechA or ZK, didn't test others.
The driver in use is only in the infolog :/ But maybe that can be dumped from lua too?
0 x

gajop
Moderator
Posts: 3022
Joined: 05 Aug 2009, 20:42

Re: Dev meeting minutes 2017-07-07

Post by gajop » 12 Jul 2017, 08:57

dansan wrote:Would it help with the discussion about OpenGL versions, if I analyse the replays (which do not include ZK!)?
Yes. Raw data for unique users helps the most.
dansan wrote:The driver in use is only in the infolog :/ But maybe that can be dumped from lua too?
It exists in the Platform table (newer engines should have it).
Example:

Code: Select all

[f=0000380] $ table.echo(Platform)
[f=0000380] return {
  glRenderer = "GeForce GTX 760/PCIe/SSE2",
  glVendor = "NVIDIA Corporation",
  glVersion = "4.5.0 NVIDIA 375.39",
  glVersionShort = "4.5.0",
  glewVersion = "1.13.0",
  glslVersion = "4.50 NVIDIA",
  glslVersionShort = "4.50",
  gpu = "GeForce GTX 760/PCIe/SSE2",
  gpuMemorySize = 2048,
  gpuVendor = "Nvidia",
  osFamily = "Linux",
  osName = "Linux 4.8.0-58-generic #63~16.04.1-Ubuntu SMP Mon Jun 26 18:08:51 UTC 2017 x86_64",
  sdlVersionCompiledMajor = 2,
  sdlVersionCompiledMinor = 0,
  sdlVersionCompiledPatch = 4,
  sdlVersionLinkedMajor = 2,
  sdlVersionLinkedMinor = 0,
  sdlVersionLinkedPatch = 4,
}
0 x

gajop
Moderator
Posts: 3022
Joined: 05 Aug 2009, 20:42

Re: Dev meeting minutes 2017-07-07

Post by gajop » 12 Jul 2017, 09:07

zwzsg wrote:Would migrating to newer OpenGL automagically makes every Spring game look better?
Now? With nothing implemented? No. In the future? Yes, some features may require very little work for the content devs to use. Others may be rather time consuming and require complete rework.
zwzsg wrote:Are there game devs with the will, time, and competence, to take advantage of newer OpenGL to make a pretty flagship game?
Yes. Additionally, you can be sure that there won't be any "pretty flagship game" if we become (remain) stale.
zwzsg wrote:Unity is popular not because of performance, but because of the ease of use and massive amount of tutorial, tools, and third party libraries & asset packs. Our wiki's is pretty good (though Löve2D's wiki better), so I am not sure how to improve on that front. Maybe better tools? mapconv and UpSpring haven't been touched in ages for instance.
Unity already has most features that we are now considering to maybe implement. Additionally, afaik, it relies entirely on shaders while we still have FFP and ARB nonsense in the engine. We need modern rendering support if we want to compete.

UpSpring shouldn't exist. Map compilers aren't going to bring anything new.

The lowest hanging fruit right now is creating a map shader framework and utilizing custom map shaders that kloot has developed.
1 x

dansan
Server Owner & Developer
Posts: 1190
Joined: 29 May 2010, 23:40

Re: Dev meeting minutes 2017-07-07

Post by dansan » 12 Jul 2017, 10:42

gajop wrote:
dansan wrote:Would it help with the discussion about OpenGL versions, if I analyse the replays (which do not include ZK!)?
Yes. Raw data for unique users helps the most.
Uniqueness can be created by associating the platform data with the user account. Ignoring smurf-accounts is IMHO statistically no problem.
gajop wrote:
dansan wrote:The driver in use is only in the infolog :/ But maybe that can be dumped from lua too?
It exists in the Platform table (newer engines should have it).
Example:

Code: Select all

[f=0000380] $ table.echo(Platform)
[..]
If such a collection of platform statistics is desired, game devs have to implement it. A common format is desirable.

Alternatively to dumping it into the demofile, the data could be sent to a to-be-created stats.springrts.com service via lua sockets.
But here i am thinking: this could also be done by the engine when it starts or by the lobby.
The thing is that games have shorter update cycles, and thus might be a better choice, if it were decided that more/other data should be added to the statistics collection.

I think this is taking to much space in this topic, so I split it here: viewtopic.php?f=71&t=36294
0 x

Post Reply

Return to “Meeting Minutes”