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 »
211
Announcements / Re: We can't decide
« on: November 04, 2011, 08:36:22 pm »
LLVM is probably composed 30% of C++ virtual function tables, 30% of indirection, and 20% of processor-specific data tables. The last 10% is the actual source code.
212
Announcements / Re: We can't decide
« on: November 04, 2011, 06:37:35 pm »
Guess what you can't do in C++, but could do in EDL if Josh wanted to write a better code generator?
Code: [Select]
(a ? foo : bar) = 3
213
Announcements / Re: We can't decide
« on: November 03, 2011, 08:46:10 pm »
luiscubal is exaggerating the performance impact on execute_string- all the header files, etc. could be parsed once on startup (which is pretty much unnoticeable, especially with clang), and the project Josh was referring to is Cling, which is designed to be a sort of REPL for C++ so it would be well-suited to execute_string. It probably wouldn't be any faster than GM's, but most uses of execute_string can be eliminated with new functions and will be in a standard (heh) way in GM9.
---
The biggest problem here is due to the fact that ENIGMA is distributed primarily through Subversion in source form. This does generally tend to keep it compatible with all the systems it gets used on, but it also requires that everyone download the libraries and even some toolchain stuff for platforms they don't necessarily use. Isolating all the platform-specific stuff to an installer/package outside of the repository would solve the Subversion problem as 1) various distros' package managers can handle dependencies and 2) developers can be expected to download things outside of the repository.
I see two options beyond that:
Continue with a C++ Compiler
The size requirement on Windows is large no matter what process is used to compile C++- MinGW packages binutils and libstdc++ (which is part of the g++ package <_<) are required pretty much no matter what. Supporting C++ directly, as with Definitions, requires a large compiler- either GCC or Clang. Clang's appeal is due to the fact that it provides a reusable C++ parser to replace ENIGMA's.
A Windows ENIGMA installer would include the 77Mb combination of mingw-get and Clang, then "mingw-get install g++ msys-bash msys-make" leading to a 26Mb download and an installed size of 229Mb. Without Clang, that would drop 76Mb from the installer (to 153Mb installed size) but add a considerable maintenance component to ENIGMA- a complete C++ parser separate from, and thus probably subtly incompatible with, the one used to compile the games.
This system would require minimal change to ENIGMA's current infrastructure, with at worst a new C++ parser to go with GCC and at best just some calls to Clang's libraries. It would be able to call all the existing C++ standard library and other libraries with minimal work from end users. It would be relatively simple to debug games with existing debuggers.
Write Your Own LLVM Frontend
Running with a custom recursive descent parser, ENIGMA would have enough information to generate code for EDL directly using LLVM. LLVM is fully capable of generating object files, but requires a system-specific linker to turn them into an executable. This would be essentially replacing both GCC and Clang with an EDL compiler, and libc/libstdc++ with and ENIGMA library with the appropriate libraries statically linked.
An EDL compiler with the required LLVM libraries linked would pull in about 19Mb (about 2Mb of that is x86-specific; ARM is not included but is also about 2Mb), and mingw-get is only 453Kb. The Windows installer in this case would download 1.79Mb for binutils, and unpack it into 22Mb. In total, the installed size would probably be 50-55Mb, compared to the full-blown compiler installation which is anywhere from 150-250Mb.
This smaller package would use only a single parser and code generator, but would still require some kind of intermediary between the EDL and the ENIGMA library, either through a combination of extern "C"/name mangling and better language features in EDL, or something like what luiscubal described, which may or may not be generated automatically at ENIGMA-build-time using Clang. EDL would probably get its own standard library that would be portable across all output languages. There would be more flexibility with the implementation of things like var, with, switch, etc. and they would be less likely to break.
---
Considering the goal of generating both native executables and JavaScript, it may be a good idea to isolate EDL, Definitions, and extensions from each other and the underlying platform. Instead of Definitions just being project-specific code written in whatever language the project targets, Definitions would be a part of GM-style extensions and include implementations of their API in EDL, C++ and/or JavaScript.
This would require some extension developers to have their own C++ compilers (i.e. not distributed with ENIGMA), but if they're writing C++ directly already that shouldn't be a problem. It would require multiple binaries of the platform-specific parts, but then again that's probably necessary in source form already, and the cross-platform bits could be written in EDL. This kind of a change would also make ENIGMA more compatible with actual GM extensions.
---
Cross-platform building is still a sticky issue in all of these situations. Using GCC, cross-compilation would require rebuilding the compiler for every target- infinitely larger than anything previously discussed. Clang and thus LLVM can cross-compile objects files, but not link them, and linkers are always highly-platform-specific. Cross-linking, the real problem here, can only really be eliminated by a custom linker (bad idea) or a runner of some kind (pointless and 20Mb games).
---
The biggest problem here is due to the fact that ENIGMA is distributed primarily through Subversion in source form. This does generally tend to keep it compatible with all the systems it gets used on, but it also requires that everyone download the libraries and even some toolchain stuff for platforms they don't necessarily use. Isolating all the platform-specific stuff to an installer/package outside of the repository would solve the Subversion problem as 1) various distros' package managers can handle dependencies and 2) developers can be expected to download things outside of the repository.
I see two options beyond that:
Continue with a C++ Compiler
The size requirement on Windows is large no matter what process is used to compile C++- MinGW packages binutils and libstdc++ (which is part of the g++ package <_<) are required pretty much no matter what. Supporting C++ directly, as with Definitions, requires a large compiler- either GCC or Clang. Clang's appeal is due to the fact that it provides a reusable C++ parser to replace ENIGMA's.
A Windows ENIGMA installer would include the 77Mb combination of mingw-get and Clang, then "mingw-get install g++ msys-bash msys-make" leading to a 26Mb download and an installed size of 229Mb. Without Clang, that would drop 76Mb from the installer (to 153Mb installed size) but add a considerable maintenance component to ENIGMA- a complete C++ parser separate from, and thus probably subtly incompatible with, the one used to compile the games.
This system would require minimal change to ENIGMA's current infrastructure, with at worst a new C++ parser to go with GCC and at best just some calls to Clang's libraries. It would be able to call all the existing C++ standard library and other libraries with minimal work from end users. It would be relatively simple to debug games with existing debuggers.
Write Your Own LLVM Frontend
Running with a custom recursive descent parser, ENIGMA would have enough information to generate code for EDL directly using LLVM. LLVM is fully capable of generating object files, but requires a system-specific linker to turn them into an executable. This would be essentially replacing both GCC and Clang with an EDL compiler, and libc/libstdc++ with and ENIGMA library with the appropriate libraries statically linked.
An EDL compiler with the required LLVM libraries linked would pull in about 19Mb (about 2Mb of that is x86-specific; ARM is not included but is also about 2Mb), and mingw-get is only 453Kb. The Windows installer in this case would download 1.79Mb for binutils, and unpack it into 22Mb. In total, the installed size would probably be 50-55Mb, compared to the full-blown compiler installation which is anywhere from 150-250Mb.
This smaller package would use only a single parser and code generator, but would still require some kind of intermediary between the EDL and the ENIGMA library, either through a combination of extern "C"/name mangling and better language features in EDL, or something like what luiscubal described, which may or may not be generated automatically at ENIGMA-build-time using Clang. EDL would probably get its own standard library that would be portable across all output languages. There would be more flexibility with the implementation of things like var, with, switch, etc. and they would be less likely to break.
---
Considering the goal of generating both native executables and JavaScript, it may be a good idea to isolate EDL, Definitions, and extensions from each other and the underlying platform. Instead of Definitions just being project-specific code written in whatever language the project targets, Definitions would be a part of GM-style extensions and include implementations of their API in EDL, C++ and/or JavaScript.
This would require some extension developers to have their own C++ compilers (i.e. not distributed with ENIGMA), but if they're writing C++ directly already that shouldn't be a problem. It would require multiple binaries of the platform-specific parts, but then again that's probably necessary in source form already, and the cross-platform bits could be written in EDL. This kind of a change would also make ENIGMA more compatible with actual GM extensions.
---
Cross-platform building is still a sticky issue in all of these situations. Using GCC, cross-compilation would require rebuilding the compiler for every target- infinitely larger than anything previously discussed. Clang and thus LLVM can cross-compile objects files, but not link them, and linkers are always highly-platform-specific. Cross-linking, the real problem here, can only really be eliminated by a custom linker (bad idea) or a runner of some kind (pointless and 20Mb games).
214
General ENIGMA / Re: Makefile is fucked
« on: October 29, 2011, 12:28:55 pm »
Update on Runtime.exec(): http://developer.apple.com/library/mac/#documentation/Java/Conceptual/Java14Development/05-CoreJavaAPIs/CoreJavaAPIs.html#//apple_ref/doc/uid/TP40001902-SW5
Looks like it doesn't have the specific form LGM uses to launch make. Should be a simple fix, unless I'm missing something- what error do you get, ugriffin?
Looks like it doesn't have the specific form LGM uses to launch make. Should be a simple fix, unless I'm missing something- what error do you get, ugriffin?
215
General ENIGMA / Re: Makefile is fucked
« on: October 29, 2011, 11:55:55 am »
I'm curious as to why Apple's JVM can't run make- is it the plugin's fault for using the API in a way that doesn't work on OS X, or does the API simply not exist?
Apple is in a hurry to ditch their custom JVM build. Oracle, however, will still provide a JVM for OS X (OpenJDK, thus supporting all the way up to Java 7): http://blogs.oracle.com/henrik/entry/oracle_and_apple_announce_openjdk_project_for_osx
I wouldn't mind an IDE in something other than Java, except the only other options appear to be C++ or C#, neither of which are very appealing. C++ is not the best thing to write an IDE in, especially trying to use a cross-platform widget library (maybe Qt would be slightly less painful than Java?), and C# has essentially the same problems as Java.
Apple is in a hurry to ditch their custom JVM build. Oracle, however, will still provide a JVM for OS X (OpenJDK, thus supporting all the way up to Java 7): http://blogs.oracle.com/henrik/entry/oracle_and_apple_announce_openjdk_project_for_osx
I wouldn't mind an IDE in something other than Java, except the only other options appear to be C++ or C#, neither of which are very appealing. C++ is not the best thing to write an IDE in, especially trying to use a cross-platform widget library (maybe Qt would be slightly less painful than Java?), and C# has essentially the same problems as Java.
216
General ENIGMA / Re: Makefile is fucked
« on: October 28, 2011, 07:04:38 pm »
Mac's find sucks and doesn't default to searching in the current directory, so I've updated the Makefiles to supply it. You'll need to use r936 to get the fix.
Also, LGM should build the plugin on its own, is there a reason you're running make yourself?
Also, LGM should build the plugin on its own, is there a reason you're running make yourself?
217
Off-Topic / Compiled Code in GM9
« on: October 25, 2011, 03:45:50 pm »
http://gmc.yoyogames.com/index.php?showtopic=522585&view=findpost&p=3851900
Emphasis added.
Previously (http://gamemakerblog.com/2011/06/18/work-on-official-gamemaker-obfuscator/, http://enigma-dev.org/forums/index.php?topic=838.msg9359), Russell mentioned that the C++ runner would use GML compiled with LLVM, so this is just a target version for that change.
Quote from: rwkay
script_execute was not removed - it was overlooked that is all, we are only deprecating anything that requires a GML compiler/interpreter to run on the target (i.e. execute_string or execute_file) as we will no longer be supporting interpreting on the target machines (yes, we will be moving to fully compiled code in GM9).
Once the bug was filed we implemented script_execute... keep the bugs flowing so we can increase compatibility amongst all the targets.
Russell
Emphasis added.
Previously (http://gamemakerblog.com/2011/06/18/work-on-official-gamemaker-obfuscator/, http://enigma-dev.org/forums/index.php?topic=838.msg9359), Russell mentioned that the C++ runner would use GML compiled with LLVM, so this is just a target version for that change.
218
Proposals / Re: Overworld Resource
« on: October 19, 2011, 09:13:52 pm »
I like the idea of named entry/exit points. In fact, that would be a nice addition to the instance id system in general- rather than ever exposing instance ids directly, instances could be named and accessed through constants. This could probably be reused to name regions and entry/exit points.
You proposal would make for a nice API- just call overworld_follow(some_endpoint) in e.g. the collision event with a door, and the game would switch rooms and then trigger an event for "followed overworld connector" that gets passed (similar to other in collision events) the exit point in the new room. Other useful functions could be overworld_get_endpoint() and overworld_get_room(). Handling multiple endpoints should probably involve the door collision event picking one rather than any code in the overworld system.
One question is what endpoints should be attached to- instances? regions? points? just names? I'm thinking probably names would be the most flexible, but that could make the overworld editor somewhat annoying as the arrows wouldn't automatically point from some meaningful origin to a meaningful exit point.
Another problem associated with using names would be resolving the new coordinates. If all you have is the name of an endpoint, you would have to do a lot of work yourself, negating the advantages of an overworld editor.
A possible solution to these problems would be to associate some arbitrary piece of data with each endpoint, including instances, points, regions, etc. This might be tricky to do in the overworld editor, but it could lead to a lot of flexible configurations for different styles of games. If there is a good way to do this, arrows would have meaningful endpoints and the room-entry events would be able to grab the data in whatever way the game is designed to use.
You proposal would make for a nice API- just call overworld_follow(some_endpoint) in e.g. the collision event with a door, and the game would switch rooms and then trigger an event for "followed overworld connector" that gets passed (similar to other in collision events) the exit point in the new room. Other useful functions could be overworld_get_endpoint() and overworld_get_room(). Handling multiple endpoints should probably involve the door collision event picking one rather than any code in the overworld system.
One question is what endpoints should be attached to- instances? regions? points? just names? I'm thinking probably names would be the most flexible, but that could make the overworld editor somewhat annoying as the arrows wouldn't automatically point from some meaningful origin to a meaningful exit point.
Another problem associated with using names would be resolving the new coordinates. If all you have is the name of an endpoint, you would have to do a lot of work yourself, negating the advantages of an overworld editor.
A possible solution to these problems would be to associate some arbitrary piece of data with each endpoint, including instances, points, regions, etc. This might be tricky to do in the overworld editor, but it could lead to a lot of flexible configurations for different styles of games. If there is a good way to do this, arrows would have meaningful endpoints and the room-entry events would be able to grab the data in whatever way the game is designed to use.
219
Proposals / Re: Overworld Resource
« on: October 19, 2011, 11:26:21 am »
Your description of the overworld resource suggests a rather simple method that would work in GM- separate rooms with a simple global array of their overworld coordinates. This could be somewhat painful, but a new editor like you describe would make it great.
However, game worlds don't always work that way. RPG-style overworlds where the player walks around in a hierarchy of rooms come to mind, as well as slightly more complicated Metroid-style ones with rooms oriented outside of a single, 2D map, such as with doors to other layers and/or rooms extending "into" the world.
A vague suggestion that would accommodate all three of these styles: rather than translating between overworld and room coordinates directly, build the overworld resource out of "connectors" between rooms. These connectors would be associated with doors, room edges, teleporters, etc. on both ends, allowing for much more flexible layout of the game world.
However, game worlds don't always work that way. RPG-style overworlds where the player walks around in a hierarchy of rooms come to mind, as well as slightly more complicated Metroid-style ones with rooms oriented outside of a single, 2D map, such as with doors to other layers and/or rooms extending "into" the world.
A vague suggestion that would accommodate all three of these styles: rather than translating between overworld and room coordinates directly, build the overworld resource out of "connectors" between rooms. These connectors would be associated with doors, room edges, teleporters, etc. on both ends, allowing for much more flexible layout of the game world.
220
Off-Topic / Re: Terrena a11 - my game
« on: October 16, 2011, 07:58:42 pm »
Ah, good. The cards are much more balanced now, and I like the randomized positions.
Valid movement positions probably only need to be highlighted on hover, like placing terrain- when the majority of the screen turns red my first thought is "oh no death"
It would also be nice to start out further zoomed out, and to make zooming out less artifacty (esp. the grid lines, which can disappear or be missing pixels).
I also must say that now that the cards issue is fixed, it gets somewhat tedious to click though all the computer actions (since they do so much more).
Finally, I'm getting another text bug- the deck labels have some strange flickering and changing characters at the end, including both unicode-squares and others.
Valid movement positions probably only need to be highlighted on hover, like placing terrain- when the majority of the screen turns red my first thought is "oh no death"
It would also be nice to start out further zoomed out, and to make zooming out less artifacty (esp. the grid lines, which can disappear or be missing pixels).
I also must say that now that the cards issue is fixed, it gets somewhat tedious to click though all the computer actions (since they do so much more).
Finally, I'm getting another text bug- the deck labels have some strange flickering and changing characters at the end, including both unicode-squares and others.
221
Off-Topic / Re: Terrena a10 - my game
« on: October 13, 2011, 12:37:50 pm »
Although running it in Mono still has the issue of not searching the working directory for dlls, the interface has improved a ton. There is much less hunting through menus to find things, and the text at the start helps massively in knowing what to do first. The rotating selection tile is somewhat distracting (and probably unnecessary), and the resource/card system, battles, dice-rolling, and the current player could use a little more explanation interface-wise, but mostly it's good.
However, some games the cards and resources I'm getting are rather unbalanced now. I can't seem to manage having both cards I can use and resources I can use them with, so I just sit on my tile doing nothing until I die. The computer players are interesting but also rather close together, and moving the camera around is difficult (maybe middle click panning instead of edges?). I'm also not always sure where the units are allowed to move (not on rivers? on others' tiles? etc), where tiles are allowed to be placed (hidden island requires water underneath, not just around), or which units are whose (maybe recolor helmets/sails instead of just circles). Finally, the cards could use an interface improvement similar to the character, to avoid modal menus just to decide whether to build as well as to show the information on the card in a more readable way from the main screen.
edit: after playing for a while it seems the units have reverted to their old behavior? I have to double click them to do anything?
However, some games the cards and resources I'm getting are rather unbalanced now. I can't seem to manage having both cards I can use and resources I can use them with, so I just sit on my tile doing nothing until I die. The computer players are interesting but also rather close together, and moving the camera around is difficult (maybe middle click panning instead of edges?). I'm also not always sure where the units are allowed to move (not on rivers? on others' tiles? etc), where tiles are allowed to be placed (hidden island requires water underneath, not just around), or which units are whose (maybe recolor helmets/sails instead of just circles). Finally, the cards could use an interface improvement similar to the character, to avoid modal menus just to decide whether to build as well as to show the information on the card in a more readable way from the main screen.
edit: after playing for a while it seems the units have reverted to their old behavior? I have to double click them to do anything?
222
Proposals / Re: HTML5 exporter
« on: September 27, 2011, 07:34:18 pm »
And yet, the idea that compiling EDL to C++ will automatically grant you magic "map foo;" powers fails as soon as you try to compile to JS as well.
223
Proposals / Re: HTML5 exporter
« on: September 27, 2011, 04:21:05 pm »
And that means you can #include <map> or glue to std::map in JavaScript because C++ is in there some 3 levels down.
224
Proposals / Re: HTML5 exporter
« on: September 27, 2011, 12:02:10 pm »
Except Rhino is written in Java.
225
Proposals / Re: HTML5 exporter
« on: September 26, 2011, 10:58:01 am »
It's funny because now C++ is not the magical source of all power in the universe.