Show Posts
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
1
Off-Topic / These numbers took 1.3 gigs of RAM to generate
« on: February 20, 2009, 11:01:45 am »
Probably because my implementation was suspect, but still. Big calculation.
ChIkEn's computer ran the calculation, the best computer in my house only had a gig of ram.
They consist of 640 keys, of which every combination of 3 keys has a unique XOR. As well, every combination of 2 keys also has a unique XOR. Essentially what this means is that if you take Elements A, B, C and xor them, they will never equal Elements D, E, F xor'd. (unless the keys in A B C are the exact same as in D E F).
The numbers (in the form of a C++ array):
http://willhostforfood.com/users/C/ChIkEn/results.txt
One of the 11 arrays is completely blank, because its just there for spacing reasons.
Now, practical reasons for this? I thought they'd be good for Zobrist hashing (which forms hashes based on xor combinations of preset keys).
Ensuring every xor combination of 4 elements is unique is probably possible, but would take about 320 times as much RAM, and thousand-folds more running time.
ChIkEn's computer ran the calculation, the best computer in my house only had a gig of ram.
They consist of 640 keys, of which every combination of 3 keys has a unique XOR. As well, every combination of 2 keys also has a unique XOR. Essentially what this means is that if you take Elements A, B, C and xor them, they will never equal Elements D, E, F xor'd. (unless the keys in A B C are the exact same as in D E F).
The numbers (in the form of a C++ array):
http://willhostforfood.com/users/C/ChIkEn/results.txt
One of the 11 arrays is completely blank, because its just there for spacing reasons.
Now, practical reasons for this? I thought they'd be good for Zobrist hashing (which forms hashes based on xor combinations of preset keys).
Ensuring every xor combination of 4 elements is unique is probably possible, but would take about 320 times as much RAM, and thousand-folds more running time.
2
Proposals / Some things just have to be deprecated
« on: November 23, 2008, 01:56:12 pm »
GML as it is in GM should definitely only be in a special compatibility mode. Instead, the real EDL language should have some more logical restrictions, and better organization of functions.
GM Code:
if variable_local_exists("Counter")
{
Counter+=1
ds_list_add(myList,Counter)
}
else
{
Counter=0
myList = ds_list_create()
}
EDL Equivalent
//Static variables are used instead, this code can be thought of 'only executing the first time', it is not set to 0 every time it is run
static int Counter = 0;//=0 is optional, in C++ static variables are always initialized to 0
static list myList; //creates an empty list if one is not created
Counter++
push(myList,Counter)
GM Code:
if variable_local_exists("Counter")
{
Counter+=1
ds_list_add(myList,Counter)
}
else
{
Counter=0
myList = ds_list_create()
}
EDL Equivalent
//Static variables are used instead, this code can be thought of 'only executing the first time', it is not set to 0 every time it is run
static int Counter = 0;//=0 is optional, in C++ static variables are always initialized to 0
static list myList; //creates an empty list if one is not created
Counter++
push(myList,Counter)
3
Announcements / Colligma 2.0
« on: October 01, 2008, 07:48:29 pm »
For the clueless, Colligma is ENGIMA's collision system, written by me, ludamad.
As have many things in ENIGMA history, Colligma is experiencing a complete re-write. The reasons for this were mostly because the old code was not as nearly as efficient as it could have been, and writing it from scratch is allowing me to avoid problems I ran into with the old Colligma completely. Most importantly, old Colligma did not work properly without at least one of the objects compared having a rotation, and in that case it'd work, but work slowly. As of the time of this writing, new colligma already has a properly implemented collision function for non-rotated objects.
Please note that Josh and I work on completely separate threads of code, and stalling on one side doesn't inhibit progress on the other.
Paragraphs are annoying, so here is some point form:
-The new Colligma will be optimized for 32 bit systems (as opposed to old colligma, which really wasn't optimized for anything). I will release a 64 bit optimized version too (the changes needed are trivial).
-The new Colligma benefits from better knowledge of optimization now.
-The new Colligma uses a less confusing naming structure, bitMask is the basic structure instead of collCustom.
-A EDL frontend will be written for ENIGMA, basically meaning one can call Colligma with no knowledge of C++ (it will be similar to GML).
Well, that's the news. So there.
As have many things in ENIGMA history, Colligma is experiencing a complete re-write. The reasons for this were mostly because the old code was not as nearly as efficient as it could have been, and writing it from scratch is allowing me to avoid problems I ran into with the old Colligma completely. Most importantly, old Colligma did not work properly without at least one of the objects compared having a rotation, and in that case it'd work, but work slowly. As of the time of this writing, new colligma already has a properly implemented collision function for non-rotated objects.
Please note that Josh and I work on completely separate threads of code, and stalling on one side doesn't inhibit progress on the other.
Paragraphs are annoying, so here is some point form:
-The new Colligma will be optimized for 32 bit systems (as opposed to old colligma, which really wasn't optimized for anything). I will release a 64 bit optimized version too (the changes needed are trivial).
-The new Colligma benefits from better knowledge of optimization now.
-The new Colligma uses a less confusing naming structure, bitMask is the basic structure instead of collCustom.
-A EDL frontend will be written for ENIGMA, basically meaning one can call Colligma with no knowledge of C++ (it will be similar to GML).
Well, that's the news. So there.
4
Alright, that's not the name of the team. Names come later. What I want to do is have a team that will make ENIGMA exclusive games, taking advantage of ENIGMA features, and coding around whatever problems it may (temporarily, it would allow us to find bugs) have. The team approach is simply so that multiple talents can come together, so far Mitch (Aeron) and I have decided on some sort of platform game with destructible terrain elements (a strength of ENIGMA compared to GM). Right now I'm just looking for people who are interested, and feel they can help.
So yeah, state your interest and your strengths.
I'll be doing bits of sprite-work, and a good deal of programming.
So yeah, state your interest and your strengths.
I'll be doing bits of sprite-work, and a good deal of programming.
5
Function Peer Review / GML?
« on: May 08, 2008, 11:47:27 am »
ENIGMA really shouldn't call it's scripting language GML, as neither is a proper subset of either. E++ is more like it, or C.En, to show its relationship to C++. Those are just suggestions, thoughts? Oh and you can move this, but this is a comment about this forum name.
Pages: 1