Since these forums have been dreadfully quiet (although the IRC has been jumping), I figured I'd give an update on some of the changes that I've been working on for ENIGMA.
Of course, you could just read the revision logs between r550 and now (r574) and the LateralGM revision logs (r462 to r473), but this gives you an in-depth overview and the technical stuff you need to know without getting into the technical stuff that the revision logs need to say.
As I'm the main developer (and currently only developer) of LateralGM, I'll start with that.
First, I rearranged the sound frame a little as it was badly in need of a makeover. I think you'll approve
http://img9.imageshack.us/i/soundframe.png/Next, I added a Sprite Load-From-Strip button and corresponding dialog. You won't need a screenshot of that because it looks just like GM. I'm still working out a little kink where the preview insists on being massive for large images, rather than obeying/using the scroll panel.
Also, many of you will be happy to know that you can now override the GM preferences (e.g. which sprite editor to use, and other settings inside
preferences.properties *inside the jar*) using Java Preferences. Although there isn't a GUI for it yet, I'll explain how you can do it by hand in footnote 1. This means that you don't need to keep going inside the jar and fixing
preferences.properties every time we include a new LGM jar with enigma.
After that, I realized that I'm apparently the only person in the world who knows Java, and am the only one working on LGM, at which point I slit my wrists.
After I got back from the hospital, I started work on Enigma, since other people are actually working on that too, even though I despise C++ (and now I'm re-learning why).
Most of my work on Enigma has centered around the collision system. Most of you have probably already seen my bbox collision functions which you could copy-paste into the Definitions, along with a hacked-together is_solid function since Enigma didn't support solid. Well, that code isn't there anymore, because it's now part of Enigma, so it wouldn't be a good idea to define the functions twice. Not to mention, the enigma versions are much better. Here's what I did:
1> I implemented solid. Much to the surprise of Josh, I actually edited something deep within Josh's code. Now, if the Object has "[X] solid" checked in LateralGM, ENIGMA will also realize that it's solid.
2> I added better Makefile API support for Collision APIs and such. This was just preliminary stuff to make sure that 3 would work.
3> I added a BBox Collision API which provided my collision functions, which now make use of the implementation of 'solid', as well as Mith's 'notme' implementation.
4> I modularized my Collision API, breaking it into essentially 3 tiers, which will make it much easier for other implementations (e.g. Polygon collisions) to extend upon it. Please see footnote 2 for an explanation of the tiers.
5> I've been working on polygon masking of the sprites, which will allow r9k to work on polygon collisions. For the most part it works great, but for some reason I've gotten it to get stuck in an infinite loop and then consume all of the JVM's memory and error out on certain kinds of sprites. I'm hoping to have that fixed next, and then r9k can have his polygon mask points.
Josh and I have also done a major overhaul of the wiki. Some other users helped out in little areas here and there, and we very much appreciate that. If you haven't seen it recently, go check it out by clicking the wiki link up top, orifyou'retoofucking
lazyyoumightfindthelinkinhere...
Footnote 1: How to override LGM Preferences defined in
preferences.properties.
Ensure that no instances of LGM are currently running (e.g. Close LGM). Now determine which settings you wish to override and what value you would like to override it with. If you aren't completely sure, open LGM.jar like a zip file (e.g. with a half-decent archive manager), and browse to org/lateralgm/main/preferences.properties and open it. Each property will be a `name: value` pair, and #comments have a hash sign (#) before them to explain what each setting is and how to format your values.
Once you know your property name and value, the next step is to inject that into Java Preferences. You can either do this by using Java, or bypass Java and just inject into wherever it stores those preferences.
Java way:
import java.util.prefs.Preferences;
public class Inject { public static void main() {
Preferences.userRoot().node("/org/lateralgm").put("NEWKEY","My New Value"); System.out.println("Done.");
}}and change NEWKEY with the property name, and My New Value with the new property value. Name the file "Inject.java". Compile and run it. If all goes well, the only thing you should see output is "Done." (if you run from command line). LGM should pick it up on next run.
Bypass way, Ubuntu/Linux edition:
> gedit ~/.java/.userPrefs/org/lateralgm/prefs.xml &
Note that .java and .userPrefs are hidden directories, so you won't see them by default in the file browser. The file should look like this:
<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<!DOCTYPE map SYSTEM "http://java.sun.com/dtd/preferences.dtd">
<map MAP_XML_VERSION="1.0">
<entry key="KEY1" value="value1"/>
<entry key="KEY2" value="value2"/>
...
</map>So it will be a simple matter of adding a new line before the </map>, which reads as follows:
<entry key="NEWKEY" value="My New Value"/>
Change NEWKEY with the property name, and My New Value with the new property value. Save the file, and close it. LGM should pick it up on next run.
Bypass way, Windows Edition:
Since I don't use Windows, I don't know the specifics of how this works, but you should be able to figure it out. The starting point would be to open the Registry Editor, and locate:
HKCU\Software\Javasoft\Prefs\org\lateralgm
and presumably you'd just add your Key/Value pair.
Bypass way, Mac Edition:
Browse to ~/Library/Preferences/org/lateralgm and figure it out from there. The Linux method might provide some insights.
If anybody can provide more information for these methods, by all means, go ahead.
Footnote 2: One Tier to rule them all, One Tier to find them, One Tier to bring them all and in the darkness bind them.
The collision system is broken into 3 crucial tiers.
The lowest level tier is utility functions, which provide basic shape collision functions, like bbox-bbox, bbox-line (which delegates to rect-line), bbox-point, and rect-line. These functions are appropriately named according to their shapes, and as such are implementation independent.
The middle tier is defined by interface functions - function names and arguments which every API implementation must implement in their own way. These are the collide_inst_* functions, which will return the first instance colliding (however that instances collision is determined in this implementation) with a certain shape or another instance.
The highest level tier is abstract GML functions, like collision_line, place_free, and position_meeting. These functions delegate to the interface functions, which allows them to be implementation independent.
