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

Off-Topic / Re: So this is what people talk about at the GMC
« on: April 02, 2014, 07:54:51 PM »
wow TKG thanks for sharing, looks like YYG is doing a good job improving the quality of GameMaker end products

General ENIGMA / Re: Splash Functions
« on: April 01, 2014, 11:12:56 AM »
Quote from: TKG
Have you got this working on Linux yet? Or is that part still being worked on? Have you found a way to do this for Linux, but you just haven't implemented it fully yet? In any case I'm glad there's been some rapid progress on this!
What working on Linux? Splash? No, this topic is about me not wanting to add them. If you meant video functions, no as I want to plan them out properly first and I need to get other things ready as well.

Quote from: ExDeus
1) What API you plan to use for all of that?
I didn't pick one for cross-platform, right now they only exist in DirectShow, and I haven't exactly worked out video_draw_frame() yet. I do know that playing it the default way in DirectShow is already hardware accelerated on Vista or later. I haven't looked into how you do it exactly yet. I may just give people a video_get_surface function, because DirectShow may actually just give you direct access to it's surface or it might not, I don't know.

Quote from: TheExDeus
Would this API allow loading from webcam?
I hadn't planned on it until you asked :P
But yes we can do that.

Could OpenCV handle all of our Linux video stuff we need it to though?

Quote from: TheExDeus
They would be several GL windows? So you could render to all of them?
That's the idea yes, but with a window_get_main, only the main window will create its graphics context by default. After calling window_create you will also need to call window_create_graphics if you intend to render to the window. I haven't exactly thought out the implementation fully yet, but the purpose is basically to let you draw directly to the message window for custom dialogs instead of shitty message_box functions which limit how you use them. Also by not creating a graphics context by default on all newly created windows, will make it easier for developers who do want to create Win32 native widgets and the likes, or people who want to use GTK, etc.

This way the very least we can do is provide a properly abstract windowing system like SDL or Qt, etc.

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.
This is the specific commit.

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

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.

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.

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.

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.
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
7) A lot of RTS engines also implement lua or python scripting such as SpringRTS.

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.

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]

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.

Programming Help / Re: Find the Memory Leak
« on: March 31, 2014, 09:19:29 PM »
obj_wall1: obj_wallbasic
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.
"    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?

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.

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.

The obj_monster_basic code parses out to this.

This is the IDE_EDIT_objectfunctionality.h requested by Harri.

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.

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.

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.

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.

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

Code: (EDL) [Select]
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.