Essay on Programming Concepts

Originally Posted by Nestharus

Ok, uh captain griffen. Thanks for the flames, really appreciated. I don't know if you can read or what, but obviously from what you've said you can't read at all, so I'm not even going to bother replying except for this.

You're talking shit.

Yes, OpenGL is possible -.-. Don't bloody say NO UR WRONG, U CANT DO THAT, UR A MORON. If you have no clue how it would be done and you're curious on how it would be done *IN JASS,* which is what this entire discussion is about, then ask and decide after you hear the answer.

JASS is a VM with no API for OpenGL.

#1: You need to read my explanation on what I'm talking about because you seem to think that I'm talking about doing regular OpenGL in wc3. I never said that anywhere in the post. I never said about doing actual multi-threading in the post. I never said anything about managing your own memory exactly like in C++.

Non-regular OpenGL is not OpenGL...OpenGL is a driver implemented level graphics API.

You said: "To put it in more simpler terms, it can be described as car lanes on a road. When you have one lane, only one car can go through it at any given position. When you have 2 lanes, you can have 2 cars right next to each other both going through at the exact same time."

WC3 is purely sequential execution. It cannot process multiple threads simultaneously.

This discussion is about doing things in JASS that would be similar to the regular things on the user end.

Similar and yet completely useless. JASS is a single threaded only API run in a VM. C++ is a full programming language compiled to machine code and allowing multithreading if you code it as such. Hence, what works advantageously in C++ may just be slower and more complicated in JASS.

For some reason, nobody's reading my explanations that are scattered all over the first post -.-.

Your post is more shit than useful.

It's not like it's hard at all to do -.-. This is more for mediocre JASS people who wouldn't know how to do this stuff and are wondering how. I'm sure that people like yourself could figure it out pretty easily if you gave it a little thought. But I'm not going to explain it yes because nobody's yet to ask about it so... Like I keep saying, if you're curious about it, just ask.

Why the hell WOULD WE WANT TO? It has no advantages in JASS, and lots of disadvantages.

And if you want a good example of what I'm talking about, look at the C++ memory management section. I'm not actually managing the real memory... all I'm doing is creating an array in the background called memory and putting pointers within the variables that point to that memory. No, this isn't just like C++, but it's pretty darn similar and can let you do some things that you wouldn't normally be able to do without a setup like this. There's a more detailed explanation in the section and there are explanations describing some of the differences between this and the real thing. And remember, this is for JASS and is not describing how it actually *works* in C++. It's describing how it would work in JASS. You need to keep this in mind for all of the discussions.

You seem to be trying to explain dynamic arrays, which we've had for donkeys years (DARY I think (that the name?) by PipeDream is considerably older than vJASS).

What does this mean. This means that for things like the OpenGL thingie, it wouldn't be describing how OpenGL actually worked, but how you could get a similar result in JASS.

We have no graphics API of anywhere near the same strength, efficiency or flexibility of OpenGL.

I've scattered explanations just like this all over the first post, but nobody can seem to read so I'm saying it again.

So in short guys, stop saying I'm instantly wrong ok. Read first and see what this thing is actually about.

But you are wrong. This is key.

Well, now that it appears you've read : ).

Those are your own opinions and you're completely welcome to them = ). Also, I wasn't describing dynamic arrays : p.

But yea, now that you understand what I was talking about with OpenGL and so on, we can actually talk : ).

If you want to argue about how the stack works though :p, bring up some old quotes from posts and guides regarding the stack. I learned about it a long time ago from various vets and from reading a lot of posts ; ), so I was pretty sure I knew what I was talking about.

A: 6 threads per player and a main thread for the main function (once the main function is done, the main thread goes away so it's best to put the main function to sleep so this thread remains active)

B: Nothing is automatically syncd unless it accesses a global variable or is told to sync with other threads.

C: Functions that run on new threads (mostly via triggers) are automatically allocated to current active threads. It's impossible for you to start your own thread.

D: When all threads are handling data, the remaining triggers or whatever go on to a stack where they are added to a timer that goes off every second to check to see if any threads are available.

E: A thread is generally used when a trigger goes off, but you can also forcibly allocate (you can't choose which thread, but you can say it has to go on a new thread) a function to a thread via the ExecuteFunc() command.

-------------------
Now that the basics of how threads work in the JASS environment are over, let's go over some other stuff.

------
You cannot handle your own memory in JASS. Memory is handled in the background automatically with C++. There is no way to control this or anything. However, you can make your own C++ memory handling thing if you want to and all it would take it an array.

Ok, now that we're on the same page on that as well, moving on

OpenGL-
The only way to fully manipulate a model in wc3 the same way you would manipulate a model in OpenGL is to have that model completely broken up. This means you wouldn't import 1 model, but maybe 30 pieces of that model. You could also use generic square colored blocks to build your models in-game.

From here, you need to create a skeleton that will be used to animate your model. You do this by defining an origin z coordinate and then defining points based on offsets from your origin (no matter what z is, it would still be 0 in your skeleton because it's being used as the origin). Once you have all of the offset points set up, you can add your blocks on to each of these points. After this, you need to keep them updated with the origin point (the origin point is also the point that moves the model about). After this, you can animate it any way you like w/e. The more points you have on the skeleton, the more detailed you can be (every single particle on a finger or w/e you want).

Keep in mind that there are currently no good designs on doing this. If it were to be done and you were to play a regular game of wc3, wc3 would probably crash. This is because instead of 1 model on the screen (like ur little unit), you might have 100 little models making up that single model. From here, you have to keep them all syncd etc. Once a design is created for this, it'd be easy to update your models and what not, but it'd still be hard to actually build your own models inside of wc3 with various model parts or generic pieces and you'd still have CPU issues and memory issues.

For this design, you would have to have the following:
A system that would only create and update seen elements (elements that could be seen. For example, anything underneath a tree's bark wouldn't be animated until that tree's bark came off).

Only creating and updating what's on screen (would save a lot, but would still be intensive).

Only creating what's on screen for the local player (requires your own networking code, tools for this (WarSoc) can be found in RtC).

Really, I could only see something like this in First Person games because it'd kill any third person game if the detail was intense. I could see a design like this being used for low-detail things, like you might split your model into 4 pieces or w/e and let people choose their own face, or things like that. It'd also give a little more freedom in animation.

Like I said, this would be similar to OpenGL but it wouldn't be OpenGL. This would be as close as you could get to OpenGL if you wanted to do it in wc3.

Ok, any other questions? ;o

Originally Posted by Nestharus

Those are your own opinions and you're completely welcome to them = ). Also, I wasn't describing dynamic arrays : p.

You're babbling, be clear about what you WERE saying.

But yea, now that you understand what I was talking about with OpenGL and so on, we can actually talk : ).

Either it is opengl or it isn't.

If you want to argue about how the stack works though :p, bring up some old quotes from posts and guides regarding the stack. I learned about it a long time ago from various vets and from reading a lot of posts ; ), so I was pretty sure I knew what I was talking about.

I learnt from Pipe and Vex, and they actuall DO know what they're talking about.

A: 6 threads per player and a main thread for the main function (once the main function is done, the main thread goes away so it's best to put the main function to sleep so this thread remains active)

Why?

B: Nothing is automatically syncd unless it accesses a global variable or is told to sync with other threads.

Are we talking WC3 synced or thread synced? Because WC3 doesn't sync globals.

C: Functions that run on new threads (mostly via triggers) are automatically allocated to current active threads. It's impossible for you to start your own thread.

D: When all threads are handling data, the remaining triggers or whatever go on to a stack where they are added to a timer that goes off every second to check to see if any threads are available.

E: A thread is generally used when a trigger goes off, but you can also forcibly allocate (you can't choose which thread, but you can say it has to go on a new thread) a function to a thread via the ExecuteFunc() command.

Why would you do any of this? You haven't explained that.

You cannot handle your own memory in JASS. Memory is handled in the background automatically with C++. There is no way to control this or anything. However, you can make your own C++ memory handling thing if you want to and all it would take it an array.

You're saying nothing.

OpenGL-
The only way to fully manipulate a model in wc3 the same way you would manipulate a model in OpenGL is to have that model completely broken up. This means you wouldn't import 1 model, but maybe 30 pieces of that model. You could also use generic square colored blocks to build your models in-game.

From here, you need to create a skeleton that will be used to animate your model. You do this by defining an origin z coordinate and then defining points based on offsets from your origin (no matter what z is, it would still be 0 in your skeleton because it's being used as the origin). Once you have all of the offset points set up, you can add your blocks on to each of these points. After this, you need to keep them updated with the origin point (the origin point is also the point that moves the model about). After this, you can animate it any way you like w/e. The more points you have on the skeleton, the more detailed you can be (every single particle on a finger or w/e you want).

Keep in mind that there are currently no good designs on doing this. If it were to be done and you were to play a regular game of wc3, wc3 would probably crash. This is because instead of 1 model on the screen (like ur little unit), you might have 100 little models making up that single model. From here, you have to keep them all syncd etc. Once a design is created for this, it'd be easy to update your models and what not, but it'd still be hard to actually build your own models inside of wc3 with various model parts or generic pieces and you'd still have CPU issues and memory issues.

a) You're running it in a high-level VM.
b) You're running it off one CPU core.
c) You're running it in an engine not designed to do anything like it.

Totally and utterly unworkable.

For this design, you would have to have the following:
A system that would only create and update seen elements (elements that could be seen. For example, anything underneath a tree's bark wouldn't be animated until that tree's bark came off).

Only creating and updating what's on screen (would save a lot, but would still be intensive).

Only creating what's on screen for the local player (requires your own networking code, tools for this (WarSoc) can be found in RtC).

Really, I could only see something like this in First Person games because it'd kill any third person game if the detail was intense. I could see a design like this being used for low-detail things, like you might split your model into 4 pieces or w/e and let people choose their own face, or things like that. It'd also give a little more freedom in animation.

Like I said, this would be similar to OpenGL but it wouldn't be OpenGL. This would be as close as you could get to OpenGL if you wanted to do it in wc3.

It's totally unworkable, impossible to implement, and nothing at all like OpenGL.

It accomplishes something similar is all I was saying -.-

For the threads, every post I read about it and everyone I talk to about it has always said that there are 6 threads available for each player and there is one thread available for the main function.

From all posts I've ever read and from all discussions I've ever discussed about it, that's how the stack works ><.

And by the way, I explained that with high detail using that system, wc3 would probably crash :o. The only thing I could ever see where it'd be usable in very high detail would be in a first person view game with heavy limitations on what's constantly updated and animated. It'd also probably require something similar to RtC with local instances for each player. This means the players wouldn't be totally syncd together (a unit wouldn't be on the map for one player but on the map for the other) unless they were in the exact same area.

I'm just saying how you'd go about doing these things if you were really interested in doing them. Who knows, maybe someone will figure out some better methods of doing some of this stuff from reading my own methods ; ).

The point is that this was my own personal essay where I was describing my own methods of putting things into JASS that aren't normally done or are viewed by other as impossible to do. I'm just talking about work-arounds and nifty thingies ;o.

You don't have to be in the convo if you don't want to. You're just saying this stuff is useless and what not, but all I'm saying is how to do it. I'm also explaining why it would be kind of silly to use in some instances and some instances where it'd be ok to use in my own opinions (remember, this is an essay aimed for discussion).

If you don't agree with it, then yea, that's fine. But some people might be interested in controlling every aspect of their model to achieve ultra high realism, or some people might be handling radical amounts of data and want just that slight speed increase by forcing functions on to different threads (which has a limit as I described), or some people might like to have a memory structured in the background.

Really, that's for them to decide. I know that in some cases, I do use some of these things and I have seen improvements. I generally put all of these designs into all of my maps just in case. To me, map making is an art and it has to be absolutely perfect. The programming has to look really beautiful, I like to use one function for 50 different things instead of 50 somewhat similar functions that just handle different types of data but do the same operations (instead of taking an integer, it might take a string, or a unit, or w/e O_o).

But that's just me, and I figured that a lot of people can't really figure some of this stuff out.

Btw, the main reason why the multi-threading concept (I know it's not real multi-threading and I described that in the first post and we finally are on the same page that it's not real multi-threading) would be slower in some cases than others is the fact that global variables act more slowly than local variables ;o. Another reason might be that you have more functions going out than threads you can use, which means it gets stacked (super slow).

So rather than saying giving abrasive feedback like, you suck, you're wrong, that's bad, you're a moron, you might want to give some constructive feedback with your own thoughts on the issues at hand.

If you believe something is actually wrong (like our debate on the threading stuff), then put a post up or a guide up that says otherwise. I based a lot of this stuff off of the JASS Manual Wiki and discussions with a lot of people. I do have a lot of experience with JASS even if you don't believe it.

Oh, while we're on the subject, here are some other cool things to think about:
How to make maps of any size work on b.net
How to make RtC maps work on b.net (though I don't see a point to this. You might as well play them in single player and connect to a multi-player game or w/e, but it's something to know).

Oh well : )

But you're talking shit. Really. "very high detail" CANNOT be obtained by that method. You CANNOT get a speed bonus by that crap about "multi-threading".

The point is that I was saying how it was done and how it would be possible to get speed bonuses....... lol.....

Originally Posted by Nestharus

The point is that I was saying how it was done and how it would be possible to get speed bonuses....... lol.....

Impossible to get speed bonuses.

If you're using one of the threads that are open vrs like 12.. or w/e... And you're going through like 12 functions.... The one using 12 threads will be faster than the one using a single thread.... .... because the functions are done at the same time.... .... or dern close... unless you're saying that 12 threads are the same speed as a single thread.

We already determined that it's possible to forcefully send a function along a different thread that's currently open, but it's not possible to start your own threads. We've determined that there are 6 threads per player along with the main thread (used by the main function) as a result of a lot of people saying that (not sure where that started, but it's known =D... ).

In my opinion... 12 functions that are parallel to each other are faster than 12 functions that are in a line.... but I don't know, maybe I'm wrong. Maybe 12 functions going at around the same time are "slower" than 12 functions going one at a time in a line *cough*. They're probably doing multi-threading (talking out of wc3 now and talking about regular developers) to slow down games because it's so awful. Parallel processing is just so old school. Linear for me all the way.. *cough*

What is true is that it takes longer to send a function to a different thread than to keep the function running on the same thread, so if you're just doing regular function calls for tiny functions, it'll actually be slower because of this. If you have a decent sized function or something, it might be a little faster because you need to account for the extra time it takes to call it when you're forcing it on to a different thread and making it go through the stack and all of these other things. But if you have like 12 functions all going at once and in parallel for like the initialization of the game or for some huge gridding thing or something, in my opinion, it'd be faster to work those on separate threads than to work those all in the same thread, not to mention it'll keep your thread from stopping for a sec to prevent crashing if you're going through a lot of stuff.......

You're saying you can't get any speed bonuses from running functions on parallel threads rather than running them on the same thread... The only speed loss is going through the stack etc.... so it's possible to be slower, to be around the same speed, or to be faster. It's all about outweighing that extra time for actually sending it to a different thread, and it's also about how much is on the stack (if everything is full, it'll take really long because of the timer).

It's just common sense to me, but who knows. There might be a magical fairy that makes parallel processing slower than linear processing.

Originally Posted by Nestharus

If you're using one of the threads that are open vrs like 12.. or w/e... And you're going through like 12 functions.... The one using 12 threads will be faster than the one using a single thread.... .... because the functions are done at the same time.... .... or dern close... unless you're saying that 12 threads are the same speed as a single thread.

They aren't done at the same time. Really, your continued insistence that they are is making me think you're trolling or retarded. WC3 does no parallel processing.

We already determined that it's possible to forcefully send a function along a different thread that's currently open, but it's not possible to start your own threads. We've determined that there are 6 threads per player along with the main thread (used by the main function) as a result of a lot of people saying that (not sure where that started, but it's known =D... ).

I've had thousands of JASS threads running before. What evidence do oyu have for the 6 thread stuff, or it affecting anything in JASS?

In my opinion... 12 functions that are parallel to each other are faster than 12 functions that are in a line.... but I don't know, maybe I'm wrong. Maybe 12 functions going at around the same time are "slower" than 12 functions going one at a time in a line *cough*. They're probably doing multi-threading (talking out of wc3 now and talking about regular developers) to slow down games because it's so awful. Parallel processing is just so old school. Linear for me all the way.. *cough*

FFS, you cannot do more than one thing at once in WC3. Get that into your head...

What is true is that it takes longer to send a function to a different thread than to keep the function running on the same thread, so if you're just doing regular function calls for tiny functions, it'll actually be slower because of this. If you have a decent sized function or something, it might be a little faster because you need to account for the extra time it takes to call it when you're forcing it on to a different thread and making it go through the stack and all of these other things. But if you have like 12 functions all going at once and in parallel for like the initialization of the game or for some huge gridding thing or something, in my opinion, it'd be faster to work those on separate threads than to work those all in the same thread, not to mention it'll keep your thread from stopping for a sec to prevent crashing if you're going through a lot of stuff.......

Function calls in WC3 don't create a new thread...they just move from one part of the byte code to another. All of what you've said there is shit...

You're saying you can't get any speed bonuses from running functions on parallel threads rather than running them on the same thread... The only speed loss is going through the stack etc.... so it's possible to be slower, to be around the same speed, or to be faster. It's all about outweighing that extra time for actually sending it to a different thread, and it's also about how much is on the stack (if everything is full, it'll take really long because of the timer).

YOU CANNOT HAVE PARALLEL THREADS. You do not get any speed gain.

It's just common sense to me, but who knows. There might be a magical fairy that makes parallel processing slower than linear processing.

Read above.

How do you guys type that much without fainting, you should write a book.

I know seriously : D.

Ok, I just read up on something. I kept talking about various documentation.

Well, there's some confusion with some people, : o

Here:
In the AI Script for a map, you have 6 threads per player and 1 thread for the main function etc. You also have a function which actually allows you to start up *new* threads, not send them to already there threads. When a thread reaches its op limit *in an AI Script* it goes on the stack with a 1 second timer. When it returns null or finishes out, etc, the thread is terminated.

In small text as a very side note, new threads cannot be started in the Map Script for Maps in wc3. There is no information in any of the documentation as to how many threads are running in the map script and as to how execute func works. How the explanations made it sound to many people (including myself) is that you had 6 threads per player in any given script and 1 thread for the main function and that ExecuteFunc made data go to a different thread on a stack (this is a combination of the documentation and some JASS explanations by well known JASS figures).

The reality is that you can't start up new threads in JASS (which is what I've been saying all along -.-), but as for how ExecuteFunc actually works, the explanations given by some big figures was it sends it to various different threads in parallel, and by you is that there is no parallel processing.

Now, JASS is an Asynchronous language, which means multi-threading right there. As we saw above, you can start up your own threads in the AI portion of the script, but not in the MapScript area. However, because we already know JASS has these capabilities and that it's using parallel processing and what not in the AI area, it's probably doing the same thing in the map script area, I mean, half of it runs off of events ... Also look at ExecuteFunc.

According to you, here's how ExecuteFunc would work. You call your function with it, as soon as the original function ends, the new function would start up because there's only one thread so it can't do them both at once. If you were to actually use it, they'd both be running at the same time. Do a quick test if you want using a few strings and you'll see my point. Another thing you might say is, it just calls the function like regular, but that's not the case because in every single explanation of it and every test with it and so on, the original function is still moving on.

How could this be possible with a single thread? It's not... so either it runs off of magical ganja fairies or JASS, just like everyone says, is an Asynchronous language and the mapscript area for your JASS maps runs off of multiple threads off of a stack.

I've done my research = ).

Also, multithreading started its development back in 1955. In the 90s, there were major advancements in it, especially in the mid 90s. Now, warcraft 3 was released in 2002, so it def has multi-threading capabilities at the C++ level and according to everything from the wikis, the documentation, and the history and what not, it has support in the scripting language as well.

Now, I'm not saying you can start up your own threads, but I'm saying there is a pool of threads where threads are activated and deactivated. If you didn't do that, you're thread would just constantly be crashing. I mean, if you're having a few timers running at .03 seconds, you're going to have some major issues if the mapscript area is only on one thread ><.

Now, because I haven't seen the source code, I can't say for sure. This is just my theory on how it works.

Have you seen the actual source code? That's really the only way to know for certain because really you can set up some timers and what not to make it seem like multi-threading, and in the output or spewing or whatever really happens would be the same in either case, multi-threading would just be better for efficiency and what not, and so really, just by testing and using you can't tell. You've really gotta see the source to know for sure.

As I said, it'd be silly if mapscripts only ran on one thread and JASS already has multithreading capabilities.... you can even start up your very own threads in the AI area...

There is no parallel processing in WC3. The fact you've not even tried to draw distinctions between kernal threads, fibers, etc., implies you don't really have a clue wtf you're saying.

Multithreading in terms of parallel processing (ie: multiple threads at once; technically an abuse of the term, but it's how it is popularly used) is very different to just having several threads. Programming for the two is very different. Programming for the first was pointless pre-dual core era (in terms of gamers), and would have increased work load significantly without any benefit.

I've seen WC3 several times get locked to 50% CPU usage on my Pentium D. Never above. Pretty much 100% certain proof it is not capable of parallel processing.

I'm talking about multi-threading, not parallel processing ;o. In technicality, if you only have one CPU, parallel processing is impossible just like you said : )

Now, if you have multiple CPUs, this is when this comes in handy if wc3 lets the OS handle the threads. If it handles its own threads and so on in relation to the CPUs, then I guess that'd totally depend on how they did it.

You repeated have explitly talked about parallel processing...