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

Proposals / Re: LGM Bug
« on: June 27, 2010, 09:40:30 pm »
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.

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

Proposals / Re: LGM Bug
« on: June 26, 2010, 10:21:22 am » Unexpected end of file reached at filepos: 0
        at org.lateralgm.file.StreamDecoder.read4(
        at org.enigma.EnigmaReader.readChanges(
        at org.enigma.EnigmaRunner.compile(
        at org.enigma.EnigmaRunner.actionPerformed(
        at javax.swing.AbstractButton.fireActionPerformed(
        at javax.swing.AbstractButton$Handler.actionPerformed(
        at javax.swing.DefaultButtonModel.fireActionPerformed(
        at javax.swing.DefaultButtonModel.setPressed(
        at javax.swing.AbstractButton.doClick(
        at javax.swing.plaf.basic.BasicMenuItemUI.doClick(
        at javax.swing.plaf.basic.BasicMenuItemUI$Handler.menuDragMouseReleased(
        at javax.swing.JMenuItem.fireMenuDragMouseReleased(
        at javax.swing.JMenuItem.processMenuDragMouseEvent(
        at javax.swing.JMenuItem.processMouseEvent(
        at javax.swing.MenuSelectionManager.processMouseEvent(
        at javax.swing.plaf.basic.BasicPopupMenuUI$MouseGrabber.eventDispatched(
        at java.awt.Toolkit$SelectiveAWTEventListener.eventDispatched(
        at java.awt.Toolkit$ToolkitEventMulticaster.eventDispatched(
        at java.awt.Toolkit.notifyAWTEventListeners(
        at java.awt.Component.dispatchEventImpl(
        at java.awt.Container.dispatchEventImpl(
        at java.awt.Component.dispatchEvent(
        at java.awt.LightweightDispatcher.retargetMouseEvent(
        at java.awt.LightweightDispatcher.processMouseEvent(
        at java.awt.LightweightDispatcher.dispatchEvent(
        at java.awt.Container.dispatchEventImpl(
        at java.awt.Window.dispatchEventImpl(
        at java.awt.Component.dispatchEvent(
        at java.awt.EventQueue.dispatchEvent(
        at java.awt.EventDispatchThread.pumpOneEventForFilters(
        at java.awt.EventDispatchThread.pumpEventsForFilter(
        at java.awt.EventDispatchThread.pumpEventsForHierarchy(
        at java.awt.EventDispatchThread.pumpEvents(
        at java.awt.EventDispatchThread.pumpEvents(

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

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.

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

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.

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.

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

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.

Cloned the Wii? Nah, they cloned the Eye Toy. Which was "kind of cool," but never really did Sony any good. Of course, no one is as good as Microsoft at tooting their own horn, so maybe they'll manage some good sales.

I've not heard of the 3DS and don't want to go looking; what exactly is it? (Other than a model format I'm going to hate implementing)

And yes, the Wii is the only console that would really make sense to put Portal 2 on. The controls would be perfect. Damn you, valve. Probably too much effort to get working.

Announcements / Re: Var 4
« on: June 20, 2010, 12:52:48 am »
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.)

Announcements / Re: Battling
« on: June 19, 2010, 08:01:37 pm »
That may be a good idea. But we've not devised such a format. I'll wait until your versioning branch is the trunk.

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