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

Developing ENIGMA / Re: Window Alpha and Message Box
« on: January 31, 2014, 11:03:20 pm »
Is somebody going to merge this pull request here or what, it is completely unrelated to any of this icon stuff and only contains bugfixes and 4 added functions.

I'll put one of these icons into LGM and commit it and build that LGM for the next portable ZIP. But this pull request needs merged first, and an icon needs picked. I vote for the 3rd or 4th if all gears are made pure white.

I also think alpha should be 0-1. It's the way it usually is and it is mostly how it is in GM and ENIGMA right now (I actually can't think of a function taking an unsigned char). So we should stick with one convention.
draw_set_alpha_test_ref - Sets the reference value for alpha testing from 0 to 255 (default value is 0)
Code: (gml) [Select]
col = draw_getpixel_ext(mouse_x, mouse_y);
alpha = (col >> 24) & 255;
blue = (col >> 16) & 255;
green = (col >> 8) & 255;
red = col & 255;
Code: [Select]
buffer The buffer to write the information to.
a The alpha value for the colour (0 - 255).
r The red component part of a colour (0 - 255).
g The green component part of a colour (0 - 255).
b The blue component part of a colour (0 - 255).

Using double for alpha is inconsistent with all other color functions for RGB accepting 0 to 255 and returning 0 to 255. I am glad YoYoGames is finally correcting this.

Quote from: JoshDreamland
I don't care how you feel about using a float for alpha. If you don't use a float, you're wasting three bytes of alignment, anyway.
Also just to build on top of that, it is against ISO RGB.
Quote from: ISO/TS 22028-3:2012
ISO 22028-3:2012 specifies a family of scene-referred extended colour gamut RGB colour image encodings designated as reference input medium metric RGB (RIMM RGB). Digital images encoded using RIMM RGB can be manipulated, stored, transmitted, displayed or printed by digital still picture imaging systems. Three precision levels are defined using 8-, 12- and 16-bits/channel.

An extended luminance dynamic range version of RIMM RGB is also defined, designated as extended reference input medium metric RGB (ERIMM RGB). Two precision levels of ERIMM RGB are defined using 12- and 16-bits/channel.

FP-RIMM RGB, a floating point version of RIMM RGB, defines the expression method of RIMM RGB in a floating point figure. Three precision levels of FP-RIMM RGB are defined using 16-, 32- and 64-bits/channel.

Developing ENIGMA / Re: Window Alpha and Message Box
« on: January 31, 2014, 10:34:13 am »
I don't care how you feel about using a float for alpha. If you don't use a float, you're wasting three bytes of alignment, anyway.
int is all you ever need for RGBA, 4 bytes total, and no more, the system and the monitor can't even display anything higher, let alone could your eye notice it that is why it's full color, the only argument I've read for using floats is that it is apparently easier to understand... why people think that I do not know

Even worse. I don't care what you make the icon; don't make it anything that even remotely implies we are supporting a brand. Especially not that brand. The icon I made that was nothing but circles reminded you of .NET, so you replaced it with a goddamn XBox controller. Let me tell you, the XBox reminds of of .NET.
Well you could have made more, a variety, a selection at the very least. Make some pretty ones, and make them all game related.

Developing ENIGMA / Re: Window Alpha and Message Box
« on: January 31, 2014, 09:01:00 am »
Conventionally, alpha is a float.
I am not sure if you mean GM or in graphics programming such as OpenGL, but you already know how I feel about alpha being anything more than unsigned char.

But some GML functions accept 0 to 255 for an alpha and others take float.

And why is the game icon a sixaxis controller?
Yeah that icon you made started making me violently ill everytime I saw it, it made me think of the .net framework or something similar.

If you want me to be more coy about this, I can tell you that ENIGMA now compiles on the .NET Framework and XNA if you like :)

ALLCAPS BOARD / Rock Monster
« on: January 31, 2014, 08:35:39 am »

We were on the moon, everybody had - matching socks! Somebody went exploring and there they saw a rock!

But it wasn't a rock...

it was a - rock monstaaaa!!!!

Developing ENIGMA / JDI Definitions Fix
« on: January 31, 2014, 05:44:33 am »
So I finally managed to figure out a little bit about how Josh's compiler works and was able to fix the issue with why definitions modified was populating keyword and function lists for the plugin with only those that were unscoped.

The following commit contains the fix.

I have also partially corrected the issue with them not showing up properly in the Function List panel and the autocompletion window.
The following is the commit to the LGM plugin that resolves this.

As you can see in the following image not only does it display correct but ENIGMA specific functions such as those for threads will now syntax highlight.

While I am on the subject, this window from the plugin should have access to all definitions and be able to filter them, for debugging purposes it is useful to look up definitions and tokens from other namespaces and what not. This could also all be done from a single window.

I created a mockup of what the frame could look like in Qt.

Issues Help Desk / Re: Particles not displaying properly
« on: January 31, 2014, 01:21:35 am »
Ok I will need to investigate, do you happen to have a minimal GMK or something for me to test with?

Off-Topic / Re: New Member Intro + Other
« on: January 30, 2014, 10:55:02 pm »
It's not added yet because I haven't had the time. It is not that important on desktops where video memory is not quite as expensive and bigger games such as Battlefield, SimCity, etc. require effective use of multi-texturing which ironically can have the same outcome in reducing memory usage. Texture paging is more of an issue for mobile games where AGP memory is limited.

Developing ENIGMA / Window Alpha and Message Box
« on: January 30, 2014, 10:10:30 pm »

Tinkering around I add two new functions to ENIGMA which GM doesn't have.
Code: (cpp) [Select]
void window_set_alpha(unsigned char alpha);
unsigned char window_get_alpha();

This is the pull request implementing the functions.

Documentation is available on the Wiki.

Now this also gave me the idea that we could overload all of these window functions to accept the Win32 handle allowing them to work with multiple windows. Another important thing this would rectify is removing the need for message_* functions, such as message_alpha, allowing you to obtain the window handle of a message box function and simply use window_set_alpha()

We should also consider doing the message functions entirely differently and modeling them after something like Java/C#/VB message boxes like the following.
Code: (EDL) [Select]
mid = message_box_show("Hello, world!");
wid = message_box_get_window(mid);
window_set_alpha(wid, 150);
message_box_set_visible(mid, true);
This could all be done without removing support for the old version of the functions.

This would be the equivalent in Java. (even though there is a bug in JDK 1.7 making this example cause an exception)
Code: (java) [Select]
JOptionPane.showMessageDialog(null, "Hello, World!");

There is however another issue and that is our Message Box system does not have a dialog result interface.

Developing ENIGMA / Re: Asynchronous Dialogs/Win32 Threads Implemented
« on: January 30, 2014, 07:58:23 pm »
Yeah that is pretty much what this is, the changes are already in the new Windows Portable ZIP.

Developing ENIGMA / Re: Asynchronous Dialogs/Win32 Threads Implemented
« on: January 30, 2014, 08:36:17 am »
This can also be done to speed up the loading, as you can load many resources in parallel.
I have been thinking about that this entire time. Though what got me started on it was video streaming for that new guy who posted yesterday.

edit: And just for a record - what namespace the threads run in? Can you actually access instance local's and such? Or just globals like GMThreads?
If you can access object locals from a script then yes obviously, but that could lead to the mutex issues DaSpirit and dazappa are complaining about.

And is it async to room_speed too? Like an infinite loop in the script will run it as fast as possible (like thousands of times a second and thus create a CPU spike)?
Hum, that's a good question, I think I want to say it goes to infinity because only the main thread does the framerate stuff. So nothing is blocking the execution. But there is always sleep()

Just set a global.framerate_rendered = true; everytime the draw event occurs, then check that in your thread.

Developing ENIGMA / Re: Asynchronous Dialogs/Win32 Threads Implemented
« on: January 30, 2014, 05:32:24 am »
Not to sound like I am ignoring you we discussed this further on the IRC.

But I want to add to this post I also went ahead and added the asynchronous dialog functions to a new Asynchronous dialog extension. It works perfectly just like Studio and I ran plenty of tests on it. The reason for making it an extension is because of how retarded these functions are and that they rely on other extensions such as data structures as well as threading (though not an extension).

I have partially corrected their stupidity by making the async functions not just return a retarded id but they actually return the index of the thread. Then you can bypass the async dialog event all together and just call thread_get_return(id);

Interim documentation is available on the Wiki.

Issues Help Desk / Re: Particles not displaying properly
« on: January 29, 2014, 09:50:38 pm »
Try Build->Settings and the "API" tab, see how it is in another graphics system, I noticed particles in OpenGL1 are like really thick or bigger for some reason.

Off-Topic / Re: New Member Intro + Other
« on: January 29, 2014, 09:49:03 pm »
Indeed, and I am a windows user
Not anymore, I just added threads for Windows to couple our POSIX threads so that script threading will work on all platforms. This way you can do the above mentioned escape key to close video playback with DirectShow. If you don't mind I am also going to move this over to off-topic.
Please read the following topic for details, however it is not merged to the main repo and is not quite yet available for use.

When I it is merged I can write you an example with a basic threaded video playback if you like.

also they have a new audio engine, no regrets, in fact I remember there was a good deal / special for GM8.1 to GM:S, even got the HTML5 deal too.
The new audio system was overdue, their first implementation of OpenAL which we had for years was pure butchery. Then they just recently deprecated all of the music functions after they realized how dumb they were. It is great but their execution of their ideas is really botched.

That is standard on most company forums.
That is really bad though, because people have their freedom of speech, and competition is good for consumers.

There are certain things I notice are present in the GM IDE that are not in LateralGM such as autocomplete
LGM has automatic completion in the code editors and the shader editor, start typing and hit CTRL+Space.

I think any  good, honest, serious company (serious about their product and the very people that put bread and butter on their table and reason for existing) should openly accept criticism, providing it is genuine and constructive.
Exactly, this also allows them to publicly address it and with good PR skills they could even for instance apologize and promise to do better making it a positive for their image and say "hey look at least we don't ignore your complaints and criticisms like other companies" etc.

BTW, if I were to compare GM Studio and ENIGMA in terms of GML, how compatible would you say is your program in terms of %
Well it depends, to Studio, about 70% of functions are there, 20-25% you may experience bugs or issues with. But as for deprecated functions we have most if not all of the deprecated functions.

It would be good to have the LateralGM automatically determine which APIs
to check, based on the project, to avoid having to check anything, allow
manual or automatic would be nice.  Example if a project uses audio, the proper default setting would be selected and greyed out, so you cannot disable it as your project would NOT compile otherwise.   If a program uses video, then directshow would be checked and greyed out.....if you used physics, same......etc.
Save your project as an EGM and it will save all of ENIGMA settings, so you won't have to set them each time you run. We just can't save those settings to Global Game Settings or GMX or GMK because those aren't our formats, so we invented our own.

Developing ENIGMA / Re: Win32 Threads Implemented
« on: January 29, 2014, 09:22:53 pm »
You mean mutual exclusion, not important right now since its only used for asynchronous messages atm.

I was not aware of that though, so thanks for informing me. However I have to disagree because if somebody has that going on they clearly haven't written their threads correctly. This occured with me when making some plugin changes where the plugin plays red light green light when loading so that it can register the EGM format, start loading the plugin DLL in a thread, and at the same time return to the main LGM thread and start loading the project and then fire a reload performed which propagates back to the plugin when the driver is finished being initialized.

Take a look at the main entry point for the LGM plugin and you'll see.
The fixes to my original version are thanks to TGMG.

Developing ENIGMA / Re: Win32 Threads Implemented
« on: January 29, 2014, 08:49:45 pm »
What do you mean ENIGMA's not thread-safe? It's at least thread-safe for basic functions for now, and asynchronous dialogs.