Staredit Network

It's pretty unlikely that SCs graphics cause any lag. It's only simple bitmaps, no 3D stuff that would require some graphics processing... And I doubt SC tries to paint every single unit you create; only the ones that exist at the time when a frame is drawn.
The only real options for lag are the processor and bnet connection. It probably is a mix of both.

im not sure what lags it, but i know its not my connections, cause rush lagged my computer and I never played that online.

Trying to change 1000 unit structures, or do pathing for 1000 units at once can cause major lag.

You tell us how to 'place fog of war' and you will be one popular person.

And it doesn't have anything to do with animations. They're the kinda thing people could make in paint. (but only if they're really good)

Um... take away the map revealers...

Rush has to be played online.

Well, I can play it offline very well. Just has to be UDP or the sort of it.

I play it on udp or ipx, works just fine! Also if you were to play it online by yourself its just the same cause it has no connection to anyone else.

That doesn't make fog of war! That just leaves the area grey. Either way, this is getting off topic, as that doesn't matter.

it seems logicial everytime i do a game were there is a large amount of units it usally lags alot and people start to blame other people such as me. i wish there was a way to get rid of lag . and just get to the point why we play starcraft in the first place wich is ... drumroll to PLAY it alas.. it seems that all of these reasons will contieu to create lag for the rest of starcrafts days

Sorry, can't help ya, I tried the map and not a single one lagged me... Maybe Try it with some friends... I have a couple real laggy ones...

From what I heard and I have heard alot lol it is your connection memeroy and Connection cords that are like your main cords that cause or help lag.Ofcourse when it comes to really working with parts I am noob.I am just good at programs.

Well my computer is just slow, so if I lag on crazy maps where there are tons of units, its no surprise for me

Do you know what the fog of war is? It's the 'grey area'.

Anyway, as far as optimizing for performance the best way to understand what is causing the slowdown would be to hook starcraft up to a debugger. Step through code blocks that are called when you use certain triggers and find out what coding patterns are causing the lag and which aren't. From that you should be able to derive methods to minimize the lag by using different methods to the same end.

In the end this will be much more efficient as you'll begin to understand the slowdown's underlying problem instead of merely testing each situation separately. I assume that there are simply poorly optimized pieces of Starcraft's code.

A much more complex and time consuming fix would be to optimize these problems in asm and then load a dll at runtime which would patch them. That's no small undertaking though.

I'm sorry if I am posting in the wrong place.

Tux, where are those toipcs on Mechnogears map? I've recently played it and wanted to post some feedback when suddenly realized they all are closed Are you still working on version 2? There are so many fresh ideas... It would be sad if you leave this map off just like this...

If any non-network thing was causing lag, it would be pathing.

Indeed you're correct. I was bored a few days ago and took a look at some things in ollydbg - the unit pathing is a rather basic implementation of A* that is quite often called recursively. This is definitely not optimal and a cause of the slowdowns.

Nice to know, I always suspected SC to use A* now I know for sure

Do you think you could throw me a link with information about A*? I have no idea what A* is.

Hmm, where did I read about it...

Wiki as always

Should give you enough information to get it. It's a simple, heuristical pathing algorithm that is mostly useful for plain graphs (2D-terrain).
For single unit movements it is a nice algorithm, but for lots of units there should be way better ones... Then again I only know Dijksta and Floyd-Warshall pretty well, and I guess there are better algorithms for the planar case...

There are other variations on A*, however in most applications a well implemented A* is the best choice. The problem with starcraft's pathfind is not that it uses A*, but that it's a poor (perhaps basic is a better word) implementation.

After re-reading your post and for completeness it's worth mentioning that A* is also a great algorithm for 3d pathfinding - you just have the added step of getting a movement graph beforehand.

edit #2:



Just read this - I'll find them again when I'm on my computer that has starcraft installed. As for a better algorithm just cleaning and optimizing the A* would make great strides. Without having looked too closely I'd say that generating some basic paths from the map as its loaded would have been a good idea.

However, I have to qualify with this that it would be no small feat to change anything as intrinsic to the game as pathfinding without screwing something up. I wouldn't want to try it.

Do you know if SC applies A* for every single unit when you for example order a whole team to move to some location? I would guess so. I am pretty sure that movement of multiple units could be solved better.

Take Dijkstra's Algorithm, for example, and find all shortest paths from the destination to evrey accessible location. This is done in a single run of Dijkstra. Now you can move all units from any location on the map to a certain destination. Of course units blocking each other will have to be treated, and I am no specialist on this stuff. I just think that it is possible to find better solutions.

A* is sufficient for SC though A game like those newer 1,000,000 units-battle games will need something else

I haven't looked at it closely enough - in fact I've only debugged it with single unit moves - but my gut is that yes, it does it on a per unit basis. You can have units selected that are 362 units apart - it'd be pretty hard to do a group based move on those units. Since there's no special checks before the A* is run (that I saw) I doubt it's optimized in this way. It'd be fun to implement though!