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.

Messages - Josh @ Dreamland

Announcements / Re: Var 4
« on: June 19, 2010, 02:04:43 PM »
That's what I was thinking. In fact, the new instance system also uses quite a bit more memory than the old. We're talking nearly half a megabyte for a game with 1,000 instances at 10 events apiece. But it introduces a beautiful mechanism for the instance functions, and even with() and the like.

Announcements / Re: Battling
« on: June 19, 2010, 01:29:43 PM »
It will so long as the calling process has them as well. Problem is, Java explodes when groped by GDB. Even if what's called is perfectly healthy.

Announcements / Var 4
« on: June 19, 2010, 07:12:35 AM »
Questions on which to pick and why have boiled down to the need to separate var into individual sources, each implementing a behavior. Var 4 will apparently implement several options.

The first of these is in how arrays are handled:
- GM uses a Map for everything, as some of you know. I guess I could make that an option.
- ENIGMA R3 uses a simple dynamic array. It checks for size, then dereferences O(1).
- Lua uses both. It would implement no additional overhead from R3, but would add some in computing whether it should use the map for large indexes.

The second of these is in how variants store memory.
- GM's method cannot be determined simply through experimentation. Presumably, since it is interpreted, Mark keeps close track of type (an extra check among a map lookup is nothing).
- ENIGMA R3 kept variant next to double for max speed, but high memory usage.
- I am capable of constructing and destroying string on the site, at the cost of an additional check per = operation (and of course, constructor and destructor call). This will reduce memory usage, but slightly(?) lower speed as well.

I will spend today trying to implement them (among other things).

Announcements / Re: Battling
« on: June 18, 2010, 01:23:27 PM »
Yeah, it works fine for me due to hardware sync. But...

Announcements / Re: Battling
« on: June 18, 2010, 12:29:38 PM »
Nope, I don't think she can. Haha. Besides, it would have been more difficult to find than that, it seems.

Indeed. When I had the compiler generate the segment of code responsible for event iteration, I omitted the function call that handles FPS calculation. That will be fixed after the implementation of var4 and further segfault testing today.

Announcements / Re: Battling
« on: June 17, 2010, 04:21:57 PM »
Sorry. Forgot to install new FPS limiter. So you're probably getting some ridiculous framerate.

Announcements / Re: Battling
« on: June 17, 2010, 10:30:09 AM »
I was trying to allow for a separate target ("link") to take care of everything, then just rename the file to Dll on windows or so on Linux. That's the only part that's different (It looked much better on paper than in code).

Anyway, I found the problem, I believe; these things tend to be much easier to find when you actually experience them. So the segfault on random platforms and architectures should be resolved, as of the just-committed r266. Hopefully that's the end of our trouble; I'll proceed for now.

I'm happy to report that the new instance system is, as I'd hoped, faster. than. all. fucking. greased. lightning.
Holy. Hell.

I can safely say that this is the best idea I've had all year. Pics and code will follow.

Announcements / Re: Battling
« on: June 17, 2010, 09:43:58 AM »
It almost seems that the problem is with 32bit systems... and with Freezway's 64bit arch. <_<" Love me some consistent data. Let me run some diagnostics...

Yep, that's Microsoft's way of dealing with a segfault, I'd forgotten.

Announcements / Battling
« on: June 17, 2010, 01:05:13 AM »
Ism reports a segfault when she runs Catch the Clown with what's uploaded of the new instance system, as does freezway. I can't reproduce this on any machine at my disposal. The new instance system is mostly done, but does not yet implement a (working) instance_destroy(). It just prints an error to the console at the moment. It is not difficult to implement, but I want to hear that people can compile Catch the Clown first.

I don't understand the problem. I checked out everything for the first time on a new Win7 machine. Downloaded RapidSVN, checked out, installed MinGW, ran. I had to edit six lines to get it to compile on Windows; after that, no segfault. No negative repercussions.

If anyone could provide useful insight into the segfault, that'd be useful. Current effective revision is 265. Catch the Clown is available from Ism's topic, ultimately from this link on her website:

Windows users can get MinGW here:
RapidSVN here:
From RapidSVN, go to Repository->Check out. URL is Pick a directory yourself.
For the MinGW installer, select G++ Compiler and MinGW Make as well. ENIGMA needs both.
Run CMD and move to the folder containing ENIGMA. Execute `mingw32-make.exe -C CompilerSource windows`. You will need to identify where mingw32-make.exe is. It's probably `C:\MinGW\bin\mingw32-make.exe -C CompilerSource windows` for you. Windows is odd. If make errors towards the end, rename compileEGMf.exe to compileEGMf.dll yourself.

From Linux, install the following with your favorite package manager:
libgl1-mesa-dev (or similar)
zlib1g-dev (tab complete is your friend)
sun-java6-jre (Or Java in general, but I -strongly- recommend this one)
Then run this:
svn co enigma-test
cd enigma-test
make -C CompilerSource linux
java -jar lgm16b4.jar

In either case, when LGM loads with the ENIGMA background, load the GMK you got from and try to compile and run it. If the game seems to compile but closes immediately on run, it probably segfaulted (Linux users, the OS will tell you if this happened). In that case... Well, just tell me it did along with your architecture and operating system and I will try to come close to it. I will be testing on my other machines. I hope I can reproduce the problem, or that perhaps the problem was magically resolved by some minor change in the meantime.

Too tired to proofread or bother further right now. Think I'll just bed.

Tips, Tutorials, Examples / Re: Which should I use?
« on: June 15, 2010, 10:28:48 PM »
Sorry, but outside of the scope in which it is declared, postfix [] and prefix * are synonymous.

Code: (C) [Select]
#include <stdio.h>
int array[3] = { 1, 2, 3 };
void function(int arg[]) {
  puts((void*)arg == (void*)&arg ? "true" : "fail");
int main() {
  return function(array), 0;


Tips, Tutorials, Examples / Re: Which should I use?
« on: June 15, 2010, 03:36:35 PM »
Sure, but good luck passing the array to a function and keeping that true.

Tips, Tutorials, Examples / Re: Which should I use?
« on: June 15, 2010, 10:59:27 AM »
Eh, char* and char*& are two different things. Array != &Array... &Array will, should the array for some reason be given a register despite its use, dump the pointer into the memory and give you a reference to it. Assuming you meant Array == Array&, that isn't true, either. If you never state Array = something; in the code taking Array&, it will modify the array without requiring return. Taking Array as a parameter would simply copy the pointer, and only the local copy in the new scope would be changed.


Now, in the context of his code, GCC will probably be nice and make it such that (int Array) is the same as (int &Array). So fine.
...But they're still different. :troll:

Announcements / Re: Around the Clock
« on: June 15, 2010, 01:01:52 AM »
There are parsers for YAML taking thousands of lines and requiring several awkward symbols to be added to my file, which I think is beautiful as it is. The parser for it barely takes 200 lines. It's just not that complicated. YAML introduces what seems to be hundreds of features we don't use, requires symbols to make explicit what should be implied, and lacks (for sake of versatility on a scale not required here) a feature the current format uses. It would be easier for me (perhaps even at this point) to include some huge YAML nonsense, but I don't think I'll be doing so. If Ism, however, indicates in any way an intention to share this file with me, I will, via a simple regexp, make the file into YAML, and either revise my parser to use YAML's | and >, or perhaps even break habit and include some fucking huge thing and piss with its API to get the info I need. The question is whether I want the format to be YAML or to be YAML compliant, assuming I want it to be related to YAML at all (which I slightly do, since Ism reports that the format being YAML-ready would slightly improve her odds of working with it).

That's a bug, yes. Should work like GM. And yes, Shift wouldn't change anything; I get the keycode raw and convert it myself via large array. This array is -not- cross API, meaning it may work find on Winblows even though I screwed up on X. I'd prefer not to add checking for both at first glance due to the unfolding of code that would have to transpire (either unfolding an array by segment, keeping a second array, or just adding a special check), but I will look into doing so all the same. If I did, I would probably mandate that a correction be implemented just above the API level (as soon as I have a key code), so no additional checking is done each keyboard_check. Hoping this isn't the work of XLookupKeyCode, or whatever that function was.

Announcements / Re: Updates, Updates, Updates on the way.
« on: June 15, 2010, 12:44:09 AM »
Code: (C) [Select]
#include <stdio.h> //puts
int main(int,char**) {
  return puts("Hello, world!") , 0; /* this is just lazy */
} // tits

Code: (C) [Select]
#include <stdio.h>
#include <stdio.h>
#include <stdio.h>
#include <stdio.h>
#include <stdio.h>
#pragma arse
#include <stdio.h>
#include <stdio.h> //puts
int main(int,char**) {
  return puts("Hello, world!") , 0; /* this is just lazy */
} // tits

Code: (C++) [Select]
int a[b] please don't be bold [/b]; b = 'weee';

Announcements / Re: Around the Clock
« on: June 10, 2010, 01:08:13 PM »
I like the format how it is. It's humanly readable now without the %YAML, ---, -, \nGroup ID:, and ....
In fact, it's close enough to YAML that I'm comfortable calling it that anyway. Or at least YAML-like. I'll outline all six differences in the docs regarding the events file, if you like.  ::)

YAML highlighters are grotesque at best; I'd get better highlighting if I named the file *.sh. I don't see much benefit to trying to comply...