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 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 145 146 147 148 149 150 151 152 153 154 155 156 157 158 159 160 161 162 163 164 165 166 167 168 169 170 171 172 173 174 175 176 177 178 179 180 181 182 183 184 185 186 187 188 »
1771
Proposals / Re: Optimize it
« on: August 26, 2010, 11:18:57 pm »
My biggest suggestions are to reduce your draw_set_color() calls (by calling one up front of the loop instead of letting the graphics system call the equivalent literally 80,000 times) and to use C++ types more often.
I noticed your implementation has a few workarounds in it. I will do my best to remove the need for such. I have already made one improvement to allow further optimization of your game. Please check out the latest revision.
I have implemented my suggestions here:
http://dl.dropbox.com/u/1052740/watersimulation.gmk
Cheers.
I noticed your implementation has a few workarounds in it. I will do my best to remove the need for such. I have already made one improvement to allow further optimization of your game. Please check out the latest revision.
I have implemented my suggestions here:
http://dl.dropbox.com/u/1052740/watersimulation.gmk
Cheers.
1772
Proposals / Re: GM Function Implementations
« on: August 25, 2010, 03:21:41 pm »
RetroX:
In whitespace:
#define action_if(x) if (x)
#define action_draw_arrow draw_arrow
#define create_object instance_create
int action_draw_life(int x, int y, int spr) {
for (int i = 0; i < life; i++)
draw_sprite(spr,0,x + i*sprite_get_width(spr), y);
}
etc.
Note: that draw_life one won't work as-is; it's just a demonstration. Let me set up an API to make that easy for typical users, and I'll update this with it.
In whitespace:
#define action_if(x) if (x)
#define action_draw_arrow draw_arrow
#define create_object instance_create
int action_draw_life(int x, int y, int spr) {
for (int i = 0; i < life; i++)
draw_sprite(spr,0,x + i*sprite_get_width(spr), y);
}
etc.
Note: that draw_life one won't work as-is; it's just a demonstration. Let me set up an API to make that easy for typical users, and I'll update this with it.
1773
General ENIGMA / Re: Help File?
« on: August 23, 2010, 06:39:59 pm »
HaRRiKiRi:
The function list page (however outdated) will allow you to submit a description.
The function list page (however outdated) will allow you to submit a description.
1774
General ENIGMA / Re: Help File?
« on: August 23, 2010, 04:15:35 pm »
ENIGMA Will do no such thing. A warning is thrown if the variable is not an ENIGMA type, and the value is truncated.
1775
Announcements / Re: Where do we stand?
« on: August 23, 2010, 11:33:38 am »
IsmAvatar:
As on Unix, a beginning \ denotes root of the drive on Windows. So when you see \, just replace with the current drive letter if Java can't.
We'll discuss the updating on the IRC, if both of you are on.
As on Unix, a beginning \ denotes root of the drive on Windows. So when you see \, just replace with the current drive letter if Java can't.
We'll discuss the updating on the IRC, if both of you are on.
1776
Announcements / Re: Where do we stand?
« on: August 23, 2010, 01:40:15 am »
Also, Ism. When winmake.txt reads this:
\MinGW\bin\mingw32-make.exe
Java can't find it. I don't know what Java uses to make system calls, but it's apparently bad at life. Could you try to remedy that?
Also, seems the gray, open console box is fixed in the latest revision.
\MinGW\bin\mingw32-make.exe
Java can't find it. I don't know what Java uses to make system calls, but it's apparently bad at life. Could you try to remedy that?
Also, seems the gray, open console box is fixed in the latest revision.
1777
Announcements / Where do we stand?
« on: August 23, 2010, 01:35:44 am »
I decided to implement backgrounds in the meantime, and dazappa has kept me busy with a number of interesting bug reports (the worst of which I have just worked out). I am not sure what is in the update-stable/ tag, but fixing it to actually work out of the box on at least Windows and Linux is priority one.
Ism has made great progress on the updater. From what I can tell it is finished, though it has an odd tendency to leave a console window open with a gray background for me.
RetroX has finished some packages, but we were discussing what the package should be responsible for vs what LGM should be responsible for. I believe right now, he's configured them to give 777 permissions to /opt/enigma, where it is installed. But it seems he includes the entire repository with the package, which means users could be downloading an outdated package from square one. Correct, RetroX?
As for the Windows release, I don't even think an installer is necessary. I think a zip file containing ENIGMA.exe, lgm16b4.jar, and the plugins folder will suffice. ENIGMA.exe and LGM will take care of the rest.
If you object to not having an installer for Windows, speak now, and I or someone else will make one.
Retro, if you want to carry our discussion regarding the packages over here, please do so. Otherwise, I think ENIGMA.exe and the jar files will suffice, along with that dependency list you've already implemented.
I am going to finish dazappa's last few bug reports.
IsmAvatar, when you are content with the updater, please say so.
RetroX, when you are done with the packages, please link all of them here, and I will rehost.
The release (And frantic workarounds for everything that goes wrong soon after) will begin as soon as the three of us are done.
Ism has made great progress on the updater. From what I can tell it is finished, though it has an odd tendency to leave a console window open with a gray background for me.
RetroX has finished some packages, but we were discussing what the package should be responsible for vs what LGM should be responsible for. I believe right now, he's configured them to give 777 permissions to /opt/enigma, where it is installed. But it seems he includes the entire repository with the package, which means users could be downloading an outdated package from square one. Correct, RetroX?
As for the Windows release, I don't even think an installer is necessary. I think a zip file containing ENIGMA.exe, lgm16b4.jar, and the plugins folder will suffice. ENIGMA.exe and LGM will take care of the rest.
If you object to not having an installer for Windows, speak now, and I or someone else will make one.
Retro, if you want to carry our discussion regarding the packages over here, please do so. Otherwise, I think ENIGMA.exe and the jar files will suffice, along with that dependency list you've already implemented.
I am going to finish dazappa's last few bug reports.
IsmAvatar, when you are content with the updater, please say so.
RetroX, when you are done with the packages, please link all of them here, and I will rehost.
The release (And frantic workarounds for everything that goes wrong soon after) will begin as soon as the three of us are done.
1779
General ENIGMA / Re: Help File?
« on: August 22, 2010, 03:48:49 pm »
CHM files are just HTML, too. If LGM could this format natively, though, without further coding (in excess of an include and a call), then the format sounds perfect. Otherwise... Most platforms come with some sort of chm viewer, or at least have one easily available.
1780
General ENIGMA / Re: Help File?
« on: August 22, 2010, 11:21:17 am »
I actually started a CHM file, but then I realized that maintaining it is too large a task for any one person, so I decided to invest in an online method and a way for LGM to retrieve that text, as Ism was pointing out.
With a little luck, we'll be able to pull off a Javadoc-like system, capable of looking up info on a function while you are coding.
I may maintain a generic CHM file for learning how to use LGM and ENIGMA, becoming a developer, etc... I need to think about organization, though.
But yes, when this is settled you will be able to help by submitting descriptions for functions that work in ENIGMA. We'll see what we can do with those from there.
With a little luck, we'll be able to pull off a Javadoc-like system, capable of looking up info on a function while you are coding.
I may maintain a generic CHM file for learning how to use LGM and ENIGMA, becoming a developer, etc... I need to think about organization, though.
But yes, when this is settled you will be able to help by submitting descriptions for functions that work in ENIGMA. We'll see what we can do with those from there.
1781
Off-Topic / Re: Some guy working since 1987 SPEAKS OUT!!!!!!
« on: August 20, 2010, 09:38:41 pm »Quote
1. Trigraph and Universal character name conversion.
2. Backslash line splicing.
3. Conversion to preprocessing tokens. The Standard notes this is context dependent.
4. Preprocessing directives executed, macros expanded, #include's read and run through phases 1..4.
5. Conversion of source characters inside char and string literals to the execution character set.
6. String literal concatenation.
7. Conversion of preprocessing tokens to C++ tokens.
My parser does the first six in one pass. The seventh one is unnecessary for my purposes. Also, my compiler skips over the code inside implemented functions, and is not precise in its template instantiations. As a result, I can parse a whole lot of libraries (the entire C posix library and C++ standard template library, in addition to ENIGMA's own headers) in under a third of a second on my machine. (The libraries in question being libraries being sys/signal.h; cpio.h, dirent.h, fcntl.h, grp.h, pthread.h, pwd.h, sys/ipc.h, sys/msg.h, sys/sem.h, sys/stat.h, sys/time.h, sys/types.h, sys/utsname.h, sys/wait.h, tar.h, termios.h, unistd.h, utime.h; map, list, stack, string, vector, limits, iostream, fstream, cstdlib, cstdio, and cmath.)
I can't control how the GCC does its passes, though, and so yes, I inherit its problems, to which that list applies.
I have, however, done my best to make ENIGMA modular. The vast majority of ENIGMA is partitioned into independent modules that only need recompiled when updated.
Someone told me I should roll my own compiler, too (Not necessarily for C++, but for EDL). I could probably modify my parser to pay closer attention to templates and to tree up the code as well as the declarations, without doubling the time taken. However, I don't have what it takes to assemble and optimize all of that code myself. I believe that I could do it faster than the GCC. I have no idea that I could do it faster than Clang. But I could not do as good a job on the output as either.
Item number 5 on that man's list, though, is just the kind of thing my parser fixes.
Quote
5. The meaning of every semantic and syntactic (not just lexical) construct depends on the totality of the source text that precedes it. Nothing is context independent. There's no way to correctly preparse, or even lex, a file without looking at the #include file contents. Headers can mean different things the second time they are #include'd (and in fact, there are headers that take advantage of this).The actual function code in the headers is never necessary to assess such. The very point of my parser is, in fact, to fix that. ENIGMA reads the headers up front, extracting only type and parameter information, in order to emulate GM's speedy syntax check. The method is rough at present, but the parsers are still quite fast. They will probably increase in precision over time, as it becomes necessary for me to do accurate checks on function parameter casts.
Anyway, the point is, I have recognized these problems for a while and have done my best to deal with them. We will alwas have dependencies on the GCC (or some other competent compiler--I've been looking into ways to allow compiler trade-out for anything that supports the GNU extensions I use, which presently may just be lrint). It falls on them to implement fixes for the obvious problems.
1782
Announcements / Re: ENIGMA R4
« on: August 20, 2010, 12:24:10 pm »
God damn it, that is the stupidest fucking excuse in the book, and it's officially pissed me off, because now we have the most flaringly beautiful fallacy of accident I have ever seen.
1. Using a runtime library makes binaries smaller, WHEN MORE THAN ONE BINARY DEPENDS ON THE LIBRARY AND SO THE USER CAN BE GUARANTEED THAT IT IS ALREADY INSTALLED. I have to include a megabyte-large AL installer with ENIGMA, and if I don't do something about it, users will have to include that same installer with their games. Why? Because no one has fucking AL installed! As the sole proprietor of libcompileEGMf.so, it doesn't matter WHERE THE FUCK WE PUT IT, IT'S STILL A MEGABYTE OF DLL. Maybe if fuck-anybody had any reason to install OpenAL on Microsoft, I could happily leave AL's DLLs dynamic. But as it stands, no. one. does.
2. Putting a DLL in a system folder that would, ideally, be updated by LGM moderately frequently, is not a good idea. Sure, you can set its permissions to allow LGM to replace it, but then 20 different things have to be modified in LGM to make sure /usr/lib is what this particular operating system supports: so far, Mac has been riding Linux's coattails to functioning at the bare minimum. I'm not exactly sure what trying to write into the correct system folder would do.
1. Using a runtime library makes binaries smaller, WHEN MORE THAN ONE BINARY DEPENDS ON THE LIBRARY AND SO THE USER CAN BE GUARANTEED THAT IT IS ALREADY INSTALLED. I have to include a megabyte-large AL installer with ENIGMA, and if I don't do something about it, users will have to include that same installer with their games. Why? Because no one has fucking AL installed! As the sole proprietor of libcompileEGMf.so, it doesn't matter WHERE THE FUCK WE PUT IT, IT'S STILL A MEGABYTE OF DLL. Maybe if fuck-anybody had any reason to install OpenAL on Microsoft, I could happily leave AL's DLLs dynamic. But as it stands, no. one. does.
2. Putting a DLL in a system folder that would, ideally, be updated by LGM moderately frequently, is not a good idea. Sure, you can set its permissions to allow LGM to replace it, but then 20 different things have to be modified in LGM to make sure /usr/lib is what this particular operating system supports: so far, Mac has been riding Linux's coattails to functioning at the bare minimum. I'm not exactly sure what trying to write into the correct system folder would do.
1783
Announcements / Re: ENIGMA R4
« on: August 19, 2010, 04:13:32 pm »
Make is the longest part *on your connection.
1784
General ENIGMA / Re: Someone should
« on: August 17, 2010, 02:59:10 pm »
My proposals are, since I am now in the clear of being the "first person" and therefore likewise clear of being shot, as follows:
ENIGMA vector:
http://dl.dropbox.com/u/1052740/elogo.svg
ENIGMA vector:
http://dl.dropbox.com/u/1052740/elogo.svg
1785
Announcements / Re: Enigma on all platforms
« on: August 17, 2010, 02:04:35 pm »
Brett: IsmAvatar is working on that one. Assuming she's working on anything right now; I haven't bothered her about it lately.
Ism: Are you working on that right now?
Ism: Are you working on that right now?
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 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 145 146 147 148 149 150 151 152 153 154 155 156 157 158 159 160 161 162 163 164 165 166 167 168 169 170 171 172 173 174 175 176 177 178 179 180 181 182 183 184 185 186 187 188 »