Pages: « 1 2
  Print  
Author Topic: Windows GIT patch  (Read 7775 times)
Offline (Unknown gender) TheExDeus
Reply #15 Posted on: May 15, 2012, 10:18:55 AM

Developer
Joined: Apr 2008
Posts: 1886

View Profile
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.
Logged
Offline (Male) polygone
Reply #16 Posted on: May 15, 2012, 10:40:32 AM

Contributor
Location: England
Joined: Mar 2009
Posts: 803

View Profile
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.
« Last Edit: May 15, 2012, 11:09:40 AM by polygone » Logged
I honestly don't know wtf I'm talking about but hopefully I can muddle my way through.
Offline (Female) IsmAvatar
Reply #17 Posted on: May 15, 2012, 11:31:03 AM

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

View Profile Email
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.
« Last Edit: May 15, 2012, 11:39:41 AM by IsmAvatar » Logged
Offline (Male) polygone
Reply #18 Posted on: May 15, 2012, 12:06:14 PM

Contributor
Location: England
Joined: Mar 2009
Posts: 803

View Profile
Meh, the speed is nothing just gonna add an if inside screen redraw.
Logged
I honestly don't know wtf I'm talking about but hopefully I can muddle my way through.
Offline (Unknown gender) TheExDeus
Reply #19 Posted on: May 15, 2012, 01:17:54 PM

Developer
Joined: Apr 2008
Posts: 1886

View Profile
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);
Logged
Offline (Female) IsmAvatar
Reply #20 Posted on: May 15, 2012, 01:28:18 PM

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

View Profile Email
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.
Logged
Offline (Male) polygone
Reply #21 Posted on: May 15, 2012, 03:19:27 PM

Contributor
Location: England
Joined: Mar 2009
Posts: 803

View Profile
It's fine I've sorted it. This is getting far too over-discussed it's beyond trivial  ;D
« Last Edit: May 15, 2012, 03:43:15 PM by polygone » Logged
I honestly don't know wtf I'm talking about but hopefully I can muddle my way through.
Offline (Unknown gender) TheExDeus
Reply #22 Posted on: May 15, 2012, 04:16:06 PM

Developer
Joined: Apr 2008
Posts: 1886

View Profile
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.
Logged
Offline (Male) polygone
Reply #23 Posted on: May 15, 2012, 04:21:41 PM

Contributor
Location: England
Joined: Mar 2009
Posts: 803

View Profile
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?
« Last Edit: May 15, 2012, 05:42:08 PM by polygone » Logged
I honestly don't know wtf I'm talking about but hopefully I can muddle my way through.
Offline (Female) IsmAvatar
Reply #24 Posted on: May 15, 2012, 09:45:56 PM

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

View Profile Email
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.
« Last Edit: May 15, 2012, 09:47:38 PM by IsmAvatar » Logged
Offline (Male) Josh @ Dreamland
Reply #25 Posted on: May 15, 2012, 09:57:49 PM

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

View Profile Email
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.
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) cheeseboy
Reply #26 Posted on: May 19, 2012, 06:27:03 PM

Member
Location: The internet
Joined: Mar 2011
Posts: 107

View Profile
you're all sooo lazy. heres windres.exe

USER WAS NEARLY BANNED FOR THIS POST (but Josh is too fucking lazy)
« Last Edit: May 20, 2012, 04:19:23 PM by Josh @ Dreamland » Logged
Offline (Female) IsmAvatar
Reply #27 Posted on: May 23, 2012, 10:19:40 PM

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

View Profile Email
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
Logged
Offline (Unknown gender) testaccount
Reply #28 Posted on: June 02, 2012, 01:04:38 PM
"Guest"


Email
HELLO I ASSURE QUOB.
Logged
Pages: « 1 2
  Print