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: February 02, 2014, 10:52:04 AM »
Quote from: JoshDreamland
(1) ISO RGB does not concern alpha. Maybe you meant to quote something from ISO that includes the letter "A" or specifically mentions phrases such as "alpha" or "opacity."
Actually, the point was the lack-thereof the alpha.
Note: 48-bit color is also known as deep color and implemented as 16-bits/channel.
One of such programs that can do so is 3DS Max.,topicNumber=d30e524001

Quote from: TheExDeus
This is because GM stores all colors in int's (and so does ENIGMA
And so does Java, GM used to waste the remaining 8 bits.

Quote from: JoshDreamland
Moreover, Game Maker never used ARGB.
OpenGL prefers RGBA, Direct3D prefers ARGB. I am not arguing with you, it is just important to note.
Quote from: OpenGL Wiki
Colors in OpenGL are stored in RGBA format. That is, each color has a Red, Green, Blue, and Alpha component

f we keep adding their shit ass implementations of functions, then ENIGMA will become as chaotic as GM. We either have to start ditching that useless compatibility with GM:S. Or stick with their bull only in their functions and use correct (and consistent) convention in ENIGMA functions. I wouldn't have problems with ENIGMA taking 0-1 in all functions, but that clearly isn't possible. Unless we start putting colors in structs (or classes) and then overloading drawing functions.
3 chars followed by a double is more consistent than 4 bytes? I don't think so, YYG is at least getting closer to following standards, however very poorly. I am not arguing in favor of their shit, I am simply arguing in favor of color being 4 bytes internally. Whatever wrappers or macro's people want to add for color is perfectly fine.

In fact, we can just go ahead and drop this debate and macro all the functions that accept color, people can toggle between 4 floats, 3 bytes and a float, or 4 bytes, whatever the hell they choose, and we just convert it internally to 4 bytes RGBA, which is what our engine should use always, everywhere. I'll write it up later.

They are not merged because we are clearly still talking about them. We should do this more often, than just randomly merge all the stuff you somehow deem worthy. That is why I personally only merge for bug fixes instead of new functionality. For new functions I actually try to read the code.
Then you didn't bother to read the pull request, it contains a number of fixes to outstanding bug reports including ENIGMA being able to finally syntax highlight its own functions, but that topic was buried by this one, but both were part of the same pull request.

Quote from: JoshDreamland
, as to whether we embrace a byte for alpha or a float, I am unbiased. Robert prefers bytes for the sake of cards with terrible memory bandwidths, which ENIGMA should ideally cater to as well.
Macro expansion Joshi, read above. On a side note, I just realized your name is Yoshi with a 'J'.
But also, I actually want ENIGMA's defaults to be RGBA, as in make_color_* would expand to the following...
Code: (C++) [Select]
unsigned make_color_rgba(byte red, byte green, byte blue, byte alpha);
unsigned make_color_argb(byte alpha, byte red, byte green, byte blue);

Proposals / Re: Request: Cursor Lock
« on: February 02, 2014, 10:07:06 AM »
Please for the love of god make sure you enable "Freeze form when the game loses focus" even non-GM games fail to do this. It is damn near impossible to ALT+Tab out of games, fucking pisses me off sooooooo bad.

Proposals / Re: Embed SWF?
« on: February 02, 2014, 10:03:25 AM »
Yes I wanted that in my Mario topic as well because I have YouTube videos. Josh randomly added the double clicking to size up images for me already so I am sure he can figure it out.

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: (C++) [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.