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

Issues Help Desk / Re: I have a problem!
« on: October 11, 2014, 03:17:55 AM »
You're welcome, I was hoping I could help to get it working for you. Thank you for your patience as well! If you need anymore assistance do not be afraid to ask.  (Y)

Developing ENIGMA / Re: LateralGM
« on: October 11, 2014, 01:19:45 AM »
I've uploaded a couple more fixes, the exception dialog was not actually displaying the stack trace. Please check OP for full changes and download.

General ENIGMA / Re: General Enigma Questions
« on: October 10, 2014, 09:56:02 PM »
Well first of all you can't compare unsigned (i) to signed (-1).

I just tested the following and it worked.
Code: (EDL) [Select]
int i = 4096*4096;
while i > -1 {
  arr = irandom(65535);
  i -= 1;

Unsigned works as well it's just that an unsigned number is always larger than 0. So we just need to add array length support and then we can offer alternative and much better more efficient functions than what Studio has anyway.

I tried the following as well.
Code: (EDL) [Select]
int i = 4096*4096;
unsigned start_time = get_timer();
while i > -1 {
  arr = irandom(65535);
  i -= 1;

show_message(string(get_timer() - start_time));

And it executed in 312546 microseconds.

I tried the following variation in Studio which executed in 5605667 microseconds for me.
Code: (GML) [Select]
i = 4096*4096;
start_time = get_timer();
while i > -1 {
  arr = irandom(65535);
  i -= 1;

show_message(string(get_timer() - start_time));

Off-Topic / Re: We will be discontinuing YYC Compiler!
« on: October 10, 2014, 09:21:33 PM »
Yeah but if it was done natively TKG you could render it to surfaces and then do post-processing effects, and for instance play videos in black and white, etc.

General ENIGMA / Re: General Enigma Questions
« on: October 10, 2014, 09:10:34 PM »
Quote from: Rujik
BUT, here is the problem:

A 16 bit 4096x4096 wrapped buffer takes 32 megs of memory but a grid would take 160 megs. I would gladly switch to any other form of data storage if one exists with a low memory cost.  Originally, I was using grids but switched over as my map size increased.
If there was a ds_grid_set_bits command or something I would switch over in a heartbeat.
Ahhh you see here you are probably correct. Why would this be the case? Because the buffers store the data with actual data types, a data structure stores the contents in var/variant meaning it overloads all reals as doubles.

Quote from: Rujik
I have no problem with GMS compatibility != 100%. I'm just stuck trying to "find new ways to perform what you can in GMS" as you said. Learning C++ would probably be a considerable benefit here though. I haven't given up yet though!
Well there is a much better way that's even more optimal than using buffers and quicker to iterate, read, and write. It's called using arrays of type unsigned for each pixel, which ENIGMA does currently support. We do currently support real int, boolean, and standard C++ data types. But currently we need to fix var to overload array so that we can return them from functions, at which point I am going to add the function surface_get_pixels to ENIGMA. I also plan on functions like d3d_model_vertices(var vertices[]), draw_getpixels(), and other related functions.

Sorlok says he can fix it after he finishes new placement with var.

Quote from: Rujik
So in conclusion, any suggestions for 16 bit number storage on a large scale?
Yes using an array with the actual data type.

Off-Topic / Re: We will be discontinuing YYC Compiler!
« on: October 10, 2014, 09:06:44 PM »
I don't know about runner or not never actually used the HTML5......Though I do have the export, as when I paid for my Pro it was bundled with it (pro+html5).
It would have to be dude, there's no other way they could translate the GML to JavaScript, unless they wrote a JavaScript GML interpreter in addition to the YYC. Occam's razor, etc.

From what I read on GMS2 it will run natively on several platforms, I guess this whole discontinuing YYC and integrating it as part of the engine is paving way for GMS2 new architecture, perhaps it will be C++ based who knows.  I agree that it should have been this way from the beginning that's what I've been saying all along :D  But I learned how sneaky they are... With GMS2 around the corner, they probably have something significant enough to have people PAY for in GMS2 they won't get in GMS1, so the YYC being included might not have that much value......Maybe in GMS2 it will be an enhanced compiler, faster, etc.....It's all about money, not what people want, you know that by now
Are you excited to see an IDE that was not only improved by them, but literally built from the ground up and designed by them? Studio 2.0 is supposed to have a brand new IDE, and I think they may make it more revolutionary, but I'll be surprised at what they come up with, it will be interesting to say the least.

Yes they can increase prices as they want, I guess they want to target the professional market not just the 12- key demographics they have going lol.  Though a $800 probably soon a $1000 product that does not support video playback I cannot fucking swallow.  I mean sure lonewolff has an engine and all, but still think it's something YYG should have integrated in their expensive product, as this is a basic function.
I think you know why I stated that the way that I did, and I think you know what I was getting at, they can do whatever they want, but how far will it take them?

General ENIGMA / Re: Who fixed arrays?
« on: October 10, 2014, 08:27:52 PM »
Another satisfied customer! :D
If I had the authority, I'd double your salary sorlok. If you could fix arrays and give me the array length, I would be very happy and implement a lot of powerful functions that would completely remove the need for even dealing with buffers to read surfaces, I honestly don't know why YYG always has to overcomplicate things too.

Off-Topic / Re: We will be discontinuing YYC Compiler!
« on: October 10, 2014, 08:26:16 PM »
Robert, this was announced on their home page.  They are making really positive changes lately, that's one thing worthy of mention, mind you, with version 2.0 around the corner, I kinda saw this coming.  The $300 ridiculous price they charged probably was not a hit.    Perhaps for someone with ALL exports, but for windows only developers it was ridiculous to pay price for 3 YYCs on exports you don't own.

Let's see what they have to offer for GMS2.
You make a good point, I actually had not thought of it in that way before. But yes I do agree this is a good move for them, but I still think it should have been this way from the beginning.

not only that - export modules are going to increase in price, in other words they are scattering the cost to individual modules.  I think it is more fair this way contrary to what people believe.
I don't believe that all of the exports had a runner, I believe the HTML5 always has and always will use the YYC because it would be required for LLVM to translate the GML to JavaScript. Correct me If I am wrong, but that would mean it doesn't warrant an upgrade in the cost of the HTML5 export, but they can increase their prices arbitrarily after all it's their product.

Off-Topic / Re: We will be discontinuing YYC Compiler!
« on: October 10, 2014, 07:14:18 PM »
Well that's interesting, that's the way it should have been from the beginning, got a source? It was seriously the only thing worth selling Studio thus far, the only real thing that changed in Studio, it should have never been an extra cost besides the cost of the upgrade in addition to modules. The YYC should have been free from the beginning. Otherwise what the hell was the base $50 price for, a buggy ass IDE that deprecates a ton of hold features in the runner?

Edit: Got one

Looks like opinions are pretty mixed.
Welp, my game takes 20 minutes to compile with YYC (runs much faster, though), so hopefully there will be an option for this, or that the debug mode runs without YYC as it does today.
Aaaaaaaaand the idea of getting a module for my birthday next year goes out of the window.

At least this is going to help the professionals.

General ENIGMA / Re: Who fixed arrays?
« on: October 10, 2014, 06:31:25 PM »
Do you have any ideas on implementing array length sorlok? I was wanting to add some like sprite_getpixels and surface_getpixels or even d3d_model_vertices(var vertices[]) functions that return an array to avoid multiple bindings for each pixel. Without JDI supporting collections in EDL yet and me not wanting the functions to rely on the data structure extension, we are left with returning arrays. But they are unusable if the user can not get the array dimensions with the Studio function.

Issues Help Desk / Re: I have a problem!
« on: October 10, 2014, 06:28:40 PM »
Does the file "ENIGMA/enigma-dev/compileEGMf.dll" exist? Additionally, we do plan to add 64bit support, but not anytime soon, GM and Studio do not build 64bit games either. They use the .NET framework which is I believe both 32bit and 64bit. You also, do not have to uninstall 64bit Java, you can install 32bit and 64bit in parallel.

Just install 32bit Java in parallel and change the settings.ini launch command for LGM and it should work.

Off-Topic / Re: Castle Game Engine FOSS under LGPL with Linking exception
« on: October 10, 2014, 04:14:14 PM »
That's a nifty little engine, I don't have anything against Pascal, I've never even seen any code written in it, so I can't really judge it. Looking at some Pascal examples, it just looks like Delphi to me. I don't really judge python or any language either, each of them have them bad aspects and good aspects. It's just like how everybody says all code not written by them looks like crap. Thanks for sharing!  (Y)

Also, I think maybe we should make a subforum specifically for talking about other game engines.

General ENIGMA / Who fixed arrays?
« on: October 10, 2014, 02:42:33 AM »
I was going to do a little something, and realized that arrays were fixed. I can't quite recall who or what fixed them or when they did it, but they do seem to work now.

The following builds fine for me on the latest master.
Code: (EDL) [Select]
var ass;
ass[0] = 69;


Whoever it was, thank you!

Additionally that thing I was trying to do was provide an array length function, but sadly JDI fails to parse the templates, it keeps saying the function is undefined unless I change the parameter
Code: (C++) [Select]
  template <unsigned array_size>
  unsigned array_length_1d(variant (&v)[array_size]);

General ENIGMA / Re: General Enigma Questions
« on: October 10, 2014, 02:42:13 AM »
Bing Crosby used to whip his children with a belt.

Off-Topic / BlitzBasic Gone Free and Open Source!
« on: October 10, 2014, 02:12:13 AM »
I've always been a big fan of the BlitzBasic engine and products, though never really having used them that much, I liked the environment much better over GM. It made it very easy to manage objects and everything from code and for novices to learn without having to create excessive GUI infrastructures. Well anyway since Mark Sibly is focused on Monkey X now, they've put Blitz Plus and Blitz 3D up for free. Blitz Max and the programming manual are still being commercially sold.

You can read the official announcements on the home page and the forum threads.

Anybody not already aware, Monkey X is an open source cross-platform game engine with the BASIC programming language as well, sort of based on BlitzBasic. For $100 it can export to numerous modules including Android, Playstation, Xbox, and other platforms. The IDE is built, quite evidently, with the Qt Framework, and it's a very nice IDE.