This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.
Pages: « 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 »
151
Proposals / Re: do-until
« on: January 28, 2011, 10:24:20 am »
I'll check again, but I think that it didn't work on the parser side.
Hmm, seems to be working now. Odd.
Hmm, seems to be working now. Odd.
152
Function Peer Review / Re: move_towards_point
« on: January 27, 2011, 01:10:10 pm »
Well, basic integers are handled quickly by the processor. var has to check, at every calculation, what variable type is being used and how to handle it. It's not a huge notice, but if you take an entire project and convert it from var to primitive types, you'll see a relatively decent increase in speed.
153
Proposals / Re: Static object variables
« on: January 27, 2011, 01:07:29 pm »
I like the scope resolution because it treats classes like namespaces. I found how Java did it as being weird. :V
154
Announcements / Re: Happenings
« on: January 26, 2011, 09:57:12 pm »The school computer that I'm using uses eight coresdo they even offer prebuilt oct-core machines
155
Proposals / Static object variables
« on: January 26, 2011, 05:15:26 pm »
This is something that I think would be particularly useful. Opinions? Not sure if they'd use the member ( . ) operator or scope resolution ( :: ) like C++. Probably could be an option.
For those that are unfamiliar, static variables are variables that are accessed by a class, or object type, rather than a specific instance.
For those that are unfamiliar, static variables are variables that are accessed by a class, or object type, rather than a specific instance.
156
Function Peer Review / Re: move_towards_point
« on: January 26, 2011, 04:55:49 pm »
GML functions are slower in nature because they use var. But compared to the speed of GM, it's already loads faster anyways.
Besides, if you code something in GML, post it here, and someone will likely be able to convert it to C++ for you.
Besides, if you code something in GML, post it here, and someone will likely be able to convert it to C++ for you.
158
Announcements / Re: Happenings
« on: January 25, 2011, 10:50:12 am »
The GCC probably only supports dual-core.
159
Proposals / Re: Applications
« on: January 24, 2011, 05:13:17 pm »
If I'm not mistaken, what he means is having an option to not limit the framerate. But I don't see why it's needed.
160
Announcements / Re: Happenings
« on: January 24, 2011, 05:09:28 pm »
This might not be useful to many people, but just clarifying:
The GCC on every operating system in the entire world besides Windows separates C and C++ library functions into separate runtime libraries (DLLs or SOs depending on the OS). This is to reduce the size of programs, because if every program were to include them, it would just be a massive file size bloat.
Now, for Windows users, most people want to be able to bundle a single EXE and give it to people. If it's bigger, "more important," people usually don't groan about DLLs, because it's installed in some arbitrary folder in the middle of oblivion. But the unofficial Windows philosophy is to bundle every DLL with every program anyways, removing the point of them.
When C++ code is compiled, it is compiled into "objects" - these are intermediate, non-runnable bits of pre-compiled code that can be easily made to be runnable. A dynamic library (DLL or SO) is a file that contains the codes in a morphed form that enables executable programs to find the code and run it. This allows several programs to use the same code and link to only one place where it is located.
A static library is merely an archive (like ZIP) of all of the "objects," which are compiled along with a file to create an EXE. It is essentially duplicating the code and putting it in the executable.
For the GCC, it has libraries for libgcc, glibc, and libstdc++. glibc and libgcc are combined as far as the GCC sees. By default, the GCC it will link to dynamic libraries, requiring the DLLs to be placed in a usable PATH (on Windows, usually system32 or the current directory). If you use the -static-libgcc and -static-libstdc++ flags, these libraries are linked statically.
MinGW isn't being stupid. It's just finally decided that it's stupid to do something different from what the regular GCC does - and besides, its libraries are no different from Microsoft's C++ runtime. However, for the usage with a game similar to those of GM's, most people will hate the idea of bundling DLLs.
The GCC on every operating system in the entire world besides Windows separates C and C++ library functions into separate runtime libraries (DLLs or SOs depending on the OS). This is to reduce the size of programs, because if every program were to include them, it would just be a massive file size bloat.
Now, for Windows users, most people want to be able to bundle a single EXE and give it to people. If it's bigger, "more important," people usually don't groan about DLLs, because it's installed in some arbitrary folder in the middle of oblivion. But the unofficial Windows philosophy is to bundle every DLL with every program anyways, removing the point of them.
When C++ code is compiled, it is compiled into "objects" - these are intermediate, non-runnable bits of pre-compiled code that can be easily made to be runnable. A dynamic library (DLL or SO) is a file that contains the codes in a morphed form that enables executable programs to find the code and run it. This allows several programs to use the same code and link to only one place where it is located.
A static library is merely an archive (like ZIP) of all of the "objects," which are compiled along with a file to create an EXE. It is essentially duplicating the code and putting it in the executable.
For the GCC, it has libraries for libgcc, glibc, and libstdc++. glibc and libgcc are combined as far as the GCC sees. By default, the GCC it will link to dynamic libraries, requiring the DLLs to be placed in a usable PATH (on Windows, usually system32 or the current directory). If you use the -static-libgcc and -static-libstdc++ flags, these libraries are linked statically.
MinGW isn't being stupid. It's just finally decided that it's stupid to do something different from what the regular GCC does - and besides, its libraries are no different from Microsoft's C++ runtime. However, for the usage with a game similar to those of GM's, most people will hate the idea of bundling DLLs.
161
Function Peer Review / Re: move_towards_point
« on: January 24, 2011, 04:49:03 pm »
IsmAvatar - C++ doesn't allow setting access to globals. All globals are public. Only members of structs and classes can be set with access specifiers.
What could be done is merely not including the code for that header in the game, or just not linking the object. If the header provides a declaration and no implementation is provided, it will still compile as long as the function isn't being used. Alternatively, you can add these flags to the GCC:
-fdata-sections -ffunction-sections
which compiles everything into separate sections in the actual object, and:
-Wl,-gc-sections
which will remove unused sections from the program upon linking.
On that matter, for debugging purposes, it would be nice to be able to add -g -O0, which will provide C++ debugging symbols, which GDB can use. It's extraordinarily useful.
What could be done is merely not including the code for that header in the game, or just not linking the object. If the header provides a declaration and no implementation is provided, it will still compile as long as the function isn't being used. Alternatively, you can add these flags to the GCC:
-fdata-sections -ffunction-sections
which compiles everything into separate sections in the actual object, and:
-Wl,-gc-sections
which will remove unused sections from the program upon linking.
On that matter, for debugging purposes, it would be nice to be able to add -g -O0, which will provide C++ debugging symbols, which GDB can use. It's extraordinarily useful.
162
Function Peer Review / collision_point
« on: January 22, 2011, 09:00:14 pm »Code: [Select]
int collision_point(double x, double y, int obj, bool prec /*ignored*/, bool notme)
{
const enigma::object_collisions* r = collide_inst_point(obj,false,notme,x,y); //false is for solid_only, not prec
return r == NULL ? noone : r->id;
}
It's Ism's fault that this wasn't added.
163
Ideas and Design / Re: Extension API
« on: January 22, 2011, 08:41:23 pm »
I think that we should have a separate resource type entirely for C++ scripts. It would act like definitions, although, all concatenated. This would allow people to sort their sources rather than dumping them all into one pile.
I think that an entire extensions system is kind of overkill.
Maybe we could allow LGM to import GML or C++ scripts from an archive?
I think that an entire extensions system is kind of overkill.
Maybe we could allow LGM to import GML or C++ scripts from an archive?
164
Announcements / Re: Happenings
« on: January 18, 2011, 01:17:09 pm »
If you initialise variables in a switch case, they'll just be deleted at the }.
165
Issues Help Desk / Re: Unit Formations In RTS
« on: January 18, 2011, 10:13:26 am »
Please use [code] tags; they make code much easier to read.