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.
Pages: « 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 »
496
General ENIGMA / Re: Some common GML issues, and dealing with them in Enigma?
« on: December 22, 2010, 09:36:45 pm »
Careful with how you name them. 'draw' is a common variable name that people use to determine whether something will draw or not. 'step' is usually an incremental variable, sometimes used to indicate how many 'steps' a character has walked. I wouldn't expect people to use them as script names, though, so draw() and step() would be safe, as long as they are distinguished from their non-parenthesized namesake.
497
Proposals / Re: Script Editor Improvements
« on: December 22, 2010, 07:14:17 pm »
You never asked me to isolate JEdit, you asked me to isolate JTextField. JEdit is already isolated, inside org.lateralgm.jedit, an entirely self-contained package.
498
General ENIGMA / Re: Some common GML issues, and dealing with them in Enigma?
« on: December 22, 2010, 06:48:48 pm »
freezway: This behavior is defined in events.res, I believe, which is a text file that you may freely modify. It seems like ENIGMA currently has game start occur first, then room start, and then create. This could be simply reordered as you desire.
499
Proposals / Re: Editing Events Inside LGM
« on: December 22, 2010, 05:59:58 pm »
Due to the multi-platform nature of LGM-ENIGMA, I have been considering modifying LGM's events system, so you may see this implemented in the somewhat near future. I might work on it next. And good thinking about the Trigger system. We'll have to see what can be done there.
500
General ENIGMA / Re: Compiling on OS X
« on: December 20, 2010, 07:40:44 pm »
I was kidding about the social security number. In order to download the program with the SDK from Mac's website, you need to be a registered developer. Registration is of course free, but they ask for sensitive information like you name, address, and phone number. Then you have to scrounge around on their pages to find the stupid download link. Once you find it and attempt to download it, it's of course standard browser-to-server download. And who has time to download 3.5 GB all at once? So the torrent is really just a convenience thing. If you're that concerned, then by all means, sell your soul to Mac and download the thing straight from their servers yourself.
501
General ENIGMA / Re: Compiling on OS X
« on: December 20, 2010, 03:39:07 pm »
ugriffin: LGM overrides whatever L&F you try to tell it to have. This is programmed in. We're considering relaxing this restriction.
502
General ENIGMA / Re: Compiling on OS X
« on: December 20, 2010, 03:35:06 pm »
I am now torrenting the sdk dmg. It is the file attached at the bottom of this post. The reason I'm doing this is because it's really hard to find (you need a mac dev account, which asks for your social security number and first born), and it's ridiculously large, so by torrenting it, you can download it at your leisure and stop and continue as you'd like, as long as a seeder is available. I should be seeding it with pretty close to 90% uptime. It might take a minute or two before it picks up the seed. If you're having trouble finding a seed, tell me on the IRC and I'll try and find out what's going on.
Please re-seed.
Please be aware that the resulting file is 3.5 GB. I have not tested it myself yet, but the download went smoothly and I've never had a problem with data corruption in the past, so it should be good.
If this torrent doesn't work, you might have more luck with an existing one on TPB:
http://torrents.thepiratebay.org/5793708/Xcode_3.2.3_and_iOS_SDK_4.0.2.5793708.TPB.torrent
Please re-seed.
Please be aware that the resulting file is 3.5 GB. I have not tested it myself yet, but the download went smoothly and I've never had a problem with data corruption in the past, so it should be good.
If this torrent doesn't work, you might have more luck with an existing one on TPB:
http://torrents.thepiratebay.org/5793708/Xcode_3.2.3_and_iOS_SDK_4.0.2.5793708.TPB.torrent
503
Announcements / Re: Collisions update
« 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 checkIt 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.
504
Announcements / Re: Collisions update
« 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.
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.
505
General ENIGMA / Re: Compiling on OS X
« on: December 19, 2010, 03:40:15 pm »
afaik, all you need is some super-massive dev kit for OSX, and then everything will just work.
If anybody knows the exact process, please document it on the wiki.
If anybody knows the exact process, please document it on the wiki.
506
Announcements / Collisions update
« 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'retoofuckinglazyyoumightfindthelinkinhere...
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:
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:
<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.
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'retoofuckinglazyyoumightfindthelinkinhere...
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.
507
Function Peer Review / Re: move_towards_point + move_snap
« on: December 17, 2010, 12:24:39 am »
r570 implements solid, and r571 links in the new collision system functions.
place_free now works wonderfully.
place_free now works wonderfully.
508
Function Peer Review / Re: move_towards_point + move_snap
« on: December 16, 2010, 07:18:18 pm »
1) Couldn't you just do:
2) That said, since obj->solid isn't populated yet, I've been using true instead. I'll document it.
Edit: I've now documented (r569) that obj->solid isn't populated yet. The temporary solution is basically what you said - to put checks inside is_solid for each object you know to be solid. Otherwise, just returning true will treat all instances as solid.
Code: (C++) [Select]
bool is_solid(const enigma::object_collisions *obj) {
return obj->solid;
}
2) That said, since obj->solid isn't populated yet, I've been using true instead. I'll document it.
Edit: I've now documented (r569) that obj->solid isn't populated yet. The temporary solution is basically what you said - to put checks inside is_solid for each object you know to be solid. Otherwise, just returning true will treat all instances as solid.
509
Function Peer Review / Re: move_towards_point + move_snap
« on: December 16, 2010, 04:06:49 pm »
Please share your new place_Free and place_empty and is_solid code.
510
Function Peer Review / Re: clamp()
« on: December 14, 2010, 05:54:39 pm »
Another neat thing about median is that argument order doesn't matter.