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: 3D functions and capabilities
« on: March 26, 2014, 11:32:28 am »
Project Mario crashes for me now after I merged my branch again with Harri's stuff. Prior to that his last commits at least worked, as in no segfault, and the main menu would at least draw "PRESS START" and the main room would draw at least the water, skybox, and HUD.

We could also write the sampler our selves :P

Project Mayo don't work in Studio :P

Anyway, that doesn't matter, even if you did fix it one of those ways, it would still be technically broken. My specific game it may not matter, but on someone elses game it would. Possibly 3D shadow examples, etc.

No Harri, I meant I've been the one advocating OpenGL1 not focus on dumping the FFP or anything like that, as Josh stated, me and you are treating OpenGL 1 so that it works on both old and new computers, and OpenGL3 targets the users with higher end graphics cards. The same is not being done with Direct3D, Direct3D9 and 11 systems are meant to be the same as OpenGL 3.

Edit: Also, fuck the idea of rendering to a framebuffer and waiting to copy to the main buffer. Just render to the main buffer but don't swap.

Edit 2: Also there are other ways of using textures themselves as render targets we could look into that might possibly fix the flipping shit.

Edit 3: Also none of you guys solutions is going to work anyway, why? Because of surface_get_texture() and games like Project Mario that use surfaces as textures :P

Quote from: JoshDreamland
The rest can be moved to universal,
Toss it in General, because Universal is getting to be a mess and needs cleaned up and organized into folders or something.

Quote from: JoshDreamland
So you are trying to maintain forward compatibility. So that GL1 games can run on modern machines and old machines, while GL3 games only work on modern machines. I suppose that's acceptable, and probably beneficial as (1) it gives us more control over multiplication order (which was a problem for compatibility in the past) and (2) it gives users access to those matrices for math, in addition to a possible (3) that when lots of matrix math is done, communication with the graphics card can be reduced substantially.
Actually, that's been my doings, and I asked that he do the same.

Quote from: JoshDreamland
LGM should be giving texture data to us in the format most immediate to itself, which is probably right-side up. If GL or DX has to flip this texture to load it correctly, so be it. But what you might be missing is that it is not an option to only flip the projection: as soon as you start texturing in a surface, you'll find those textures are upside-down in the end. Using the GL1 API, we can invert the y-values for both the projection and the sampler matrices, thus mimicking DirectX's behavior. I see no reason to not do this.

If it's of any consolation, I am planning on this new compiler supporting scripting. So graphics systems will, ideally, be able to supply code to invert texture data at compile time, if need be. The new JDI I am currently hooking up has very nice AST evaluation support, so I believe EDL scripting in the compiler is going to be an option.
What's all this driver nonsense, as I already said, OpenGL reads textures into memory upside down. Direct3D can do either since you perform the memory allocation yourself. For the same reasons OpenGL and Direct3D both use BGRA internally, and why I switched ENIGMA to do the same.

LGM should be giving texture data to us in the format most immediate to itself, which is probably right-side up. If GL or DX has to flip this texture to load it correctly, so be it.
I agree with the former, but not the latter. Direct3D is completely unaffected by this issue and the BGRA byte ordering for the reasons stated above, that is, that you perform the memory allocation yourself and can easily swap the order bytes are transferred to the GPU with no performance difference.

imho, I am more comfortable with OpenGL's origin than Direct3D's

Issues Help Desk / Re: Enigma errors
« on: March 25, 2014, 01:53:14 pm »
Yes Harri, that was his issue. However, purely deleting the ProgramData folder did not solve it. He also had to rebuildcompiler from git-bash after re-extracting, but he did eventually get it working again.

The new Portable ZIP is live and ready for download.

Issues Help Desk / Re: Enigma errors
« on: March 24, 2014, 10:17:49 pm »
That was pretty hard to infer Harri, since you started off talking about it being a broken update I ended up ignoring the rest of what you said, updating from Git should not break anything.

Tips, Tutorials, Examples / Re: GameMaker related magazines
« on: March 24, 2014, 08:27:33 pm »
Lol, that was back in the day, you can read articles written by 15 y/o me XD

Issues Help Desk / Re: Enigma errors
« on: March 24, 2014, 08:24:19 pm »
No that is not the issue at all, he's getting the errors from the General platform headers and changes I made. He just needs to rebuild all or delete eobjs to clear the cache.

Third Party / Re: FakeFullscreen.dll
« on: March 24, 2014, 12:22:21 am »
Heh, I really despise the premise of the whole thing, ENIGMA too. I just think we have a better C-inspired cross-platform wrapper for DirectX on Linux, etc.

Third Party / Re: FakeFullscreen.dll
« on: March 23, 2014, 09:39:41 pm »
Quote from: TheExDeus
To make os_is_paused() work like GM it will have to be a lot less pretty (we need additional variable to check if window was in focus last frame).
You're assuming that the 1 step is guaranteed.

At any rate I have fixed it and tested it for Win32 to have the expected behavior and committed, the following works fine. I still need to test and make sure Studio does actually behave this way, and if so then it can be merged. However, I don't agree at all with the way they handled this, honestly it was so stupid, they should have just made FocusGain and FocusLost events.
Code: (EDL) [Select]
if (os_is_paused()) {
show_message_async("OS Paused");

This was the commit amended that fixed the issue.
I also had to apply the following fix to that.

Edit: I have tested Studio, and the current version appears to behave exactly the same, so the pull request is good to merge. However I have noticed a new inconsistency in the asynchronous dialog functions.

Ok, I honestly can't believe what I am reading, but it appears Josh has gone over to the dark side. I am not going to stand here and let our OpenGL system be dumbed down because of DirectX.

Issues Help Desk / Re: Windows 7 x64 and ENIGMA?
« on: March 22, 2014, 10:25:44 pm »
Looks like we need to make an ENIGMA distribution that works with restricted user privileges. I don't know if anyone recalls but GM also used to support such a version but no longer does.

Issues Help Desk / Re: Windows 7 x64 and ENIGMA?
« on: March 22, 2014, 01:15:35 pm »
And if he didn't update, it makes no sense why he's receiving the error.

Third Party / Re: FakeFullscreen.dll
« on: March 22, 2014, 01:07:19 pm »
It was a simple mistake I overlooked it, cut me a break. I have amended the pull request with the fix for XLIB and Win32.

Quote from: TheExDeus
But that again break not only the naming convention but common sense. The OS is NOT paused when that function returns true, the game is not even paused. The game just lost focus. But at least if I make two versions they can be both used - this one will work just like GM:S and the window_get_focus() will work like it really should.
Yeah no, that is not what the function is at all. It has to do with mobile devices and whether the application is in the background, ie. you have an incoming call on your cell phone.

Quote from: TheExDeus
I will implement this to make it work like a window function and then implement the os_ one to work like GM.
Or you could just, you know, amend my commit since I've outlined other functions as well.