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

1666
Issues Help Desk / Re: 3D functions and capabilities
« on: March 26, 2014, 03:03:37 PM »
I'll GDB right now.

Use the following to resize images.
Code: ( (Unknown Language)) [Select]
[img width=xxx]url[/img]
Edit: Weird, I am not getting the segfaults now. But here is what it looks like in GL3

At the main menu, I only see the "Press Start" text, everything else is black. Also GL3 runs significantly slower than GL1 (about 50% slower)

1667
Programming Help / Re: Access instance variables stored in ds_list
« on: March 26, 2014, 11:37:03 AM »
I'll bet it was that damn Sasquatch again.


1668
Issues Help Desk / Re: Windows 7 x64 and ENIGMA?
« on: March 26, 2014, 11:35:00 AM »
This is also probably why Studio and no other IDE writes programs to temp Josh. See I told you we need to get moving with my idea.

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

1670
We could also write the sampler our selves :P

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

1672
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

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

Quote
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

1674
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.
http://enigma-dev.org/docs/Wiki/Install:Windows

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

1676
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

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

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

1679
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.
https://github.com/RobertBColton/enigma-dev/commit/28b0f89bba5f1c38daf3944781cfe495d92af51f
I also had to apply the following fix to that.
https://github.com/RobertBColton/enigma-dev/commit/a6706ff2d12141c561d4d2d172826955e224cbc7

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.

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