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

Announcements / Re: Christmas Plans
« on: December 31, 2012, 02:21:57 AM »
Didn't happen. Ended up cleaning up some mess in JDI instead, correcting some bugs I was unaware of. Also did some much-needed testing; any test codes welcome so I have something to check before we're ready to unleash this on the masses. Hopefully TGMG will be around to automate that for us again.

In the meantime, the parser reads and gives a dump of test_gml.h in the JDI branch if you build the CBP in either of the standalone modes. It should build without warnings, except in the placeholder file that declares empty versions of the old parse functions to prevent link errors, because the new parser is still not integrated.

In fact, I'm still working out how many passes I should handle up front and how many I should leave to the language plugin. I want to minimize both numbers, but especially the latter, so as to facilitate easy extension of the compiler.

Announcements / Re: Christmas Plans
« on: December 30, 2012, 01:21:56 AM »
Very well. At least it's somewhat original. Just likely to get recycled a lot.

In other news, I went ahead and pushed my current working copy of the parser. A lot of integration needs done, but the parser is basically complete. I spent the last day or so shelling out all the old compiler warnings and doing some major reorganization.

This may be done by tomorrow night.

Announcements / Re: Christmas Plans
« on: December 29, 2012, 10:45:51 PM »
*shrug* I didn't spend very much time on them.
Filters->ABC->Noise Transparency
Place gears, add simple gradients, subtract circles from gears. Done.

Announcements / Re: Christmas Plans
« on: December 29, 2012, 06:06:12 PM »
Threw you together an avatar, HaRRi. It's all generic and shit.

Take your pick.

Forthevin gets one next. If you have any requests, state them; otherwise your avatar, too, will be made using the first InkScape filters I see.

Issues Help Desk / Re: Damn Android
« on: December 29, 2012, 09:27:19 AM »
Our Android port hasn't been maintained in a while. You should have a file in Compilers/Windows/ called Android.ey.

It's also possible that compiling to Android never worked from Windows; I believe it was designed for Mac but worked on Linux by extension.

If you have built Android applications before, you could write your own Android.ey file by copying the gcc.ey and modifying it to use the Android toolchain. Otherwise, I advise you wait for TGMG to do something about it again; he wrote the entirety of the existing port.

Proposals / Re: Image Speed
« on: December 29, 2012, 01:26:56 AM »

Maybe even just putting all that off in a panel similar to the "Origin" group, only instead reading "Preview", would make the difference.

Or even, in addition to that, adding a box under Origin called "Animation" which offers a default image_speed option. The only thing standing between us and that implementation is the fact that image_speed is independent of room_speed. I think that could be explained in a [?] box or generic tooltip.

Announcements / Re: Christmas Plans
« on: December 28, 2012, 09:52:06 PM »
Simple as placing "using namespace <name here>;" in the global scope. Just like you would any other namespace. I'll set ENIGMA up to read from :: or ::edlwhatever based on a macro. After everything's migrated, or we think everything's migrated, you'll just flip that flag and try compiling.

Proposals / Image Speed
« on: December 27, 2012, 02:17:12 PM »
The LGM sprite editor, like the GM equivalent, has an entry for image speed which is used for previewing. It's a little confusing to newcomers who would expect that the speed is used in-game, even though it's just a demonstration. It'd be the simplest thing to add that value to the EGM format, and support it in the exporter. The alternative, of course, is to just clarify in the GUI that the speed is for previewing purposes, and add a tooltip explaining how to set it in the object.

When you think about it, though, how often do you really want two objects with the same sprite playing at a different speed? In that case, you need to use image_speed anyway, so why bother forcing it to start as 1?

Announcements / Re: Christmas Plans
« on: December 27, 2012, 12:04:32 PM »
Also, who among you is interested in the idea of encapsulating EDL types and functions in their own namespace? It would make it easier to deal with noise from library implementations, but it would require putting lots of shit into that namespace and using lots of shit from STDC.

In other words, we'd no longer have problems with time or list being illegal variable names unless the user specifically said, using std::list; or using namespace std;, which I intend to unify between all viable backends (meaning, in JavaScript as well).

The new parser is much, much more adept at making these distinctions, so I can probably get it to allow using types and shit as variable names (especially in compatibility mode), but this would be a fix-all.

Announcements / Re: Christmas Plans
« on: December 25, 2012, 12:27:20 PM »
For future reference, by default, the first sentence is used as the brief.

Announcements / Re: Christmas Plans
« on: December 25, 2012, 01:06:11 AM »
Yes, you'll find JDI is riddled with those comments. They won't help you understand how a system works as a whole, only how individual functions work. If you want to document the system, you have to write up a huge, separate comment using the @page directive, then link to it from a main page (or leave it up to the user to find it in the ToC). Kind of annoying, and not something that is likely to happen considering it's just as easy to create pages on the wiki for that purpose.

I use the same style for my comments, though I don't normally put the * on every line, and I don't always explicitly say @brief.

Announcements / Re: Christmas Plans
« on: December 24, 2012, 01:31:27 PM »
The system described above will fix (1). Or at least it should; I'm not sure what problem you're talking about.
IsmAvatar will have to be persuaded into doing (2), unless I finally tackle making LGM compile. Not signing up for that.

I have been using Doxygen for the new parser/systems as the plan became solid enough to permit. If you want to start documenting things with Doxygen, go ahead. There's not much benefit to doing so, though, when the systems that most need documented will need large, independent Doxygen comments anyway.

Announcements / Re: My Plans
« on: December 24, 2012, 08:52:28 AM »
Also, IsmAvatar, if you're feeling left out, I have plans for you, too. I was thinking that I could forward you a frontend to the EDL tokenizer so you could get a linear lex of the code for use in the editor. Combined with the parser, it would let you format the code manually, and could also be used for syntax highlighting if you wanted dead (preprocessed-out) code to remain unhighlighted and brace/whatever matching to work accordingly. It would also let you identify which loop break and continue statements belong to, like Eclipse does. It would also let you discriminate between shit used as identifiers, shit used as declarators, and shit used as functions.

Really up to you, though; I'm not gonna put forward the effort if you have no interest in the idea.

Tell me especially if you are interested in it for bracket/parenthesis matching so I can add that in now.

Announcements / Christmas Plans
« on: December 24, 2012, 08:27:54 AM »
First off, Merry Christmas to all of you. Hope you are enjoying some time off for the holidays.

The parser is behaving to expectation, which is great, considering I told you all that it would do everything short of walk on water. However, there are still two problems I see in ENIGMA that I fear will go uncorrected until they bite someone in the ass; I am going to address both of them and one personal problem here.

If you are a developer, try to pay a little attention. At least to the first two.

Problem 1: The extension system is subtly broken.
I don't know if anyone noticed this (I think HaRRi has stumbled upon it?), but the extension system is not as modular as it was designed to be due to issues with uninformed sideways casting. The compiler handles all the casting; the linker is not involved. Thus, extensions think they are the only class that enigma::object_locals inherits virtually. Issue is, they are not. Thus, since alarms are first alphabetically, they're the only extension which will work.

Contrary to popular belief, extensions were designed to facilitate adding "heavy" functions as opposed to "groups of two or more" functions. By "heavy," I mean functions that have weighty dependency that might drive someone who is interested in disk and memory efficiency to drop us a complaint about it. Maybe someone doesn't need a 16 integer array in each object (talking of alarms). Maybe it really bothers someone that their objects all need a path_index variable, as well as position and time variables for their path. The point is, extensions make it so they can remove the entire system from their game, including the local variables that weigh down their objects.

To clarify, the issue is simply that when they need alarms and paths, both extensions assume that their bytes are the first in the structure, and one of them must logically be wrong. The fix is simply to do the casting from within the engine file (which is informed as to what each extension looks like and which extensions are being included). The detriment? We have data misread and life is hard.

Presently, you access the current instance (ENIGMA's equivalent of this) using a global. There are actually a few problems with doing this:
  • Casting that global to a virtual ancestor doesn't always work (as discussed above)
  • Only one object can be this per running game per femtosecond
  • All code has to be aware of any access boundaries associated with having only one object being this at a time
By the last one, I mean loops such as with() need to be extremely cautious about the length of time for which they change the current instance pointer. So far, this has only really entailed being careful to set it back at the end of the loop. It also, again, destroys any hope for threading anything to do with instances.

The solution: I am turning the instance addressing system on its ear.
The solution is actually pretty simple. We dump the globals that represent the current instances/iterators (namely, ENIGMA_global_instance and instance_event_iterator) and we replace them with a parameter given to ENIGMA functions which modify the current instance.

So basically, instead of this function:
Code: (C++) [Select]
void motion_set(int dir, double newspeed)
    enigma::object_graphics* const inst = ((enigma::object_graphics*)enigma::instance_event_iterator->inst);

We have this function:
Code: (C++) [Select]
void motion_set(enigma::object_graphics* enigma_this, int dir, double newspeed)

So, not a huge difference, but enough that it will mean some chaos.

If you are worried about the parameter, don't be. That's where the new parser comes in. I have not added this yet, as the pretty printer is not written. I want everyone on board with this idea before I ship it.

This idea has been up on the proposals board for some time; we're just finally to a point where I think I'll have the free time to deal with it. I will put everything up in the ENIGMA-JDI branch before I begin the migration. I'll make a new newspost to let you know the time has come to tackle it and do regression testing, when I'm ready for the change myself.

Again, the benefits are a fixed extension system, the option of threading, and a more stable instance addressing system.

As for the central iterator list (the list of active iterators to be conscious of when deleting shit), I am still happy with it. Though I may refactor it slightly to maintain links in the list correctly instead of moving deleted iterators back (in case an iterator is reused which is expecting one type of object and instead finds another type by mistake). For now, it should be fine.

Problem 2: The Platform-Graphics bridge is ill-conceived and horrible.
The engine directory structure gives the impression that you can use OpenGL or DirectX as your library on Windows. Presently, this isn't the case, as both systems require the window to be initialized in a special way. You may be familiar with WGL and GLX; they are, respectively, the Windows GL interface and the GL-X11 interface. Code for these monsters is found right in the Platforms folder—So far we've avoided possible issues using preprocessors, but these hurt compile time and are in general unattractive.

It's been a clusterfuck so far, because we're dealing with three entities in the Platforms folder instead of one:
  • Platform-dependent code for all manner of things, including grabbing executable name and working with directories
  • Window system code; the code that creates and manipulates windows
  • Platform-specific Graphics code, eg, WGL/GLX

It's messy to separate those three items, which is why we have issues.

Solution: Create a new folder of bridge systems.
I don't care where in SHELL this folder is created, but it needs to contain folders such as Win32-OpenGL, Win32-DirectX, X11-OpenGL, etc, for each valid pairing of Window System - Graphics System.

We may also want to separate out the window system code and put it with the widget system code. This is leading to minor technicalities on Linux: The window is governed by raw X11, while the widgets are governed by GTK+. It hasn't led to any problems, but it has the potential to do so—especially on pairings in the future (eg, if some poor bastard tries to write QT widgets).

Since much of the code in the Win32/ folder was written by me when I was 16, it may be a good idea to comb over it again, anyway. If this can serve as an excuse to do so, go ahead and let it.

Personal Problem: I return to school after two weeks.
I have 14 days of freedom before I return to school, and I already need to start making preparations for that. Depending on how I tackle this semester, it may be even more work than the last. The good news? Two things: (1) the course which will generate the most work? It's on game design. That's right, the thing we've all been doing since we were 12. (2) I am taking five courses instead of six, and one of them is philosophy. For those of you who have not taken a college philosophy course, they are an easy, effortless, and even fun A if you have an open mind and don't mind some discussion.

The bad news: The game I design has to use Ogre (or Unity or XNA—Not even considering the latter, not wanting the former since I use Linux), which I have never used before.

The other good news: I intend to deal with this gracefully by writing an Ogre extension for ENIGMA. If I have to deal with Ogre, this project may as well benefit from it.

Now you are all up to speed. In summary, brace for impact.

General ENIGMA / Re: EGMJS
« on: December 18, 2012, 12:51:41 PM »
Sounds great. As I see it, this is what you'll have to do:

1) Create methods in C++ to populate a JDI context with function and variable definitions. You'll have, for instance, a define_global(string name), and a define_function(string name, something).  I can write these for you, if you need.

2) Create Java methods which call the C++ methods. Basically, just wrappers through JNA, like we do for everything else that goes on between ENIGMA and LateralGM.

3) Create JavaScript functions through Rhino which call the JNA wrapper functions. So the JavaScript function def_function() calls the Java function DefineFunction, which uses JNA to call the C++ method define_function(). Just for example.

4) Using Rhino and JavaScript reflection, call the JavaScript functions for each member. As I left the system, each function contained a variable representing its minimum and maximum number of parameters.

Depending on if you want to support overloading, they may need to contain more information than that. It's that information which ultimately determines the other parameters to define_function(). JDI supports storing any type of function C++ supports; it's up to you how many to simulate in the JavaScript engine. It may be that all define_function() needs is name, parameter names, and minimum/maximum parameter counts (for variadic functions, the maximum would be -1).