PLZ SUBMIT COAD PATCH. The real devs spend their time on things that actually matter.DZHIBRISH wrote:i repeat.
we need optimization and perhaps duel core support
Attacks on new players
Moderator: Moderators
-
Complicated
- Posts: 369
- Joined: 06 Jun 2007, 18:51
Spectate CA games, very socialable and reasonable community who love spectators. CA is probably the most spectated mod.TheBigPK wrote:err ya i tried to spectate a few games today and got booted. I always play spring on SP cause my connection at my apartment blows right now because I'm* broke and today I went on campus and wanted to see how people play online and how I'd have to alter playstyle to compensate. Does spectating have some kind of negative effect on preformance or something? I dont really see why you wouldnt let noobs spectate I mean they arent going to screw anything up that way... except maybe the chatbox or drawings i guess but really.
edit; I guess i should note that no one was being impolite or anything they just preferred not to have spectators even if they werent noobs. i wanted to know if it was detrimental to performance to spectate cause I would stop trying and start playing if thats true.
-
Complicated
- Posts: 369
- Joined: 06 Jun 2007, 18:51
Better said that done.Soul wrote:I agree that the only way you can get real good would be playing MP, but you may still learn the basics quite fast if not faster in a tutorial.
Good tutorialless noobs
QED
At the moment I'm putting together a new tree for spring, a proper Campaign, single player, quite integrated into the game.
Single player games will attract new players, shows them the game, lets them know the units (aims of the campaign) and basic rules. Multiplayer games require other experience but being armed with some knowledge of the game will help you alot better.
Eventually we may introduce awards on campaign to carry out into the spring lobby.
This can also make Spring and the lobby server integrated and far more user friendly. Appearance of the lobby is also vital. (Current lobby looks like something from WinME)
Working on spring and the noobs will gain more respect, eventually mature players will join and we'd have a decent community.
-
MightySheep
- Posts: 243
- Joined: 11 Nov 2007, 02:17
lordmatt it does matter.many players are switching to duel core systems..
of course it matters....the more time goes by without spring supporting duel core the more effect it will have on the community...
as i wrote...most important thing is optimizing spring and making a user firendly lobby...if you want the community to grow that is...there will be many people turned off when they try to use there new cool systems just to see that their fps decreased!
no one wants to play a game that can be played on full gfx but plays like you have pentium 3(just to make a point).
of course it matters....the more time goes by without spring supporting duel core the more effect it will have on the community...
as i wrote...most important thing is optimizing spring and making a user firendly lobby...if you want the community to grow that is...there will be many people turned off when they try to use there new cool systems just to see that their fps decreased!
no one wants to play a game that can be played on full gfx but plays like you have pentium 3(just to make a point).
Perhaps the less technically inclined among you can be forgiven for begging for dual core support, but here's a hint - it ain't gonna happen on this engine.
The amount of core engine code that would have to be entirely rewritten in order to make use of dual or multi core systems is so great that you might as well just build an entirely new engine. We're talking hundreds of hours of not-very-rewarding work from a small handful of people working in their (generally rather limited) free time. So when somebody tells you that dual core support in the engine isn't going to happen, you should listen.
The amount of core engine code that would have to be entirely rewritten in order to make use of dual or multi core systems is so great that you might as well just build an entirely new engine. We're talking hundreds of hours of not-very-rewarding work from a small handful of people working in their (generally rather limited) free time. So when somebody tells you that dual core support in the engine isn't going to happen, you should listen.
I think the support they want is just that spring doesn't crap itself if you don't force it to a specific core.Nemo wrote:Perhaps the less technically inclined among you can be forgiven for begging for dual core support, but here's a hint - it ain't gonna happen on this engine.
The amount of core engine code that would have to be entirely rewritten in order to make use of dual or multi core systems is so great that you might as well just build an entirely new engine. We're talking hundreds of hours of not-very-rewarding work from a small handful of people working in their (generally rather limited) free time. So when somebody tells you that dual core support in the engine isn't going to happen, you should listen.
I've come across some players with max experience that are considerably worse than me.
For example I was playing a speedmetal map (I don't care if you think it is lame) with a guy against two others. My ally who was experienced went air. Anyway he spotted a krogoth (they got krogs first) at the other side of the map without telling me and by the time I noticed it it was too late. The problem is that this scenario has happened time after time when I have had experience players as allies. They build a row of doomsdays or annihilators at the entrance after seeing the krog or orcone when it would take a fraction of the time to send an ACA or two forward a bit to build fort walls, and you don't even have to build a full line, just use z and x to make a line that's 101010 on off on off and a krogoth can't get through. Plus it's insanely quick to build, yet even the most experienced players fail to see this simple solution and send in slow to build expensive units when the solution is 8 pieces of wall that cost about the same as a raider or a stumpy each.
Then there are smurfs. Anyone who takes the tasclient ranking system too seriously is an idiot anyway, especially if they are experienced.
As for sucking in games, everyone at some point fails. If you ask me, it's much worse when a non newbie does it.
One problem though that spring has is that the AI/single player mode just isn't as well polished as multiplayer. You might actually learn more and advance quicker if you start by playing TA original with various mods against the AI (with the unit limit remover and game speed unlimiter).
For example I was playing a speedmetal map (I don't care if you think it is lame) with a guy against two others. My ally who was experienced went air. Anyway he spotted a krogoth (they got krogs first) at the other side of the map without telling me and by the time I noticed it it was too late. The problem is that this scenario has happened time after time when I have had experience players as allies. They build a row of doomsdays or annihilators at the entrance after seeing the krog or orcone when it would take a fraction of the time to send an ACA or two forward a bit to build fort walls, and you don't even have to build a full line, just use z and x to make a line that's 101010 on off on off and a krogoth can't get through. Plus it's insanely quick to build, yet even the most experienced players fail to see this simple solution and send in slow to build expensive units when the solution is 8 pieces of wall that cost about the same as a raider or a stumpy each.
Then there are smurfs. Anyone who takes the tasclient ranking system too seriously is an idiot anyway, especially if they are experienced.
As for sucking in games, everyone at some point fails. If you ask me, it's much worse when a non newbie does it.
One problem though that spring has is that the AI/single player mode just isn't as well polished as multiplayer. You might actually learn more and advance quicker if you start by playing TA original with various mods against the AI (with the unit limit remover and game speed unlimiter).
Fair enough.KDR_11k wrote:I think the support they want is just that spring doesn't crap itself if you don't force it to a specific core.Nemo wrote:Perhaps the less technically inclined among you can be forgiven for begging for dual core support, but here's a hint - it ain't gonna happen on this engine.
The amount of core engine code that would have to be entirely rewritten in order to make use of dual or multi core systems is so great that you might as well just build an entirely new engine. We're talking hundreds of hours of not-very-rewarding work from a small handful of people working in their (generally rather limited) free time. So when somebody tells you that dual core support in the engine isn't going to happen, you should listen.
-
Google_Frog
- Moderator
- Posts: 2464
- Joined: 12 Oct 2007, 09:24
I agree OTA helps A LOT. But you can't expect people to buy OTA for spring (*A mods) and if we rely on the old OTA community the spring community won't grow. TA has the steepest learning curve of any RTS i know and spring has no tutorial. The noob training system could be the best solution at the moment,Orakio wrote:One problem though that spring has is that the AI/single player mode just isn't as well polished as multiplayer. You might actually learn more and advance quicker if you start by playing TA original with various mods against the AI (with the unit limit remover and game speed unlimiter).
lol there's nothing like getting called idiot after some few flashes get through back of your base onto teammate's base, and chain-explode ALL his winds and metal makers 
or a case of trying to save teammate's defenceless base on DSD (he was teching right away) but having to protect your own base too, hence not having time to chase enemy troops on his base, and him drawing lines around instead of telling "pls move your troops here" and finally again calling you idiot for not devoting full attention to his base.
or a case of trying to save teammate's defenceless base on DSD (he was teching right away) but having to protect your own base too, hence not having time to chase enemy troops on his base, and him drawing lines around instead of telling "pls move your troops here" and finally again calling you idiot for not devoting full attention to his base.
Its a game, you either win or lose.. If your playing with a noob, you give him tips help him out abit maybe even share some res, if he tries his best and listens to you, yet fails ,dont flame him just say nice try. If you see others like WTF U NOOB, u tell them to STFU. Loss is a part of it, people who complain about loss need to get a life. Theres a simple solution... dont be Assholes.
True google frog, it is a suggestion that would only be suitable for some.
Baladin, I half agree but criticism is an important part of teaching. It helps people to figure out what they did wrong.
Anyway how did this get to being about multiple core processors?
Converting some parts of the engine for multiple for support would not be difficult but only a small amount of places would allow for easy implementation. Arrays are generally easy, for example in pseudo code.
Original: for (i=0;i<length;i++) do something;
Dual core:
n=length/2
thread 0 creates thread 1
thread 0: for (i=0;i<n;i++) do something; wait for thread 1 to end;
thread 1: for (i=n;i<length;i++) do something; end;
That's a crude example, with a little bit of overhead (dividing the array into two or working out how to spread the load which in some cases may be guesswork or take allot of calculation, creation a new thread and if you don't want to waste core you would have to have a horribly complicated system of when a thread is finished having it communicate to another and taking some of its load away or doing things in lots of tiny chunks meaningmassive overhead and then there's the horror of increased risk of hanging from deadloks etc massive increase in potential bugs temporal issues etc) so it would need to keep the original, perhaps use classes and load the one for the relevant core. However there are probably only a few places in spring that could be improved in such a way and given the increased complexity it would not be worth the effort for a long time. And as mentioned before, to make the spring engine take full advantage of multiple core the code would probably have to be radically altered and rewritten. No only that but the overhead would make it slower on single core, there are somethings which are impossible to do in parallel and to keep it running fast on single core you would practically have to have two engines.
Not to mention, spring runs well enough in single core mode. At the moment the bottleneck with dual core processors is rarely the cpu. Usually it is internet that causes a slowdown bandwidth. In my experience most of the time someone slows the game down with cpu lag is because they have a rubbish system anyway (ie p4 with pc 133 ram and not enough memory bandwidth or a celeron, virus, etc). Each single core of a dual core CPU is fairly powerful anyway. For example I upgraded a while ago from AMD 64 3200 single to AMD 4800 X2 which has a 20% faster block rate and twice the cache per core so is still faster in single core. Also there are probably many optimisations that can still be made that don't use a second core.
Also dual core does usually provide a minor speed boost for single core games, for example background kernel activity (ie general routine tasks) and libraries/system calls ie to the kernel or something like opengl might use threads, but I wouldn't expect to see more than a 1% overall speed increase.
Hope that explains why giving spring dual core support is not a good idea.
Baladin, I half agree but criticism is an important part of teaching. It helps people to figure out what they did wrong.
Anyway how did this get to being about multiple core processors?
Converting some parts of the engine for multiple for support would not be difficult but only a small amount of places would allow for easy implementation. Arrays are generally easy, for example in pseudo code.
Original: for (i=0;i<length;i++) do something;
Dual core:
n=length/2
thread 0 creates thread 1
thread 0: for (i=0;i<n;i++) do something; wait for thread 1 to end;
thread 1: for (i=n;i<length;i++) do something; end;
That's a crude example, with a little bit of overhead (dividing the array into two or working out how to spread the load which in some cases may be guesswork or take allot of calculation, creation a new thread and if you don't want to waste core you would have to have a horribly complicated system of when a thread is finished having it communicate to another and taking some of its load away or doing things in lots of tiny chunks meaningmassive overhead and then there's the horror of increased risk of hanging from deadloks etc massive increase in potential bugs temporal issues etc) so it would need to keep the original, perhaps use classes and load the one for the relevant core. However there are probably only a few places in spring that could be improved in such a way and given the increased complexity it would not be worth the effort for a long time. And as mentioned before, to make the spring engine take full advantage of multiple core the code would probably have to be radically altered and rewritten. No only that but the overhead would make it slower on single core, there are somethings which are impossible to do in parallel and to keep it running fast on single core you would practically have to have two engines.
Not to mention, spring runs well enough in single core mode. At the moment the bottleneck with dual core processors is rarely the cpu. Usually it is internet that causes a slowdown bandwidth. In my experience most of the time someone slows the game down with cpu lag is because they have a rubbish system anyway (ie p4 with pc 133 ram and not enough memory bandwidth or a celeron, virus, etc). Each single core of a dual core CPU is fairly powerful anyway. For example I upgraded a while ago from AMD 64 3200 single to AMD 4800 X2 which has a 20% faster block rate and twice the cache per core so is still faster in single core. Also there are probably many optimisations that can still be made that don't use a second core.
Also dual core does usually provide a minor speed boost for single core games, for example background kernel activity (ie general routine tasks) and libraries/system calls ie to the kernel or something like opengl might use threads, but I wouldn't expect to see more than a 1% overall speed increase.
Hope that explains why giving spring dual core support is not a good idea.
An excellent extension to this idea would be animation interpolation for rendering only (aka unit movement and cob animation would occur at >30 fps). Currently, differences in update frequency between movement/animation and rendering cause some stuttering, particularly visible when you set the camera to track a unit.AF wrote:I totally disagree.
For one we could speed things up by moving the simulation and the rendering to two separate threads. That way your framerate isn't jittering while that units eating up all the main threads time pathfinding.