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 »
1606
Off-Topic / Re: execute_string is not a bad coding practice!
« on: April 01, 2014, 10:59:28 am »Quote from: TheExdeus
And ENIGMA doesn't have that because we didn't want to include the parser and the compiler with the game (which would be required for GML/EDL support).Koala!
Quote from: TheExDeus
The most popular in this regard is Lua, which is fast, small and easy to learn. Something like that is useful, but execute_string() wasn't.I could write a Lua extension, I've just never seen Lua scripts before or anything. I just wonder how big of a task it would be to provide functions for it, and what the hell that even means.
Quote from: TheExDeus
1) Both GM:S and ENIGMA are compiled C++ now. This means there is not interpreter to run this execute_string. Making one would take a lot of time and the result wouldn't be very fast (as GML/EDL in its core is still C++ and so compilation would be required).execute_string still exists in Studio ask TKG, DatZach was actually able to get it to work
Quote from: TKG
That would be pointless because what we could do is just add these...We have to add those when we add game_save, but JDI according to Josh will be able to optimize them out if not used. This is why I documented the functions yesterday with their potential data types.
http://enigma-dev.org/docs/Wiki/Unimplemented#Variable_Access
1607
General ENIGMA / Re: Splash Functions
« on: April 01, 2014, 02:56:03 am »Quote from: Darkstar2
BTW, while the video is being rendered on a surface,Actually, yes and no, yes meaning you'll be able to control the videos audio streaming, yes as in I am making the function set powerful enough to not only allow you to render to surfaces and use them as textures but to also allow you to only use a few simple calls just to make a video, without having to render to a surface, thus the inclusion of video_play.
I assume its audio will also be played back right, (meaning audio/video) the same as the standard video playback right ?
Some of the functions are already implemented and usable, I started adding them for TKG. The drag and drop actions also work, simply enable the DirectShow extension.
http://enigma-dev.org/docs/Wiki/Audio_and_Video_Functions
I'm also considering not doing the message_box functions, let me provide my reasons for that.
1) ENIGMA does not need to have a full-blown cross platform widget system, the users can do this themselves if REALLLLLY needed by hacking our widget system code, or they can make a Qt extension or wxWidgets extension, or w/e
2) I plan on gui_* functions that remove the need for draw_text for instance and will have most common controls for dialogs that can be easily styled and textured like Unity3D's.
3) I plan on overloading window functions to allow multiple window handling as well as window_create(), and *gasp* window_set_target
The purpose of window_set_target is of course to set the rendering target to another window you have created, this will allow you to custom render your dialogs easily, and then simply window_reset_target() to the main window.
You see the point is not to be lazy, just provide something much much better.
1608
Off-Topic / execute_string is not a bad coding practice!
« on: April 01, 2014, 01:24:49 am »
In fact, it's very standard in many many professional games. Some of them you may have heard of.
1) Grand Theft Auto ("invented" by none other than Mike Dailly himself): a low-level interpreted scripting language is used for mission coding (Main.SCM) see link for details.
https://www.google.com/#q=main.scm
2) Command and Conquer: scenario scripting
3) Sudden Strike: scenario scripting like other RTS games
4) Rise of Nations: scenario scripting...
5) 0 A.D. : scenario scripting.......................
6) Jak and Daxter: one of my all-time favorites
https://en.wikipedia.org/wiki/Game_Oriented_Assembly_Lisp
7) A lot of RTS engines also implement lua or python scripting such as SpringRTS.
http://springrts.com/wiki/Lua_Scripting
https://en.wikipedia.org/wiki/Lua_%28programming_language%29
It has many upsides, such as properly abstracting game code from engine code. Most of the processing intense work can be done in the lower level engine, such as mesh loading and terrain deformation, while easy tasks such as creating goals, spawn points, can be easily coded in an interpreted language, since the cost of functions implemented at this level are usually inexpensive.
Sorry for the rant, just sick of YYG's contempt, especially because of aforementioned Dailly.
1) Grand Theft Auto ("invented" by none other than Mike Dailly himself): a low-level interpreted scripting language is used for mission coding (Main.SCM) see link for details.
https://www.google.com/#q=main.scm
2) Command and Conquer: scenario scripting
3) Sudden Strike: scenario scripting like other RTS games
4) Rise of Nations: scenario scripting...
5) 0 A.D. : scenario scripting.......................
6) Jak and Daxter: one of my all-time favorites
https://en.wikipedia.org/wiki/Game_Oriented_Assembly_Lisp
7) A lot of RTS engines also implement lua or python scripting such as SpringRTS.
http://springrts.com/wiki/Lua_Scripting
https://en.wikipedia.org/wiki/Lua_%28programming_language%29
It has many upsides, such as properly abstracting game code from engine code. Most of the processing intense work can be done in the lower level engine, such as mesh loading and terrain deformation, while easy tasks such as creating goals, spawn points, can be easily coded in an interpreted language, since the cost of functions implemented at this level are usually inexpensive.
Sorry for the rant, just sick of YYG's contempt, especially because of aforementioned Dailly.
1609
General ENIGMA / Splash Functions
« on: April 01, 2014, 01:02:40 am »
Well, I am at a point now where I could code in the splash functions in my free time, or I could just not do that, ever, at all, and leave them deprecated for ENIGMA. But why would I want to do this? Well for several reasons, but mainly.
1) YoYoGames designs functions very badly, that leave little room for abstraction.
2) The functions are basically just a salad of various API's, meaning it's not possible to build a game that for instance only uses splash_show_image without linking DirectShow, unless I move splash_show_video over into my DirectShow extension which is just messy including the splash settings variables all over the place, especially since some of the code has to go into the main Window handle callbacks
3) I have much better functions/implementations planned that are truly abstract, for instance, my already implemented video functions, and in future releases...
Which we can also get running in OpenGL and on Linux, and *gasp* maybe even mobile! *crosses fingers*
Point is, I want to make a better, more powerful, and easy to learn and use design for video playback, HTML and webkit content, that I can not otherwise do by emulating YYG's shit. I don't even think many games used splash functions, because they were only existent in a single release of GM. Anyway, I want to hear you guys opinions on this.
1) YoYoGames designs functions very badly, that leave little room for abstraction.
2) The functions are basically just a salad of various API's, meaning it's not possible to build a game that for instance only uses splash_show_image without linking DirectShow, unless I move splash_show_video over into my DirectShow extension which is just messy including the splash settings variables all over the place, especially since some of the code has to go into the main Window handle callbacks
3) I have much better functions/implementations planned that are truly abstract, for instance, my already implemented video functions, and in future releases...
Code: (EDL) [Select]
surface_set_target(mysurface);
video_draw_frame(myvideo);
surface_reset_target();
Which we can also get running in OpenGL and on Linux, and *gasp* maybe even mobile! *crosses fingers*
Point is, I want to make a better, more powerful, and easy to learn and use design for video playback, HTML and webkit content, that I can not otherwise do by emulating YYG's shit. I don't even think many games used splash functions, because they were only existent in a single release of GM. Anyway, I want to hear you guys opinions on this.
1610
Programming Help / Re: Find the Memory Leak
« on: March 31, 2014, 09:19:29 pm »
obj_wall_basic
obj_wall1: obj_wallbasic
obj_monster_basic
obj_monster1: obj_monster_basic
Is the basic inheritance structure, the collision event belongs to obj_monster_basic and is checking for a collision with obj_wall_basic.
I have edited the original post with the parse output of the file you have requested.
The GMK can be downloaded anywhere, for instance, from here.
http://games.software4me.net/rpg/dload/index.php?cid=33
" GM Tutorial - First Person Shooter - Mark Overmars - 12-April-2013 1:26 pm - 2.57 MB - 56"
I'd really like to get this fixed, but I've run out of ideas what could be causing it
obj_wall1: obj_wallbasic
obj_monster_basic
obj_monster1: obj_monster_basic
Is the basic inheritance structure, the collision event belongs to obj_monster_basic and is checking for a collision with obj_wall_basic.
I have edited the original post with the parse output of the file you have requested.
The GMK can be downloaded anywhere, for instance, from here.
http://games.software4me.net/rpg/dload/index.php?cid=33
" GM Tutorial - First Person Shooter - Mark Overmars - 12-April-2013 1:26 pm - 2.57 MB - 56"
I'd really like to get this fixed, but I've run out of ideas what could be causing it
Quote from: TheExDeus
On Linux we have Valgrind which people usually praise.Also, I thought you said you use Windows? I guess you dual boot then don't you?
1611
Programming Help / Re: Find the Memory Leak
« on: March 31, 2014, 10:45:17 am »
Yes I am implying that Harri, I already replaced the collision event code with // do nothing and the memory leak still occurs. You have to fully delete and remove the collision event for the memory leak to stop. And the memory keeps on going up, about 1mb per second on the FPS example.
1612
Programming Help / Find the Memory Leak
« on: March 30, 2014, 05:43:26 pm »
I am doing some debugging on object inheritance and noticed a memory leak in Mark Overmars original FPS example, this is only 1 of 3 bugs left in this game. The memory leak does not occur if you delete the collision event of obj_monster_basic. I am posting this here so maybe Josh or TheExDeus can spot the bug.
The obj_monster1 code parses out to this.
http://pastie.org/8981241
The obj_monster_basic code parses out to this.
http://pastie.org/8981237
This is the IDE_EDIT_objectfunctionality.h requested by Harri.
http://pastie.org/8984313
The obj_monster1 code parses out to this.
http://pastie.org/8981241
The obj_monster_basic code parses out to this.
http://pastie.org/8981237
This is the IDE_EDIT_objectfunctionality.h requested by Harri.
http://pastie.org/8984313
1613
Developing ENIGMA / Re: Game Information Implemented
« on: March 30, 2014, 02:29:40 am »
No that's actually the opposite way around. XXX does all kinds of reverse engineering on GameMaker, he wrote the decompiler, and he said that they track in HTML5 games whether they were built with a legit Studio version or not, it checks your license. And from what I am aware of the cracked versions usually remove this shit in order to make the crack even work.
1614
Developing ENIGMA / Re: Game Information Implemented
« on: March 30, 2014, 02:16:01 am »
I'll install the cracked version tomorrow and check it out.
1615
Developing ENIGMA / Re: Game Information Implemented
« on: March 30, 2014, 02:03:17 am »
That was using the standard runner, I haven't installed the Mast Collection crack yet on my new PC.
1616
Developing ENIGMA / Re: Game Information Implemented
« on: March 30, 2014, 01:38:17 am »
Ok interesting, I went and tested on that Studio exe I just built with show_message/draw_circle and got 0 false positives, and the same result you got for the ENIGMA version.
So I wonder why it's picking up ENIGMA's as a Trojan. This is really surprising considering we don't even have backdoors like they do, and we don't have spyware to get peoples licenses.
So I wonder why it's picking up ENIGMA's as a Trojan. This is really surprising considering we don't even have backdoors like they do, and we don't have spyware to get peoples licenses.
1617
Developing ENIGMA / Re: Game Information Implemented
« on: March 30, 2014, 01:19:44 am »
Well let's see.
Putting that into the create event of an object and sticking it in a room builds an exe in Studio of 1.85mb, 2.68mb in ENIGMA, 1.08mb in ENIGMA if I disable the unused extensions and set Audio to "None".
Adding that code to the draw event oddly yields the same results.
So ENIGMA can build really small exes, you just have to manually turn off shit you aren't using. Also, ENIGMA is doing this without compressing the final exe and its data inside a 7zip.
Code: (EDL) [Select]
show_message("hai!");
Putting that into the create event of an object and sticking it in a room builds an exe in Studio of 1.85mb, 2.68mb in ENIGMA, 1.08mb in ENIGMA if I disable the unused extensions and set Audio to "None".
Code: (EDL) [Select]
repeat (500) {
draw_circle(random(room_width), random(room_height), 10, false);
}
Adding that code to the draw event oddly yields the same results.
So ENIGMA can build really small exes, you just have to manually turn off shit you aren't using. Also, ENIGMA is doing this without compressing the final exe and its data inside a 7zip.
1618
Developing ENIGMA / Re: Game Information Implemented
« on: March 30, 2014, 12:53:30 am »
Smallest exe size with YYC is at least 4mb's from the last time I tested it which was a fairly recent 1.2 build.
1619
General ENIGMA / Re: Please vote for ENIGMA's new license
« on: March 29, 2014, 10:39:44 pm »
That's not exactly what I meant. It's the way you are arguing.
Apple has a highly restrictive Store Policy, therefore we should change our whole license around to accommodate it.
Which is really just absurd. The better way to argue it is the following.
ENIGMA has a restrictive license, let's try to find ways to give users more rights.
Is the better way to make the argument.
Apple has a highly restrictive Store Policy, therefore we should change our whole license around to accommodate it.
Which is really just absurd. The better way to argue it is the following.
ENIGMA has a restrictive license, let's try to find ways to give users more rights.
Is the better way to make the argument.
1620
Developing ENIGMA / Re: Game Information Implemented
« on: March 29, 2014, 10:32:33 pm »
What do you mean? The library is only loaded if you call the function, I am not linking it from the makefile, so you shouldn't have any issue.
Also the topic is only here until I am ready to post it, I don't want it merged yet, I am having trouble on how to read the messages only when its blocking or embedded to the game window.
Edit: Also if you look in your C:/Windows folder, you'll see that riched32.dll has several versions (6 for me on Windows 8), two are 12 bytes and the others are 9kb's. Also Greg did some magic and got our executables down real small, build one just to see, our exe's are extremely small now.
Also the topic is only here until I am ready to post it, I don't want it merged yet, I am having trouble on how to read the messages only when its blocking or embedded to the game window.
Edit: Also if you look in your C:/Windows folder, you'll see that riched32.dll has several versions (6 for me on Windows 8), two are 12 bytes and the others are 9kb's. Also Greg did some magic and got our executables down real small, build one just to see, our exe's are extremely small now.
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 »