ENIGMA Forums

General fluff => Announcements => Topic started by: Josh @ Dreamland on May 14, 2012, 02:35:56 AM

Title: Windows GIT patch
Post by: Josh @ Dreamland on May 14, 2012, 02:35:56 AM
Since polygone is decidedly a whiny bitch, and TGMG goes AWOL every time I hint at this idea, I have gone and compiled a patch file which can be extracted over the git repository on Windows to make everything run as it did before the migration--almost.

The patch can be downloaded here:
http://dl.dropbox.com/u/1052740/WinPatch.7z

You can download the git repository as a zip archive from the GitHub page (https://github.com/enigma-dev/enigma-dev). It is the button that has a picture of a cloud with an arrow pointing down out of it, that says "ZIP" next to it. You would have to be polygone to miss it.

Anyway, this patch archive is by no means complete. It contains the following:

This means that the following must still be done at some point by somebody:

Anyway, I'm tired. So I think I'll take the next three minutes to rant about polygone.

You see, the reason I wnt ahead and did this is because polygone was pissing and moaning about how someone needs to "fix" the git repository. What no one here seems to understand is that the git repository is not broken.. Nor was it before I assembled this patch. There were three reasons I modified the git repository while making this patch:

That said, let me reiterate: The Git repository is not broken. The reason we are having these release issues is because no one can come up with a good place to put binary files, so everyone just cries and throws a tizzy instead of obtaining them for themselves. In actuality, the problem was so minuscule that even cheeseboy could solve it with his installer zip.

Now, that zip of cheeseboy's did have an issue that Rusky introduced when he decided there was no reason we would ever need a custom ALURE build. You see, Rusky lives in this ideal world where every software component on the internet is specially tailored to fit every possible need. Back in the real world, however, people like dazappa just want their game to be self-contained, and ALURE/AL are not conducive to that. So provisions had to be made. I have added to this patch a detailed set of steps followed to get from the latest version of ALURE distributed on KittyCat's website to the version you see shipped with ENIGMA. If anyone deletes that again, I will track him or her down and break every bone in every finger he or she possesses individually, using two spoons.

The moral of this story is, being a whiny bitch might actually annoy Josh into doing something.

inb4 polygone/HaRRi have some stupid problem with the patch.
Title: Re: Windows GIT patch
Post by: polygone on May 14, 2012, 06:06:37 AM
Oh yay it actually works, except you forgot to put plugins in the patch archive. I needed to run LGM through bash still as well.

Quote
The moral of this story is, being a whiny bitch might actually annoy Josh into doing something.
That is a good moral you're right, I have learnt well from the ways of the sacred Cheeseboy one. You're like one of those parents where the kids know they should just scream and cry until they get what they want, it seems to be the only effective way to do get you to do anything.

But thanks for sorting it though Josh. :)

On a completely separate note someone (I'm guessing harri) seems to have fucked something up somewhere with a recent commit because everything is getting drawn upside down and some other oddities are also occurring with the drawing in 3d (probably related).
Title: Re: Windows GIT patch
Post by: Josh @ Dreamland on May 14, 2012, 08:12:13 AM
It's probably to do with HaRRi's screen_save being upside-down because bitmap is upside-down. He probably fixed it by just making everything else upside-down.

I've added the plugins folder to the archive.
Title: Re: Windows GIT patch
Post by: polygone on May 14, 2012, 08:16:33 AM
Code: [Select]
    int FBO;
    glGetIntegerv(GL_FRAMEBUFFER_BINDING_EXT, &FBO);
    glScalef(1, (FBO==0?-1:1), 1);
It's this he added to screen_redraw, I presume FBO value isn't 0 for me. Also Harri why did you move glClear(GL_COLOR_BUFFER_BIT | GL_DEPTH_BUFFER_BIT); back inside the background_showcolor check? It needs to be executed regardless of the background_showcolor being true.
Title: Re: Windows GIT patch
Post by: Josh @ Dreamland on May 14, 2012, 08:53:18 AM
I don't know how many regressions we've had as a result of everyone's refusal to use the git repository. I'm telling you now, though, I'm not fixing them all twice.
Title: Re: Windows GIT patch
Post by: TheExDeus on May 14, 2012, 11:15:26 AM
Finally.. after several months of non-stop whining we achieved something. Thank you. I will check to see what I need to whine next about.

Poly, is it upside down only when drawing in 3d? FBO should be 0 for the screenbuffer, so that is why I added that if statement. When drawing on surfaces you have to flip the image so its correct, while in drawing on screen you don't have to (as the viewport is flipped). Maybe I should just make the viewport flipped for surfaces as well...

Also, glClear(GL_COLOR_BUFFER_BIT | GL_DEPTH_BUFFER_BIT) is to clear to color. If you do that even when background color is disabled, then it will still clear to black as this is the function that actually clears it, the other (glClearColor) just sets the color. For correct behavior seen in GM you have to have it this way, although I still see flickering when background color is disabled (double buffering?, or screen refresh problems, as the flickering goes away when the game "synchronizes" with the monitor or at least I think that is the case). Does this cause problems? As I didn't try 3d, and in 2d I didn't see anything. Maybe show screenshot.

And I also had to use msys bash to run exe, but just for the first time. After that I could run it normally. And AL doesn't work because its not rebuilding right? I have this:
http://pastebin.com/rvjrgJ5E

Also, if something doesn't work, then it is technically broken. ENIGMA didn't work on Windows, then it was broken on windows. Of course it would work with modifications and whatnot, but that is just like saying - if you buy a car without an engine, then car is not broken, its just not functional because of a missing piece, which you could add yourself if wanted.
Title: Re: Windows GIT patch
Post by: polygone on May 14, 2012, 11:23:40 AM
Quote
Poly, is it upside down only when drawing in 3d? FBO should be 0 for the screenbuffer, so that is why I added that if statement. When drawing on surfaces you have to flip the image so its correct, while in drawing on screen you don't have to (as the viewport is flipped). Maybe I should just make the viewport flipped for surfaces as well...
FBO is 48 for me, and it's just a simple 2D game.

Quote
Also, glClear(GL_COLOR_BUFFER_BIT | GL_DEPTH_BUFFER_BIT) is to clear to color. If you do that even when background color is disabled, then it will still clear to black as this is the function that actually clears it, the other (glClearColor) just sets the color. For correct behavior seen in GM you have to have it this way, although I still see flickering when background color is disabled (double buffering?, or screen refresh problems, as the flickering goes away when the game "synchronizes" with the monitor or at least I think that is the case). Does this cause problems? As I didn't try 3d, and in 2d I didn't see anything. Maybe show screenshot.
I can't remember what the problem was, but I moved it out of there because there was definitely some big problem I had when using 3D which moving it resolved.

Quote
And AL doesn't work because its not rebuilding right? I have this:
http://pastebin.com/rvjrgJ5E
I never had that problem myself, sound are working fine for me now.

Quote
And I also had to use msys bash to run exe, but just for the first time. After that I could run it normally.
Funny, I have to run through bash all the time, otherwise it doesn't find make.

Using my old gcc.ey has resolved it though:

Code: [Select]
%e-yaml
---
Name: Mingw GCC G++
Native: Yes
Maintainer: cheeseboy
Target-platform: Windows

# Some info about it
path: \MinGW\bin\;\MinGW\msys\1.0\bin\;
tcpath: /MinGW/bin:/bin:
make: \MinGW\msys\1.0\bin\make.exe
binpath: \MinGW\bin\
defines:  \MinGW\bin\cpp -dM -x c++ -E $blank
searchdirs: \MinGW\bin\gcc -E -x c++ -v $blank
searchdirs-start: "#include <...> search starts here:"
searchdirs-end: "End of search list."
resources: $exe
cppflags:
cxxflags: -I../Additional/Windows/include
cflags:
ldflags: -L../Additional/Windows/lib -static-libgcc -static-libstdc++
links:

Build-Extension:
Run-output: $tempfile
Run-Program: $game
Run-Params:
Title: Re: Windows GIT patch
Post by: Josh @ Dreamland on May 14, 2012, 03:27:07 PM
Of course that resolved it. The only reason anyone has that issue is because cheeseboy wrote a gcc.ey that assumes your systems are set up with MinGW and MSys in the path. That idiot.

That's why you see this line in it:
Maintainer: cheeseboy
Pretty much the mark of being broken. This is what we get for allowing Rusky to pull arbitrary changes from him without review and against my instruction.

Implement those same changes in the old wingcc_template.eyt and include it in the Autoconf folder, and ENIGMA.exe will generate correct gcc.ey files once more, and no one will ever have to run ENIGMA from Bash again. Except those people whose systems completely fuck up mkdir through CreateProcess, but I've never actually used such a machine. I'm wondering if they even exist.
Title: Re: Windows GIT patch
Post by: TheExDeus on May 14, 2012, 03:43:39 PM
Quote
FBO is 48 for me, and it's just a simple 2D game.
That is very weird. Altough we use EXTensions. Maybe I should rewrite it to OpenGL current spec? I don't know what will happen to compatiblity though. Basically, I use GL_FRAMEBUFFER_BINDING_EXT to get current framebuffer, but I can't find documentation for that anymore. I can find GL_DRAW_FRAMEBUFFER_BINDING here: http://www.opengl.org/sdk/docs/man4/xhtml/glGet.xml . And it clearly says:
"If the default framebuffer is bound, this value will be zero. The initial value is zero". So maybe that would fix it.. Although 0 IS bound by default (for example, when surface_reset_target() is called). Do you use surfaces in you game? Does calling surface_reset_target() in create event of some object fixes this flipping problem?

Quote
I can't remember what the problem was, but I moved it out of there because there was definitely some big problem I had when using 3D which moving it resolved.
Maybe depth buffer should be cleared in either case when using 3d, but color buffer shouldn't be cleared when background color is disabled. Anyway, if you show the example for the problem you are having, then maybe I will be able to fix it.

Quote
I never had that problem myself, sound are working fine for me now.
Weird.
Title: Re: Windows GIT patch
Post by: Josh @ Dreamland on May 14, 2012, 03:46:33 PM
It may be that configuring ENIGMA to build static libraries for the codecs (similar to what I have done for ALURE) will fix your problem, HaRRiKiRi.
Title: Re: Windows GIT patch
Post by: polygone on May 14, 2012, 05:05:27 PM
I don't use surfaces in the game, no. And it happens on all games not just that one. I'm going to change it back to how it was in my next commit.

Quote
Maybe depth buffer should be cleared in either case when using 3d, but color buffer shouldn't be cleared when background color is disabled. Anyway, if you show the example for the problem you are having, then maybe I will be able to fix it.
Yes it was the depth buffer that needed to be cleared, but like I said I can't remember exactly what the problem was but it was necessary to clear the depth buffer every step. So yeah, I'll split it up and always clear the depth buffer but leave the color clear just inside the background_showcolor.
Title: Re: Windows GIT patch
Post by: IsmAvatar on May 14, 2012, 06:53:11 PM
Quote
The only reason anyone has that issue is because cheeseboy wrote a gcc.ey that assumes your systems are set up with MinGW and MSys in the path. That idiot.
I'd sooner blame MinGW and MSys for not setting up the path variable. It *always* annoys me in Windows when I install MinGW and can't immediately type "gcc" from the command line because I then need to do this additional, practically undocumented step of adding gcc to PATH, whereas EVERY other program I've used with a cli knows to add its bin/ directory to PATH.

Quote
This is what we get for allowing Rusky to pull arbitrary changes from him without review and against my instruction.
s/Rusky/Polygone/
Code: [Select]
$ git log Compilers/Windows/gcc.ey
commit 7082cf98ac0b3ddf99168cfdd2e5292ac8fac590
Author: polygoned <flexaplex@gmail.com>
Date:   Sun Mar 18 00:01:42 2012 +0000

    final changes

commit c8dbf7fc3f14e22da8d29c79d686ed18503f7b29
Author: polygoned <flexaplex@gmail.com>
Date:   Sat Mar 17 22:49:23 2012 +0000

    blahh

commit 2e9961ac82f4067243f753bf36aeb5db712355e1
Author: polygoned <flexaplex@gmail.com>
Date:   Sat Mar 17 22:36:08 2012 +0000

    Just switching over entirely to cb's fork
Title: Re: Windows GIT patch
Post by: polygone on May 14, 2012, 07:05:09 PM
He knows I did it, but it's sorted now anyway so whatever.
Title: Re: Windows GIT patch
Post by: TheExDeus on May 15, 2012, 04:49:48 AM
Quote
. I'm going to change it back to how it was in my next commit.
And I will change it back, as that will just break surfaces when using screen_redraw(). The problem is something on your end, and I will maybe try the other gl check and send it to you so you can see if that helps. I have ran that code with surfaces on 2 PC's (one of which is laptop), and without using surfaces on about 4 more (my friends tested some programs I made). As well as Ism. So its something weird on your PC and changing the code to break on all is not the best option. Maybe its something to do with your driver or gfx card. What gfx card do you have? I suppose it could have sketchy support for GL standard. Also, compile a game with the upside down screen and send it to me. Wanna know if its compile time or runtime problem.
Title: Re: Windows GIT patch
Post by: polygone on May 15, 2012, 05:57:30 AM
My system info:
http://pastebin.com/S2neAq4S

Did all the systems you test it on have fbo support? The fact that I don't might be the underlying problem.

Here is a compiled game:
http://www12.zippyshare.com/v/83747739/file.html

While on the subject of surfaces did you ever look into pbuffer for surfaces at all? I'm looking for an alternative for those without fbo support, of course directX is also an option.
Title: Re: Windows GIT patch
Post by: TheExDeus on May 15, 2012, 10:18:55 AM
Quote
Did all the systems you test it on have fbo support? The fact that I don't might be the underlying problem.
Ah, yes. I didn't know there existed PC's without FBO support, but that could certainly be the problem. I tested it on all PC's and friends PC's I know (oldest is about 6-7 years old PC) and all of them support FBO's so I didn't notice any problem. Adding additional check inside the redraw function would make it unnecessarily slower... I don't really know what to do then. Maybe Josh has an idea? Theoretically using surface_is_supported() shouldn't be that big of an impact, but I am not sure. Does surface_is_supported() return 0 on your PC Poly?

Quote
Here is a compiled game:
Yes, it looks fine. So its your cards lack of GL support.

Quote
While on the subject of surfaces did you ever look into pbuffer for surfaces at all? I'm looking for an alternative for those without fbo support, of course directX is also an option.
pbuffers are old (out of date), a lot slower (on newer hardware) and more limited. If you want to make a directx port then go ahead. I have never done anything with it, so I don't know anything about it.
Title: Re: Windows GIT patch
Post by: polygone on May 15, 2012, 10:40:32 AM
Quote
Theoretically using surface_is_supported() shouldn't be that big of an impact, but I am not sure. Does surface_is_supported() return 0 on your PC Poly?
Yes, it returns 0. I suggest maybe defining a variable stating whether fbos are functional, then ifdef'ing it. I don't really want the screen_redraw being slower either when I'm not using FBOs at all.

Quote
]pbuffers are old (out of date), a lot slower (on newer hardware) and more limited.
I know they're obviously going to be worse, but can offer them as an alternative to fbos for those that can't use fbos. I don't know anything about them though, so I'm unsure how well they could match what GM surfaces do.
Title: Re: Windows GIT patch
Post by: IsmAvatar on May 15, 2012, 11:31:03 AM
If you're concerned about the speed of checking FBO availability, simply call it once and set a global variable for it. FBO support is not going to change throughout the game.
Title: Re: Windows GIT patch
Post by: polygone on May 15, 2012, 12:06:14 PM
Meh, the speed is nothing just gonna add an if inside screen redraw.
Title: Re: Windows GIT patch
Post by: TheExDeus on May 15, 2012, 01:17:54 PM
Adding global will not change anything much as you still need to do the if check somewhere. And you can't ifdef it as you still can compile the project even when you don't have it supported and give it to others who have FBO support and they can run it fine. And if I compile a project where I use surfaces and you run it on a PC which doesn't have FBO support it will still flip the screen. So we need to do real time if checking either way. Maybe creating the global variable static would make the compiler to compile the tertiary operation as static as well, like true?0?1 would optimize as 0 no? But it can only do that at compile time, so again, same problem. But this is the worst case (and only for now) scenario to fix this:
Code: [Select]
glScalef(1, (surface_is_supported()?(FBO==0?-1:1)?-1), 1);
Title: Re: Windows GIT patch
Post by: IsmAvatar on May 15, 2012, 01:28:18 PM
Quote
Adding global will not change anything much as you still need to do the if check somewhere
However, for a time-intensive operation, adding global will only need to perform the check once, rather than every time.
Title: Re: Windows GIT patch
Post by: polygone on May 15, 2012, 03:19:27 PM
It's fine I've sorted it. This is getting far too over-discussed it's beyond trivial  ;D
Title: Re: Windows GIT patch
Post by: TheExDeus on May 15, 2012, 04:16:06 PM
Quote
However, for a time-intensive operation, adding global will only need to perform the check once, rather than every time.
Wouldn't you need to check the global every redraw anyway? Like what Poly just did with GLEW_EXT_framebuffer_object.

Quote
It's fine I've sorted it. This is getting far too over-discussed it's beyond trivial  ;D
That is not the most elegant way, but I also can't think of anything better. Also, you declare "int FBO;" twice, so I don't know why it doesn't error at compile time for you. Also, I am glad someone got around making the paths part of instances. I doubt its working right now because you don't execute path_update() anywhere yet (also, the path_update function doesn't have the position calculations in it anyway), but at least its moving forward.
Title: Re: Windows GIT patch
Post by: polygone on May 15, 2012, 04:21:41 PM
Quote
Also, you declare "int FBO;" twice
oops. although I don't know why it doesn't error either...

Quote
I doubt its working right now because you don't execute path_update() anywhere yet
I execute it in the step event, like GM does. It has a check for whether the path extension is used before executing it so it's fine to work with extensions.

However you're right, it doesn't work right now because josh hasn't added support for local variables set in extensions to be modified in functions, at the moment it just completely corrupts the structure. With the actual path_update function you just need to use the path local variables (after they work) like path_speed, path_position, path_scale etc. you're probably more suited to that than me though since you wrote the paths.

$
oh and something else, can you tell me what happens when you enable windows widgets please harri?
Title: Re: Windows GIT patch
Post by: IsmAvatar on May 15, 2012, 09:45:56 PM
Quote
Wouldn't you need to check the global every redraw anyway? Like what Poly just did with GLEW_EXT_framebuffer_object.
let's assume you have a function, bool canFBO() which takes 20 milliseconds to return - so it's a time-intensive operation.

Scenario 1: We use canFBO() everywhere we want to use FBO, so we know if we have to use an alternative method instead. Every single call is 20 milliseconds, and those add up. Your game will run a little sluggish.
Scenario 2: We store the return value of canFBO() in a global variable right up front. Start of game is delayed 20 milliseconds. Every time thereafter that we want to use FBO, we check our global variable, which takes nanoseconds. At the cost of 20 milliseconds up front, we have sped up the rest of our game (or, rather, prevented it from slowing down with all those checks).

So to answer your question, yes, we will have to keep checking the variable, but if canFBO() is a time-intensive operation, it's *much* more preferable to check the variable than to check the function.


However, as polygone pointed out, canFBO() is actually a trivial and non-time-intensive operation, so it doesn't matter if you use a global or the function.
Title: Re: Windows GIT patch
Post by: Josh @ Dreamland on May 15, 2012, 09:57:49 PM
Until you obtain a recent build of windres.exe, widgets will not work. Period. I doubt HaRRi's version is any more recent than yours, polygone.
When we do have such a build in hand, we can implement project icons and executable info.
Title: Re: Windows GIT patch
Post by: cheeseboy on May 19, 2012, 06:27:03 PM
you're all sooo lazy. heres windres.exe (http://link removed)

USER WAS NEARLY BANNED FOR THIS POST (but Josh is too fucking lazy)
Title: Re: Windows GIT patch
Post by: IsmAvatar on May 23, 2012, 10:19:40 PM
A discussion between Polygone and Harrikiri regarding Path implementation and troubles has been split into a new topic:

http://enigma-dev.org/forums/index.php?topic=971
Title: Path trouble
Title: Re: Windows GIT patch
Post by: testaccount on June 02, 2012, 01:04:38 PM
HELLO I ASSURE QUOB.