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.

Topics - Josh @ Dreamland

Pages: « 1 2 3 4 5 6 7 8 9 10 11 12 13 »
Announcements / Where do we stand?
« on: August 23, 2010, 01:35:44 am »
I decided to implement backgrounds in the meantime, and dazappa has kept me busy with a number of interesting bug reports (the worst of which I have just worked out). I am not sure what is in the update-stable/ tag, but fixing it to actually work out of the box on at least Windows and Linux is priority one.

Ism has made great progress on the updater. From what I can tell it is finished, though it has an odd tendency to leave a console window open with a gray background for me.

RetroX has finished some packages, but we were discussing what the package should be responsible for vs what LGM should be responsible for. I believe right now, he's configured them to give 777 permissions to /opt/enigma, where it is installed. But it seems he includes the entire repository with the package, which means users could be downloading an outdated package from square one. Correct, RetroX?

As for the Windows release, I don't even think an installer is necessary. I think a zip file containing ENIGMA.exe, lgm16b4.jar, and the plugins folder will suffice. ENIGMA.exe and LGM will take care of the rest.

If you object to not having an installer for Windows, speak now, and I or someone else will make one.
Retro, if you want to carry our discussion regarding the packages over here, please do so. Otherwise, I think ENIGMA.exe and the jar files will suffice, along with that dependency list you've already implemented.

I am going to finish dazappa's last few bug reports.

IsmAvatar, when you are content with the updater, please say so.
RetroX, when you are done with the packages, please link all of them here, and I will rehost.

The release (And frantic workarounds for everything that goes wrong soon after) will begin as soon as the three of us are done.

Announcements / ENIGMA R4
« on: August 09, 2010, 11:39:23 pm »
So I pulled overtime. I Haven't eaten anything today but a bagel. And a handful of spaghetti, which I grabbed out of a bowl as I walked by.
R4 is ready for release, but there's a problem. I was depending on a certain IsmAvatar for an update that would enable LateralGM to download and build ENIGMA. I spent the whole day getting everything perfect. But she's gone. So everybody post "WHY, ISM? WHYYYYY?".

Anyway, here's how the release today (8- 10 -10) works:

Double click ENIGMA.exe
Do what it says.

Most Linux users have been using R4 for a month or so. I'll see about putting a .deb and a... whatever that thing is that Retro uses. Hey, Retro, can you assemble those for me tomorrow?

Anyway, I'm really bummed about the release not being 8-9-10, especially that it wasn't even at 11:12 like I thought it would be when the amazing Super Ism showed up to save the day. But hey, life goes on, especially for ENIGMA.

Currently implemented:
  • Sprites
  • Sounds
  • Rooms
    • Views (haven't tested in a while) (view_object may not do anything)
    • Background color
  • objects
    • Code
      • Types
      • Keywords global and local
      • Template types (imported from C++)
    • DND
      • Framework laid (basic flow, but functions are not implemented
    • Heredity
      • Works by nature of the instance system, but code is not yet inherited properly
    • Events
      • Conditional events
      • Extensible system (event conditions and classifications loaded from a file)

And of course, the function lists have grown significantly. I will see about getting those up sooner or later. But I'm feeling very abandoned. I don't really blame anybody; it's just that today was apparently not a good day to say, hey, let's get a zipped distributable out!

So. What will happen tomorrow:
1) I'm implementing sound_loop, sound_pause, sound_isplaying, sound_ispaused, sound_resume
2) I'm making sure users have access to WhiteSpace (the name-pending C++ resource).
3) I'm making sure X.Y works, at least as well as it did in R3.
4) Ism is finishing work on her updater. Or else.
5) I will see if Retro will prepare a deb and archwhatever containing the essentials for LGM and ENIGMA on Linux.
6) The same is basically done for Windows as it stands (just waiting for Ism...)
7) See if a2h can fix some things on the site.

See you all then. Be there, or be *mutter mutter* (and if you happen to be IsmAvatar and are not there, I'll shoot you.)

Announcements / Shortcuts
« on: July 28, 2010, 10:34:26 pm »
Long, long ago, in a land far-- actually, it was in this chair. Or some chair that looked similar. Be it as it may, a while back, I took a shortcut and thought, "If this ever comes back to bite me, it'll be after the rest of the project is stable and I can fix it without fear." Well, that mostly came true. There are no detrimental effects at this time, simply because the amount of skill required for the malefaction to manifest simply isn't being exhibited by ENIGMA users at this time. For those who wish to be weary, this is the issue:

When I designed the C++ parser, I did not implement a proper overloading system. Overloads were, instead of instantiated as children of a main instance as I considered doing, applied to the current copy by way of modifying the bounds for acceptable parameter numbers. For instance,
Code: (C++) [Select]
string func(int a) { return "test"; }
double func(int a, int b) { return  "test2"; }

is stored only as a function returning double that takes either 1 or 2 parameters. Had the second function taken three parameters, the choices would be 1, 2, or 3, even though 3 was actually an invalid option. This makes for a blazingly inaccurate syntax check in rare situations (a GML user would never come close to noticing).

It also means a less pleasant inaccuracy on a more important system.
The following expressions were passed to a new type resolution system of mine:

room + room
room + 1
room - 1

The results were, respectively, as follows:
Let's see if I can't waste some space and make a nicer table.

room + room=>variant
room + 1=>variant
room - 1=>double

The more curious of you have a few questions. I'll do my best to answer those here:
room_speed and the like are being left integers. I see no point in wasting memory and speed so users can set some random array element in global scalars.
The type resolution system doesn't distinguish between cast and type at the moment (by choice, so I can debug without thinking of a global by that type. :P)
The type "roomv" is a special type with an overloaded operator= that calls room_goto(). It inherits from variant.
Because "roomv" is a special variant, room + room will return variant. This is correct. Room + anything will, in fact, so you can keep adding things such as strings.
However, room - 1 is double because subtraction only works on such. It wasn't worth it to avoid a warning on re-cast. Maybe I'll change my mind later, but in any case, the resolver was accurate.
Calls to [] on var are indeed variants.

So what's the problem? Look at item three, "*var". The parser can't distinguish between binary and unary *. Even though it knew it wanted the unary version, it couldn't get the accurate type, because I only store the type of the last declared overload, and so the parser was given `double`, the type returned by the multiplication operator.

When I need, I will store all overloads with argument counts and types, but that is a job for after the basics are all working. I want one more thing to work before I proceed, and it is indeed a trick; I would like for templated types to work, and if possible (by which I mean, it shall pass), templated casts. This way, if you have map<int,int> amap, you can say amap[whatever].x and have it behave correctly. That has been important to me since square one.

Another nice thing I can implement with the help of this system is the switch() optimization, as well as something brand new.

It befuddles me that neither C++ nor GML have a foreach construct. ENIGMA will be given one. It will work rather uniquely, since neither language was designed for it. Basically, it will have the following syntaxes:

foreach (array as element)
foreach (element in array)
foreach (element : array) //Java-esque

Trouble is getting it to work around this little issue: "in" and "as" are common variable names. So, I'm going to work around that thanks to how carefree my parser is when it operates.

Code: [Select]
foreach in in as

will work fine.

To ease the sadistic and curious, that will look like this in intermediate parse:

Which makes it very easy to parse out. The first item, in (), is either what I'll be iterating, or the element name. The second, of form "nn;", will determine which; it should be "in" or "as". The third set, denoted easily by regexp /;(^;);/, is the corresponding element of the foreach.

So, how will that work from there? Simple. I determine which is the container to iterate. I then check for the following:
  • Typedef by name "iterator"; iterator container::begin(); iterator container::end(); iterator::operator++() or iterator::operator++(void)
  • container::operator[](int); size_t container::size() or typeof(container::operator[](int))::operator bool()

Depending on which of those I find, the foreach will be replaced with code to iterate each. The real trick is managing to proxy the "as" component in as a method of retrieving the element itself, and not the iterator type. Mind all of you, I'm not afraid to implement a macro if I must. But I imagine I can find a creative way to cram more instructions into the mix using operator, .

Anyway, I'll be busy. Thanks for your patience. I know this is taking a while, but the level of detail Ism and I've put into this goes far beyond the previous releases' quicker development time.


Announcements / Worth Mentioning
« on: July 10, 2010, 08:58:21 am »
As a by-the-way sort of deal, I've reduced ENIGMA's compile time to roughly two seconds on this old computer. Compile, link, and run took 2.75 seconds. This means I pressed "run," and in 2.75 seconds (minus my reflex time on the stopwatch), the game window was there.

On my laptop, a newish (less than two years) dual core with decent specs by today's standards, the process takes 1.4 seconds. Again not accounting for my reflexes.

So all-in-all, I'm pretty happy about that.

I've gotten a few bug reports via the tracker and have fixed most of them that were for me. More will follow, but I've been busy these last few days; today should be my last busy day. I'll be moving air conditioners around; don't ask. The most immediate thing I'll be working on is my type resolver. The only reason it's not finished is the amount of crap I've had to deal with lately.

So. Enjoy the new compile time. I believe it can later be reduced further; we'll see.

It's also worth mentioning that I could use someones to verify that all the math functions work properly (they are included directly from the C library, mostly; ambiguity is quite possible with var's many legal casts). The bessel_* functions may or may not work; I'll figure that out eventually. Logically, they shouldn't; I renamed the symbols in the header without renaming them in whatever library they are implemented in. But who knows? Also, if someone is feeling really bored, they could make sure that all the operators work on var. They are largely code-generated, so slight error can be catastrophic. For instance, division once returned zero consistently. And freezway found an ambiguity in variant += var. There's a lot of boring testing to do with those.

Announcements / Progress
« on: July 08, 2010, 12:01:23 pm »
I'm so happy with a couple changes I've made and am making.

First off, I'm proud to announce that standard templates are now completely available to ENIGMA users.
Code: (C++) [Select]
map a; // is the same as...
map<> a; // is the same as...
map <variant> a; // is the same as...
map <variant,variant> a;

That's right: ENIGMA now correctly defaults all non-defaulted template parameters (as in, template parameters that are not already optional according to the C++ library) to variant. That means that once Ism and I are finished coordinating our new "Definitions" resource (previously "WhiteSpace"... we're still working on a catchy name) you will be able to #include <map>, use it, and use codes like this:

Code: (EDL) [Select]
map a;
a[100] = "one hundred";
a[15625682900000000.0] = "lol, big float";
a[3.141592653589793238] = "pie";
a["pi"] = 3.14;

That's right: with the implementation of var4, comparison operators are correctly implemented for all types and mirrored const. This makes them capable of complete interaction with the standard template library. GM's ds_* functions are officially toilet food in comparison.

Furthermore, map isn't exactly necessary for large numbers. Var4 also implements Lua's algorithm for fast, sparse arrays. This introduces a number of nice properties:

Code: (EDL) [Select]
var a = 0;
for (int i=0; i<100; i++) a[i] = i;
a[1000000000] = "one billion";

How can this be efficient? It's simple. a[0..127] operates in O(1), because that's how much space was allocated for the array. a[128] operates in either O(1) or O(n), depending on how your system resources are doing. a[256..INT_MAX] operates in O(log(N)), as it relies on a map for the lookup. (This will hopefully be replaced with a sparse hash map at some point).

Currently the system is functional, but not finished. Var4's lua_table<> needs to ensure that elements can hop data structure when the array part is resized. Templates need field tested, which will happen after my latest renovation: the dot operator.

Because C++ introduces structures and classes which I do not want to alienate, I have to take special care to ensure that the left-hand side of the dot is not an instance of a structure. This requires a type resolver, which I hope to complete inside 400 lines. We'll see. Basically, it will return the type of the expression that precedes the dot. I intend for the following to happen:

If it's an instance of a class, check for a member by name of the variable to the right hand side of the dot. If the member exists, ignore the dot. Possibly, if the class was actually a pointer, not a direct reference, replace the dot with ->. C++ should have done this from square one; I see no use for pointer.member. If no member was found, or if the type was scalar, replace the dot with an integer-based accessor function and record that the global was indeed accessed that way so optimizations can be done later. Also try to warn if it was a class without a member and without operator int() or some other scalar that can be cast easily. Perhaps it should be up to ENIGMA to find an appropriate cast path, such as int(var()).

Anyway, just something to think about.
Back to work, ciao for now.

Announcements / Happy Independence Day
« on: July 04, 2010, 06:54:20 pm »
Since a2h is Australian (and asleep anyway, I guess), Ism is actually a Russian spy, and none of the other administrators know what the hell day it is, happy fourth to all you Americans.

I'm going to go set something on fire and blow some other things up in good American spirit. ...The old spirit. Well. I mean.

Explanations later.


Announcements / COmputers SUck
« on: June 30, 2010, 04:37:53 pm »
It's been a long journey, ENIGMA has. I've picked up a lot of tricks on the road, trying to complete it. The events and workings that transpired while working on R4 were extensive, not that I think most will notice. I've finished my replacements now. Instance System 2, Var4, and Reflex2 are all implemented. With little left to correct. But there are still some problems that I have personally and that ENIGMA has in general. The list is large and foreboding.

1) On Windows Vista, video memory is cleared every time the user presses control-alt-delete. ENIGMA loses its drawing context in the fire, and GM6 loses its surfaces. Yes, GM6 doesn't run on Vista, but I can't speak for 7 and 8 because I can only imagine Mark has corrected that in the meantime. So yes, every time the user presses control-alt-delete, ENIGMA loses the ability to display things. I'm not yet sure how to correct this, but I imagine I can test if it's happened and just ask for a new one.

2) On Linux, input is awful. In fact, much of Linux is glued together where it should be loosely tied with strings. I can't tell you how many times I'll be reading something huge, and will, without thinking, use the middle mouse button to gesture vertical scroll, only to wait for ten minutes for Firefox to finish this conversation with X:
Oh, you want me to scroll up? One minute.
*Scrolls some three pixels*
Gee, thanks Firefox.
Hey, Firefox, the mouse moved. And that button's pressed.
Oh, so you want me to scroll up? One minute.
*Scrolls some three pixels*
Gee, thanks Firefox.
Hey, Firefox, the mouse moved. And that button's pressed.
Oh, so you want me to scroll up? One minute.
This continues until either
A) No more mouse move events in the queue. This takes approximately enough time for Earth's amoebas to evolve, gain sentience, become this universe's greatest minds, construct their own universe in parallel with our own, live there for some hundred thousand millennia, populate the entirety of it and then begin a siege on ours for more living space.
B) FireFox reaches the end of the page, which causes the conversation to look more like this:
Hey, Firefo--/Yeah, I know, I'm out of scroll space./Ah, okay./Hey, Firefo--/Yeah, I know, I'm out of scroll space./Ah, okay./Hey, Firefo--/Yeah, I know, I'm out of scroll space./Ah, okay./Hey, Firefo--/Yeah, I know, I'm out of scroll space./Ah, okay.
Causing for near instant completion.
During that time, though, while X is chatting with Firefox, it's too busy to, say, LET ME SWITCH FUCKING WINDOWS. So I've no access to anything to kill Firefox. Gnome-panel is dead, so I can't switch that way or use force quit, and alt-tab/control-alt-delete are non-responsive. Control-alt-f2 also does something very unsavory. I can't remember what.

So, you may be wondering, why the bitchfest on the ENIGMA forum? Well, because ENIGMA inherits all those fun problems. If an input problem surfaces, I never know if it's my fault for screwing up ENIGMA or if it's my cry-blood-inducing, woefully inadequate input drivers.

And speaking of drivers, here on home, sweet, my graphics drivers are also parsecs ahead of the latest and greatest human technology. </sarcasm> So basically, it takes ENIGMA (and old Game Maker games that still work with WINE) approximately 11.25 microseconds to draw a single pixel of sprite (A single 128*139 sprite draws at 5fps). No other computer I've tested on has this problem, and GM does it to, so I know it's not my fault directly. The question is, how is Firefox blitting out images at decent framerates? Hell, there's a huge wallpaper rendering on my desktop, and it's not going 0.2 fps. What does it take? I'm not sure. I'll probably need to look into hardware acceleration.

(For the record, draw_rectangle with fantastic gradients works at amazing speeds; it's only sprites that are slow.)

Either way, I imagine those problems will get worked out eventually. Like I said, the instance system, new var, and new reflex (speed, direction, hspeed, vspeed, room, etc) are done. Here's what's coming up to do:

1) Test heredity. This should already work in cases such as instance_nearest, just by nature of the design of my new instance system.
2) Implement depth. This actually isn't all that hard, but may be annoying. Essentially, a new reflexive type will be created for depth. On assign, it moves the instance around in a map of draw events to iterate. In the constructor of each object, depth = <compiler inserts default depth here>; is executed. Or perhaps a separate constructor to avoid checks.
3) Go back over the syntax check and format parse, adding the remaining features.
4) Implement backgrounds. It's about time that got done. Then implement tiles, and add them to the draw depth map by way of instantiating a custom object_basic that does nothing but draw tiles at a given depth.

After that, I'll be content to start adding DND functions. These will be implemented like any other function, by the GM tile name, i.e., action_set_speed(). ENIGMA is healthy enough now that I would recommend and appreciate help implementing those.

Announcements / I have defeated Valgrind
« on: June 22, 2010, 12:42:38 pm »
valgrind: the 'impossible' happened:
   Killed by fatal signal
==28927==    at 0x3809D201: myvprintf_str (m_debuglog.c:530)
==28927==    by 0x3809D9E2: vgPlain_debugLog_vprintf (m_debuglog.c:877)
==28927==    by 0x380298E5: vprintf_WRK (m_libcprint.c:111)
==28927==    by 0x380299A7: vgPlain_printf (m_libcprint.c:143)
==28927==    by 0x38027A96: vgPlain_assert_fail (m_libcassert.c:259)
==28927==    by 0x74206572: ???

sched status:

Thread 1: status = VgTs_Runnable
==28927==    at 0x4025016: realloc (vg_replace_malloc.c:525)
==28927==    by 0x80522C8: lua_table<int>::operator[](unsigned int) (lua_table.h:124)
==28927==    by 0x805197D: main (var4.cpp:375)

*beats chest like an ape*

*returns to looking for the problem manually*

All that happened was realloc() took a shit. I'll look into why next. But this is why you've not heard updates.

Edit (three minutes later): all fixed

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

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: (Events) [Select]
beginstep: 3
Group: Step
Name: Begin Step
Mode: Special
Case: 1

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

Announcements / Tentative Todo
« on: June 03, 2010, 12:14:07 pm »
This is what's going on and what will be going on before release.

Current Todo:
  • Implement instance system (Currently working on)
  • Implement new var (has already been coded)
  • Resolve, once and for all, string() vs string, using a special property of macros. (#define string(x) toString(x))
  • Make some changes to the parsers to accommodate some of these and more:
    • Implement macros in the syntax check
    • Implement C++ operators scope resolve :: and template parameter pass <...>
    • Implement GML operators not equal <> , access . , and dynamic array subscript [...] .
    • Run a check on subscript passes to global variables
    • Finish implementing special treatment for variables declared as const.

What's just been done recently includes a fix on global declarations as well as testing of all drawing functions. Only draw_ellipse doesn't work, and I will fix that "soon."

Proposals / LGM Bug
« on: June 02, 2010, 01:38:11 am »
Too lazy to log in to Ism's forum on Vista laptop.

File corruption error with totally-LGM-made GM6:

Unhandled Exception:
org.lateralgm.file.GmFormatException - java.lang.NullPointerException: null

Stack trace:
javax.swing.AbstractButton.fireActionPerformed(Unknown Source)
javax.swing.AbstractButton$Handler.actionPerformed(Unknown Source)
javax.swing.DefaultButtonModel.fireActionPerformed(Unknown Source)
javax.swing.DefaultButtonModel.setPressed(Unknown Source)
javax.swing.AbstractButton.doClick(Unknown Source)
javax.swing.plaf.basic.BasicMenuItemUI.doClick(Unknown Source)
javax.swing.plaf.basic.BasicMenuItemUI$Handler.mouseReleased(Unknown Source)
java.awt.Component.processMouseEvent(Unknown Source)
javax.swing.JComponent.processMouseEvent(Unknown Source)
java.awt.Component.processEvent(Unknown Source)
java.awt.Container.processEvent(Unknown Source)
java.awt.Component.dispatchEventImpl(Unknown Source)
java.awt.Container.dispatchEventImpl(Unknown Source)
java.awt.Component.dispatchEvent(Unknown Source)
java.awt.LightweightDispatcher.retargetMouseEvent(Unknown Source)
java.awt.LightweightDispatcher.processMouseEvent(Unknown Source)
java.awt.LightweightDispatcher.dispatchEvent(Unknown Source)
java.awt.Container.dispatchEventImpl(Unknown Source)
java.awt.Window.dispatchEventImpl(Unknown Source)
java.awt.Component.dispatchEvent(Unknown Source)
java.awt.EventQueue.dispatchEvent(Unknown Source)
java.awt.EventDispatchThread.pumpOneEventForFilters(Unknown Source)
java.awt.EventDispatchThread.pumpEventsForFilter(Unknown Source)
java.awt.EventDispatchThread.pumpEventsForHierarchy(Unknown Source)
java.awt.EventDispatchThread.pumpEvents(Unknown Source)
java.awt.EventDispatchThread.pumpEvents(Unknown Source) Source)

This was made with an older version of LGM; it may be a bug with the old one that is now corrected. Of course, I'm still seeing "Unhandled exception..." But I don't speak Javanese.

Announcements / Graduation
« on: May 30, 2010, 11:05:55 am »
Of me, not yet ENIGMA. I know many others are graduating about now; congratulations to all of you.

I figure I should repost the method of obtaining and compiling ENIGMA. Again, post bugs and concerns here. At least five individuals have successfully checked out and compiled; don't think that this isn't going to work if it fails a few times, just ask for help.

Instructions for obtaining and compiling the ENIGMA R4 public testing copy

IRC Channel
ENIGMA has an IRC channel set up on Freenode. Predictably, it is called #enigma-dev. This link may take you there.

Procedure in general is as follows: (Subject to revision; pay attention)
Note: This is only for people who wish to test but do not wish to wait for "stable test," meaning "at least moderately workable pile of fail."

No recent revisions


If you are on Windows, do the following:
- Install an SVN client (either the command line version, or a visual one like RapidSVN or Tortoise)
- Install Code::Blocks ( ) unless you know how to use Make and will put up with outdated makefiles.
- After checking out the SVN (see "Getting ENIGMA"), If this file does not exist, copy it to ENIGMAsystem/additional/zlib/:

If you are on Linux, you will need the following packages:
- g++
- libgl1-mesa-dev (or similar)
- zlib1g-dev (SHOULD be installed already, but Ism's wasn't)
- codeblocks
- svn / rapidsvn / tortoise
- Java (I -strongly- recommend sun-java6-jre)

Getting ENIGMA to Work

Getting ENIGMA

- Check out the SVN repository via the most applicable of the following:
--- From command line, you will use  svn co enigma-dev )
--- From RapidSVN, go to the Repository menu, and select Checkout. Provide the URL, and specify where you want it downloaded.
- The above will begin downloading ENIGMA. Let it finish.
- Go to ./trunk/
- Go to ./CompilerSource/
- Build it with your choice of these two:
--- From Code::Blocks
------- Open the Code::Blocks project. Find the drop down box that likely reads "Release." If you're on Linux, set it to "Release-Linux."
------- Hit compile (blue gear)
--- With Make
------- Your make is either called `make` or `mingw32-make`; call it with your OS name as the target. For example, `make windows` or `make linux`.
------- Make shouldn't error, but is more likely to than C::B; if it does, post here.
- Done, go back up to Trunk

Running ENIGMA Itself (LGM)

- Run LateralGM, best done with a terminal via "java -jar lateralgm16b4.jar" -- This terminal should have +++++++++++++ at the bottom.
--- If it does not, or if that errors, paste output here. If you compiled with Make, that's probably why.
------ If the terminal errors that java is not a valid application, then you are on Windows.
------ Find "java.exe" and add its directory to your PATH variable from the control panel.
- Make something simple (like a single object drawing a graded circle; that's what I've been using as a preliminary test)
- Under the "Enigma" menu, hit "Run"
- Check the terminal window (the one I hope you used to run LGM) for syntax errors.
--- If there is one that you don't think is correct, post it here. (I'm currently developing the syntax checker).
- Your code has now been secretly translated to C++ behind your back.
- If all went successfully, your game should launch.

Testing the Game You Just "Ran"

ENIGMA should run your game for you. If it does not, and you see no errors in the terminal window, you can do the following:

-Open trunk/ENIGMAsystem/SHELL/ENIGMAengine.cbp in Code::Blocks
-Select your OS from the dropdown box once more (Debug is faster to build, release will run fastest)
-Press Compile
---If anything errors and you think you followed the above correctly, right click the error list, select "Copy Contents to Clipboard," and paste them all here.
-Press run.
---If it doesn't behave as expected, describe what went wrong here.

What now?

Repeat the step starting at "Make something simple" until you're sick of finding bugs.
The most immediate concern is that everyone can achieve a simple circle.

Common Errors

error: ‘instdata’ was not declared in this scope
--This means you did not actually create a game from LGM (By clicking "Run") before trying to compile it, the compile failed due to syntax errors, or you restarted LGM in the meantime. It isn't really an error.

- SvnKit missing, corrupted, or unusable. Please download and place next to the enigma plugin in order to enable auto-update.
---This is not an error. It is a warning thrown by Enigma.jar, warning you that it's not able to update itself if you don't have SvnKit. Of course, Enigma doesn't need to update itself.

- Unable to load plugin: SvnKit.jar: null: Missing plugin entry point (LGM-Plugin)
- Unable to load plugin: jna.jar: null: Missing plugin entry point (LGM-Plugin)
---These are not errors. They are warnings thrown by LGM indicating that it can't load those files as LGM Plugins -- because they *aren't* LGM Plugins! Basically these are just reminders to the devs that we shouldn't just throw every darned file we need access to in the Plugins folder >_<

Announcements / Documentation
« on: May 25, 2010, 09:23:55 pm »
ENIGMA's spent most of its life without a decent documentation. Now it gets a colorful one.

Gary (MahFreenAmeh) and I have been working over the last couple days (between his work and my stats project, now complete) on a parser to convert plain-text documentation into a rather lovely visual display. The display is meant for newer browsers with real features. This basically excludes IE automatically.

Anyway, the first of the documentation (thrown together only for purposes of testing the parser, so it's kind of ugly yet anyway) can be viewed here:

For now, the docs use PNG. All PNGs, including the ENIGMA Logo, are merely renders of SVGs, which the docs will use ASAP. I want an all-text documentation, basically. Docs themselves being plain text, images being SVG which, as I'm sure most of you know, is just XML.

Anyway, do view the test page and post your thoughts. Feel free to recommend ways to beautify or simplify.
Do not complain that the layout uses tables, or I will track you down and murder you in a highly creative manner.

I guess I will start typing up more docs as soon as Gary has a method of adding to them arranged.

Should be interesting.

Peace. Unless you have a vendetta against tables.

Pages: « 1 2 3 4 5 6 7 8 9 10 11 12 13 »