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

1861
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:
Quote
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:
Quote
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 127.0.0.1, 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.

1862
Off-Topic / Re: Google V8
« on: June 29, 2010, 04:23:21 pm »
Nay, one's almost entirely code-generated. I have to maintain an extra wrapper function for V8 to use as an accessor.

Luis: Static is for the entire function. No point in burdening the linker.

1863
Off-Topic / Re: Google V8
« on: June 29, 2010, 02:17:54 pm »
I don't simply propose things without thinking them through. I considered everything mentioned here and then some months ago, bouncing ideas off of Luda. It's been necessary since square one that a hash table be kept for each instance if all aspects of GML were to be supported. I statically compile everything I can, yes. R3 in fact did nothing with hash tables; R4 doesn't yet, either. But consider this code:
Code: (GML) [Select]
random(10).flarg = 90;What happens if flarg doesn't exist in the randomly chosen instance? This worked in R3; in R3, a dummy object by the same type was returned. In GM, however, the variable is added to the huge hash map Mark keeps. To simulate GM, a hash table would be used by flarg's accessor. (In R3, the accessor was this bulky thing that copied everything, because the instance system practically relied on it). Note, of course, that accessors can have nasty implications, and so are only used for instance.varname lookups. The other alternative is to scope all variables accessed that way into the parent object, but that wastes some memory in instances not using the variable, too.

The trick is that compiled code knows what variables it's accessing. Only the code-generated accessors would ever work with the hash table. V8 Would call those same accessors (which would be generated indiscriminately for the occasion); not interface with the hash table directly, which would indeed turn the entire operation into a huge mess.

What does turn the operation into a huge mess is having ENIGMA generate a wrapper to the entire C library for the interpreter. I'm surprised that wasn't your first point of attack, it's clearly the most intricate. I'll indicate, though; it is well within my capability using some neat var hacks. V8 requires all called functions take its own interesting argument array type. The array can be iterated for pass to C functions. Casting is the trick; ENIGMA doesn't keep track of argument types. So the solution is indeed an interesting one: Give ENIGMA's own variant a constructor for V8's varargs type. This would be done, via code generation, for all available functions. This is the C++ pseudo code:

Code: (C++) [Select]
ofstream wto("interpreter.cpp");
for (fit fname = functions.begin(); it != functions.end(); it++) {
  wto << "static Handle<Value> V8_WRAP_" << fname->first << "(const Arguments& argument) {" << endl;
  wto << "  return (variant)" << fname->first << "(";
  for (int anum = 0; anum < it->second->argcount; it++)
    wto << "variant(argument[" << it << "]),";
  wto << ");" << endl << "}" << endl;
}

Because variant is programmed with macros, magic, and awesome, all that would be required is a cast for each argument to variant and then a cast from the result to variant. Variant::variant(v8::Argument) would handle conversion to a sane value. The magic with which variant is laced will handle conversion to the correct type for each parameter. Variant's magic constructors would then get a workable type out of the return value of the C function. Then variant::operator Handle<Value>() would take care of the cast back to something V8 can use.

1864
Off-Topic / Re: Google V8
« on: June 29, 2010, 01:20:07 pm »
...No? With() already offered such a headache, and the new instance system blows that headache right out of the water. The accessors would just be conscious of the with() scope (which, at its lowest element, is the event scope).

1865
Off-Topic / Re: Google V8
« on: June 29, 2010, 11:19:32 am »
That's exactly what I said I'd do. And nope, not that lucky.

1866
Off-Topic / Re: Google V8
« on: June 28, 2010, 11:36:15 pm »
What retep said. But I was met with great opposition, as usual. In fact, the thread is still under the Suggestions and Proposals subforum.

You are wrong in one aspect, though; compiling it for Windows is a miserable fucking bitch and a half. I've never pulled it off.

1867
Proposals / Re: LGM Bug
« on: June 28, 2010, 11:31:52 pm »
That's good.

I'm just now realizing I didn't ask; Ism: what's that filename for? I have no insight to provide you in debug mode, only build mode... And I would expect an error, yes, but not an exception...

1868
Proposals / Re: LGM Bug
« on: June 27, 2010, 09:40:30 pm »
Retro:
That's an ENIGMA problem, it seems.
Something's screwy about that. No one else has reported such a problem. I'll inspect on my other platforms, but I'll probably need your collaboration to figure out what's causing that.

1869
Tips, Tutorials, Examples / Re: Which should I use?
« on: June 27, 2010, 09:27:58 pm »
Doesn't seem to have?

1870
Proposals / Re: LGM Bug
« on: June 26, 2010, 10:21:22 am »
java.io.IOException: Unexpected end of file reached at filepos: 0
        at org.lateralgm.file.GmStreamDecoder.read(GmStreamDecoder.java:97)
        at org.lateralgm.file.StreamDecoder.read4(StreamDecoder.java:99)
        at org.enigma.EnigmaReader.readChanges(EnigmaReader.java:42)
        at org.enigma.EnigmaRunner.compile(EnigmaRunner.java:397)
        at org.enigma.EnigmaRunner.actionPerformed(EnigmaRunner.java:427)
        at javax.swing.AbstractButton.fireActionPerformed(AbstractButton.java:1995)
        at javax.swing.AbstractButton$Handler.actionPerformed(AbstractButton.java:2318)
        at javax.swing.DefaultButtonModel.fireActionPerformed(DefaultButtonModel.java:387)
        at javax.swing.DefaultButtonModel.setPressed(DefaultButtonModel.java:242)
        at javax.swing.AbstractButton.doClick(AbstractButton.java:357)
        at javax.swing.plaf.basic.BasicMenuItemUI.doClick(BasicMenuItemUI.java:1223)
        at javax.swing.plaf.basic.BasicMenuItemUI$Handler.menuDragMouseReleased(BasicMenuItemUI.java:1327)
        at javax.swing.JMenuItem.fireMenuDragMouseReleased(JMenuItem.java:568)
        at javax.swing.JMenuItem.processMenuDragMouseEvent(JMenuItem.java:465)
        at javax.swing.JMenuItem.processMouseEvent(JMenuItem.java:411)
        at javax.swing.MenuSelectionManager.processMouseEvent(MenuSelectionManager.java:305)
        at javax.swing.plaf.basic.BasicPopupMenuUI$MouseGrabber.eventDispatched(BasicPopupMenuUI.java:807)
        at java.awt.Toolkit$SelectiveAWTEventListener.eventDispatched(Toolkit.java:2353)
        at java.awt.Toolkit$ToolkitEventMulticaster.eventDispatched(Toolkit.java:2245)
        at java.awt.Toolkit.notifyAWTEventListeners(Toolkit.java:2203)
        at java.awt.Component.dispatchEventImpl(Component.java:4528)
        at java.awt.Container.dispatchEventImpl(Container.java:2099)
        at java.awt.Component.dispatchEvent(Component.java:4460)
        at java.awt.LightweightDispatcher.retargetMouseEvent(Container.java:4574)
        at java.awt.LightweightDispatcher.processMouseEvent(Container.java:4238)
        at java.awt.LightweightDispatcher.dispatchEvent(Container.java:4168)
        at java.awt.Container.dispatchEventImpl(Container.java:2085)
        at java.awt.Window.dispatchEventImpl(Window.java:2478)
        at java.awt.Component.dispatchEvent(Component.java:4460)
        at java.awt.EventQueue.dispatchEvent(EventQueue.java:599)
        at java.awt.EventDispatchThread.pumpOneEventForFilters(EventDispatchThread.java:269)
        at java.awt.EventDispatchThread.pumpEventsForFilter(EventDispatchThread.java:184)
        at java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:174)
        at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:169)
        at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:161)
        at java.awt.EventDispatchThread.run(EventDispatchThread.java:122)


This one didn't smell right to me. Happened when I clicked "Debug" instead of "Run". Will investigate further.

1871
Announcements / Re: I have defeated Valgrind
« on: June 22, 2010, 04:55:13 pm »
Var4 now works flawlessly. I have forsaken copy on write in favor of demanding return-value optimization of the compiler. This means that sequential copy() destroy()s are optimized out at compile time. Because of this lovely feature, array returning will operate in O(1) despite COW not being implemented; meaning no additional overhead from the mix.

lua_table<> is now an operable container class you can include in ENIGMA.

Thanks to Valgrind, Var4 also doesn't leak a single byte.

Something about tacos.

1872
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:
  running_tid=1

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

1873
Odd; this is the second time Rusky has concurred with me on something but you have taken his to be the accurate. And mine was the one with the complete description this time. :ohdear:

But yeah, Rusky and I agree that it's probably a high-res version of what you see on the front of some old VHS boxes. Where you tilt the tape and the image changes, because every other "pixel" is refracted a different direction. You still couldn't twist it, say, 90 degrees and still enjoy the 3D. And a glare on either side would still kill the 3D as well. I'm not sure how they implemented a slider...

Eye strain referred to Ism's stereogram idea. VHS boxes only cause annoyance, not strain. And yeah, tilting wouldn't hurt; only rotating along the normal of your vision would.

As for the meteor, I think Dylan got hit by it when he was still on the project.

1874
Well, I was thinking that it wasn't supposed to be tilted because this time, one eye is to be on either side. So they would intentionally be seeing different images. Instead of doing it accidentally and looking awful.

1875
Announcements / Re: Var 4
« on: June 21, 2010, 12:00:07 pm »
Heh.
Also, copy-on-write will introduce a branch of overhead. I'm hoping it's negligible.