Windows Support/Development (splitted from LockFreeLua)

[Super Mario]

Google_Frog, Silentwings: i guess you did run the tests on windows?

~15-20% difference doesn't look like results from linux are transferable to windows.

Side note: I really don't like the fact that windows is being left on the side burner when it comes to support.

Edit: What I mean is that the current windows binaries is build on a Unix base server. This means that issues that goes unnoticed, until people report them the issues, which may result in issues on windows never go notice until after the binaries is distributed. Kinda counter intuitive if you ask me.

[abma]

Edit: What I mean is that the current windows binaries is build on a Unix base server. This means that issues that goes unnoticed, until people report them the issues, which may result in issues on windows never go notice until after the binaries is distributed. Kinda counter intuitive if you ask me.

none of the "core" developers works on windows. enforcing devs to work on windows is like enforcing players to use linux, this won't work. get us some windows devs! :)

[Silentwings]

Every binary is "released" and can be tested by anyone: http://springrts.com/dl/buildbot/default/. Without magically creating new developers for all OS/gfx/etc combinations, I can't see how to do any better than that.

[gajop]

Every binary is "released" and can be tested by anyone: http://springrts.com/dl/buildbot/default/.

What Silentwings means by that is that nearly* every commit will have a build for Windows/Linux that everyone can download and test. I'm not sure if Mac automatic build support is already added, but it's something they've been trying to do add for a while.

One can certainly agree that if this was a commercial project, the level of support (and number of devs) Windows has is unacceptable, but it's not like they're being paid for it, and there's certainly persistent will to fix issues for windows users.

And as abma said, devs++ please.

nearly*: With the exception of those that fail to build due to build errors

[hokomoko]

nearly*: With the exception of those that fail to build due to build errors

Unacceptable!

Not having executables of failing builds is the main obstacle for improving the spring experience for windows users.

Seriously though, spring behaves wonderfully on Windows, building is quite straight-forward, and playing is as issue-less as linux.
The lock-performance issue is really an exception, and it's unlikely having windows devs would've helped discovering this type of issue faster.

[Super Mario]

I did not expect my post to cause a split, anyways...

Edit: What I mean is that the current windows binaries is build on a Unix base server. This means that issues that goes unnoticed, until people report them the issues, which may result in issues on windows never go notice until after the binaries is distributed. Kinda counter intuitive if you ask me.

none of the "core" developers works on windows. enforcing devs to work on windows is like enforcing players to use linux, this won't work. get us some windows devs! :)

How?

Currently the engine has a steep learning curve, for me. Frankly my vacation is over, and I do not have enough spare time for me to study the code, due to subpar amount of comments that it currently has. You can improve the engine a lot by just code refactoring the engine.

I.E. Make it easier for new engine devs to participate in spring.

[PicassoCT]

In a way that has allready happend. Lua is powerfull. It has taken a lot of what would have been once c++ dev work out of engine corce.

If you really write stuff - the last thing you crave for is the base of your buildingpart beeing refactored.
My attempts to put bullet into spring phailed mainly due to my mostly c-foo, not spring beeing unreadable.

I think to attract devs to engine development, you need to go to a c++ place and talk about engine development there in public.

Or wait - i ll just start a thread to that, like my jw-thread and see what happens.

[Super Mario]

In a way that has allready happend. Lua is powerfull. It has taken a lot of what would have been once c++ dev work out of engine corce.

If you really write stuff - the last thing you crave for is the base of your buildingpart beeing refactored.
My attempts to put bullet into spring phailed mainly due to my mostly c-foo, not spring beeing unreadable.

I think to attract devs to engine development, you need to go to a c++ place and talk about engine development there in public.

Or wait - i ll just start a thread to that, like my jw-thread and see what happens.

I'm talking about engine development not game development. Quit projecting your experience on to me, and act like that is any relevant to what I'm saying.

[smoth]

Currently the engine has a steep learning curve, for me..

The engine has moved past the "my first open source project" phase and moved into you have to be pretty technically adept to actually improve the performance. I am not sure why you feel it should be easier to start working on a project that has matured as this one has.

[Super Mario]

Currently the engine has a steep learning curve, for me..

The engine has moved past the "my first open source project" phase and moved into you have to be pretty technically adept to actually improve the performance. I am not sure why you feel it should be easier to start working on a project that has matured as this one has.

New engine developers should spend less time on learning the engine and more time on contributing . The lack of information about the engine really makes it difficult for me. I appreciated the assistance I receive from abma so far, but I do not want to be an annoyance to engine devs by frequently asking questions about the engine itself.

[gajop]

You need to provide far better comments on the issues you are having and (if possible) any suggestions you can give.
This is not enough:

You can improve the engine a lot by just code refactoring the engine.

In my experience as someone who has contributed to the engine from time to time, it's not that hard really. It's going to take a few hours to get acquainted to some new part of the engine, but usually it's not too hard to push a small feature in 10h~20h work.

My suggestion is to start with something you want to do (ideally a new feature), and then ask questions if any are necessary. It's really best to avoid any attempt to *understand* the whole engine, as if that's something anyone's expected to be able to do.

[hokomoko]

@gajop +1

During game development I've had to look in the code quite a lot which made me familiar with certain bits (lua, defs, command AI, etc.) that can be "understood" in reasonable time investment.
Hacking those shouldn't require you to understand in detail how the rest of the engine works (drawing for instance is mostly irrelevant for these).

[PicassoCT]

Currently the engine has a steep learning curve, for me..

The engine has moved past the "my first open source project" phase and moved into you have to be pretty technically adept to actually improve the performance. I am not sure why you feel it should be easier to start working on a project that has matured as this one has.

New engine developers should spend less time on learning the engine and more time on contributing . The lack of information about the engine really makes it difficult for me. I appreciated the assistance I receive from abma so far, but I do not want to be an annoyance to engine devs by frequently asking questions about the engine itself.

What do you want? If you expect to know the whole engine inside out, that would mean the engine is not divided into components which would imply massive unmaintainable phail.

If you want to add a local modification, all you need to know about is your part. There could be more documentation, agreed. But some of the stuff if you follow it for a while reveals its nature fairly quickly. Do you expect autogenerated Objectbehaviourgraphs?

If you want to add another component- you will have to learn the parts you will have to specify interfaces. Thats all the engine parts you communicate with have to know.

Also, its in all fairly old code bases, where optimization sets in, that some of the optimizations make the code a little hard to read.

[Silentwings]

It's really best to avoid any attempt to *understand* the whole engine, as if that's something anyone's expected to be able to do.

This. I can't love C++ enough for being suited to working on some small part of a project without having to understand mountains of code.

[abma]

hm, maybe that could be a project?

modularize engine? so parts of it can be switched off / replaced by other implementations.

i.e. pathfinder / sim / projectiles / unsynced / rendering / map / ... (not sure what makes sense here)

means: move the parts into shared libraries and load/unload when needed.

it should simplify to understand the engine as there would be a clean api.

i know, its not very attractive for getting donations

[smoth]

Wasn't there someone looking at splitting off the renderer?

[hokomoko]

...
i know, its not very attractive for getting donations

That's the big problem with donations, you can't get donations for things that aren't "sexy", and once donations start, issues with bounties get priority over things without bounties (a worse scenario is that nothing gets done without donations).
imo though, modularisation isn't worth the effort. Obviously as things get written or refactored they should be as modular as possible but I can't see someone having the motivation to modularise the entire engine.

Some of the (GSOC) project suggestions are similar in spirit (sensor, resource refactoring), and I don't think it's a coincidence no one picked them up.

[Silentwings]

Probably large scale refactoring is not an attractive project to someone who is not a long timer dev, because it needs more knowledge than "implement cute feature #1" and there is no material gain to see from people using your cute new feature. And there is the risk of annoying lots of people if you introduce subtle bugs.

Lua seems quite well contained already to me, and I guess the same must be true of the PFS since there is the QTPFS switch. (No clue about the rest.)

[Super Mario]

In my experience as someone who has contributed to the engine from time to time, it's not that hard really. It's going to take a few hours to get acquainted to some new part of the engine, but usually it's not too hard to push a small feature in 10h~20h work.

I don't take, "it works for me" as valid argument. The features that I have in mind aren't exactly "small". Frankly it appears that you are more familiar with the engine than me, here so it's not difficult for you as it were for me.
Just comment your code more often. That's all I want. Not new features, just a brief description of every function in the header file, is good enough, for me.

Btw, the wiki is imo outdated, as there are new information concerning the development of the engine on windows and among other things that I notice. I think a yearly review of the wiki is good.

[gajop]

I'm also talking about my experiences with the earliest commits, and also every time I check a new part of the engine.
It might be different for you, maybe you're looking at rendering or physics code and that could be difficult to understand, but I hope the hard stuff are documented.

Personally I'd like the architecture defined in a short document, so I know where to look.

Regarding the wiki, we try to keep it updated, and some people like FLOZi work really hard to improve it. Any suggestions to what you feel is lacking is appreciated.

Please, be more concrete :)