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.
31
Function Peer Review / Re: action_move_to
« on: March 02, 2011, 06:05:26 am »
@IsmAvatar I initially tried to solve the problem by changing the plugin to add "{" around it. But it causes a problem when using multiple if statements:
{argument relative=false //this argument_relative is part of the action_if_something
if(action_if_something()) { //can't close the '}' for argument_relative until the end
{argument relative=false //this argument_relative is part of the action_if_something
if(action_if_something()) {
{argument relative=false
if(action_if_something()) {
{argument relative=false
action_something();}
}}}}}} //close al the if statements and the argument_relative blocks
So it needs to keep track of where to actually close the '{' for action_if's (that have the relatvie checkbox) which is much more complex than passing the value in by the argument.
@polygone: I forgot that file was still in enigma, it isn't included, it provides all the function prototypes so i can easily test out game maker games which use actions without actually implementing each action properly. As you can see its very messy and unoptimised, it was really just a way to quickly test games that otherwise wouldn't convert.
{argument relative=false //this argument_relative is part of the action_if_something
if(action_if_something()) { //can't close the '}' for argument_relative until the end
{argument relative=false //this argument_relative is part of the action_if_something
if(action_if_something()) {
{argument relative=false
if(action_if_something()) {
{argument relative=false
action_something();}
}}}}}} //close al the if statements and the argument_relative blocks
So it needs to keep track of where to actually close the '{' for action_if's (that have the relatvie checkbox) which is much more complex than passing the value in by the argument.
@polygone: I forgot that file was still in enigma, it isn't included, it provides all the function prototypes so i can easily test out game maker games which use actions without actually implementing each action properly. As you can see its very messy and unoptimised, it was really just a way to quickly test games that otherwise wouldn't convert.
32
Proposals / Re: Action functions plugin writing
« on: March 02, 2011, 04:38:17 am »
You can use it if you add it to the globals file, which I have done but deliberately not added to svn because of the problem I mention in this topic. The way to implement action functions may change as a result of this.
Does anyone have any objections to implementing the action functions like so:
void action_func( int required, bool argument_relative = false ) {}
Which means you can still call the function without the argument_relative parameter and it will fix the issue without having to figure out where the ending '}''s go with lots of nested action_ifs with argument_relatives.
Does anyone have any objections to implementing the action functions like so:
void action_func( int required, bool argument_relative = false ) {}
Which means you can still call the function without the argument_relative parameter and it will fix the issue without having to figure out where the ending '}''s go with lots of nested action_ifs with argument_relatives.
33
Proposals / Re: Function approval process
« on: March 01, 2011, 05:26:50 pm »
When i'm sure everyone is happy with this idea then I will start it off. There is a list of functions which I have only half implemented and want to clean up and put on the wiki to test this idea out.
First I need to find a way to generate the list of functions unsupported by enigma by comparing that list gm has with the enigma list. Parse it and convert to a wiki format (so all the the functions link to a page). Then implement some functions and test the process out.
First I need to find a way to generate the list of functions unsupported by enigma by comparing that list gm has with the enigma list. Parse it and convert to a wiki format (so all the the functions link to a page). Then implement some functions and test the process out.
34
Proposals / Re: Function approval process
« on: March 01, 2011, 04:06:50 pm »
I like the idea of using a bot to streamline the process, and yes it does take some commitment for someone to actually do it, but not really that much.
This is how it could work:
1) Someone implements function, posts code and relevant information
2) Tags page as "Review"
3) Bot (or user) picks up list of weekly pages and Posts Topic in the forum listing them
5) Community discuss any problems with the functions
6) Enigma developer reviews topic at end of week, adding accepted, tagging buggy functions and editing the page with relevant information.
So the only time investment would be the user adding the accepted functions to svn, tagging of buggy functions and everything else can be done by anyone (person who implemented the function prob).
Moving topics around sounds like much more added time as well as checking each function in the topic for which ones need to be moved.
Plus its very easy for developers who want to add a new function or looking for status on a function.
1) Go to wiki page with all unimplemented functions
2) click function name to either create a new page or view the status of the function
Rather than looking through all the topics in a forum which are all mixed up. Its a very easy way for everyone to see the unimplemented functions at the same time.
This is how it could work:
1) Someone implements function, posts code and relevant information
2) Tags page as "Review"
3) Bot (or user) picks up list of weekly pages and Posts Topic in the forum listing them
5) Community discuss any problems with the functions
6) Enigma developer reviews topic at end of week, adding accepted, tagging buggy functions and editing the page with relevant information.
So the only time investment would be the user adding the accepted functions to svn, tagging of buggy functions and everything else can be done by anyone (person who implemented the function prob).
Moving topics around sounds like much more added time as well as checking each function in the topic for which ones need to be moved.
Plus its very easy for developers who want to add a new function or looking for status on a function.
1) Go to wiki page with all unimplemented functions
2) click function name to either create a new page or view the status of the function
Rather than looking through all the topics in a forum which are all mixed up. Its a very easy way for everyone to see the unimplemented functions at the same time.
35
Proposals / Action functions plugin writing
« on: March 01, 2011, 12:08:15 pm »
Currently a few issues are caused by the way the enigma plugin write the actions into gml. Mostly due to the handling of "argument_relative" and possibly the writing of with statements.
Currently the lgm plugin will transform an action that has a relative checkbox into:
argument_relative=true
action_something()
Which causes a problem when the action_if is used without the block actions as it will produce:
if(false)
argument_relative=true
action_something()
So it will always call action_something even when the expression is false.
One way to solve this is to make the plugin automatically put both statements in a block which works fine apart from if statements that use the relative checkbox.
Since some if actions use relative the resulting code for alot of nested if statements would be:
if(action_if())
argument_relative=true
if(action_if_something())
argument_relative=false
if (action_if_something())
Which clearly doesn't work without the block actions.
The action_if_something is just any if action which has a relative checkbox.
So I propose the easiest solution to this would be taking in the argument_relative as an optional parameter for all the action functions, like so:
if(action_if())
if(action_if_something(arguments,true)) //true for relative
if (action_if_something(arguments,false))
You have to implement the action_if actions in order to see this effect otherwise enigma will complain about the functions not existing.
Currently the lgm plugin will transform an action that has a relative checkbox into:
argument_relative=true
action_something()
Which causes a problem when the action_if is used without the block actions as it will produce:
if(false)
argument_relative=true
action_something()
So it will always call action_something even when the expression is false.
One way to solve this is to make the plugin automatically put both statements in a block which works fine apart from if statements that use the relative checkbox.
Since some if actions use relative the resulting code for alot of nested if statements would be:
if(action_if())
argument_relative=true
if(action_if_something())
argument_relative=false
if (action_if_something())
Which clearly doesn't work without the block actions.
The action_if_something is just any if action which has a relative checkbox.
So I propose the easiest solution to this would be taking in the argument_relative as an optional parameter for all the action functions, like so:
if(action_if())
if(action_if_something(arguments,true)) //true for relative
if (action_if_something(arguments,false))
You have to implement the action_if actions in order to see this effect otherwise enigma will complain about the functions not existing.
36
Proposals / Re: Function approval process
« on: March 01, 2011, 05:39:48 am »
What about if I (or somebody) posted a new topic every week with all the new functions that have been tagged in the wiki, with links to the pages. In order to get feedback from all or most of the current developers and forum users before the function is committed to svn, if after a week their is no objections or bugs found in the functions contained in that topic they will be added to svn by me (or somebody else).
The topic could contain the top functions ready to be added, a list of functions that are too buggy to be added (to remind).
This way people would be aware of the new functions about to be added and help either test, optimise or fix functions before they are added. Since its sort of a weekly thing progress is much more likely to take place and functions are unlikely to be left unnoticed in a forum for a period of time. All the functions will be added in a weekly commit so no waiting for developers to add each individual function.
Also another benefit is that the testing information such as:
show_message("Hello world"); // Displays "Hello world" correctly in a message box
show_message("Hello \n World"); //Displays Hello on the first line and World on the second
Can easily be left in the page to become examples of how to use the function.
So when developers are testing their function they can write all the tests in the wiki page (so other users can see what tests have and haven't take place along with tests that fail), when added to svn this information can allow users new to gml examples for how to use each function.
Also functions can be tagged as not working in MacOSX and I can instantly see the functions which are causing problems, same with any platform. You can tag functions as working in Android, iphone, opengl, directX etc, so users can see which functions work and don't work for there target platforms.
If the function has been committed and later found a bug in the function developers can use the wiki page again to implement the fix and new testing information.
Plus since the programmer who implemented that function pretty much knows the function inside out, it shouldn't take too long for them to write a short description of what its used for.
The topic could contain the top functions ready to be added, a list of functions that are too buggy to be added (to remind).
This way people would be aware of the new functions about to be added and help either test, optimise or fix functions before they are added. Since its sort of a weekly thing progress is much more likely to take place and functions are unlikely to be left unnoticed in a forum for a period of time. All the functions will be added in a weekly commit so no waiting for developers to add each individual function.
Also another benefit is that the testing information such as:
show_message("Hello world"); // Displays "Hello world" correctly in a message box
show_message("Hello \n World"); //Displays Hello on the first line and World on the second
Can easily be left in the page to become examples of how to use the function.
So when developers are testing their function they can write all the tests in the wiki page (so other users can see what tests have and haven't take place along with tests that fail), when added to svn this information can allow users new to gml examples for how to use each function.
Also functions can be tagged as not working in MacOSX and I can instantly see the functions which are causing problems, same with any platform. You can tag functions as working in Android, iphone, opengl, directX etc, so users can see which functions work and don't work for there target platforms.
If the function has been committed and later found a bug in the function developers can use the wiki page again to implement the fix and new testing information.
Plus since the programmer who implemented that function pretty much knows the function inside out, it shouldn't take too long for them to write a short description of what its used for.
37
Function Peer Review / Re: action_move_to
« on: February 28, 2011, 10:09:04 am »
This is not the best place to report this but before I forget (I was going to investigate further before filing a bug report). but there is a serious problem with the way the enigma plugin writes the action code.
Before it calls any action it writes the code "argument_relative=true; action_whatever()". Which works fine normally but it doesn't work when the if action is used without the block actions! as this happens:
"if (false) argument_relative=true; action_whatever()"
So it still calls action_whatever even although it shouldn't. I think a similar thing happens with the "with" statement.
It might be better to pass argument_relative into the function as a parameter that has a default value (so it is optional incase its used in normal gml).
Before it calls any action it writes the code "argument_relative=true; action_whatever()". Which works fine normally but it doesn't work when the if action is used without the block actions! as this happens:
"if (false) argument_relative=true; action_whatever()"
So it still calls action_whatever even although it shouldn't. I think a similar thing happens with the "with" statement.
It might be better to pass argument_relative into the function as a parameter that has a default value (so it is optional incase its used in normal gml).
38
Proposals / Re: Function approval process
« on: February 28, 2011, 09:56:31 am »
Yes I agree I think we do need a much better system for approving functions. The problem I can see with using the forum is that only certain people (moderators) can edit topics and move the topics around, which is alot of work that could be spend on development.
Also another problem is that in a forum topic the useful information is spread across many different posts so information is easy to miss.
I was thinking you could use the wiki for this purpose. Have a page that lists all the unimplemented functions, each function is a link to a wiki page for that function.
You can put wiki pages into different categories like "Testing", "To be committed", "Faulty" etc. The developers can easily just look through the categories and put the "To be committed" in svn etc.
The page could allow developers implementing the functions to share information like test cases, problems with the current implementation, optimizations etc.
When the function is complete the page can simply become the documentation page for that function. The implementation details could either be removed or could provide helpful information for functions that don't have documentation yet.
Forum topics would still be useful for discussion about functions though.
Also another problem is that in a forum topic the useful information is spread across many different posts so information is easy to miss.
I was thinking you could use the wiki for this purpose. Have a page that lists all the unimplemented functions, each function is a link to a wiki page for that function.
You can put wiki pages into different categories like "Testing", "To be committed", "Faulty" etc. The developers can easily just look through the categories and put the "To be committed" in svn etc.
The page could allow developers implementing the functions to share information like test cases, problems with the current implementation, optimizations etc.
When the function is complete the page can simply become the documentation page for that function. The implementation details could either be removed or could provide helpful information for functions that don't have documentation yet.
Forum topics would still be useful for discussion about functions though.
39
Announcements / Re: Happenings
« on: January 30, 2011, 07:27:24 am »Quote
As for the GLES folder, ask TGMG. He thought it would become necessary; we haven't seen it be so yet.Well without that folder enigma iphone/android games wouldn't work so it is very necessary for phone development. It contains the same files as it as alot of opengl code is the same, but many features have to be rewritten for opengles (no glbegin/glend for example).
40
Function Peer Review / Re: file_delete
« on: December 31, 2010, 09:50:53 am »
All of them it looks like since this is what file_manip.cpp looks like:
Code: [Select]
int file_exists(std::string fname);
int file_delete(std::string fname);
int file_rename(std::string oldname,std::string newname);
int file_copy(std::string fname,std::string newname);
int directory_exists(std::string dname);
int directory_create(std::string dname);
std::string file_find_first(std::string mask,int attr);
enum {
fa_readonly = 1,
fa_hidden = 2,
fa_sysfile = 4,
fa_volumeid = 8,
fa_directory = 16,
fa_archive = 32
};
std::string file_find_next();
void file_find_close();
bool file_attributes(std::string fname,int attr);
std::string filename_name(std::string fname);
std::string filename_path(std::string fname);
std::string filename_dir(std::string fname);
std::string filename_drive(std::string fname);
std::string filename_ext(std::string fname);
std::string filename_change_ext(std::string fname,std::string newext);
void export_include_file(std::string fname);
void export_include_file_location(std::string fname,std::string location);
void discard_include_file(std::string fname);
extern unsigned game_id;
extern std::string working_directory;
extern std::string program_directory;
extern std::string temp_directory;
int parameter_count();
std::string parameter_string(int n);
std::string environment_get_variable(std::string name);
41
Issues Help Desk / Re: Segfalt with enigma compiler
« on: December 31, 2010, 07:02:47 am »
Yes they wouldn't learn anything but enigma should at least warn every time its used other wise it will lead to errors like:
if (speed=0)
Which will compile fine, but will set speed to 0 instead of checking for 0, which is actually very hard to debug, especially when you didn't write the original code.
if (speed=0)
Which will compile fine, but will set speed to 0 instead of checking for 0, which is actually very hard to debug, especially when you didn't write the original code.
42
Issues Help Desk / Re: Segfalt with enigma compiler
« on: December 29, 2010, 04:23:44 pm »
Both segfaults? I'm not sure if both games were due to the same segfault or not but the output looked different. ah yes ofc I have now linked to the 64digits page where I got each example incase the top 10 changes.
Even if lgm had a search tool which searches all the resources for a certain string. I was thinking at one point of implementing an lgm plugin which added some sort of scripting language such as jpython with functions to read and write the resource attributes, to easily implement stuff like this without putting pressure on lgm developers.
It would be useful to have a setting to add 'enigmaVariable_' to all the variables, but that would probably slow down the compiler.
IDE_EDIT_resourcenames.h is the bit I was talking about, the problem with changing them is that all references to them also have to be changed to each variable will have to be checked if it is a resource name and if so append the relevant prefix.
Even if lgm had a search tool which searches all the resources for a certain string. I was thinking at one point of implementing an lgm plugin which added some sort of scripting language such as jpython with functions to read and write the resource attributes, to easily implement stuff like this without putting pressure on lgm developers.
It would be useful to have a setting to add 'enigmaVariable_' to all the variables, but that would probably slow down the compiler.
IDE_EDIT_resourcenames.h is the bit I was talking about, the problem with changing them is that all references to them also have to be changed to each variable will have to be checked if it is a resource name and if so append the relevant prefix.
43
Issues Help Desk / Segfalt with enigma compiler
« on: December 29, 2010, 09:44:42 am »
Since I haven't been able to run enigma games on macos or iphone/android recently I decided to test how well the compile process works up to the running stage. I am really impressed with how well the enigma compiler works at the moment, with a small edit to the compiler and a definitions file which contains the empty functions that are needed for the game I was able to almost compile and link all of them. They do require certain modifications (see the errors I posted on tracker recently) such as removing switch statements, editing some of the actions, changing resource names, changing all '=' to '==' in expressions etc
So first the games that I was testing are the top 10 most downloaded on 64D:
1) Platform shooter works (works but have to change = into ==)
2) Online engine works but not server (works but requires commenting switch statements!)
3) gceffects engine (has a variable called write/index! didn't finish replacing all variables)
4) real water (linker error)
5) Jenners platform engine ( works but have to change = into ==,has a variable named free!)
6) Skidmark all (normal and unreg) works (but have to change = into ==)
7) Online highscores (compiles successfully)
8) Dndexample works (drag and drop objects)
9) physics engine v2 (compiles but 2 linker errors sprite_add and _working_directory)
10) segfaults the enigma compiler
I haven't listed all the errors in the brackets as most have the = to == and require the switch statement removal.
But a few really annoying things kept creeping up, first variable names, alot of game maker games use variables with names like 'index' 'write' 'pow' which won't work in enigma as they have been defined by something else. I gave up replacing all the variable names in the gceffects engine as there was so many.
Another annoying thing is the way people name there resources, some are c++ keywords like 'catch' other contain spaces and more often the sprites have the same name as the objects etc. Which causes a compile error which would be very confusing to new users.
Anyway onto the segfaults, you will need these definitions files to test all of them:
actions: http://enigma.pastebin.com/tBZvy2C6
others: http://enigma.pastebin.com/5JLTHQj8
They also require a change to the enigma compiler:
added to compile.cpp under the rest of them:
Now the files:
ackack: http://dl.dropbox.com/u/5072558/segfaulting/ENIGMA_ackackenginev1.7.gm6
server: http://dl.dropbox.com/u/5072558/segfaulting/Enigma_Online%20Engine%20Server.gm6
ackackengine gives:
online server gives:
Next i'm going to try and look into all the errors that I posted on the tracker and try and fix them if possible, although just the enigma plugin ones related to actions, would have no idea how to implement the parser ones (== and switch statements), and then hopefully do the next 10 which I hope will go much smoother.
So first the games that I was testing are the top 10 most downloaded on 64D:
1) Platform shooter works (works but have to change = into ==)
2) Online engine works but not server (works but requires commenting switch statements!)
3) gceffects engine (has a variable called write/index! didn't finish replacing all variables)
4) real water (linker error)
5) Jenners platform engine ( works but have to change = into ==,has a variable named free!)
6) Skidmark all (normal and unreg) works (but have to change = into ==)
7) Online highscores (compiles successfully)
8) Dndexample works (drag and drop objects)
9) physics engine v2 (compiles but 2 linker errors sprite_add and _working_directory)
10) segfaults the enigma compiler
I haven't listed all the errors in the brackets as most have the = to == and require the switch statement removal.
But a few really annoying things kept creeping up, first variable names, alot of game maker games use variables with names like 'index' 'write' 'pow' which won't work in enigma as they have been defined by something else. I gave up replacing all the variable names in the gceffects engine as there was so many.
Another annoying thing is the way people name there resources, some are c++ keywords like 'catch' other contain spaces and more often the sprites have the same name as the objects etc. Which causes a compile error which would be very confusing to new users.
Anyway onto the segfaults, you will need these definitions files to test all of them:
actions: http://enigma.pastebin.com/tBZvy2C6
others: http://enigma.pastebin.com/5JLTHQj8
They also require a change to the enigma compiler:
added to compile.cpp under the rest of them:
Code: [Select]
wto << "enum //font names\n{\n";
for (int i = 0; i < es->fontCount; i++)
wto << " " << es->fonts[i].name << " = " << es->fonts[i].id << ",\n";
wto << "};\n\n";
wto << "enum //timeline names\n{\n";
for (int i = 0; i < es->timelineCount; i++)
wto << " " << es->timelines[i].name << " = " << es->timelines[i].id << ",\n";
wto << "};\n\n";
wto << "enum //path names\n{\n";
for (int i = 0; i < es->pathCount; i++)
wto << " " << es->paths[i].name << " = " << es->paths[i].id << ",\n";
wto << "};\n\n";
Now the files:
ackack: http://dl.dropbox.com/u/5072558/segfaulting/ENIGMA_ackackenginev1.7.gm6
server: http://dl.dropbox.com/u/5072558/segfaulting/Enigma_Online%20Engine%20Server.gm6
ackackengine gives:
Quote
Writing modes and settings
Writing object switch
Writing resource names and maxima
Writing events
Checking for default code in ev[2, 0.
Checking for default code in ev[0, 0.
Checking for default code in ev[8, 0.
Checking for default code in ev[6, 50.
Checking for default code in ev[5, 86.
Checking for default code in ev[9, 88.
Checking for default code in ev[6, 4.
Checking for default code in ev[7, 5.
Checking for default code in ev[3, 0.
Checking for default code in ev[7, 10.
Invalid memory access of location 0x28 rip=0x7fff84df19bf
Segmentation fault
online server gives:
Quote
>> Searching for `global` in globj->locals (19 entries)
{ acc_id, argument0, argument1, argument2, argument3, argument4, argument5, argument6, argument7, dll_cdecl, i, keyboard_string, name, pid, servertcp, tcp, ty_real, ty_string, username, end }
Typeless
Invalid memory access of location 0x0 rip=0x7fff84df20aa
Next i'm going to try and look into all the errors that I posted on the tracker and try and fix them if possible, although just the enigma plugin ones related to actions, would have no idea how to implement the parser ones (== and switch statements), and then hopefully do the next 10 which I hope will go much smoother.
44
Proposals / Re: Additions to new platform system
« on: December 29, 2010, 04:39:23 am »
Well it doesn't have to specify the makefile location I suppose the plugin could just look in the platforms folder for it, it was just because a few platforms might share the same makefile so ti would reduce the need for more than 1 of the exact same makefile. Also so in the future if a makefile has to be in a specific path for whatever reason no edits need to be made to the plugin/compiler. Also it would be pretty easy to change the makefile to test changes without modifying the proper one.
I also don't know how iphone compiling for mac/linux might work in the future so allowing a different makefile for the same platform could help keep things more organised instead of having a very different makefile for win/linux inside the same makefile for mac just to compile for iphone.
I also don't know how iphone compiling for mac/linux might work in the future so allowing a different makefile for the same platform could help keep things more organised instead of having a very different makefile for win/linux inside the same makefile for mac just to compile for iphone.
45
Proposals / Re: Additions to new platform system
« on: December 28, 2010, 02:46:28 am »
I have edited compilers (http://enigma-dev.org/docs/wiki/index.php?title=Compilers/) with what i think should be added into the .ey file. With those changes it should as far as I can see allow all the compilers I know about.
MacOsX (Data file name will be "game.app/Contents/MacOS/enigma", makefile similar to current make file but with "-o <RelativePathWhichICan'tRemember>/game.app/Contents/enigma" and no need for bin path)
Android (Data file name will be "<RelativePathWhichICan'tRemember>/jni/libenigma.so", make file will be completely custom, bin path will be the path to the crystax ndk)
Iphone (Data file name will be "<RelativePathWhichICan'tRemember>/game.app/gamedata.data", makefile will call xcodebuild so completely custom, bin path won't be needed)
PSP (Data file name will be "<RelativePathWhichICan'tRemember>/gamedata.data", makefile will be custom, bin path will be psp sdk path)
DS (Data will be handled differently so no data file, makefile will be custom, bin path will be ds sdk path)
I haven't looked into ps3 yet but I think it will be similar to psp from what I have seen, Nativeclient will be similar to android esp with the bin path and makefile but i am not sure how it will handle the data file yet.
MacOsX (Data file name will be "game.app/Contents/MacOS/enigma", makefile similar to current make file but with "-o <RelativePathWhichICan'tRemember>/game.app/Contents/enigma" and no need for bin path)
Android (Data file name will be "<RelativePathWhichICan'tRemember>/jni/libenigma.so", make file will be completely custom, bin path will be the path to the crystax ndk)
Iphone (Data file name will be "<RelativePathWhichICan'tRemember>/game.app/gamedata.data", makefile will call xcodebuild so completely custom, bin path won't be needed)
PSP (Data file name will be "<RelativePathWhichICan'tRemember>/gamedata.data", makefile will be custom, bin path will be psp sdk path)
DS (Data will be handled differently so no data file, makefile will be custom, bin path will be ds sdk path)
I haven't looked into ps3 yet but I think it will be similar to psp from what I have seen, Nativeclient will be similar to android esp with the bin path and makefile but i am not sure how it will handle the data file yet.