ID:1799692
 
How many people are currently learning how to use the Dream Maker?

Also, an unrelated question. Is there a way to tell how many people use this site?

And, Am I posting this in the correct place?
You don't really ever stop learning I think.
If you mean trying to become proficient?

<--- This guy is.
I recently started delving into DM. I initially investigated the gaming engine a month or two ago on a friend's suggestion but started working on stuff in earnest within the last week or two. It's been engaging so far!
I agree with Zecronious, although one may know the language in-and-out, you'll always find several ways to achieve the same goal. Some of these ways may surprise you at that.

In the end, knowing the terms for the program is vital, utilizing the logic to make something out of these terms is the point.

I may create something in 5 lines of code that takes Zecronious 20, or vice-versa, but it's great to know both ways and which is more effecient to run on your server.

Example:

You may be somebody who likes to use if and else statements to toggle a variable rather than use a single line of code.

Multiple Lines, more code:

var/toggle_me = "OFF";
mob/verb/Toggle()
{
if(toggle_me == "OFF")
{
toggle_me = "ON";
} else {
toggle_me = "OFF";
}
src<<"You have toggled the switch [toggle_me]";
}



Or just do it in a single line of code.

var/toggle_me = "OFF";
mob/verb/Toggle()
{
toggle_me = toggle_me == "OFF" ? "ON" : "OFF";
src<<"You have toggled the switch [toggle_me]";
}


Of course there are more complex systems than a toggler, but using what BYOND's language provides for you plus your logic, your limitations are practically what you make them, aside from BYOND's standard limitations like non-3D(Raycasting isn't 3D, just psuedo-3D).
Learning is a constant process with just about any programming language. Experience has a way of uncovering new techniques in reference to features you have not previously used or new ways to using such features.

Regardless of my beginnings since very late 2003/very early 2004, I have learned new things over the years. It has been a long while since I delved into DM, but I have just put some thought into dealing with DM again.
In response to Ssj4justdale
I prefer to use math like

Toggle=0
Toggle=1-Toggle

In order to toggle things. But neither of these methods is going to cause you problems
In response to DanteVFenris
var toggle = FALSE

mob/verb/Flip()
toggle = !toggle
world << (toggle ? "TRUE" : "FALSE")

Ill stick with my 0's and 1's. But yea that just goes to show yet another way of doing same process. It's just in larger components having certain ways may be valuable as maybe the way your currently doing it is using a lot of resources.
In response to DanteVFenris
It is more efficient, conceptually and CPU-wise, to treat boolean values as boolean values.

Although TRUE and FALSE are actually 1 and 0, toggling with "1 - x" is nonsense in the context of booleans, where the "!x" operator is meant to be used.
In response to Kaiochao
I'm not too knowledgable with what happens in the computer but I thought the compiler would have to remember that 0 and 1 in fact equated to TRUE AND FALSE. So using the not operator is more efficient than subtraction? Well my way works for all languages at least I don't have to worry what language I am writing.
Well my way works for all languages at least I don't have to worry what language I am writing.

Your way is actually inferior no matter what language you are writing in. It's simply the fact that arithmetic is meaningless in the context of a boolean value. In many languages, the +/- operators may not even have a meaningful context with a left or right hand operator as an explicit boolean, which may potentially lead to compiler errors.

Booleans are actually an area of poor understanding for most people.

Memory addresses are enumerated in sequences of 8 bits, so a boolean cannot in most languages actually occupy only a single bit. The occupancy of a bit is often 8 bytes. However, the specific compiler for the language will often times treat boolean primitives as simply ignoring the remaining 7 bits in the chain, effectively making the first bit the only one that matters for evaluation purposes.

In a pure CS sense, you should always treat your primitive types as though they exist within specific contexts. This means that some operations are ideologically invalid even if the language in question permits you to commit such atrocities.

For booleans, binary/logical operations are the only operations that are considered valid in the context of a boolean, and thus should be the only operations used in the context of booleans.

DM itself is like many modern more flexible languages, in that the language is somewhat casting-agnostic. This is good and bad. Good, because it allows you to more fluidly manipulate values, and bad because it also allows you to make logical errors that a more strict compiler worth its salt would prevent you from making.

Booleans in BYOND are the same thing as all other numeric types. They simply reference a signed floating point value with integer precision up to 24 bits. This means that a boolean value can accidentally exit the expected range, for instance being set to 2 or -1, which in the context of a boolean is completely meaningless. There is no 2, and there is no signing bit, so these values just straight up don't make a lick of sense.

Sure, Garbage-in, garbage out, and all of that, but in your specific case, your approach would compound the issue, whereas a logical not would actually not be at all perturbed by this.

!-1 -> 0
!2 -> 0
!0 -> 1


1-(-1) -> 2
1-2 -> -1
1 - 0 -> 1


Not only is your method slower, it's also prone to preserving existing errors in the valuation range, while the logical and binary operators are not.

I'm not too knowledgable with what happens in the computer but I thought the compiler would have to remember that 0 and 1 in fact equated to TRUE AND FALSE. So using the not operator is more efficient than subtraction? Well my way works for all languages at least I don't have to worry what language I am writing.

Actually, the way it works, is that when a project in DM is compiled, a standard library called stddefs.dm is included silently in your project. stddefs.dm includes a definition for TRUE and FALSE:

#define TRUE 1
#define FALSE 0


TRUE and FALSE are the same thing as any other preprocessor macro.

The DM compiler is a two-stage compiler. First, it searches through the files included with the project in sequence, strips out comments and parses each token out of the file. When it encounters a preprocessor command, the command helps shape the compiler's state. A #define command will instruct the compiler to add a token alias. Every time the compiler finds a label, it will check to see if there is a matching label in the compiler's running list of token aliases and replace the label with whatever the token maps to as defined in the second part of the #define operation. #undefine removes definitions from the map, also included are logical expression branches #if/#else/#endif, error generators: #error/#warn, and the #include directive, which tells the compiler to immediately jump to that file and perform preprocessing on it before continuing in the current file.

After expansion, the entire codebase is more or less a series of tokens ready for second-step compilation. First-step compilation actually constructs the type tree, variables, and function names, while second-step compilation mostly has to do with the function bodies. Think of the first step as C++ header linking. BYOND's two-stage compiler allows the language to be aware of objects and their properties before they've been literally defined. Since the only time you can access objects and their properties is inside of a function, separating out function body compilation to the second step prevents link errors that tend to drive new programmers up the wall in C++. The second stage more or less just boils down function bodies into bytecode and stuffs it all into the DMB.

TL;DR: typing TRUE is identical to typing 1, as far as the runtime engine is confirmed. The compiler automatically replaces preprocessor macros with their constant values during pre-compilation.
Oh okay thank you that was very helpful. I like to know what's going on inside.

I assumed false and true were defined but like I said that meant nothing to me as I don't know how it handles data inside. But how the bits are interpreted makes sense

Edit: But also in my case
Var/toggle=0
Toggle=1-toggle
It would never equate to 2 unless for some reason I did toggle=2. But I get what you mean it prevents logic if it were to behave in that process.
It would never equate to 2 unless for some reason I did toggle=2

True. It's a moot point, as when it comes to developer-facing stuff, Garbage-In, Garbage-out. There isn't much need to sanity check developer-oriented code, so as long as you filter any user input (I always say that you should assume that your end-user is a cat laying on the keyboard), you won't have any real problems. Assuming the developer's an idiot isn't worth the time.

One thing to note, though, is what yours compiles down to in bytecode:

push 1
access x (push)
sub (pop pop push)
assign *Toggle (pop)


Whereas !x would simply be:
access x (push)
lnot (pop push)
assign *Toggle (pop)


The lnot is 1 instruction fewer, and one stack mutation fewer. It's not a huge difference, but it is a difference. You also have to remember that each of these operations also has an underlying impact from BYOND itself's compiled machine code. The ASM instructions will also be different between these two, creating an even more significant impact.
In response to Ter13
So would this be correct.

Let's say an integer is just 4 bits for simplicity. I was doing 0001-0000 and the operations to do that. While the other way just detects if the first bit is a 1 or 0?
No. The other way checks if the value is equal to 0000 assuming that integers are 4 bits, because BYOND doesn't actually have such a thing as explicit boolean values. All numeric values are 32 bits in length, with only 24 of them being precise, and only 16 being accessible to binary operations.

!0000 == 0001
otherwise: 0000
Well thank you that's nice to know
In response to Zecronious
Zecronious wrote:
You don't really ever stop learning I think.

I still learn a few things everyday. Especially from Lummox since he's started posting some inside information on what is efficient and inefficient. Much like how the for to loop is far superior than other repetitive loops.

Not to mention that there new procs coming out occasionally and new features (Time to learn JS for all you WebClient devs). So, there's a lot to learn about how things are done in DM. You never stop learning. At least not while BYOND is in development. One way to keep up to date is to read release notes here: http://www.byond.com/docs/notes/ and here too... http://www.byond.com/forum/?forum=16 . Stay up to date about what's new and you'll eventually learn some interesting things.
In response to Ssj4justdale
Dale. I hate you for using curly brackets. That is one of DMs cool features. The lack of being forced to include curly brackets every time. Don't be that guy. Don't... Lol.

Curly braces can be useful some of the time. Mostly when condensing code for use in preprocessor macros, but yeah. I prefer to leave them out of my code.
Page: 1 2 3