TheExDeus
|
 |
Reply #15 Posted on: May 15, 2012, 10:18:55 am |
|
|
 Joined: Apr 2008
Posts: 1860
|
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? Here is a compiled game: Yes, it looks fine. So its your cards lack of GL support. 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
|
|
|
|
polygone
|
 |
Reply #16 Posted on: May 15, 2012, 10:40:32 am |
|
|
 Location: England Joined: Mar 2009
Posts: 794
|
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. ]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.
|
|
|
|
polygone
|
 |
Reply #18 Posted on: May 15, 2012, 12:06:14 pm |
|
|
 Location: England Joined: Mar 2009
Posts: 794
|
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.
|
|
|
|
|
polygone
|
 |
Reply #21 Posted on: May 15, 2012, 03:19:27 pm |
|
|
 Location: England Joined: Mar 2009
Posts: 794
|
It's fine I've sorted it. This is getting far too over-discussed it's beyond trivial 
|
|
« 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.
|
|
|
TheExDeus
|
 |
Reply #22 Posted on: May 15, 2012, 04:16:06 pm |
|
|
 Joined: Apr 2008
Posts: 1860
|
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. It's fine I've sorted it. This is getting far too over-discussed it's beyond trivial  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
|
|
|
|
polygone
|
 |
Reply #23 Posted on: May 15, 2012, 04:21:41 pm |
|
|
 Location: England Joined: Mar 2009
Posts: 794
|
Also, you declare "int FBO;" twice oops. although I don't know why it doesn't error either... 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.
|
|
|
IsmAvatar
|
 |
Reply #24 Posted on: May 15, 2012, 09:45:56 pm |
|
|
LateralGM Developer
 Location: Pennsylvania/USA Joined: Apr 2008
Posts: 877
|
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
|
|
|
|
Josh @ Dreamland
|
 |
Reply #25 Posted on: May 15, 2012, 09:57:49 pm |
|
|
Prince of all Goldfish
 Location: Pittsburgh, PA, USA Joined: Feb 2008
Posts: 2950
|
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
|
|
|
|
IsmAvatar
|
 |
Reply #27 Posted on: May 23, 2012, 10:19:40 pm |
|
|
LateralGM Developer
 Location: Pennsylvania/USA Joined: Apr 2008
Posts: 877
|
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=971Title: Path trouble
|
|
|
Logged
|
|
|
|
testaccount
|
 |
Reply #28 Posted on: June 02, 2012, 01:04:38 pm |
|
|
"Guest"
|
HELLO I ASSURE QUOB.
|
|
|
Logged
|
|
|
|
|