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 »
992
Proposals / Reintroduction of build mode
« on: September 13, 2012, 02:33:54 pm »
I need reports on a successful widget system from each platform. Widgets have not stopped working on Linux, to my knowledge, provided the correct GTK packages are installed. However, they don't work on Windows due to problems with the outdated windres.exe, to which I have still not heard an end, and they also do not work on Mac without serious poking, I imagine.
So I need TGMG or another similarly capable Mac developer to write Cocoa equivalents for the Win32 widget functions (if the Cocoa API is free-form like Windows) or to the GTK widget functions (if Cocoa is more like GTK). I stress this difference because the Windows widget functions have a function which behaves like the layout managers in wx, GTK, and Java Swing: It is capable of ordering items into a table for the existing layout option.
So get widgets working, people. I've coded what I can; we just need windres and a cocoa port.
After that, I'll need collaboration from IsmAvatar to actually set it back up as it once was.
If you're wondering what build mode is, it's a secret.
So I need TGMG or another similarly capable Mac developer to write Cocoa equivalents for the Win32 widget functions (if the Cocoa API is free-form like Windows) or to the GTK widget functions (if Cocoa is more like GTK). I stress this difference because the Windows widget functions have a function which behaves like the layout managers in wx, GTK, and Java Swing: It is capable of ordering items into a table for the existing layout option.
So get widgets working, people. I've coded what I can; we just need windres and a cocoa port.
After that, I'll need collaboration from IsmAvatar to actually set it back up as it once was.
If you're wondering what build mode is, it's a secret.
993
Proposals / Static Sprites
« on: September 13, 2012, 02:22:40 pm »
An idea you'll find in non-GM game development suites is static sprites. Mechanistically, they're sprites that you place at a fixed (static) position in the room. Essentially, they are animated tiles. This is 90% UI related, or I'd probably just throw it in without ever writing up a proposal. LGM's tile editor is sad as it stands, and so is ENIGMA's tile implementation (no offense to TGMG, who just wanted something in that worked).
Ideally, they'll be placed at a certain depth using the tile editor. We'd want a way to set their coordinates, animation speed, and maybe scale/rotation.
Ideally, they'll be placed at a certain depth using the tile editor. We'd want a way to set their coordinates, animation speed, and maybe scale/rotation.
994
Proposals / Re: Arrays
« on: September 13, 2012, 02:19:11 pm »
This is an EDL feature; the expectation is that the user will distinguish those two with the use of a semicolon. However, if you have an idea to eliminate that, let's hear it.
995
Proposals / Re: Named loops vs numbered breaks
« on: September 13, 2012, 02:18:07 pm »
I see both sides. I'm pretty sure I'll end up doing both; the mechanism that handles the double break will be the same, so the difference between the two implementations C++-side will be in identifying the loop to which the user is referring.
996
I doubt anyone would disagree that ENIGMA needs arrays. What I'm proposing is that rather than inherit array syntax from C++, we take a page out of the JavaScript playbook and denote them with [].
I want to use [] for a couple reasons. First, of course, is that [1, 2, 3][1] looks neater than {1,2,3}[1]. That was a joke; I don't give a shit about that. What I want to allow is this sort of syntax:
Using {} for arrays, {x,y} would be ambiguous; it could be a new scope which uses x and y, or it could be our assignment array. There would be next to no way to distinguish the two, so it's out of the question if we want the assignment array.
As for the dynamics, when compiling to C, this is what it would look like:
In the [a,b,c]=array_func() case:
In the [a,b,c] = scalar_func() special case:
As for building an array, that's easy. Old ENIGMA can do that. [expression1, expression2, expression3] simply becomes this:
[snip=cpp](Array(3).put(0,expression1).put(1,expression2).put(2,expression3))[/snip]
Where [snip]Array(int N)[/snip] reserves N variants, and [snip]Array& Array::put(int, variant)[/snip] is the same as [snip]Array::operator[](int)::operator=(variant)[/snip].
I want to use [] for a couple reasons. First, of course, is that [1, 2, 3][1] looks neater than {1,2,3}[1]. That was a joke; I don't give a shit about that. What I want to allow is this sort of syntax:
Code: (EDL) [Select]
[x, y] = [y, x] // Switches the values of x and y
[x, y] = get_some_coordinates(); // Fetches a length-2 array of coordinates, assign
Using {} for arrays, {x,y} would be ambiguous; it could be a new scope which uses x and y, or it could be our assignment array. There would be next to no way to distinguish the two, so it's out of the question if we want the assignment array.
As for the dynamics, when compiling to C, this is what it would look like:
In the [a,b,c]=array_func() case:
Code: (cpp) [Select]
{
Array tmp = array_func(); // This is copied verbatim
switch (tmp.length) { default: // Array size is size_t; must be >= 0
case 3: c = tmp[3]; // Waterfall
case 2: b = tmp[2];
case 1: a = tmp[1];
case 0: ;
}
}
In the [a,b,c] = scalar_func() special case:
Code: (cpp) [Select]
c = b = a = scalar_func();
As for building an array, that's easy. Old ENIGMA can do that. [expression1, expression2, expression3] simply becomes this:
[snip=cpp](Array(3).put(0,expression1).put(1,expression2).put(2,expression3))[/snip]
Where [snip]Array(int N)[/snip] reserves N variants, and [snip]Array& Array::put(int, variant)[/snip] is the same as [snip]Array::operator[](int)::operator=(variant)[/snip].
997
Proposals / Re: Sprite sheets
« on: September 13, 2012, 01:44:43 pm »
A sprite sheet would contain m subimages from n sprites, m >= n. Maybe the user wants one sprite sheet per sprite, maybe they want the entire world on one sheet (and maybe it's efficient to do so!).
I believe the better word for what I am describing is a "texture map." I am not sure if they are genuinely synonymous, but I figured more people here would know what a sprite sheet looked like. What I'm really referring to looks something like this:
I believe the better word for what I am describing is a "texture map." I am not sure if they are genuinely synonymous, but I figured more people here would know what a sprite sheet looked like. What I'm really referring to looks something like this:
998
Proposals / Re: Named loops vs numbered breaks
« on: September 13, 2012, 01:41:05 pm »
I'd warn/error on break 0, too.
It's easier to to read break 2, in my opinion; even if you're in a huge nested loop, you have an idea of how many loops you're in, whereas you can easily forget what a loop is named. Granted, you can assume it breaks the big one or huge one based on context, but with break 3, you know it's breaking all of them.
It's easier to to read break 2, in my opinion; even if you're in a huge nested loop, you have an idea of how many loops you're in, whereas you can easily forget what a loop is named. Granted, you can assume it breaks the big one or huge one based on context, but with break 3, you know it's breaking all of them.
999
Proposals / Re: Resource group load/save functions
« on: September 13, 2012, 01:37:54 pm »
I should have clarified; I intended the non-threaded load to wait for any threads which may be loading the resources.
So during a cutscene, you would call the thread version, but after the cutscene, you would call the non-threaded version and it would make sure the load finished before returning.
So during a cutscene, you would call the thread version, but after the cutscene, you would call the non-threaded version and it would make sure the load finished before returning.
1000
Proposals / Preprocessors
« on: September 13, 2012, 11:13:41 am »
Since ENIGMA supports compilation on a wide variety of platforms, and soon, a small variety of languages, it is going to become necessary to give the user a way to deal with that.
Now, C++ gives a fine way of doing that: Preprocessors. The issue with C preprocessors is that they are ugly. They must be the first thing on a line, and must consume the entire line. In EDL, we'll want to fix that.
My proposal is that preprocessors be given by [snip]{{}}[/snip]. So, if you wanted a piece of code to run only on Mac, you'd use something like this:
That will bring up the game center on iOS, or something. Ask TGMG; I really have no clue about iOS.
Now, C++ gives a fine way of doing that: Preprocessors. The issue with C preprocessors is that they are ugly. They must be the first thing on a line, and must consume the entire line. In EDL, we'll want to fix that.
My proposal is that preprocessors be given by [snip]{{}}[/snip]. So, if you wanted a piece of code to run only on Mac, you'd use something like this:
Code: [Select]
{{if ENIGMA_Platform == "ios"}} gamecenter_initialize(); {{endif}} // Initialize the game center if we're on iOS
highscore_add(name, score);
That will bring up the game center on iOS, or something. Ask TGMG; I really have no clue about iOS.
1001
Proposals / Definitions Resource
« on: September 13, 2012, 10:49:04 am »
LateralGM offers a script editor in ENIGMA settings which allows the user to specify C++ definitions. The issue is, there's only one instance, and it only supports C++. Later on, when ENIGMA supports other languages as the back end (which so far we only plan to be JavaScript), we will want another such resource. If this becomes a big part of ENIGMA, it may be frugal to offer definitions as a tabbed script resource which allows specifying definitions in each language. So one Definitions resource can contain a script full of C++, a script full of JavaScript, etc.
When you save a definitions script, a reparse will be run, and the definitions will become available to you from within EDL. It would be possible to export the definitions resource, and it would be saved with the EGM (as the existing definitions script is now).
When you save a definitions script, a reparse will be run, and the definitions will become available to you from within EDL. It would be possible to export the definitions resource, and it would be saved with the EGM (as the existing definitions script is now).
1002
Proposals / Sprite sheets
« on: September 13, 2012, 10:43:25 am »
The way I see it, there are two good ways to do sprite sheets.
1) Have a sprite sheet resource, and have sprites optionally refer to a sprite sheet.
2) Re-use the directory system.
3) Let ENIGMA just cram them together based on which fit together the best; the user can tell ENIGMA not to put the sprite in a sheet.
4) Use option 1, but provide an "Automatic" in addition to a "None" which lets ENIGMA decide.
I'm undecided on this one. I don't think I need to elaborate very much on it, as the concept is very simple. For those who are unclear, a sprite sheet is a big texture containing all the sprites. It is useful in that it saves render time due to not having to bind a new texture every time a sprite is drawn (only when sprites are on a new sheet).
The question is, how do we want the user to be able to specify that? Is it prudent to keep sprite sheets as a separate resource, or would it be too much work on the user's part?
This needs handled eventually if we want ENIGMA to make happy on mobile devices which just don't have the memory for 32,000 little tiny PO2 textures.
1) Have a sprite sheet resource, and have sprites optionally refer to a sprite sheet.
2) Re-use the directory system.
3) Let ENIGMA just cram them together based on which fit together the best; the user can tell ENIGMA not to put the sprite in a sheet.
4) Use option 1, but provide an "Automatic" in addition to a "None" which lets ENIGMA decide.
I'm undecided on this one. I don't think I need to elaborate very much on it, as the concept is very simple. For those who are unclear, a sprite sheet is a big texture containing all the sprites. It is useful in that it saves render time due to not having to bind a new texture every time a sprite is drawn (only when sprites are on a new sheet).
The question is, how do we want the user to be able to specify that? Is it prudent to keep sprite sheets as a separate resource, or would it be too much work on the user's part?
This needs handled eventually if we want ENIGMA to make happy on mobile devices which just don't have the memory for 32,000 little tiny PO2 textures.
1003
Announcements / Yet Another Renaissance
« on: September 13, 2012, 09:34:27 am »
I'm posting an announcement because people are really bad at finding buried topics on SMF. With JDI done and (mostly) working (I need to work out a problem on 32-bit machines), I am posting several proposals in the appropriate forum section.
One of them I posted early for the lulz. One of them's an old topic that still hasn't been dealt with; now might be a good time.
Dealing with nested statements: Named loops or numbered breaks?
Loading and unloading resources by name
Sprite sheets
Overworld resource
Definitions Resource
Preprocessors: {{}}
Arrays: [[1,2],[3,4]]
Static Sprites
Reintroduction of build mode
I don't have the time to post all these proposals at once. Check this topic frequently for more. (Or actually visit the Suggestions and Proposals board and see the list for yourself.)
One of them I posted early for the lulz. One of them's an old topic that still hasn't been dealt with; now might be a good time.
Dealing with nested statements: Named loops or numbered breaks?
Loading and unloading resources by name
Sprite sheets
Overworld resource
Definitions Resource
Preprocessors: {{}}
Arrays: [[1,2],[3,4]]
Static Sprites
Reintroduction of build mode
I don't have the time to post all these proposals at once. Check this topic frequently for more. (Or actually visit the Suggestions and Proposals board and see the list for yourself.)
1004
Proposals / Resource group load/save functions
« on: September 13, 2012, 09:30:51 am »
The idea is simple in concept. GM/ENIGMA users often group objects which are related spatially or temporally in the resource tree. GM games are notorious for their huge RAM consumption, and ENIGMA games can only be so much better while operating in an arbitrary CPU/RAM use constraint. So, how do we propose a solution?
Simple. Allow selecting whether resource tree groups are preloaded or not, and give a method called [snip=EDL]resource_group_load("The name of the tree item")[/snip].
Basically, the resource group "Player" and "Enemies" — and don't lie, you've used groups by this name! — will be loaded up front, as will the resource group "Terrain" in simple games, or "Overworld 1" in more complicated games. When you need resources from the second overworld, you call [snip=EDL]resource_group_unload("Overworld 1"); resource_group_load("Overworld 2");[/snip].
Now, if you're afraid that will mean in-game load time, well, your fears are justified for extremely large games. But think of it this way—all that loading would be done at the same pace up front otherwise. You've just broken it into manageable segments at worst; no one is forcing you to call the unload() function.
To solidify the proposal, I am suggesting the following methods:
Perhaps later we will want to offer functions which narrow the search to individual resource tree items.
Along with tree storage, I would like to offer a function to fetch the ID of a resource by its name, and vice-versa, then allow loading or unloading an individual resource manually by ID. Those will follow later, and are not really the concern of this proposal.
What I need from Java: A way to mark groups as preloaded.
Simple. Allow selecting whether resource tree groups are preloaded or not, and give a method called [snip=EDL]resource_group_load("The name of the tree item")[/snip].
Basically, the resource group "Player" and "Enemies" — and don't lie, you've used groups by this name! — will be loaded up front, as will the resource group "Terrain" in simple games, or "Overworld 1" in more complicated games. When you need resources from the second overworld, you call [snip=EDL]resource_group_unload("Overworld 1"); resource_group_load("Overworld 2");[/snip].
Now, if you're afraid that will mean in-game load time, well, your fears are justified for extremely large games. But think of it this way—all that loading would be done at the same pace up front otherwise. You've just broken it into manageable segments at worst; no one is forcing you to call the unload() function.
To solidify the proposal, I am suggesting the following methods:
Code: (EDL) [Select]
/** Load groups of resources with the given name in the resource tree into memory.
The group id can be from any resource folder; all matching groups will be loaded.
To narrow the ID, the forward slash "/" can be used to denote nested groups.
Hence, the string "Overworld 1" will load all resources found in any group called
Overworld 1, while the string "Enemies/Overworld 1" will load only such a group
contained in a group called Enemies.
If a resource in the group is already loaded, no action is taken for it.
The function returns only when all resources in the group are loaded.
At that time, the function returns the number of matching groups loaded. */
void resource_group_load(string group_id);
/** Unload groups of resources with the given name in the resource tree from memory.
The resource matching dynamic is identical to that of resource_group_load.
Returns the number of groups unloaded. */
void resource_group_unload(string group_id);
/** Load groups of resources with the given name in the resource tree into memory.
Very similar to resource_group_load, except it performs all loading operations in a
new thread, returning immediately. */
void resource_group_load_thread(string group_id);
Perhaps later we will want to offer functions which narrow the search to individual resource tree items.
Along with tree storage, I would like to offer a function to fetch the ID of a resource by its name, and vice-versa, then allow loading or unloading an individual resource manually by ID. Those will follow later, and are not really the concern of this proposal.
What I need from Java: A way to mark groups as preloaded.
1005
Proposals / Re: Named loops vs numbered breaks
« on: September 12, 2012, 05:20:44 pm »
It is the same as break, so why use it?
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 »