Essay on Programming Concepts

[Nestharus]

These essays address how one would put standard programming concepts into JASS along with non-standard ones : P

These would work off of pretty simple systems that you could design for your own map or download from a site like the hive. These systems would be designed according to the concepts discussed in these essays.

Some of these could be inserted into vjass as well =).

Please feel free to comment or ask questions about programming concepts that you'd love to do in JASS but you have no idea how to do it.

Examples:
OpenGL done in JASS
Dynamic Classes done in JASS
C++ Memory Handling in JASS
Creating a C++ array in JASS
Maximizing speed using multi-threading techniques in JASS

feel free to ask anything you're curious about : )

Table of Contents - Search for these titles to jump from title to title
Multi-Threading Concept
Handling Memory Like C++

Multi-Threading Concept
Most of us know what a thread is and what it means to create multi-threading applications and systems for both inside and outside of warcraft 3, but for those who don't know, a thread is a stream of code (or calculations). 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. This can go on. Now, there is something that has to be noted. Warcraft 3 doesn't let you create your own threads. You are allowed to run on threads that are already pre-defined. Your wants to use the threads are put into a stack. There are 6 threads per player. These aren't regular threads and wc3 doesn't let a user create a pre-defined thread. Another thing, the main function also runs on it's own thread so it's suggested that you never ever let the main function close. Put the thread to sleep or w/e. You can still maximize speed with multi-threading concepts (allocating your data to run as quickly as possible).

So, let's say you have 3 functions that are called within another function ,for example:
function randomstuff takes nothing returns nothing
call stuff1()
call stuff2()
call stuff3()
endfunction

Let's say that these 3 functions don't work off of each other and might as well go at once. We have 2 things which can make these go at once (one will add ugly code in the background, but is faster. The other allows for dynamic function calling using strings).

function randomstuff takes nothing returns nothing
call ExecuteFunc("stuff1")
call ExecuteFunc("stuff2")
call stuff3.execute()
endfunction

All three of these will start a new thread.

So, you're probably thinking at this point, threads are pretty cool and they can make my map run a lot faster! : O. Just imagine rewriting your main function in your map to be completely multi-threaded.

Well, while multi-threading can be awesome, you can't pass any information to these threads in JASS and there is no way for the function to wait for the new thread to finnish. So, let's analyze these issues.

1. Inability to send data to a new thread-
Eep

2. Unable to wait for new threads to finnish before continuing on
Example-
call ExecuteFunc("func1")
call ExecuteFunc("func2_that_needs_func_1")

In this example, func2 would start before func1 would get a chance to set the information up which would result in errors, crashes, and all sorts of fun things : D.

So, why not just call the function regularly in these cases?
Example-
call func1()
call ExecuteFunc("func2_that_needs_func_1")

Well, one issue you can have in this case is what could be called crashing a thread. Another thing is you can't maximize the speed. Let's say you only need the first 2 lines of function 1 to happen and then you can continue on to function 2. Let's say there are 100 lines of executed code in function one. That's 98 lines of code of wasted time.

So, how do we maximize speed? Well, what we can do is create a thread structure to connect our threads together.

Let's say we have a function called CreateThread, which creates a new thread structure and dynamically gives it a unique ID, so we could have like-

local integer ThreadID = ThreadTable.CreateThread()

In the background, CreateThread would be a method within ThreadTable that would auto generate our cache and so on for our new thread and store it in the global data structure called ThreadTable : o.

Ok, let's rewind here. Exactly what am I talking about when I'm saying ThreadTable, CreateThread, and so on. Threads are created via ExecuteFunc and .execute ><. Does the CreateThread Method use one of these things to create a new thread or what?

No, not really. What happens is if you were to create a design like this, you could set up a Global Thread Table that would initialize at the very start of the map. This thread table would contain function IDs (an array of various functions (strings)), storage arrays (storing units, integers, and what not), a boolean array (booleans to determine whether a thread is being used or not), and well, yea. So, what are these thread things we're talking about anyways?

Well, we know a regular thread is used to calculate information. When we're talking about thread tables and creating new threads in these cases, we're talking about mediums to transfer information between threads.

So wait? We can send local variables into other threads? that's impossible.

Well, the only work-around would be to either use the game cache or global variables. that's why we have our global structure for thread information.

So wait? When we create a new thread all we're doing is creating a space to store information and a pointer to it so we can access it later on?

Example-
Big Table
A pointer to the big table that's stored in a local variable

Well, if we do this, we get a pointer and what not to access our big table (like the indexes of the arrays), but how do we send this to the new function if we can't send any data at all?

Well, remember our function table? Well, can't we use that? So let's say we create a variable for each thread that stores a function ID.

So for example, like this
Thread[ThreadID].FunctionID = FunctionID in our Function Table

FunctionTable-
Function[1] = Our Spiffy Function
Function[2] = Our other spiffy function
Each index in the array would be the function ID

Now, when we start up a new thread that calls that function
call ExecuteFunc("Our Spiffy Function")

that function can start up by looking through all current threads that aren't being accessed and that contain its own function ID. So if we call 2 functions and have 2 pointers for those functions, they'll each get information for them.

Now, what does this mean? If you send data to a function within a new thread, that data won't necessarily make it to that specific function if another function that's the exact same would be called at once. So let's say you have 2 threads that are doing the same thing and they both start up new threads that do the same thing. Let's say we have an x1 and an x2 (thread1 and thread2). It could look something like this

Thread1- Sends x1 to Thread1New
Thread2- Sends x2 to Thread2New

Thread1New searches for an x1 with it's function ID, meaning it might either find x1 or x2

Let's say it finds x2
Thread1New closes off x2 so nothing else can retrieve it's info

Thread2New searches and because the only data that's left is x1, it recieves x1
Thread2New closes off x1 so nothing else can retrieve it's info

So
Thread1- Sends x1 to Thread1New
Thread2- Sends x2 to Thread2New
Thread1New recieves x2
Thread2New recieves x1

The data just jumped threads! : O. Yes, this is possible with a design like this. Does it really matter though? Let's say the functions do this

set y = y + x (x being the recieved data)

Let's say one piece of data applies it for like a treasure chest (increase the coins in it) and the other sends it to a bank (inceases the gold in the bank)

Well, since each function is the same, the properties for where to send it would be in the data

So let's say that in x1 and x2, there's a value, the integer that increases the gold, and a value of where to send the gold (either to the bank or to the treasure chest).

So now it turns like this

set y[xproperty] = y[xproperty] + x[value]

Now what this means is that it doesn't matter what specific instanced function receives the data so long as it's the same function. No matter what, the gold in the bank will go up and the gold in the treasure chest will go up by the right amounts.

So when we're sending data to a new thread, we really don't care which thread it goes to. All we care about is that it makes it to the right function : p, doesn't matter what thread the function comes from.

So, we learned how to send data in between threads and how to sort of design a basic system to do this. What exactly would the speed increase be for using a design like this?

Well, it really depends on how much code you're going through. A system like this would also prevent thread crashes because every function would get its very own thread. If you're just calling one function, it'd probably go slower with this system. If you're calling 30 functions, it'd go faster. It really depends on how much data you're handling.

Cool, so I'd only use a design like this for heavy data functions, like initializing 398230580348590 variables and creating a bundle of units or running a very complex combat system?

Well, yea... : p

But the functions still won't wait for the new threads to finish. How do I make them wait??

Well, remember our function state variable that closes off functions. When a new thread is created, you need to create different states for that thread.
State 0 = empty thread
State 1 = full thread waiting to be xfered
State 2 = received thread

Function States-
State 0 = Calculating data
State 1 = Finished calculating

This means that we can do 2 things to wait
Method #1:
If we want to wait for the thread to finish transferring, we'd just create a loop in the function that has a sleep timeout of .01 and just constantly checks the Thread's State for 0 using the ThreadID we got initially.

Method #2:
We store the original function's Function ID (the function calling the other function) into the Thread so that the called Function can call back on the original Function. From here we can create steps in the original function.

Example:
function1
checkstep (could be an if statement)
createthread
storedata
storestep (an integer)
call function2

function2
searchforthread
retrievedata
canstoredata
call function1

function1
checkstep
possibleretrievedata
possiblestoredata
call function3

etc etc

at the very end you'd have a DestroyThread, which would clear out the thread and remove it from the indexes and set its state to 0 .

Now you're probably thinking, jeezes, the timer would sure take up a lot. The steps seem kinda messy though if I use if statements.

Well, you don't have to use if statements : P. You could create a library of actions for each function within a data structure using methods and what not to make it really spiffy and organized.

So, now we know work-arounds for sending data in between threads and making functions wait for threads to finish sending data or for threads to totally finish up everything in them : D.

Would this be faster?
In some cases, yes, in some cases, no.

Is it worth it?
If you really want a spiffy as fast as possible map utilizing everything you can use, yes.

-------------------------------------------
Handling Memory Like C++

In C++, you can handle you own memory : D. What does this mean?

Well, variables are actually pointers to memory. They contain automatic index values of where the memory is stored. (not literally, but for our explanation on how to do this in JASS, yes)

It's really much like an array (not really, but for for the JASS design, yes)

Once again, this is an explanation for doing this in JASS****
Let's say that we have a variable called var and it contains a value of 3
The variable doesn't actually contain the value of 3, but rather a pointer to the place in memory where 3 is stored, almost like this.

(once again, this is dif from regular C++, C++, all 3 of these would be the same. C++ has a special thingie for retrieving the pointer to the memory. The normal variable would be the value that it points to in memory. You can set the memory value by changing the variable or the memory. In JASS, it works more like the below example) Yes, I'm inserting these little notes for people who are freaking out over my explanations .

var = 0
memory[var] = 3

In C++, you can either retrieve the 3 or you can retrieve the pointer value of 0. Now, how is this useful? Well, let's say you want to set variables dynamically. Let's say that a function can handle a type of data. Now, let's say we have 20 different global variables that are that type of data. We want to set a specific one.

Now, when passing information into functions (JASS), you can pass values and data types, but you can't pass variable names.

For example

integer x = 0
call function1(x)

That would not send the variable x into function1. It would just send the value of x, which is 0. Now, let's say we really wanted to pass the actual group of memory that x had into the function. Well, how can we do this in a scripting language???

Well, the way to do it is to set up our own C++ memory thing (This isn't like regular C++ memory, it's just a work-around to get very similar results) and to work all variables off of it. This means we create a huge array that I'm calling memory for now and we set all of our variables to contain indexes for that array. We also set our variable arrays to just contain indexes for that array + x, x being the index of our variable.

Here's a kinky example:

memory[0] = 0
memory[1] = 0
memory[2] = 0
variable1 = 0 (this accesses memory[0])
variable2[0] = 1+index (index is 0)
variable2[1] = 1+index (index is 1)

You're probably going, what's the point of this. Well, the point of this is passing actual variables through functions and not just their values. If we treat every variable as only a pointer to a piece of data and we use that pointer to access the data, then we can change that data because there's only one variable name. Here's an example.

set memory[variable1] = 10
call test(variabiable1,30)

function test takes integer variable1 returns nothing
set memory[variable1] = memory[variable] + 30
endfunction

Now, this seems pretty simplistic, but it makes it so you can manage your own memory (not literally, but similar) and allows you to pass actual spaces of memory (once again, not literally, but similar) into functions and not just values. How could this be useful? A lot of ways .

Hey, so now that we know how to do this, how can this play a role in everything? Well, let's say that we have a function that uses an equation to damage something dynamically in a combat system. Let's say there are 100 unique cases of units on the map each stored in their own little space of memory (memory where data structure is stored).

So one attacks the other. Now, normally, all we can do is retrieve the values of the damage, send that through the function, and then damage the unit per an event. Now, with this new feature, we can send the actual structures through the variables (not the values, but the entire structures themselves) and act upon those : D. We can retrieve the data within the actual damage function, and let's say we have custom hp, so we can act upon that hp within the structure. Creating a full custom combat system like this would not be able to retrieve triggering units, so it's very important that we are able to pass variables and what-not through functions. This means that all functions must only contain pointers to our special memory array and cannot contain actual values.

So, with this set up, we change our crappo jasso memory management (none at all) into memory management that's somewhat similar to C++.

So really, the only use for this is if you wanted to set any given variable to a value. Remember, normally you have to write out
x = x + 1

You can't suddenly change it to y or whatever during the game. To get around this, people use arrays and what not, which are icky. Yes, we're still using arrays, but we're working it a bit differently. Yes, this does take up more memory because we're using pointers and such (double to be precise), but for those cases where you need something like this, you can work those variables into a memory management thingie in the background like this. If every variable in your entire map needed this, well then, God Help You. Go learn C++.

Essays will continue on later = ).

 

[Captain Griffen]

WTF are you smoking?

 

[Vegavak]

What, no pie graphs?

 

[Nestharus]

These are just essays on concepts that some people might be interested in learning how to do or learning about and could be beneficial : ).

The one on handling memory in a C++ environment is rather small, basic, and simple : D.

Oh well, I was hoping that by writing these essays I'd be contributing. . I might even edit the posts to include some sample code of various things in use : D.

 

[PurplePoot]

Eh, what griffen is saying is more so that a lot of this is useless/wrong/both.

 

[Nestharus]

Fixed up explanations so that they explain it's not literally like C++ but similar. Fixed up a few typos.

Fixed up explanations on how these things could be useful.

Fixed up explanations on the limits of these things and added a note a the end =).

 

[PurplePoot]

Well, for example, your comments about avoiding code execution with threading are in complete clash with how the stack actually works, and thus wrong. That's the sort of problem.

 

[Nestharus]

Er, for our cases, we're just calling it multi-threading. I know about the stack, but eh.... I'm trying to describe it in basic terms. : p. Fine, I'll go through and edit my explanations, u win again poot

Ok, edited to include an explanation on what *threads* are in wc3.

 

[Cokemonkey11]

I'm not totally sure what to think because I sort of skimmed by this, but it seems like both ideas can be replaced by simpler and smaller ones.

I have no plans on using some insane damage calculation system which will reap the benefit of your thread idea (which you told me was your secret, shame on you).

And you memory index pointers seem very case specific and can be avoided simply by making a library when you're trying to do something as specific as calling something within something

Why would I call 1 in int[A] where int[1] = 5 when I can just call 5?

 

[Nestharus]

Ok, here are the real benefits:
You should really run your entire variable system off of this. The pros heavily outweigh the cons.

Why?
You'll be able to send physical variables into functions like C++. This means you can set any variable you want inside of called functions dynamically.

So instead of set x = x + 1

it'd be like

set var = var + 1 (where var is whatever variable you're sending in).

So yes, this is worth it.

For multi-threading:
I'm not saying all maps will use it, but in any case where you use multi-threading, you should use a system to allow your threads to communicate with each other.

Now, I talked with a guy who almost has a PhD in software engineering and stuff and he said that these would be standard ways of doing it if you wanted to do these things in JASS. I showed him the actual code I did though : p.

Now, in C++, you have all of these features but you don't use them sometimes. It's the fact that they are there and you can use them.

Now, what this means...

You can have 1 function for every single item in your inventory or whatever with the memory handling.

You can maximize your map's speed fully with the multi-threading.

Also the C++ guy said that method 1 should be used (the looped timers constantly checking up on the states).

Also, I don't understand what you are saying by memory index stuff being case sensitive : P

 

[Captain Griffen]

ExecuteFunc should never, ever, ever be used if you care about execution time.

WC3 cannot multithread. The more threads it needs to keep track of and map onto its own execution thread, the slower it will be.

OpenGL done in JASS

Impossible.

Dynamic Classes done in JASS

Dynamic classes? Not quite sure what you mean, sounds like bullshit.

C++ Memory Handling in JASS

C++ memory handling is all user-driven. In WC3, it isn't. You seem to be confused...

The variable doesn't actually contain the value of 3, but rather a pointer to the place in memory where 3 is stored, almost like this.

The variable DOES contain the value of 3. I'm fairly sure this is true in C++ as well. Integers, reals, etc. are objects rather than pointer variables. Putting a wrapper pointer onto it would make it slower.

Creating a C++ array in JASS

JASS arrays are way more limited, but dynamic array systems have been around for years, you're late to the party.

Maximizing speed using multi-threading techniques in JASS

Just plain bull. You cannot multithread in WC3.

 

[Dr Super Good]

I think parts of the WC3 engine are already threaded as it uses more than one processor when running, but triggers can never be threaded and will always execute in 1 thread.

Proof behind this? Wc3 can never desync due to bad "threading". In languages like JAVA if you make 2 threads with poorly synced code which handle the same data, like manipulating the same variable, the threads will not both finish at the same time and so the outcome may be different everytime the program is run due to the order each thread is run not being the same. This is most noticable on single CPU computers which can only run 1 thread at a time.

However, WC3 never sufferes from this so unless it syncronizeses every variable in every thread every time it comes to the variable (which would almost remove any benifits from threading at all if not make it slower), then WC3 must not multithread triggers.

 

[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.

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.

Next time, read, think, and then respond.

=).

For Dr. Super Good
Whenever a function or w/e accesses a global variable, it is syncd with the rest of the code. When it doesn't, it runs on it's own. I don't remember where I learned this, but I learned it awhile ago. This means that no, they don't all run on the same thread... They go on a stack. No, you can't start up your own threads : (, but you can assign functions to run on a thread that isn't being used at the moment. If all threads are being used, it goes on the stack and then later goes to that thread : D.

 

[Dr Super Good]

Unless you show test maps which can be used to prove the threading, no one will believe you. People like Captain Griffen and Vexorian over at WC3C know their stuff. Also WC3 was made before the time where threading had much of a point so even if it does support it, it will yield low speed benifits.

I dought OpenGL is possiable in WC3, especially since most people run it in Direct3D mode and secondly since triggers lack any native support for anything 3D related that does not envolve scaling or colouring models of objects or creating special effects / new objects.

Who knows, you might be able to prove most of the WC3 modding community wrong by giving evidence of threading or showing us the aledged openGL.

 

[Nestharus]

#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++.

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

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

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.

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.

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.

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.

 

[Captain Griffen]

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.

 

[Nestharus]

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 , 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

 

[Captain Griffen]

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 , 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.

 

[Nestharus]

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 . 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 ).

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 : )

 

[Captain Griffen]

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".

 

[Nestharus]

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

 

[Captain Griffen]

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.

 

[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.

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.

 

[Captain Griffen]

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.

 

[The_wand_mirror]

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

 

[Nestharus]

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...

 

[Captain Griffen]

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.

 

[Nestharus]

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.

 

[Captain Griffen]

You repeated have explitly talked about parallel processing...

 

[Nestharus]

When you open up new threads, if wc3 is set up properly, it should allocate these threads to various CPUs automatically (through the OS). This means that you really should do anything that you can do on various threads to keep the speed at its top ^_^.

You also have a special thing that comes in most CPUs now called Hyperthreading which is pretty spiffy and can help out with this process.

The point is programming to use the full capabilities of any given CPU. If you only figure every player is only going to have one CPU, then don't use multi-threading stuffs. If you figure they'll have more than one, then thread as much as you can so you're always at top speed and you always have 2 threads running at once ^_^.

Now, as I said, I'm unsure as to whether wc3 lets the OS handle the threads or wc3 handles the threads themselves. If it lets the OS handle the threads, then yea, multi-threading is def worth it. If not, then, I don't know if it uses multiple CPUs or not.

Unless you look at the source, there's no way to know.

 

[Captain Griffen]

Yes, there is. I can guarentee you WC3 does not have two threads running simultaneous. It has to be specially programmed for that for various reasons. It's not a simple matter, and cannot be done retroactively.

 

[HappyTauren]

Wc3 is old, it is not even meant to be ran on dual/quad/octa core processors. Hence why it can't multithread.

 

[Cokemonkey11]

...
You also have a special thing that comes in most CPUs now called Hyperthreading which is pretty spiffy and can help out with this process.
...

Intel's HTT technology does not "help with multi-threading process", it just forces the OS to see your processor as 2. Think of a dual-core with split total speed, if that makes sense (for example a 2.5ghz single core processor with HTT is half as good as a 2.5ghz dual core without, but don't think so literally because different progressions of processors bring new technologies and can't be thought of as 'twice as good' or 'half as good')

 

[Nestharus]

I didn't say it helped with the trheading process, I just said hyper-threading makes it go faster : P and is included in most CPUs.


Also, generally when you have a program or w/e, if you let the OS handle the threads and so on (meaning it has parallel processing capabilities), it can account for any number of CPUs.

Now, like I said, I was talking about multi-threading in wc3, not parallel processing, and I was talking about how the threads would be allocated to increase speed.

If it only uses 1 CPU no matter what and has absolutely no parallel processing, then I guess multi-threading would only be useful to keep your threads from crashing.

Yes, wc3 can multi-thread in either case, but it might not be able to run threads at the same time on various CPUs.

It sounds like it cant, so multi-threading would only help to keep threads from crashing = )

 

[Captain Griffen]

It cannot run more than one thread at once, full stop. Get that into your head ffs. And keeping threads from crashing is something everyone already does; if they don't, they notice quite quickly, and doing crazy ExecuteFunc abuse will never make it faster.

 

[Cokemonkey11]

I didn't say it helped with the trheading process, I just said hyper-threading makes it go faster : P and is included in most CPUs.


Also, generally when you have a program or w/e, if you let the OS handle the threads and so on (meaning it has parallel processing capabilities), it can account for any number of CPUs.

Wrong

1) you did say it helps with threading process (read my quote in last post)
2) hyperthreading does not make the multi-threading concept go faster
3) most modern CPU's in fact DO NOT have HTT.

 

[Nestharus]

Eh, this post doesn't need to be here and we already determined stuffs : P

 

[Cokemonkey11]

Coke, HTT, as the name suggests, makes threads in general go faster (spiffy programming). Many CPUs do in fact come with it built in (a college professor said so, so it must be true) and (many college textbooks support this claim).
Why?
Because you can have multi-core CPUs with hyperthreading technology.... Please post some sources that say you can't. I'd love to read them.

I don't care what the name suggests. HTT doesn't make multithreading go faster and in fact all it does is force the OS to see the processor as 2. (Also known as "2 virtual processors, 1 physical")

I don't care what college professors or college text books tell you, especially if they're wrong.

Not only is HTT an intel-only technology (therefor most cpu's couldn't possibly have HTT)

And on top of that, the system hasn't been used in the common retail market for multi-core processors.

Proof of that is right here: The only processor for sale on newegg that still uses HTT is here and it is a socket 478, 89W single-core processor.

Thanks for playing,

 

[Nestharus]

Hm... Ok, I'll give you that one, but griffen still loses ;p

Nice one coke : D



+rep for winning btw : D

 

[Captain Griffen]

You know, it's at times like this that I think, yea, banning people for gross retardation is a good idea.

You're now claiming to have said first what I said in the 11th post in this thread, because you said it in the 34th? And also coming out with outrageous strawman arguments?

 

[Nestharus]

I'm not saying I said it first, I'm saying your last post was bad ^_^, that's all : D

I came to a conclusion and you said, ur wrong, and then you said the same thing I had just said like this

I say:
2 + 2 = 4

You say:
ur wrong, 2 + 2 = 4

I say:
wtf?

and way before this, you were talking about multi-processing and I was talking about multi-threading and sending that to various CPUs, you were saying you can't do that in wc3, I was saying well, you can multi-thread, then I did some research after you clarified and I said, it seems unlikely that it uses more than one CPU, in essence, I was agreeing with you in that one, and then you say something like the model above.

= ), I hope that clarifies things : D

So, here's the road map tho

1. I say multi-thread and running threads at same time
2. You say you can't multithread
3. I say you can
4. Eventually you say you can't do parallel processing
5. I do some research and go, you can't know unless you read the source, but it's highly probable that it doesn't do parallel processing
6. You say ur wrong, it doesn't do parallel processing
7. I say, that last post was pretty retarded

But atleast we're all on the same page now, so all is ok : D

 

[Captain Griffen]

1. I say multi-thread and running threads at same time
2. You say you can't multithread
3. I say you can
4. Eventually you say you can't do parallel processing
5. I do some research and go, you can't know unless you read the source, but it's highly probable that it doesn't do parallel processing
6. You say ur wrong, it doesn't do parallel processing
7. I say, that last post was pretty retarded

Running threads at same time IS parallel processing - you alledged it (and it's also what multithreading means in common usage).

More like you say 2+2 = 5 to start with, since you EXPLICITLY said that it DOES execute multiple threads at once.

 

[Nestharus]

I said the model applies later on : P, I know I wrote that in my last post : D