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 189 190 191 192 193 194 195 196 197 198 199 »
1141
Developing ENIGMA / Re: Command Line Interface
« on: June 20, 2014, 04:56:47 pm »
You wouldn't use the CLI to create the files, it's expected that the project will be created in an IDE. The command line will compile it. But yes it's possible to edit your resources outside the IDE using text editors and image editors, you can very easily open a sprite or background from a GMX and modify the resources, and you can open the object files and change the code and other properties. You can also edit scripts using notepad++ with the following extension.
http://enigma-dev.org/docs/Wiki/Plugins
http://enigma-dev.org/docs/Wiki/Plugins
1142
Developing ENIGMA / Re: Command Line Interface
« on: June 20, 2014, 04:27:34 pm »
No, it would actually make that a lot better, LGM crashes from saving frequently because it's accumulating more and more memory usage. Although you seem to be having other issues as well like bugs in JoshEdit, which aren't out of memory errors at all and make no sense.
Anyway TKG is one person who really wants it and so do I. And having it is better than not having it. This is literally the way practically all game engines and IDE's work. I can make the thing first and yall can decide later whether you want LGM to continue being a laggy Java program or you want it sped up.
On top of that, this lays the groundwork for a C++ IDE by getting a lot of the plugin redone in C.
Anyway TKG is one person who really wants it and so do I. And having it is better than not having it. This is literally the way practically all game engines and IDE's work. I can make the thing first and yall can decide later whether you want LGM to continue being a laggy Java program or you want it sped up.
On top of that, this lays the groundwork for a C++ IDE by getting a lot of the plugin redone in C.
1143
Developing ENIGMA / Re: Command Line Interface
« on: June 20, 2014, 03:54:46 pm »
Judging your comments indicates you didn't even bother to read my post. Currently LGM loads your entire project into memory as one giant ass binary and then uses JNA to send that memory to the compiler, which requires changing endianess and is extremely slow as hell. The IDE could use the CLI interface and just pass the file to it to compile, is the whole point of this. To speed up the IDE, not make it slower.
1144
Developing ENIGMA / Command Line Interface
« on: June 20, 2014, 03:00:37 pm »
So I decided to do some testing and get the command line interface I started working and building an empty game. The program I have dubbed "emake" boots in less than 3 seconds initializing the library and all, and can compile and run an empty game in about the same amount of time. It is significantly faster than loading the IDE and building an empty game from there.
This has a lot of implications, you can build games without an IDE, you can build games much quicker, especially extremely large games like TKG makes. This also means we could significantly improve the performance of LGM working with large projects. This would be done by only loading the resource tree at startup, and loading and unloading resources or as you edit them or we could also just cache them.
This would allow someone like TKG to load a 100mb game much quicker, probably about 5-10 seconds, and build the game much quicker. The way we would accomplish building the game without loading it is by simply passing the file path of the project to the CLI and telling it to build the project.
A lot of these ideas are already utilized by Studio and it has many of the same restrictions that follow which are actually the same for most other IDE's. But we have some issues:
1) LGM does not have a guaranteed format, it lets you save and load from all formats.
2) This would require that you create the project directory when you want to make a new game, like in Studio, you couldn't get away with adding resources and saving later because the IDE has to have it on disk.
3) GMK is damn near impossible to optimize as a result of it being one giant ass file, you can't easily skip through parts of it and write a single resource.
4) You probably would not be able to build without saving your changes. I believe Studio has this same restriction.
Some possible solutions are the following:
1) Treat formats like GMK as an import/export where you can import a GMK but it will automatically be converted to GMX or EGM whichever format you choose.
Here are some benefits:
1) Faster loading times
2) Faster compile times
3) Less out of memory errors
4) Can build projects without an IDE
5) Makes it much easier for 3rd parties to write IDE's and other interfaces for the program
So the question is, does the cost outweigh the benefit? I am fairly certain most of you would say yes, but feel free to express your ideas on the matter.
*** Update ***
See latest forum post, the CLI now builds projects.
This has a lot of implications, you can build games without an IDE, you can build games much quicker, especially extremely large games like TKG makes. This also means we could significantly improve the performance of LGM working with large projects. This would be done by only loading the resource tree at startup, and loading and unloading resources or as you edit them or we could also just cache them.
This would allow someone like TKG to load a 100mb game much quicker, probably about 5-10 seconds, and build the game much quicker. The way we would accomplish building the game without loading it is by simply passing the file path of the project to the CLI and telling it to build the project.
A lot of these ideas are already utilized by Studio and it has many of the same restrictions that follow which are actually the same for most other IDE's. But we have some issues:
1) LGM does not have a guaranteed format, it lets you save and load from all formats.
2) This would require that you create the project directory when you want to make a new game, like in Studio, you couldn't get away with adding resources and saving later because the IDE has to have it on disk.
3) GMK is damn near impossible to optimize as a result of it being one giant ass file, you can't easily skip through parts of it and write a single resource.
4) You probably would not be able to build without saving your changes. I believe Studio has this same restriction.
Some possible solutions are the following:
1) Treat formats like GMK as an import/export where you can import a GMK but it will automatically be converted to GMX or EGM whichever format you choose.
Here are some benefits:
1) Faster loading times
2) Faster compile times
3) Less out of memory errors
4) Can build projects without an IDE
5) Makes it much easier for 3rd parties to write IDE's and other interfaces for the program
So the question is, does the cost outweigh the benefit? I am fairly certain most of you would say yes, but feel free to express your ideas on the matter.
*** Update ***
See latest forum post, the CLI now builds projects.
1145
General ENIGMA / Re: GL3 lights fixes
« on: June 20, 2014, 02:38:07 pm »
Excellent work Harri lights are working good now in GL3 and it is working great altogether.
I only notice a few differences:
* OGL3 is marginally slower
* OGL3 lights appear darker
But we will work out these kinks, for now I would like you go ahead and merge your branch so that GL3 has working lights. I will work with it in the future to optimize it with you.
These are wonderful developments however, it will be relatively little effort to port this system to GLES and get a proper Android port working.
I only notice a few differences:
* OGL3 is marginally slower
* OGL3 lights appear darker
But we will work out these kinks, for now I would like you go ahead and merge your branch so that GL3 has working lights. I will work with it in the future to optimize it with you.
These are wonderful developments however, it will be relatively little effort to port this system to GLES and get a proper Android port working.
1146
Proposals / Re: A couple ideas (ENIGMA and LGM at the same time)
« on: June 20, 2014, 04:25:33 am »
Very funny, but yes I swear I didn't write any of the room editor code. Use git blame if you don't believe me.
1147
Off-Topic / Re: what happened to...?
« on: June 19, 2014, 10:55:00 pm »
no fundies went to school, also he started enigger which is basically C++ GML API with no IDE, just meant to be used with Visual Studio, etc. he wrote it with SDL.
He still gets on IRC, specifically #awesome-toons on Rizon. But Josh banned him from IRC, I dnt remember why.
He still gets on IRC, specifically #awesome-toons on Rizon. But Josh banned him from IRC, I dnt remember why.
1148
Issues Help Desk / Re: Linux & LGM
« on: June 19, 2014, 10:53:07 pm »
I can't remember, did that one successfully compile on Windows? I can't remember but I could have swore that was the one with audio_music_* functions needing removed. If so can you send the updated version that compiles on Windows for me?
1149
Off-Topic / Re: what happened to...?
« on: June 19, 2014, 10:50:16 pm »
gra was just here like a week ago, I've never seen fede, DarkAceZ fell off his brony
1150
Issues Help Desk / Re: Linux & LGM
« on: June 19, 2014, 10:46:39 pm »
Actually it's not LGM is just not as optimized as Studio for several reasons.
But mainly, Studio's IDE has the same limitations ours does, GM is and has always been 32bit.
Edit: TKG, do I have this project on my desktop? I keep like all of the ones you send me because they are pretty big and I don't like downloading huge files, tell me which one.
But mainly, Studio's IDE has the same limitations ours does, GM is and has always been 32bit.
Edit: TKG, do I have this project on my desktop? I keep like all of the ones you send me because they are pretty big and I don't like downloading huge files, tell me which one.
1151
Issues Help Desk / Re: Linux & LGM
« on: June 19, 2014, 10:28:59 pm »
TKG, which project are we talking about? Is it a project you've sent me? I can try building it.
Darkstar2, were these usually experienced on Windows? You have to report them when you get them, I never get anything remotely like that.
Darkstar2, were these usually experienced on Windows? You have to report them when you get them, I never get anything remotely like that.
1152
Issues Help Desk / Re: Linux & LGM
« on: June 19, 2014, 10:07:26 pm »
That was an issue in JoshText, I have no idea what it was about because JoshText is a clusterfuck.
1154
Issues Help Desk / Re: Linux & LGM
« on: June 19, 2014, 09:27:28 pm »
The interface is mostly completed TKG, we just need functionality now.
1155
Issues Help Desk / Re: Linux & LGM
« on: June 19, 2014, 09:11:27 pm »
Because the JVM limits a single thread to 1gb RAM on Windows and apparently 2.6gb's on Linux.
With 64bit Java I don't think there's a cap.
With 64bit Java I don't think there's a cap.
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 189 190 191 192 193 194 195 196 197 198 199 »