if the engine was more modular, it would improve everything.
more easy to test, more easy to isolate problems, more easy to extend, more easy to speed-up, more easy to get new devs, becuase they actually could work in their area of expertise, instead of first learning all of spring, and then give up because it is fucked up, more easy to prevent regression, more easy to branch and merge stuff, more easy for devs to work in parallel, possible to put together a custom build, and probably more.
of course, no user or game dev cares about this, cause they never actually see the problems related to it as related to it (and not even all engine devs do).
it is THE thing that the spring engine needs! everything else is primary!
The general spring modularisation discussion
Moderator: Moderators
Re: Planetary Annihilation
Last edited by hoijui on 06 Sep 2012, 15:42, edited 1 time in total.
Re: Planetary Annihilation
To be fair I see no high level descriptions or models of how the engine is currently built, how the engine should be built, and where it is headed.
Aside from discussions of the right here and what comes next, there does not appear to be any clear goals beyond the short term that aren't 'vague' and 'wishy washy' like "improve rendering" or "make more modular". If there is, it hasn't been communicated effectively outside of the core devs, and it's a barrier to entrance for some potential developers.
Aside from discussions of the right here and what comes next, there does not appear to be any clear goals beyond the short term that aren't 'vague' and 'wishy washy' like "improve rendering" or "make more modular". If there is, it hasn't been communicated effectively outside of the core devs, and it's a barrier to entrance for some potential developers.
Re: Planetary Annihilation
the core devs are the ones that should make it more modular. i am sure that tobi knows what would have to be done, and the others know what i think should be done in that regard pretty well, so there is no lack of communication i think. wishy washy is not a problem here. problem is only jk and kloot, as they won't do it themselfs, and won't allow anyone else to do it (without threatening to leave).
to my knowledge, kloot never said anything concrete about the topic, and jk does not want it to happen cause of low level conflicts that he sees, like.. there would be more files, which make engine deving with notepad-like tools more cumbersome, or there would be more virtual function calls, which supposedly make the engine too slow (though that is very, very unlikely in my eyes, and even if they would, they could be replaced by something slightly more ugly and not slower, with still most of the benefits).
all of this was discussed in a meeting with publicly available minutes btw. in the end, tobi voted in favour of not doing the modularization, because jk was against it, and jk was (and is) one of the two most active devs (and the other one was quiet).
if everyone would cry for "more modularity" instead of "please add new feature-/unit-tag so i can unload in a 3D star shaped area into the sky from my mobile-factory-transport-amphib-krogoth while it is submerged" ...
but as said, no users or game devs will ask for that, and one can not await them to do that either.
i see some rendering and sim stuff getting split, at about the rate that zerver combines them again. (
)
i am absolutely sure that it is possible to modernize the engine incrementally, but the first step has to be heavy modularization, or else it would take 100 times more dev time -> would never happen.
the pathfinder is a good example. though it would still have to be more modularized, it is already very useful that it is as modular as it is. QTPFS would definitely not be as usable without the modularity, cause nobody would test it, or it would have produced a lot of total failaition spring releases (with it being the only pathfinder).
to my knowledge, kloot never said anything concrete about the topic, and jk does not want it to happen cause of low level conflicts that he sees, like.. there would be more files, which make engine deving with notepad-like tools more cumbersome, or there would be more virtual function calls, which supposedly make the engine too slow (though that is very, very unlikely in my eyes, and even if they would, they could be replaced by something slightly more ugly and not slower, with still most of the benefits).
all of this was discussed in a meeting with publicly available minutes btw. in the end, tobi voted in favour of not doing the modularization, because jk was against it, and jk was (and is) one of the two most active devs (and the other one was quiet).
if everyone would cry for "more modularity" instead of "please add new feature-/unit-tag so i can unload in a 3D star shaped area into the sky from my mobile-factory-transport-amphib-krogoth while it is submerged" ...
but as said, no users or game devs will ask for that, and one can not await them to do that either.
i see some rendering and sim stuff getting split, at about the rate that zerver combines them again. (
)i am absolutely sure that it is possible to modernize the engine incrementally, but the first step has to be heavy modularization, or else it would take 100 times more dev time -> would never happen.
the pathfinder is a good example. though it would still have to be more modularized, it is already very useful that it is as modular as it is. QTPFS would definitely not be as usable without the modularity, cause nobody would test it, or it would have produced a lot of total failaition spring releases (with it being the only pathfinder).
Last edited by hoijui on 06 Sep 2012, 16:35, edited 1 time in total.
Re: Planetary Annihilation
Wishywashy may not be an issue for you tobi kloot Abma or JK but you do realise that you 5 don't make up the entirety of the C++ community? =p
Re: Planetary Annihilation
you -> left field...AF wrote:Wishywashy may not be an issue for you tobi kloot Abma or JK but you do realise that you 5 don't make up the entirety of the C++ community? =p
they are the relevant ones as they are the ones doing the work.
Re: Planetary Annihilation
He's talking of attracting (or not attracting) new devs.
Re: Planetary Annihilation
"More modularity" is too abstract. Now if you tell people that you want to aim forhoijui wrote: if everyone would cry for "more modularity" instead of "please add new feature-/unit-tag so i can unload in a 3D star shaped area into the sky from my mobile-factory-transport-amphib-krogoth while it is submerged" ...
but as said, no users or game devs will ask for that, and one can not await them to do that either.
it's suddenly something they can relate to. I'm pretty sure both players and devs with a playable game out value stability and un-bugginess more than getting new features asap.more easy to prevent regression, more easy to branch and merge stuff, more easy for devs to work in parallel, possible to put together a custom build, and probably more
Worst thing about Spring for me is how there's constantly some annoying issues, and how they get replaced with new bugs at about same rate as they're squashed, so I can never even get used to them.
Re: Planetary Annihilation
but you are never going to help, so why do you need an explanation?Johannes wrote:"More modularity" is too abstract. Now if you tell people that you want to aim for
Re: Planetary Annihilation
I didn't ask for an explanation.
Re: Planetary Annihilation
Then who are the people? As hoi stated, the people who can or would are privy to those details.
Re: Planetary Annihilation
AF, i did not say that wishy washy is ok for us, but that among us, it is no wishy washy but clear stuff, and that it does not have to be as concrete to others. it does not have to be, because the (current) spring devs have to do it, cause they know best what to do, and cause they won't let others do it anyway. and even if they would let a new guy do it, he would already have to have a general idea about what modularization of code means, and to do the concrete stuff, he would have to get to know the code well by himself first anyway, or we could hint him to certain parts.
in short: to tell the public what to do exactly is practical nonsense.
in short: to tell the public what to do exactly is practical nonsense.
Re: Planetary Annihilation
Thats not true at all and those could very well have been levelled at Abma and Zerver yet they managed to gain inclusion.
Sayin what you're going to do tells us what parts of the engine are most likely to change or have bugs, and any mystery dev knows to either submit a patch or watch and learn so they can contribute in the future.
I've one across plenty of skilled people in every aspect of development who have found spring and felt a desire to contribute to the engine or start a game but have been baffled because they have no idea how or where to begin.
Sayin what you're going to do tells us what parts of the engine are most likely to change or have bugs, and any mystery dev knows to either submit a patch or watch and learn so they can contribute in the future.
I've one across plenty of skilled people in every aspect of development who have found spring and felt a desire to contribute to the engine or start a game but have been baffled because they have no idea how or where to begin.
Re: Planetary Annihilation
If they were THAT skilled, they would figure it out, they would ask for help etc. Which we see. People who start a project/game/whatever in spring do not have to be that technically adept or even close to the level of person to work on the engine. Most of what hoi is talking about is above my head let alone some random guy who cannot figure out how to work GIT.AF wrote:I've one across plenty of skilled people in every aspect of development who have found spring and felt a desire to contribute to the engine or start a game but have been baffled because they have no idea how or where to begin.
Re: Planetary Annihilation
I am never against modularization, nearly everything I do is modularization!hoijui wrote:...
E.g. I moved all buildrange checking into 2 small functions, while it was duplicated across multiple files before! And I made the SMF mesh renderer modular (it's the only real work I did to Behe's ROAM implementation).
It's we all disliked your way, cause e.g. you wanted an own file for projectile world rendering & another file for projectile minimap rendering!
Or the way you split InMapDrawing: it would would possible to replace its functionality in a single widget, you split it into 3! cpp files (+ their .h).
ModelViewController pattern is nice, but sometimes you should see it like an design idea and not as a rule...
And please don't take it too personal again, just cause some question your design ideas.
Re: Planetary Annihilation
to reduce code duplication is good, and indeed.. you do a lot of it, which is very good, but it is only a pre-processing step for modularization (the hardest and most difficult part).
but with only that, we are not modular, or not modular enough at least.
for example, 3D and minimap rendering are different things, and they should be separated. the best way of modularizing is, to use classes, not functions, as it gives one more flexibility.
lets say, we want to build a spring with only minimap rendering, or without minimap rendering, or we want to replace minimap rendering with by Lua stuff completely.
my way of modularizing was very simple, and it was done for parts already, in little time, and it brought a higher level of modularization.. no alternative to it was done yet, because they are all more complex and difficult, and mostly can't be done incrementally, or they require one to know C++ and the spring engine plus the Lua API, instead of only C++ and a bit of spring code like my solution. my solution allows to do whatever else you want to do afterwards.
in the end, the arguments against my solution were plain laughable.
i don't take it personally, as i don't feel like i did something original or impressive or whatever.. i only did what i learned, and many others learned aswell. i can give a lot of concrete, heavy reasons why it is a good solution, and you have "more files" and "virtual functions" as counter arguments. i have to call it my solution cause i feel alone with it (among spring engine devs). abma and zerver kind of said they don't understand, or don't want to try to read all the code or something, kloot was quiet, you were against it and tobi was kind of neutral, laying over to your side. you now say what i wanted to do, and put it as if that alone was a counter argument against my way, but... it is not; it is just a description of what i wanted to do.
it still seems to me that there is no real argument against it, except that you fear you will have practical problems handling the code cause of more files.
but when eg. 3D and minimap rendering is separated into different files, why do you think you would usually have to open both of them?
isn't it more likely that you would only work on either one of them, and thus have the same amount, but smaller source files open, so that even if you'd develop notepad style, it would be easier, and not more complex?
and i'd like to point out again, that you spoke against many of my ideas, and you were mostly right, and i accepted it, and was even happy that i learned something, but in this case, you totally failed to convince me, even though we talked about it for much longer then about the other topics.
also, i consider tobi a generally better developer then you or kloot, and still i saw him accept to have been wrong more often then you or kloot, which makes me suspicious.
to stay strong and defend your beliefs at all costs is the CEO/big company way of doing things. it is probably their biggest weakness, and a source of great evil. it makes them very slow and stiff. the open source way is to accept to be wrong, over and over again, accept it right away, and try to solve it. even accept to be wrong too fast, and find out that you were not afterwards.
if you can't conceivably explain why i am wrong, then maybe you are.
but with only that, we are not modular, or not modular enough at least.
for example, 3D and minimap rendering are different things, and they should be separated. the best way of modularizing is, to use classes, not functions, as it gives one more flexibility.
lets say, we want to build a spring with only minimap rendering, or without minimap rendering, or we want to replace minimap rendering with by Lua stuff completely.
my way of modularizing was very simple, and it was done for parts already, in little time, and it brought a higher level of modularization.. no alternative to it was done yet, because they are all more complex and difficult, and mostly can't be done incrementally, or they require one to know C++ and the spring engine plus the Lua API, instead of only C++ and a bit of spring code like my solution. my solution allows to do whatever else you want to do afterwards.
in the end, the arguments against my solution were plain laughable.
i don't take it personally, as i don't feel like i did something original or impressive or whatever.. i only did what i learned, and many others learned aswell. i can give a lot of concrete, heavy reasons why it is a good solution, and you have "more files" and "virtual functions" as counter arguments. i have to call it my solution cause i feel alone with it (among spring engine devs). abma and zerver kind of said they don't understand, or don't want to try to read all the code or something, kloot was quiet, you were against it and tobi was kind of neutral, laying over to your side. you now say what i wanted to do, and put it as if that alone was a counter argument against my way, but... it is not; it is just a description of what i wanted to do.
it still seems to me that there is no real argument against it, except that you fear you will have practical problems handling the code cause of more files.
but when eg. 3D and minimap rendering is separated into different files, why do you think you would usually have to open both of them?
isn't it more likely that you would only work on either one of them, and thus have the same amount, but smaller source files open, so that even if you'd develop notepad style, it would be easier, and not more complex?
and i'd like to point out again, that you spoke against many of my ideas, and you were mostly right, and i accepted it, and was even happy that i learned something, but in this case, you totally failed to convince me, even though we talked about it for much longer then about the other topics.
also, i consider tobi a generally better developer then you or kloot, and still i saw him accept to have been wrong more often then you or kloot, which makes me suspicious.
to stay strong and defend your beliefs at all costs is the CEO/big company way of doing things. it is probably their biggest weakness, and a source of great evil. it makes them very slow and stiff. the open source way is to accept to be wrong, over and over again, accept it right away, and try to solve it. even accept to be wrong too fast, and find out that you were not afterwards.
if you can't conceivably explain why i am wrong, then maybe you are.
Re: Planetary Annihilation
Not at all, some of them are avid git users, some of them have even gone and built their own engines for personal use, but as one of the longest running game developers here you're hardly qualified to comment on new people since you're inherently incapable because of your inside perspective. You haven't been an outsider looking in afresh in a very, very long time.smoth wrote:If they were THAT skilled, they would figure it out, they would ask for help etc. Which we see. People who start a project/game/whatever in spring do not have to be that technically adept or even close to the level of person to work on the engine. Most of what hoi is talking about is above my head let alone some random guy who cannot figure out how to work GIT.AF wrote:I've one across plenty of skilled people in every aspect of development who have found spring and felt a desire to contribute to the engine or start a game but have been baffled because they have no idea how or where to begin.
Re: Planetary Annihilation
God exists.... ETChoijui wrote:if you can't conceivably explain why i am wrong, then maybe you are.
please don't use this sort of argument.
because all I do is spring....AF wrote:You haven't been an outsider looking in afresh in a very, very long time.
Re: Planetary Annihilation
Reducing code duplication and using interfaces IS modularization.hoijui wrote:to reduce code duplication is good, and indeed.. you do a lot of it, which is very good, but it is only a pre-processing step for modularization (the hardest and most difficult part).
Cause you will have 1 place to change the implementation instead of doing so in 20 files. With your way of doing it you split it across such many files and reduce locality.
Re: Planetary Annihilation
jK, do you have your 5 year plan somewhere I can see?
Re: Planetary Annihilation
hoijui wrote:or there would be more virtual function calls, which supposedly make the engine too slow (though that is very, very unlikely in my eyes...)
ORLY?hoijui wrote:to stay strong and defend your beliefs at all costs is the CEO/big company way of doing things. it is probably their biggest weakness, and a source of great evil.
Here's a little anecdote: you mentioned QTPFS, which initially used a nice OO design with virtual tree nodes. Then I profiled it and found it was 20% slower per search execution than without the virtual structure. *That* is why I decided not to further modularize the pathfinders, because their code is already time-critical and they call into the engine many thousands of times per frame. So exactly who is defending their beliefs at all costs here and who has the empirical evidence to back up their points? Could it be us dumb low-level peons were right?
If we (the LL guys) supposedly cannot see anything of the big picture, then you (the HL guy) conversely cannot see the small details, and dismissing them as "laughable" and claiming "you can't conceivably explain why i am wrong" makes you the CEO and us the exploited employees whose opinion is never listened to or welcomed.