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.
16
Announcements / Judgement Day Update
« on: May 21, 2011, 01:34:19 pm »
The time is currently 14:30 EST, GMT -5 for myself and Josh, giving us another 3.5 hours to finish up enigma before fire and brimstone hits. Unfortunately we've lost TGMG, as it's currently 19:30 over there, presumably he ascended, which means that we'll have to make due without the Android port, since he was never able to get OpenGLES to work.
Josh is currently working on something about macros while he waits for the religious folks to fly into the sky giving him a much needed chance to loot and orgy until he gets struck by some act of god or October 21st, when God pulls the plug completely. I'm of course atoning for my sins and spending my last couple of hours with my family. I'm happy with the state of LGM right now, and think ENIGMA should be able to continue over the next several months without continuing improvements to it.
Josh is currently working on something about macros while he waits for the religious folks to fly into the sky giving him a much needed chance to loot and orgy until he gets struck by some act of god or October 21st, when God pulls the plug completely. I'm of course atoning for my sins and spending my last couple of hours with my family. I'm happy with the state of LGM right now, and think ENIGMA should be able to continue over the next several months without continuing improvements to it.
17
Proposals / EGM format: Allow resources in other folders?
« on: May 02, 2011, 12:26:39 am »
While we're designing the new EGM file format, there are quite a few new things that we can do that GM doesn't directly allow.
For starters, I'd like to ask your opinions on whether resources should be allowed in other folders where they're not designed to be. In essence, this would be leaving organization completely up to the user - you can clump a bunch of different resource types together in one group - like having a sprite in the same folder as an object.
This could be a nice organizational feature -- or it could be a total disaster. Also interesting, I don't think I've ever seen it suggested for GM.
As for how this effects the format - it would mean that each resource would need to identify its resource type. This would slightly increase filesize. It would also make it a little trickier to read it in - but not much.
Another interesting note - technically GM's file format allows this - there's just no IDEs that can do it.
Alternatively, we can keep it the way GM has it, and force resources to be segregated into their own folders.
For starters, I'd like to ask your opinions on whether resources should be allowed in other folders where they're not designed to be. In essence, this would be leaving organization completely up to the user - you can clump a bunch of different resource types together in one group - like having a sprite in the same folder as an object.
This could be a nice organizational feature -- or it could be a total disaster. Also interesting, I don't think I've ever seen it suggested for GM.
As for how this effects the format - it would mean that each resource would need to identify its resource type. This would slightly increase filesize. It would also make it a little trickier to read it in - but not much.
Another interesting note - technically GM's file format allows this - there's just no IDEs that can do it.
Alternatively, we can keep it the way GM has it, and force resources to be segregated into their own folders.
18
Announcements / Wiki down (and back up)
« on: April 26, 2011, 11:05:38 pm »
At some time between 2011-04-23@02:18 (when I last saw it working) and 2011-04-25@19:14 (when someone reported the problem), a fatal database corruption took the life of our wiki. We have submitted a ticket with our host to fix it, which may mean performing a rollback to an older backup. We'll let you know how it all goes, and hopefully we can have it back and running without too much work lost.
Thank you for bearing with us in the meantime.
Thank you for bearing with us in the meantime.
19
Third Party / GM8.1 format changes
« on: April 23, 2011, 11:49:21 pm »
Herein I'll try to maintain a full listing of changes between GM8.0 (800) and GM8.1 (810).
This information can kind of be gleaned by carefully reading the GM Release notes, and dumping the irrelevant junk.
http://store.yoyogames.com/downloads/gm4win/release-notes.html
Note that, at this time, none of the changes in 810 affect the filesize. They have finally learned to recycle bytes. Also note that almost all of the changes are completely backwards compatible, meaning that if you change the version identifier back to 800, it will load in GM8.0, although some minor fields may have incorrect values (e.g. Font Range Min usually changed to 255).
8.1.X (oldest)
Version identifier appearing after magic number changed from 800 to 810.
Font "Range Min" bytes now shared with Charset (default 0). First 2 bytes (little endian) still indicate Range Min. Next byte indicates charset identifier. Final byte reserved (0).
8.1.69
Font "Range Min" and Charset bytes now merged with Anti-Aliasing (AA) selection (default 3). Final byte after the charset identifier now indicates the AA. 0 for Off, other values are 1, 2, and 3. Still uncertain what the different values of anti-aliasing mean.
Game Settings "Uninitialized variables" bytes now shared with "Throw an error when arguments aren't initialised correctly." (I abbreviate it as "Mismatched Arguments" or "Parameter Checking". Default On or 1). First byte is a bit-share, where Uninitialized Variables occupies &0x01, and Mismatched Arguments occupies &0x02.
8.1.71-91
No known changes.
LGM is at this point.
8.1.106
May have changed all strings, especially script code, to unicode support. Unconfirmed.
8.1.107-108
No known format changes. Introduces new functions ansi_char(?), get_function_address(?), string_byte_length(?), string_byte_at(?).
8.1.109-123
No known changes.
8.1.125
May have changed the saved room settings format. Unconfirmed.
8.1.126-135
No known changes.
This information can kind of be gleaned by carefully reading the GM Release notes, and dumping the irrelevant junk.
http://store.yoyogames.com/downloads/gm4win/release-notes.html
Note that, at this time, none of the changes in 810 affect the filesize. They have finally learned to recycle bytes. Also note that almost all of the changes are completely backwards compatible, meaning that if you change the version identifier back to 800, it will load in GM8.0, although some minor fields may have incorrect values (e.g. Font Range Min usually changed to 255).
8.1.X (oldest)
Version identifier appearing after magic number changed from 800 to 810.
Font "Range Min" bytes now shared with Charset (default 0). First 2 bytes (little endian) still indicate Range Min. Next byte indicates charset identifier. Final byte reserved (0).
8.1.69
Font "Range Min" and Charset bytes now merged with Anti-Aliasing (AA) selection (default 3). Final byte after the charset identifier now indicates the AA. 0 for Off, other values are 1, 2, and 3. Still uncertain what the different values of anti-aliasing mean.
Game Settings "Uninitialized variables" bytes now shared with "Throw an error when arguments aren't initialised correctly." (I abbreviate it as "Mismatched Arguments" or "Parameter Checking". Default On or 1). First byte is a bit-share, where Uninitialized Variables occupies &0x01, and Mismatched Arguments occupies &0x02.
8.1.71-91
No known changes.
LGM is at this point.
8.1.106
May have changed all strings, especially script code, to unicode support. Unconfirmed.
8.1.107-108
No known format changes. Introduces new functions ansi_char(?), get_function_address(?), string_byte_length(?), string_byte_at(?).
8.1.109-123
No known changes.
8.1.125
May have changed the saved room settings format. Unconfirmed.
8.1.126-135
No known changes.
21
Proposals / LGM Find/Replace - Design Ideas
« on: April 05, 2011, 03:56:55 pm »
I'm looking to implement a somewhat competent Find/Replace feature into LGM. I'd like some input on what options you think would be good, how to lay it out, etc.
Fields:
* There will be a text field for Find
** There will be an option for regex (anybody think wildcard would be necessary?)
* There will be a text field for Replace
** This will accept regex backreferences if the Find is a regex.
* There will be separate buttons for Find, Replace Once, and Replace All.
* There will be options for search scope:
** The current script
** Another open script
** 1 All scripts
** 2 Resource names
** 3 All DND Action Arguments
** Any combination of 1, 2, and 3. (gui suggestions on how to present these options appreciated)
Functionality:
Upon pressing Ctrl+F anywhere in LGM, this dialog will appear. If it was pressed from within a script, it will be scoped for that script by default. Otherwise, it will be a global search (some combination of 1, 2, and 3 - suggestions for a default scope appreciated)
Initially, the Search textfield will have focus, and will be populated with the contents of the [clipboard | current cursor selection]. Pressing the tab key will switch focus to the Replace textfield immediately.
Pressing enter while the search textfield is in focus, and no input was given to the replace textfield, will only perform a Find.
Pressing enter with the replace textfield in focus and with text will perform a Replace Once. Holding down a certain (as of yet undetermined) key will perform a Replace All.
Ideas:
Some sort of tree structure for displaying results of performing search on global scope. Maybe even flatten single-child parent nodes (e.g. only one sprite was found, so display Sprites/spr_name, compared to Sprites/ \n \t spr_name. This example use branch/leaf, but the same would be applied to branch/branch as well).
Although it might be difficult to implement, a way to undo a full find/replace, in case it turns out badly.
Concerns:
How would focus traversal work for options? Right now it goes: Find Text > Replace Text > Find Button > Replace Once > Replace All
Global Searching should also take into account Room Creation and Instance Creation Codes.
If anybody wants to draw up the way they think it should be laid out, that'd be awesome.
Fields:
* There will be a text field for Find
** There will be an option for regex (anybody think wildcard would be necessary?)
* There will be a text field for Replace
** This will accept regex backreferences if the Find is a regex.
* There will be separate buttons for Find, Replace Once, and Replace All.
* There will be options for search scope:
** The current script
** Another open script
** 1 All scripts
** 2 Resource names
** 3 All DND Action Arguments
** Any combination of 1, 2, and 3. (gui suggestions on how to present these options appreciated)
Functionality:
Upon pressing Ctrl+F anywhere in LGM, this dialog will appear. If it was pressed from within a script, it will be scoped for that script by default. Otherwise, it will be a global search (some combination of 1, 2, and 3 - suggestions for a default scope appreciated)
Initially, the Search textfield will have focus, and will be populated with the contents of the [clipboard | current cursor selection]. Pressing the tab key will switch focus to the Replace textfield immediately.
Pressing enter while the search textfield is in focus, and no input was given to the replace textfield, will only perform a Find.
Pressing enter with the replace textfield in focus and with text will perform a Replace Once. Holding down a certain (as of yet undetermined) key will perform a Replace All.
Ideas:
Some sort of tree structure for displaying results of performing search on global scope. Maybe even flatten single-child parent nodes (e.g. only one sprite was found, so display Sprites/spr_name, compared to Sprites/ \n \t spr_name. This example use branch/leaf, but the same would be applied to branch/branch as well).
Although it might be difficult to implement, a way to undo a full find/replace, in case it turns out badly.
Concerns:
How would focus traversal work for options? Right now it goes: Find Text > Replace Text > Find Button > Replace Once > Replace All
Global Searching should also take into account Room Creation and Instance Creation Codes.
If anybody wants to draw up the way they think it should be laid out, that'd be awesome.
22
Function Peer Review / move_towards_point
« on: January 07, 2011, 04:05:11 pm »Code: (C++) [Select]
void motion_set(double newdir, double newspd) {
enigma::object_planar* const inst = ((enigma::object_planar*)enigma::instance_event_iterator->inst);
inst->direction.rval.d = newdir;
inst->speed.rval.d = newspd;
inst->hspeed.rval.d = newspd * cos(newdir);
inst->vspeed.rval.d = newspd * sin(newdir);
}
inline void move_towards_point(double x, double y, double spd) {
motion_set(point_direction(
((enigma::object_planar*)enigma::instance_event_iterator->inst)->x,
((enigma::object_planar*)enigma::instance_event_iterator->inst)->y,
x,y),spd);
}
motion_set was borrowed from action_move. It's just used as a convenience method to set both speed and direction efficiently. There have been some concerns over radians vs. degrees, and I haven't looked into them fully, but oddly enough action_move seemed to work...
23
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.
24
Function Peer Review / action_move
« on: November 03, 2010, 10:44:10 am »
I'm trying to write up the action_move function, since it doesn't really have a direct GML equivalent, due to the direction argument being multiple-choice which then gets randomly selected.
I'm also working on an educated assumption here, trying to recall from when I still had access to GM, how it behaved.
Assumption 1: It will randomly select one of the depressed directional buttons, but will not select a between value (so the resulting direction will always be a multiple of 45).
Assumption 2: The directional string directly corresponds with the directions in the dirs array. (I've done a bit of testing, so I think it is correct)
Note 1: The first argument should always be an array of characters of size 9. Longer strings are fine, but only the first 9 characters will be examined. Shorter strings may cause this to look at memory beyond the string.
Note 2: This code makes use of the random(x) function.
Note 3: A few minor optimizations can be made around random.
3a: To avoid the use of random when there's only 1 choice. Replace:
choices = int(random(choices)); //choices is now chosen
With
3c: Replace random with integrated choose() function once it's implemented, if it's more efficient.
I'm also working on an educated assumption here, trying to recall from when I still had access to GM, how it behaved.
Assumption 1: It will randomly select one of the depressed directional buttons, but will not select a between value (so the resulting direction will always be a multiple of 45).
Assumption 2: The directional string directly corresponds with the directions in the dirs array. (I've done a bit of testing, so I think it is correct)
Code: (C++) [Select]
void action_move(const char dir[9], int argspeed) {
int dirs[9] = { 225, 270, 315, 180, -1, 0, 135, 90, 45 };
int chosendirs[9];
int choices = 0;
for (int i = 0; i < 9; i++)
if (dir[i] == '1') chosendirs[choices++] = dirs[i];
if (choices == 0) return;
choices = int(random(choices)); //choices is now chosen
//We use rval.d for efficiency, so hspeed/vspeed aren't set twice.
const double newdir =
((enigma::object_planar*)enigma::instance_event_iterator->inst)->direction.rval.d = chosendirs[choices];
if (argument_relative)
argspeed += ((enigma::object_planar*)enigma::instance_event_iterator->inst)->speed;
const double newspd =
((enigma::object_planar*)enigma::instance_event_iterator->inst)->speed.rval.d = chosendirs[choices] == -1 ? 0 : argspeed;
((enigma::object_planar*)enigma::instance_event_iterator->inst)->hspeed.rval.d = newspd * cos(newdir);
((enigma::object_planar*)enigma::instance_event_iterator->inst)->vspeed.rval.d = newspd * sin(newdir);
}
Note 1: The first argument should always be an array of characters of size 9. Longer strings are fine, but only the first 9 characters will be examined. Shorter strings may cause this to look at memory beyond the string.
Note 2: This code makes use of the random(x) function.
Note 3: A few minor optimizations can be made around random.
3a: To avoid the use of random when there's only 1 choice. Replace:
choices = int(random(choices)); //choices is now chosen
With
Code: (C++) [Select]
if (choices == 1) choices = 0;
else choices = int(random(choices)); //choices is now chosen
3b: Replace random with randomInt if it's more efficient (and if it exists).3c: Replace random with integrated choose() function once it's implemented, if it's more efficient.
25
Function Peer Review / Networking on GitHub
« on: September 21, 2010, 12:27:41 pm »
I've uploaded my networking files to:
http://github.com/IsmAvatar/EnigmaNet
MIT license, so they can easily be relicensed to GPL.
Please feel free to contribute.
At this time, they are written in C only.
They are largely functional, but some aspects need a bit of improvement, or at least a thorough going-over - in particular, mplay_send and mplay_receive.
They are currently named mplay_ until we get a better name for them. They do not use DirectPlay (which GM uses) and we do not aim to create a reproduction of the mplay_ functionality.
They work standalone, but I'm sure they could be plugged into Enigma as well.
http://github.com/IsmAvatar/EnigmaNet
MIT license, so they can easily be relicensed to GPL.
Please feel free to contribute.
At this time, they are written in C only.
They are largely functional, but some aspects need a bit of improvement, or at least a thorough going-over - in particular, mplay_send and mplay_receive.
They are currently named mplay_ until we get a better name for them. They do not use DirectPlay (which GM uses) and we do not aim to create a reproduction of the mplay_ functionality.
They work standalone, but I'm sure they could be plugged into Enigma as well.
26
Announcements / Enigma on all platforms
« on: August 16, 2010, 02:09:20 pm »
After testing on Linux, Windows, the IPhone, and Mac, we've just tested and confirmed that Enigma works on the Toaster too.
Enjoy.
Enjoy.
27
Proposals / Code Formatting
« on: July 23, 2010, 08:10:10 am »
Not to sound lazy, but LGM could really use a code formatter, and since ENIGMA already has a parser, it seems like it'd be a lot easier for ENIGMA to serve that purpose than LGM. Obviously there'd be a few options to specify the format. Right now I think a simple set of post-conditional indentation controls to be the bare essentials.
1) Place first curly bracket on newline?
2) Indent curly bracket(s)?
Needless to say, the code inside the curly brackets would be indented properly without needing to specify an option at this point.
Original heap of junk:
false false:
false true:
true false:
true true:
1) Place first curly bracket on newline?
2) Indent curly bracket(s)?
Needless to say, the code inside the curly brackets would be indented properly without needing to specify an option at this point.
Original heap of junk:
Code: [Select]
if(blah){doThis();}
false false:
Code: [Select]
if (blah) {
doThis();
}
false true:
Code: [Select]
if (blah) {
doThis();
}
true false:
Code: [Select]
if (blah)
{
doThis();
}
true true:
Code: [Select]
if (blah)
{
doThis();
}
28
As the person who programmed the original X interface for enigma, I think I'm entitled to agree with this statement wholeheartedly:
"Programming graphics in X is like finding sqrt(pi) using Roman numerals."
- Henry Spencer
Followed by this haiku:
C program run.
C program crash.
C programmer quit.
"Programming graphics in X is like finding sqrt(pi) using Roman numerals."
- Henry Spencer
Followed by this haiku:
C program run.
C program crash.
C programmer quit.
29
Off-Topic / Sandy Duncan and clan
« on: July 07, 2010, 08:18:11 pm »
Turns out Sandy Duncan isn't the cross-dressing skank that Josh had us so convinced he was.
http://glog.yoyogames.com/?p=1141
According to the post, left to right as follows: Russell Kay, Sandy Duncan, Kirsty Scott, and Mike Dailly.
http://glog.yoyogames.com/?p=1141
According to the post, left to right as follows: Russell Kay, Sandy Duncan, Kirsty Scott, and Mike Dailly.
30
Announcements / Experimental GM7/8 saving support in LGM.
« on: May 21, 2010, 01:43:48 pm »
As of Enigma r234, the LateralGM included with Enigma now has the ability to save in the GM7 and GM8 formats (gmk).
Please note that support for these formats is experimental at this state, and may do any of the following:
If you experience any of these problems, or any other problems, with the exception of the last one listed (seeing as it is intended behavior), first do an svn update to ensure that a later revision doesn't fix them, and then you may report them in this post. Remember, they are LGM bugs, and NOT Enigma bugs.
If you don't want to use the experimental features, simply choose "600" when saving your file, and the behavior should remain mostly the same as it was before these features - always saving as GM6.
One of the biggest benefits expected to come out of this is the ability to use alpha transparency in sprites in 800 (GM8: gmk).
Please note that support for these formats is experimental at this state, and may do any of the following:
- Error on saving a GM file.
- Error on loading a normal GM file.
- Produce corrupted GM files.
- Be able to read the corrupted GM files it produced.
- Not be able to read the GM files it produced.
- Screw up some resource data, but not corrupt the GM file.
- Cause data loss during a conversion process between any two versions. (This is intended behavior, since different versions support different feature sets, so some features may be lost between two versions)
If you experience any of these problems, or any other problems, with the exception of the last one listed (seeing as it is intended behavior), first do an svn update to ensure that a later revision doesn't fix them, and then you may report them in this post. Remember, they are LGM bugs, and NOT Enigma bugs.
If you don't want to use the experimental features, simply choose "600" when saving your file, and the behavior should remain mostly the same as it was before these features - always saving as GM6.
One of the biggest benefits expected to come out of this is the ability to use alpha transparency in sprites in 800 (GM8: gmk).