ENIGMA Forums

General fluff => Announcements => Topic started by: IsmAvatar on December 18, 2010, 07:21:43 pm

Title: Collisions update
Post by: IsmAvatar on December 18, 2010, 07:21:43 pm
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'retoofuckingl (http://enigma-dev.org/docs/wiki/)azyyoumightfindthelinkinhere...



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:
Code: (Java) [Select]
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:
Code: (XML) [Select]
<?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.
Title: Re: Collisions update
Post by: RetroX on December 18, 2010, 09:16:30 pm
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).
And why is that? :P

Also, I do know Java, but hardly any of its classes besides the basics.
Title: Re: Collisions update
Post by: freezway on December 19, 2010, 02:29:34 am
I AM SO HAPPY NOW THAT IT HAS COLLISION LINE! It'd be cool if it had one where it set values passes as pointers (a _ext version) of the exact collsision coordinates. but im happy for at least 2 weeks.
Title: Re: Collisions update
Post by: MrGriggs on December 19, 2010, 05:39:42 am
GREAT work :)
Title: Re: Collisions update
Post by: Josh @ Dreamland on December 19, 2010, 11:16:16 am
I'm telling you, there's got to be someplace where they sell Java programmers by the crate. The purebred kind, the ones that don't know any other languages and can't think for themselves. If we buy a whole crate full, we can just throw out the defective ones and keep a few good ones for you to put to work.

Oh, and I fixed some stuff in those thirty revisions, too. I don't feel like reading through them to figure out what they were, but two I can readily recall are a glitch in the syntax checker and another in the motion handlers.
Title: Re: Collisions update
Post by: IsmAvatar on December 19, 2010, 03:45:03 pm
The problem is that LGM is set up using various design patterns and require a fair amount of abstract thinking. A lot of my desired changes would not be simply "code this", but rather "modularize this so we can use it easier and so it's easier to understand." Something you don't usually get with non-sentient code monkeys in a crate.


Also, I should mention that I did nothing special to implement 'other' yet, so as far as I can tell, 'other' is not populated.

Quote
It'd be cool if it had one where it set values passes as pointers (a _ext version) of the exact collsision coordinates. but im happy for at least 2 weeks.
The rectangle-line collision algorithm does not support this, afaik - it was implemented in an efficient way just for doing a boolean check. There are various line-clipping algorithms which would give you the coordinates where a line meets the boundaries of a rectangle, but they are nowhere near as efficient as the current algorithm. At any rate, anybody is welcome to implement them and stick them in the collision-utilities backend.
Title: Re: Collisions update
Post by: freezway on December 19, 2010, 06:19:42 pm
Would it be faster to call that one x times or to find the exact coordinates? You can find the exact and closest with base 2 n runs where n is the distance to check
Title: Re: Collisions update
Post by: The 11th plague of Egypt on December 19, 2010, 06:26:42 pm
The problem is that LGM is set up using various design patterns and require a fair amount of abstract thinking. A lot of my desired changes would not be simply "code this", but rather "modularize this so we can use it easier and so it's easier to understand." Something you don't usually get with non-sentient code monkeys in a crate.


Also, I should mention that I did nothing special to implement 'other' yet, so as far as I can tell, 'other' is not populated.

Quote
It'd be cool if it had one where it set values passes as pointers (a _ext version) of the exact collsision coordinates. but im happy for at least 2 weeks.
The rectangle-line collision algorithm does not support this, afaik - it was implemented in an efficient way just for doing a boolean check. There are various line-clipping algorithms which would give you the coordinates where a line meets the boundaries of a rectangle, but they are nowhere near as efficient as the current algorithm. At any rate, anybody is welcome to implement them and stick them in the collision-utilities backend.
I was working on a polygon-line distance/collision function as a part of my C++ dll, and it does return the coords of impact. The coder I hired seem to have stopped working, though :ohdear:
Title: Re: Collisions update
Post by: IsmAvatar on December 19, 2010, 06:44:36 pm
Would it be faster to call that one x times or to find the exact coordinates? You can find the exact and closest with base 2 n runs where n is the distance to check
It would be more efficient (and thus faster) to implement one of the existing line-clipping algorithms rather than calling my function repeated times. Although my function is entirely algorithmic and uses no loops, it still has a lot of conditionals that would not be needed/used by a clipping algorithm. But in the meantime, I think my algorithm is probably efficient enough that it *could* be used repeatedly in place of a clipping algorithm and still be fast enough.
Title: Re: Collisions update
Post by: polygone on December 21, 2010, 04:02:13 pm
I'm curious will the finished collision engine behaviour in the exact way that GM's does? Because even small differences could lead to a lot of people's existing gml code not working properly for their collisions. Or will people just have to accept that there will be some difference in the way collisions work?
Title: Re: Collisions update
Post by: Josh @ Dreamland on December 21, 2010, 07:18:59 pm
All I can say is, we'll see. I have no idea whatsoever (which is somewhat unusual; I usually thoroughly investigate the implications of any differences before acting, but in this case I have nothing to go by).

I've thought about it, and the idea that scares me the most is that a GM game in which the character could not fall through a 32px gap between blocks of the same size would do so in ENIGMA, or vice versa.

All I can say is, we'll do our best and pay careful attention to reports.
Title: Re: Collisions update
Post by: polygone on December 21, 2010, 08:06:07 pm
All I can say is, we'll see. I have no idea whatsoever (which is somewhat unusual; I usually thoroughly investigate the implications of any differences before acting, but in this case I have nothing to go by).

I've thought about it, and the idea that scares me the most is that a GM game in which the character could not fall through a 32px gap between blocks of the same size would do so in ENIGMA, or vice versa.

All I can say is, we'll do our best and pay careful attention to reports.
hmm, that is somewhat a concern and thought I have had myself for a while. I always got the feeling you have always been somewhat apprehensive about collisions, so I thought this might have been one of the reasons why. I can see the difficulty that surrounds trying to match a collision system like this, I hope it doesn't wind up being too big an issue.
Title: Re: Collisions update
Post by: Josh @ Dreamland on December 21, 2010, 08:15:09 pm
I have indeed always been. If there is one thing in that forsaken program that Mark did right, it's collisions. In theory... Actually, I don't have much of a theory. I made sure that ENIGMA's instance and event systems were at least as efficient as his, so any slack he saves I'll be saving as well. What it comes down to is us keeping up with Mark in his own domain (it is my understanding that he teaches courses in collision system design).
Title: Re: Collisions update
Post by: Rusky on December 22, 2010, 11:10:26 am
I really don't think GM does collisions all that well- it's either bounding boxes or pixel-perfect, until version 8 where you can have some other basic shapes that may or may not be implemented on top of pixel-perfect. And to make things worse, pixel-perfect is on by default. :/

Staying compatible with such a system while allowing non-brain-dead polygon collisions shouldn't be all that hard; the only real issues I can come up with behavior-wise are off-by-one errors that are easily detected and fixed. It'll just be annoying keeping the dumb way of doing things around.

Unless you're talking about performance, in which case... I'm not really qualified to say anything. I have no idea how GM implements broad-phase collision detection.
Title: Re: Collisions update
Post by: MrGriggs on December 23, 2010, 11:07:48 am
It seems to me the Y collision is off, both for checking place_free(x,y+1) and place_free(x,y-1)...

Off as in there's a larger gap than there should be between the instance and other instance when it declares there's contact.

An example of such can be found here http://www.megaupload.com/?d=DWW890M4 (http://www.megaupload.com/?d=DWW890M4)
Title: Re: Collisions update
Post by: Josh @ Dreamland on December 23, 2010, 09:52:43 pm
I'm always talking about performance, Rusky. Like everything else in GM, collision choices are relatively limited.

I'm not presently able to test your file, MrGriggs; I'll do so when I'm done working on this type resolver.
Title: Re: Collisions update
Post by: Rusky on December 24, 2010, 12:03:53 pm
Ah, yeah.

But in any case I still don't think this will be a problem:
I've thought about it, and the idea that scares me the most is that a GM game in which the character could not fall through a 32px gap between blocks of the same size would do so in ENIGMA, or vice versa.