Pages: 1 2 »
  Print  
Author Topic: Windows GIT patch  (Read 7817 times)
Offline (Male) Josh @ Dreamland
Posted on: May 14, 2012, 02:35:56 AM

Prince of all Goldfish
Developer
Location: Pittsburgh, PA, USA
Joined: Feb 2008
Posts: 2958

View Profile Email
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. 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:
  • The ENIGMA.exe binary.
  • The LateralGM binary.
  • The ENIGMA plugin and JNA helper plugin.
  • The ALURE source, and the necessary configuration files to build it alongside ENIGMA and patch OpenAL into the EXEs.
  • Pre-built static libraries for libdumb, libvorbisfile, libvorbis, libogg, libzlib, and libffi.

This means that the following must still be done at some point by somebody:
  • Modify ALURE's makefile rule to rebuild on file update (I kind of just threw it together)
  • Modify the codecs to once again build alongside ENIGMA, as ALURE does.
  • Modify zlib and libffi to build alongside ENIGMA, or include their 64bit equivalents.
  • Tend that special something I forgot to do that will ever elude developers and bite users in the ass.

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 idiot cheeseboy committed the Windows GCC.ey, which varies from computer to computer. I needed to change two lines in it.
  • The newest ALURE calls its init statically, before main() starts, and was causing a segfault, so I needed to debug.
  • CXXFLAGS weren't getting set in debug mode, a problem that affects Git, SVN, Windows, and Linux alike.

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.
Logged
"That is the single most cryptic piece of code I have ever seen." -Master PobbleWobble
"I disapprove of what you say, but I will defend to the death your right to say it." -Evelyn Beatrice Hall, Friends of Voltaire
Offline (Male) polygone
Reply #1 Posted on: May 14, 2012, 06:06:37 AM

Contributor
Location: England
Joined: Mar 2009
Posts: 803

View Profile
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).
« Last Edit: May 14, 2012, 06:54:13 AM by polygone » Logged
I honestly don't know wtf I'm talking about but hopefully I can muddle my way through.
Offline (Male) Josh @ Dreamland
Reply #2 Posted on: May 14, 2012, 08:12:13 AM

Prince of all Goldfish
Developer
Location: Pittsburgh, PA, USA
Joined: Feb 2008
Posts: 2958

View Profile Email
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.
Logged
"That is the single most cryptic piece of code I have ever seen." -Master PobbleWobble
"I disapprove of what you say, but I will defend to the death your right to say it." -Evelyn Beatrice Hall, Friends of Voltaire
Offline (Male) polygone
Reply #3 Posted on: May 14, 2012, 08:16:33 AM

Contributor
Location: England
Joined: Mar 2009
Posts: 803

View Profile
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.
« Last Edit: May 14, 2012, 11:16:44 AM by polygone » Logged
I honestly don't know wtf I'm talking about but hopefully I can muddle my way through.
Offline (Male) Josh @ Dreamland
Reply #4 Posted on: May 14, 2012, 08:53:18 AM

Prince of all Goldfish
Developer
Location: Pittsburgh, PA, USA
Joined: Feb 2008
Posts: 2958

View Profile Email
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.
Logged
"That is the single most cryptic piece of code I have ever seen." -Master PobbleWobble
"I disapprove of what you say, but I will defend to the death your right to say it." -Evelyn Beatrice Hall, Friends of Voltaire
Offline (Unknown gender) TheExDeus
Reply #5 Posted on: May 14, 2012, 11:15:26 AM

Developer
Joined: Apr 2008
Posts: 1886

View Profile
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.
Logged
Offline (Male) polygone
Reply #6 Posted on: May 14, 2012, 11:23:40 AM

Contributor
Location: England
Joined: Mar 2009
Posts: 803

View Profile
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:
« Last Edit: May 14, 2012, 12:38:11 PM by polygone » Logged
I honestly don't know wtf I'm talking about but hopefully I can muddle my way through.
Offline (Male) Josh @ Dreamland
Reply #7 Posted on: May 14, 2012, 03:27:07 PM

Prince of all Goldfish
Developer
Location: Pittsburgh, PA, USA
Joined: Feb 2008
Posts: 2958

View Profile Email
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.
« Last Edit: May 14, 2012, 03:28:51 PM by Josh @ Dreamland » Logged
"That is the single most cryptic piece of code I have ever seen." -Master PobbleWobble
"I disapprove of what you say, but I will defend to the death your right to say it." -Evelyn Beatrice Hall, Friends of Voltaire
Offline (Unknown gender) TheExDeus
Reply #8 Posted on: May 14, 2012, 03:43:39 PM

Developer
Joined: Apr 2008
Posts: 1886

View Profile
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.
« Last Edit: May 14, 2012, 03:46:36 PM by HaRRiKiRi » Logged
Offline (Male) Josh @ Dreamland
Reply #9 Posted on: May 14, 2012, 03:46:33 PM

Prince of all Goldfish
Developer
Location: Pittsburgh, PA, USA
Joined: Feb 2008
Posts: 2958

View Profile Email
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.
Logged
"That is the single most cryptic piece of code I have ever seen." -Master PobbleWobble
"I disapprove of what you say, but I will defend to the death your right to say it." -Evelyn Beatrice Hall, Friends of Voltaire
Offline (Male) polygone
Reply #10 Posted on: May 14, 2012, 05:05:27 PM

Contributor
Location: England
Joined: Mar 2009
Posts: 803

View Profile
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.
Logged
I honestly don't know wtf I'm talking about but hopefully I can muddle my way through.
Offline (Female) IsmAvatar
Reply #11 Posted on: May 14, 2012, 06:53:11 PM

LateralGM Developer
LGM Developer
Location: Pennsylvania/USA
Joined: Apr 2008
Posts: 886

View Profile Email
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
Logged
Offline (Male) polygone
Reply #12 Posted on: May 14, 2012, 07:05:09 PM

Contributor
Location: England
Joined: Mar 2009
Posts: 803

View Profile
He knows I did it, but it's sorted now anyway so whatever.
Logged
I honestly don't know wtf I'm talking about but hopefully I can muddle my way through.
Offline (Unknown gender) TheExDeus
Reply #13 Posted on: May 15, 2012, 04:49:48 AM

Developer
Joined: Apr 2008
Posts: 1886

View Profile
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.
Logged
Offline (Male) polygone
Reply #14 Posted on: May 15, 2012, 05:57:30 AM

Contributor
Location: England
Joined: Mar 2009
Posts: 803

View Profile
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.
« Last Edit: May 15, 2012, 06:01:29 AM by polygone » Logged
I honestly don't know wtf I'm talking about but hopefully I can muddle my way through.
Pages: 1 2 »
  Print