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 »
1711
Off-Topic / Re: Some guy working since 1987 SPEAKS OUT!!!!!!
« on: September 17, 2010, 06:16:15 pm »
Aware. The compilation speed issues definitely fall on GCC. And such is indeed out of my power to fix. It doesn't help that I don't ship ENIGMA with precompiled object files. That much needs to be improved on, and will need to be very shortly as people start compiling for more platforms. I need to keep a folder of objects for each device, at very least.
Eventually I will need to invest in precompiled headers, as well.
For now, though, I've tried to use few GNU extensions that would inhibit faster compilers from being incorporated. Right now, the only function that comes to mind is lrint(), but compiler support for that seems to be good. Serp used some GNU #defines in his #ifs in various functions, which should only fail to optimize correctly on faster compilers.
Ultimately, though, GCC must do the final compilation of all projects. Despite its slower compile times, it has the widest support by those who work towards cross-compilation, and is quite consistent between platforms with its #defines and its type sizes. It is by that saving grace that I managed to compile all the audio codecs natively without huge recode.
Anyway, something about tacos.
Eventually I will need to invest in precompiled headers, as well.
For now, though, I've tried to use few GNU extensions that would inhibit faster compilers from being incorporated. Right now, the only function that comes to mind is lrint(), but compiler support for that seems to be good. Serp used some GNU #defines in his #ifs in various functions, which should only fail to optimize correctly on faster compilers.
Ultimately, though, GCC must do the final compilation of all projects. Despite its slower compile times, it has the widest support by those who work towards cross-compilation, and is quite consistent between platforms with its #defines and its type sizes. It is by that saving grace that I managed to compile all the audio codecs natively without huge recode.
Anyway, something about tacos.
1712
Off-Topic / Re: What licence for my open source project?
« on: September 13, 2010, 09:22:44 pm »
Sometimes I swear those people are writing in another language.
</OffTopic> http://creativecommons.org/choose/?lang=en_US , though I'm not a proponent of CC for code.
Really, I'd just write my own license, in your position.
</OffTopic> http://creativecommons.org/choose/?lang=en_US , though I'm not a proponent of CC for code.
Really, I'd just write my own license, in your position.
1713
Proposals / Re: Add a place for extra returns.
« on: September 13, 2010, 09:15:38 pm »
Var has a overload for cast to double&, so that would be the more accommodating choice.
1714
Announcements / Re: What's happening now
« on: September 13, 2010, 05:40:13 pm »
I'd rather wait for Ism to finish her work now, on which there is no ETA (She describes this as 'new territory,' as I was sure it would be). She hopes to have something ready this week, though. For now, I the previous file seems to be holding up.
1715
Announcements / Re: What's happening now
« on: September 13, 2010, 12:13:22 pm »
I can do backgrounds as soon as I finish this, I guess.
I'm also renaming Windows to Win32, so this could get messy pretty quick.
I'm also renaming Windows to Win32, so this could get messy pretty quick.
1716
Proposals / Re: Add a place for extra returns.
« on: September 13, 2010, 12:00:18 pm »
Then the exe size would skyrocket if it was actually used with multiple types. If a function absolutely needs to take double&, then it should. But these solutions seem a little overcomplicated for a simple multivalue return.
1717
Announcements / Re: What's happening now
« on: September 13, 2010, 09:42:26 am »
Freezway:
I can't control where the installer places OpenAL. And apparently, I can't just pack the DLLs with it, because they seem to vary from computer to computer (Most likely just from 32bit to 64bit, but I can't pack 2MB worth of Audio DLL into each game). That's why I intend to create a DirectX version of the audio system.
Plague:
Sure you can participate. In fact, I kind of need you to, since yours is one of the computers with the differently named Program Files directories.
I'll tell a2h about the edit page next I see him (if he's not already fixed it by then).
I don't really need an AL wrapper; just some better way of taking AL with ENIGMA. But AL's support isn't that great right now, so I can't just assume anyone on Windows has it installed.
I can't control where the installer places OpenAL. And apparently, I can't just pack the DLLs with it, because they seem to vary from computer to computer (Most likely just from 32bit to 64bit, but I can't pack 2MB worth of Audio DLL into each game). That's why I intend to create a DirectX version of the audio system.
Plague:
Sure you can participate. In fact, I kind of need you to, since yours is one of the computers with the differently named Program Files directories.
I'll tell a2h about the edit page next I see him (if he's not already fixed it by then).
I don't really need an AL wrapper; just some better way of taking AL with ENIGMA. But AL's support isn't that great right now, so I can't just assume anyone on Windows has it installed.
1718
Proposals / Re: Add a place for extra returns.
« on: September 13, 2010, 09:25:54 am »Code: (EDL) [Select]
struct collision_result { double x, y; };
collision_result collision_line_ext(x,y,x2,y2,obj);
...
collision_result xy = collision_line_ext(x,y,o.x,o.y,wall);
x = xy.x; y = xy.y;
What luis was suggesting is passing x and y to be modified by reference. The problem with luis's idea is that now, the arguments MUST be double or var, they can't be int or anything or it'll throw a compile error.
1719
Announcements / What's happening now
« on: September 13, 2010, 12:13:25 am »
Since I put out that zip file to test who can install ENIGMA, I've been getting feedback from all angles. Basically, a couple serious issues were corrected or are being corrected, in the order they likely surfaced:
1. ENIGMA.exe could not recognize the Program Files directory on foreign (Non-English) Windows systems. This meant that it simply couldn't find Java to run it for the user. Since %programfiles% is evidently not interpreted correctly by CreateProcess, this was fixed (in theory; I've not tested but assume it to work) by fetching the environment variable manually.
2. An invalid handle (as far as DuplicateHandle is concerned) to stdin was passed to make.exe when no console window was open. This caused make to bail for no rea reason (It doesn't actually use stdin in ENIGMA's process, or in any process of which I'm aware). Combined with the previous error, this means that if ENIGMA.exe can't find Java.exe, you can't use ENIGMA at all. This error was resolved by requesting a new (also either NULL or INVALID) handle to CONIN$, which placates make.exe (again, for no good reason).
3. D:C:\ Was an issue that surfaced when I threw kkg and some others on the IRC a fix for (1). This error lived a total of ten minutes, and was fixed by adding a NOT.
4. LateralGM exception: Cannot find ENIGMA's class. This error can only be explained by blaming the update sequence. It can be remedied simply by restarting LGM without it updating. Ism is working on a fix for it now.
5. LateralGM constantly pesters for update: Fixed.
5.5: LateralGM frequently pesters for update: This is due to a number of factors, the common ones being, as Ism said, as follow:
- An update is in fact available.
- A file has changed that is under strict version control (aka, everything that downloads when you run LGM for the first time).
- An update exists for one of the other branches. This should certainly not be notified on.
What else I've fixed/am working on:
- Fixed a couple small but annoying bugs, mostly reported by polygone. The most severe of them was a crash on missing closing comment, which originally I was going to have error, but then remembered that GML allows it and removed the check for it in syntax without taxing the parser to do that check as well.
- Am currently working on the network of flag files ENIGMA will use to identify different platforms that can be compiled for. The basic gist of them is this:
That file contains everything (so far) needed to describe OS X as a platform for which ENIGMA can compile. It is located under ENIGMAsystem/SHELL/Platforms/Cocoa/. Three other files almost identical to that one exist under the other three folders. Android is not presently supported in the repository version; TGMG will likely add it after this flagging system is finished.
Wish us luck. Especially Ism. She has a lot of crap to sort through due to such road blocks as Java lacking a "delete."
*mutters something under breath*
When all of the bugs above are fixed and re-tested by my group of victims, we will re-release the zip file. If all comes back positive, the zip will be uploaded to SourceForge, as well as the other zips/packages.
Peace.
1. ENIGMA.exe could not recognize the Program Files directory on foreign (Non-English) Windows systems. This meant that it simply couldn't find Java to run it for the user. Since %programfiles% is evidently not interpreted correctly by CreateProcess, this was fixed (in theory; I've not tested but assume it to work) by fetching the environment variable manually.
2. An invalid handle (as far as DuplicateHandle is concerned) to stdin was passed to make.exe when no console window was open. This caused make to bail for no rea reason (It doesn't actually use stdin in ENIGMA's process, or in any process of which I'm aware). Combined with the previous error, this means that if ENIGMA.exe can't find Java.exe, you can't use ENIGMA at all. This error was resolved by requesting a new (also either NULL or INVALID) handle to CONIN$, which placates make.exe (again, for no good reason).
3. D:C:\ Was an issue that surfaced when I threw kkg and some others on the IRC a fix for (1). This error lived a total of ten minutes, and was fixed by adding a NOT.
4. LateralGM exception: Cannot find ENIGMA's class. This error can only be explained by blaming the update sequence. It can be remedied simply by restarting LGM without it updating. Ism is working on a fix for it now.
5. LateralGM constantly pesters for update: Fixed.
5.5: LateralGM frequently pesters for update: This is due to a number of factors, the common ones being, as Ism said, as follow:
- An update is in fact available.
- A file has changed that is under strict version control (aka, everything that downloads when you run LGM for the first time).
- An update exists for one of the other branches. This should certainly not be notified on.
What else I've fixed/am working on:
- Fixed a couple small but annoying bugs, mostly reported by polygone. The most severe of them was a crash on missing closing comment, which originally I was going to have error, but then remembered that GML allows it and removed the check for it in syntax without taxing the parser to do that check as well.
- Am currently working on the network of flag files ENIGMA will use to identify different platforms that can be compiled for. The basic gist of them is this:
Code: (e-yaml) [Select]
%e-yaml
---
Name: Mac OS X
Identifier: Cocoa
Represents: MacOSX
Description: Run on Apple Mac OS X, or other Cocoa-enabled Apple systems.
Author: TGMG
Build-Platforms: MacOSX
Run-Program: open
Run-Params: $game
That file contains everything (so far) needed to describe OS X as a platform for which ENIGMA can compile. It is located under ENIGMAsystem/SHELL/Platforms/Cocoa/. Three other files almost identical to that one exist under the other three folders. Android is not presently supported in the repository version; TGMG will likely add it after this flagging system is finished.
Wish us luck. Especially Ism. She has a lot of crap to sort through due to such road blocks as Java lacking a "delete."
*mutters something under breath*
When all of the bugs above are fixed and re-tested by my group of victims, we will re-release the zip file. If all comes back positive, the zip will be uploaded to SourceForge, as well as the other zips/packages.
Peace.
1720
Off-Topic / Re: Slow compile times for C++?
« on: September 12, 2010, 11:43:10 am »
Oh, there's definitely room to be improved upon from C++. The language would be ten times better if they dumped most of the old, unneeded parts of the C spec. But to claim that a group of languages sharing on common trait is, in general, faster at compile, load, and run than languages of other groups, is asinine.
1721
Off-Topic / Re: Slow compile times for C++?
« on: September 12, 2010, 10:22:08 am »
Wow! Better compile AND load time?!
Still, they can't compete with C++'s sourceless residuum of grandeur.
Still, they can't compete with C++'s sourceless residuum of grandeur.
1722
Function Peer Review / Re: GML: draw_sprite_tiled + draw_sprite_tiled_ext (unfinished)
« on: September 10, 2010, 02:45:18 pm »
Works for me. I figure at some point I'll have to break down and add an if() for it, anyway.
1723
Function Peer Review / Re: Instance Interface How-to
« on: September 10, 2010, 12:41:20 pm »
If you feel you can, go for it. I forget where I left off with backgrounds; they may or may not be loaded properly. See backgroundinit.cpp.
Looks like I left off after checking how many backgrounds there are. I can finish that file later today.
If you are operating from "Stable," I suggest you unzip and run again, marking "Trunk" and "I'm a dev, don't touch my changes."
If you check out from the trunk, you'll be informed of an update every time I commit something new.
Looks like I left off after checking how many backgrounds there are. I can finish that file later today.
If you are operating from "Stable," I suggest you unzip and run again, marking "Trunk" and "I'm a dev, don't touch my changes."
If you check out from the trunk, you'll be informed of an update every time I commit something new.
1724
Announcements / Re: ENIGMA R4
« on: September 10, 2010, 12:14:06 pm »
Heh, I suppose, but then we'd need to maintain a manifest of correct directories. Which is hard to decide on.
1725
Function Peer Review / Re: GML: draw_sprite_tiled + draw_sprite_tiled_ext (unfinished)
« on: September 10, 2010, 12:10:32 pm »
'fraid I have to deny those. They're unimplemented for a reason. Create a 48*48 sprite and try your functions; you won't like the results. But for power-of-two textures, that will work fine. See the issue?
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 »