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 »
1366
Issues Help Desk / Re: Android anyone?
« on: May 16, 2011, 09:59:23 am »
Oh, quit teasing him.
Freedom:
Open Compilers/YOURPLATFORM/ and make a copy of the file in Compilers/MacOSX/gcc.ey there. Then just change this line:
Target-platform: MacOSX
To say Android instead, like so:
Target-platform: Android
You will also need to change this line:
resources: $exe
But I'm not sure where TGMG wants the resources written, so I can't help you with that part.
It should work if you've set everything else up right. If you get the resource location wrong, it just won't be able to load them, and you'll have to use simpler drawing functions until TGMG does something about it.
Freedom:
Open Compilers/YOURPLATFORM/ and make a copy of the file in Compilers/MacOSX/gcc.ey there. Then just change this line:
Target-platform: MacOSX
To say Android instead, like so:
Target-platform: Android
You will also need to change this line:
resources: $exe
But I'm not sure where TGMG wants the resources written, so I can't help you with that part.
It should work if you've set everything else up right. If you get the resource location wrong, it just won't be able to load them, and you'll have to use simpler drawing functions until TGMG does something about it.
1367
Function Peer Review / Re: GML: All draw_text functions +(string_width, _height, _width_ext, _height_ext)
« on: May 12, 2011, 12:56:34 pm »
HaRRi: That's because the offsets I calculate in the texture are relative to the baseline rather than to the bottommost point on any glyph or the topmost. You are simply adding the height of the glyph to the supplied "y" coordinate of draw_text. You should instead be adding the difference between the topmost point of the tallest glyph and the baseline.
I will add a calculation for the aforementioned value, which you will use to offset the supplied "y".
IsmAvatar: No further action is required of you.
I will add a calculation for the aforementioned value, which you will use to offset the supplied "y".
IsmAvatar: No further action is required of you.
1368
Issues Help Desk / Re: Help with GM's instance ID system
« on: May 08, 2011, 11:15:26 am »
Yes.
1369
Issues Help Desk / Re: Unable to Run (me too)
« on: May 04, 2011, 08:42:58 pm »
You are using the repo marked "Stable," right, Fred?
1370
Proposals / Re: EGM format: Allow resources in other folders?
« on: May 03, 2011, 01:20:02 pm »
Correct.
1371
Proposals / Re: EGM format: Allow resources in other folders?
« on: May 03, 2011, 12:53:20 pm »
It'd default to the correct folder, Luis.
1372
Proposals / Re: EGM format: Allow resources in other folders?
« on: May 02, 2011, 08:54:41 pm »
By "reference by folder and by resource", I meant that our "References" folder would be able to include a reference to a Resource or to an entire folder of Resources, meaning that when resources were added to or removed from the referenced folder, the referenced version would reflect such.
1373
Proposals / Re: Object grouping
« on: May 02, 2011, 08:45:04 pm »
RetroX: We will be using ey. The spec mentions INI because we want it relatable.
1374
Proposals / Re: EGM format: Allow resources in other folders?
« on: May 02, 2011, 03:11:31 pm »
Are you opposed to keeping a miscellanea folder under the tree that contains all types of resources by reference?
This would solve all our problems without hurting the format's integrity (or making it a magic trick to assess).
It'd also make our mass-(ex/)import resource functions look more deliberate and driven.
Allowing reference by folder and by resource would kick ass.
Then I could just be like, resources_free("Brinstar"), resources_load("Crateria");
This would solve all our problems without hurting the format's integrity (or making it a magic trick to assess).
It'd also make our mass-(ex/)import resource functions look more deliberate and driven.
Allowing reference by folder and by resource would kick ass.
Then I could just be like, resources_free("Brinstar"), resources_load("Crateria");
1375
Proposals / Re: EGM format: Allow resources in other folders?
« on: May 02, 2011, 02:50:38 pm »
I won't vote, but HaRRi's thoughts are my initilal thoughts exactly. However, I think we should consider the changes to the format and to the future first.
I think we'll all agree that allowing it would overcomplicate our format in one way or another, but that doing so is acceptable so long as it provides a useful advantage. The issue is, it may in fact deprive us of an advantage.
The use case HaRRi mentioned is nice, but I'm thinking that a right-click context feature to locate dependencies elsewhere in the tree would supplement it in most cases. What the change in scheme could take from us is a plan I had for resource management.
I mentioned in another thread that I had plans to allow storing resources externally, and loading/freeing them by tree directory name. How does that fit into this new hierarchy? Would we still offer the functions, but allow specifying the entire resource directory? Would we use a reference system that enabled it to be referenced by the correct base node? This needs to be considered before we make any decisions on the matter.
I think we'll all agree that allowing it would overcomplicate our format in one way or another, but that doing so is acceptable so long as it provides a useful advantage. The issue is, it may in fact deprive us of an advantage.
The use case HaRRi mentioned is nice, but I'm thinking that a right-click context feature to locate dependencies elsewhere in the tree would supplement it in most cases. What the change in scheme could take from us is a plan I had for resource management.
I mentioned in another thread that I had plans to allow storing resources externally, and loading/freeing them by tree directory name. How does that fit into this new hierarchy? Would we still offer the functions, but allow specifying the entire resource directory? Would we use a reference system that enabled it to be referenced by the correct base node? This needs to be considered before we make any decisions on the matter.
1376
Proposals / Re: ENIGMA Game Format
« on: April 27, 2011, 12:23:16 am »
Or, say, a layered PNG? Most of the reasoning behind the PNG spec is how extensible it is. We could easily invest in a reader-friendly way to animate PNG.
1377
Announcements / Re: Wiki down
« on: April 27, 2011, 12:21:31 am »
Also, Design Mode is almost ready to go.
1378
Proposals / Re: ENIGMA Game Format
« on: April 26, 2011, 11:21:57 pm »
If they had the contents sorted by name, they would open the directory to find a list of pairs of text and binary files. sprite0.ey, sprite0.png, sprite1.ey, sprite1.png. It'd look fine, and it'd save moving back and forth between folders to make sure both are correct.
1379
Proposals / Re: ENIGMA Game Format
« on: April 26, 2011, 08:21:03 pm »
Why do we need a data and settings directory? They should just be thrown into the resource's directory, with a manifest file.
1380
Proposals / Re: ENIGMA Project Icons
« on: April 26, 2011, 11:02:58 am »
I say we forgo all else and make all GM-format logos as follows:
GM6:
GM7:
GM8:
As for the EGM logo, maybe someone with even greater artistic talent than hither displayed could glue together the ENIGMA or LGM logo and a zipper. Maybe the LGM logo could be one half, the ENIGMA logo the other, with a zipper in between. I don't know.
As for the game logo, GM used a red ball; I say we use a blue ball. Maybe a shiny Cinema4D rendered blue ball (by which I mean, the ENIGMA logo SVG sans the fancy e).
GM6:
GM7:
GM8:
As for the EGM logo, maybe someone with even greater artistic talent than hither displayed could glue together the ENIGMA or LGM logo and a zipper. Maybe the LGM logo could be one half, the ENIGMA logo the other, with a zipper in between. I don't know.
As for the game logo, GM used a red ball; I say we use a blue ball. Maybe a shiny Cinema4D rendered blue ball (by which I mean, the ENIGMA logo SVG sans the fancy e).
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 »