Show Posts

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.


Messages - Goombert

1636
Issues Help Desk / Re: Problem using joystick functions.
« on: April 01, 2014, 11:05:25 AM »
You still haven't even let me properly fix the axis code so that I can commit it to the repository, you stormed off with a version of the code you *thought* worked, but may in fact not work with other joysticks because as I said it wasn't calibrating properly. If you would get on IRC and test the code for me, it would be much easier to fix these bugs as I do not have a game controller.

Edit: We have properly fixed the joystick calibration and committed the code. The commit is in the following pull request and will appear in the next stable release of ENIGMA.
https://github.com/enigma-dev/enigma-dev/pull/683
This is the specific commit.
https://github.com/RobertBColton/enigma-dev/commit/b7a9a4b7f6bc20b3c2a0a4d6d00844f29a341af3

1637
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

1638
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,
I assume its audio will also be played back right, (meaning audio/video) the same as the standard video playback right ?
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.
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.

1639
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.

1640
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...
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.

1641
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 :(

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?

1642
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.

1643
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

1644
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.

1645
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.

1646
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.

1647
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.

1648
Developing ENIGMA / Re: Game Information Implemented
« on: March 30, 2014, 01:19:44 AM »
Well let's see.

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.

1649
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.

1650
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.