ENIGMA Development Environment

Website is in read-only mode due to a recent attack.

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.

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.

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

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.

XD
Yes, stereograms can cause horrible eye strain and headaches. Maybe it wouldn't be so bad if generated by a computer (such as 3DS).

Game_boy, what you describe would vastly alleviate this, but would require the DS be held at a certain distance from your face. It probably uses "tilt this VHS box to see the cover art plus scared faces or sans clothing" technology. The little triangular prisms covering alternating lines of pixels. I always hated those. Perhaps it will be better since you don't have to move the DS to see them. Turning the DS upside down would invert the 3D, though, and twisting it past a certain point would remove 3D completely (And possibly visibility). Glare on one side would also remove 3D.

Copy on write will be implemented as well. Basically, scripts can return arrays via this new magic. At no efficiency cost. However, there is a detriment on setting equivalent a var and a large array. Because of that, I believe I will be making as many globals as possible use scalar types. (Or variant if I have to).

Variant will now be a type at the user's disposal. Not boost::variant, just R3's enigma::variant.

Also, string() is handled more beautifully, such that string str; will still get you a string, but string(somevar) will work as well. This is possible via a simple macro, #define string(x) toString(x). (Luckily, string alone will not error nor attempt to unfold the macro function.)

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.

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