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.
16
Announcements / Re: Tentative Todo
« on: June 07, 2010, 08:14:28 pm »
The concept of reducing the size of a game and its being an idea. A one bit game is a one bit idea. Unfortunately x86 isn't entirely suitable as a measurement. Also resources. Josh had an error, I stated *&. It solved his error, though only for another. It caused me to think about how much information was communicated. High estimate is 14bits. Of all the vast amounts of information churned by both him and I, 14 bits were all he required from me. So small in comparison to it all. It's the power of diff. The PAQ inspired competition of wiki text compression presumes compression and AI to be intertwined, having proved optimal compression to require a predictor model. It's true in so far as the leader in the competition had to modify PAQ to account for some semantic analysis of English. To note, they add the decompressor to the compressed text's size. 14 bits of compressed information were all Josh needed from me, but the data involved is still the entirety of his mind which he projected towards the transmission. I sent the characters individually, thus he misinterpreted the first character. Branch prediction plays in somewhere. Whatever, it's all just pattern matching
18
Proposals / Re: Recursion
« on: May 31, 2010, 05:07:59 pm »
C99:
5.1.2.2.1 Program startup
1 The function called at program startup is named main. The implementation declares no
prototype for this function. It shall be defined with a return type of int and with no
parameters:
int main(void) { /* ... */ }
or with two parameters (referred to here as argc and argv, though any names may be
used, as they are local to the function in which they are declared):
int main(int argc, char *argv[]) { /* ... */ }
or equivalent;9) or in some other implementation-defined manner.
2 If they are declared, the parameters to the main function shall obey the following
constraints:
— The value of argc shall be nonnegative.
— argv[argc] shall be a null pointer.
— If the value of argc is greater than zero, the array members argv[0] through
argv[argc-1] inclusive shall contain pointers to strings, which are given
implementation-defined values by the host environment prior to program startup. The
intent is to supply to the program information determined prior to program startup
from elsewhere in the hosted environment. If the host environment is not capable of
supplying strings with letters in both uppercase and lowercase, the implementation
shall ensure that the strings are received in lowercase.
— If the value of argc is greater than zero, the string pointed to by argv[0]
represents the program name; argv[0][0] shall be the null character if the
program name is not available from the host environment. If the value of argc is
greater than one, the strings pointed to by argv[1] through argv[argc-1]
represent the program parameters.
— The parameters argc and argv and the strings pointed to by the argv array shall
be modifiable by the program, and retain their last-stored values between program
startup and program termination.
5.1.2.2.1 Program startup
1 The function called at program startup is named main. The implementation declares no
prototype for this function. It shall be defined with a return type of int and with no
parameters:
int main(void) { /* ... */ }
or with two parameters (referred to here as argc and argv, though any names may be
used, as they are local to the function in which they are declared):
int main(int argc, char *argv[]) { /* ... */ }
or equivalent;9) or in some other implementation-defined manner.
2 If they are declared, the parameters to the main function shall obey the following
constraints:
— The value of argc shall be nonnegative.
— argv[argc] shall be a null pointer.
— If the value of argc is greater than zero, the array members argv[0] through
argv[argc-1] inclusive shall contain pointers to strings, which are given
implementation-defined values by the host environment prior to program startup. The
intent is to supply to the program information determined prior to program startup
from elsewhere in the hosted environment. If the host environment is not capable of
supplying strings with letters in both uppercase and lowercase, the implementation
shall ensure that the strings are received in lowercase.
— If the value of argc is greater than zero, the string pointed to by argv[0]
represents the program name; argv[0][0] shall be the null character if the
program name is not available from the host environment. If the value of argc is
greater than one, the strings pointed to by argv[1] through argv[argc-1]
represent the program parameters.
— The parameters argc and argv and the strings pointed to by the argv array shall
be modifiable by the program, and retain their last-stored values between program
startup and program termination.
19
Proposals / Re: LGM-ENIGMA options panel.
« on: May 18, 2010, 04:17:25 pm »
Zip is a good format for distribution, but having to go through the process of zipping any save isn't nice. Thus why it'd be good if Enigma supported opening zip files, but in reality worked with uncompressed directories. Trust your file systems
20
Proposals / Re: LGM-ENIGMA options panel.
« on: May 18, 2010, 02:40:25 pm »
Demur: .jar is a bad idea to find inspiration from
Demur: .jar is meant for release
Demur: You're only picking over source representation
Demur: Making it an uncompressed directory probably suits better
Josh: Post so
Demur: Why should I?
Josh: well, if you wanted credit for the idea
Demur: It's the obvious solution
Demur: sprite0 sprite1 naming scheme
Demur: If people want, they can reorganize IDs on their own
Demur: Want to add a resource? Put it in the directory
Josh: except it loses part of the idea
Josh: which is to have a format that's easy to upload
Demur: Zip the directory
Demur: Done
Josh:
Demur: .jar is meant for release
Demur: You're only picking over source representation
Demur: Making it an uncompressed directory probably suits better
Josh: Post so
Demur: Why should I?
Josh: well, if you wanted credit for the idea
Demur: It's the obvious solution
Demur: sprite0 sprite1 naming scheme
Demur: If people want, they can reorganize IDs on their own
Demur: Want to add a resource? Put it in the directory
Josh: except it loses part of the idea
Josh: which is to have a format that's easy to upload
Demur: Zip the directory
Demur: Done
Josh:
21
Proposals / Re: Tiering vs Components
« on: May 16, 2010, 08:07:42 pm »
The large thing with dynamic execution of code is if it's really worth adding a JIT for. The only language I believe eval belongs in is Lisp, anywhere else is a convenient hack. My opinion of convenient hacks: Abuse them while they're around, and don't cry when they get removed because they stop being convenient
23
Proposals / Re: Tiering vs Components
« on: May 14, 2010, 09:02:04 pm »
Josh likes the system he came up with because it suits his objectives, instead of Rusky's? Scandalous
24
Issues Help Desk / Re: C++, Linux and 39DLL.
« on: May 14, 2010, 02:58:52 pm »
It appears he doesn't, due to thinking it the same as Option 1. There is no need to think in stacks once you receive it server side. Though I'll admit that 39dll's stack abstraction is quite nice for sockets, making the streaming abstraction apply throughout
25
Issues Help Desk / Re: C++, Linux and 39DLL.
« on: May 14, 2010, 08:34:11 am »
You don't have to use 39dll on a Linux server to communicate with a 39dll client
26
Issues Help Desk / Re: Physics bugs
« on: May 13, 2010, 07:11:12 pm »
Your code makes me feel gross inside
if(other.x>x-5) if(other.x<x+5) if(other.y>y1-5) if(other.y<y1)
&&. If you plan to use Enigma, that's sense. If you're trying to be fast on GM, that's not how to go about it. Going about it is to use the more efficient alternative methods offered
left = 0;
right = 0;
up = 0;
down = 0;
jump = 0;
if(keyboard_check(vk_left)){
left = 1;
}
if(keyboard_check(vk_right)){
right = 1;
}
if(keyboard_check(vk_up)){
up = 1;
}
if(keyboard_check(vk_down)){
down = 1;
}
if(keyboard_check(vk_space)){
jump = 1;
}
Should be
left=keyboard_check(vk_left)
right=keyboard_check(vk_right)
up=keyboard_check(vk_up)
down=keyboard_check(vk_down)
jump=keyboard_check(vk_space)
if(up){
vspeed = -120
}
if(down){
vspeed = 120;
}
else if. Use it
hspeed = right*125-left*125;
Consistency. Use it. If you're going to do stuff like that, don't have the if else elsewhere doing so. Personally, I'd use 125*(right-left)
As for your bug, such seems to be inherit to overly stateful code
if(other.x>x-5) if(other.x<x+5) if(other.y>y1-5) if(other.y<y1)
&&. If you plan to use Enigma, that's sense. If you're trying to be fast on GM, that's not how to go about it. Going about it is to use the more efficient alternative methods offered
left = 0;
right = 0;
up = 0;
down = 0;
jump = 0;
if(keyboard_check(vk_left)){
left = 1;
}
if(keyboard_check(vk_right)){
right = 1;
}
if(keyboard_check(vk_up)){
up = 1;
}
if(keyboard_check(vk_down)){
down = 1;
}
if(keyboard_check(vk_space)){
jump = 1;
}
Should be
left=keyboard_check(vk_left)
right=keyboard_check(vk_right)
up=keyboard_check(vk_up)
down=keyboard_check(vk_down)
jump=keyboard_check(vk_space)
if(up){
vspeed = -120
}
if(down){
vspeed = 120;
}
else if. Use it
hspeed = right*125-left*125;
Consistency. Use it. If you're going to do stuff like that, don't have the if else elsewhere doing so. Personally, I'd use 125*(right-left)
As for your bug, such seems to be inherit to overly stateful code
27
Announcements / Re: Anaphase
« on: April 05, 2010, 03:53:51 pm »
http://coq.inria.fr/stdlib
Click a few links, you'll see some Coq code. This isn't the language suited for implementing Enigma
Click a few links, you'll see some Coq code. This isn't the language suited for implementing Enigma
28
Announcements / Re: Anaphase
« on: April 05, 2010, 03:03:42 pm »
Rusky is into solving the halting problem
29
Announcements / Re: Metaphase
« on: April 02, 2010, 09:07:37 am »
Fede: Glitches are preferred towards things which are more random (such as faulty hardware). Bug is the preferred term for clever code that isn't clever enough
30
Tips, Tutorials, Examples / Re: Which should I use?
« on: March 31, 2010, 01:27:22 pm »
size_t is not defined to be the size of a pointer. size_t is only defined to be the type returned by sizeof. C doesn't define intersections between pointers and integers