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

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

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

MrJackSparrow2:
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.

1878
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.

1879
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.

1880
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...

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

1881
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: http://www.ismavatar.com/Catch_the_Clown.gmk.

Windows users can get MinGW here: http://sourceforge.net/downloads/mingw/Automated%20MinGW%20Installer/MinGW%205.1.6/MinGW-5.1.6.exe/
RapidSVN here: http://www.rapidsvn.org/download/release/0.12/RapidSVN-0.12.0-8051.exe
From RapidSVN, go to Repository->Check out. URL is https://enigma-dev.svn.sourceforge.net/svnroot/enigma-dev/trunk. 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:
g++
libgl1-mesa-dev (or similar)
zlib1g-dev (tab complete is your friend)
subversion
sun-java6-jre (Or Java in general, but I -strongly- recommend this one)
Then run this:
svn co https://enigma-dev.svn.sourceforge.net/svnroot/enigma-dev/trunk 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 http://www.ismavatar.com/Catch_the_Clown.gmk 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.

1882
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;
}

Quote
fail

1883
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.

1884
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.

:troll:

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:

1885
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).

Ism:
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.

1886
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';

1887
Announcements / Re: Around the Clock
« on: June 10, 2010, 01:08:13 PM »
-Sigh-
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...

1888
Announcements / Re: Around the Clock
« on: June 10, 2010, 01:55:53 AM »
Indeed. Kinda laughed.

Anyway. This new instance system is beautiful. What was 55 lines is now 17. This unified iterator thing didn't look half as powerful on paper. Damn, what an idea.

1889
Announcements / Re: Around the Clock
« on: June 09, 2010, 10:03:31 PM »
:troll:

u toll

1890
Announcements / Around the Clock
« on: June 09, 2010, 09:00:53 PM »
Hardly. I've worked on Thank You cards to six million people. My cousin's graduation party is Sunday, which I will apparently be attending. Today I took a trip north with my dad, solely to visit my grandparents. Made the mistake of committing my code so I could work on ENIGMA there from my laptop. Didn't have much time to do so, ultimately. What's more, I came back to a certain someone informing me that the code I committed mid-sentence doesn't compile. <___<"

No, the instance system is not done. But I do have a surprise for you all.

I've seen questions going around of how GM handles events. Specifically, questions regarding the order in which they are executed. I myself used to wonder what exactly went on to implement hspeed and vspeed that ruined my first slope-using platformer. Well, that won't be a problem in ENIGMA.

I have implemented a file for R4 that contains a list of all events, the code executed in them, and some other details and trivia. I know a few are thinking right now, "great, another document for Josh to not maintain." Well, HAH. This one will always be current. Why? Because it's the file ENIGMA actually uses to determine what events were passed.

This is a beautiful thing for a number of reasons, one of the most important being that anyone can correct an event or add an event that a new version of GM implements. This is a snippet of the file, for demonstration purposes:

Code: ( (Unknown Language)) [Select]
beginstep: 3 Group: Step Name: Begin Step Mode: Special Case: 1alarm: 2 Group: Alarm Name: Alarm %1 Mode: Stacked Sub Check: { if ((alarm[%1] == -1) or (alarm[%1]--)) return 0; }# Keyboard events. These are simple enough.keyboard: 5 Group: Keyboard Name: Keyboard <%1> Type: Key Mode: Stacked Super Check: keyboard_check(%1)#...step: 3 Name: Step Mode: Special Case: 0 Constant: { x += hspeed, y += vspeed; speed -= friction; vspeed += sin(gravity_direction * pi/180), hspeed += cos(gravity_direction * pi/180); }#...collision: 4 Group: Collision Name: %1 Type: Object Mode: Stacked Super Check: instance_number(%1) Sub Check: place_meeting(x,y,%1)
That code will serve to bring an end to the hard-coded, undocumented GM method of event management.

Anyway, I'm back to work.