I know, not again... I've got tearing. :(
BlitzMax Forums/BlitzMax Programming/I know, not again... I've got tearing. :(
| ||
| So I'm using totally fixed-rate logic + render in my game, synced to 60hz. I'm in OGL on an Intel Mac, and I'm getting fullscreen tearing. Where to begin? Could delta-timing sort this out? It shouldn't be necessary though, should it? And it would be a lot of work to implement into my long and convoluted code... I'll be uploading a demo soon, if there's anyone who can test it for me, I had planned to anyway, just to the Blitz community for a sort of pre-alpha testing as the engine is 99.9% complete, hence I am now thinking about issues such as screen-modes, flicker and what-have-you. But off the tops of your heads is there anything I could try without having to use delta timing? Thanks in advance, Sonic |
| ||
| You are using Max2D and do not use Flip 0 or -1, I assume from this posting, is that right? (because Synced to 60hz does not mean that you use flip 1 or flip, it could as well mean that you try to fake fixed rate syncing through timer or time difference / delay and flip 0) |
| ||
| I call vanilla flip(), no delays, in Max2D. Any ideas on where to start? |
| ||
| The only idea I have: Your screen is not 60hz but 72 or 75 and you initialize graphics with 60hz which will lead to tearing ... |
| ||
| Can you describe what you're calling tearing? Tearing should never occur unless you're not syncing your buffer flips with VSync or your drivers are set to not VSync at all. I can't remember for the life of me what Max2D does with vanilla Flip(). I would assume it attempts to VSync, since previous Blitz's did. |
| ||
| I personally use high rate logic and forget aboout all this delta timing shannigans - but then, most of my stuff doesn't need delta timing. Anyway... Flip with no paramters seems to invoke some sort of random software syncing that can look a total mess with tearing all over the place, although this only tends to be in a windowed mode. Under Windows, this saves a lot of processor consumption (i.e. 10%-ish instead of 99%). I've not tested this under Mac. On my Mac's (Intel and PPC) I tend to stick with Flip True (or 1) and I have no problems with tearing. They are both laptops, but I am confident both act as any Mac desktop would. If you need a tester, I'm only too happy to help. |
| ||
| Use flip 1 for hardware syncing (i.e. no tearing unless gfx card driver has forced vsync off) and it that fails it'll drop back to software syncing (same as flip -1). Flip 0 means run at full framerate but will always tear so is not really suitable imho. |
| ||
| Hi. @Dreamora I'm using an Intel iMac so I'm sure my screen does have a higher refresh rate than 60Hz... I don't initialise Graphics() with any Hz parameter as I heard that Blitz defaults to 60Hz. But it still shouldn't tear, should it? I thought it would just double some frames? @Gabriel The tearing looks like two frames meeting at a certain horizontal line on the screen, ie you can see the screen being drawn. It's been described in other threads and I'd say it's exactly like that! @JazzieB Well that's really interesting - I think you might have found a workable solution for me: I assumed that Flip with no paramaters would call Flip(1) and therefore I hadn't tested it... But it seems to have cleared up the problem - in fact Flip(-1) seems to produce the same results as Flip without params. However there is now a slight sluggishness to the response of the main character which is interesting... Is it adding a slight delay with Flip(1)? Anyway, this is a much better situation, so it looks like I might go with it. It will need further testing though. Thanks! @Grey Alien Thanks, that seems to confirm what JazzieB was saying, I wonder if this situation will work cross-platform? On Windows, I assume I will have to ensure the end-user has VSync enabled on their card? I will test this on my Windows partition soon... |
| ||
| Just to add to what I said - there is now no tearing with Flip(1), however it seems to be a lot slower to respond in general, for example there is a visible delay when the character turns from the point you input the command, which wasn't there with Flip(). As is often the case fixing one problem creates another... It might just be a case of choosing a lesser evil - which would be the delayed response, as I can't live with the tearing. |
| ||
| With Flip 1 and 60 FPS, you have 16ms per mainloop, so if you input is faster, it will simply have to wait for the next frame to become visible. But you could use hooks to get around that "wait for sync" delay state. That shouldn't be the show stopper in BM as it was in B3D. |
| ||
| Hmm, thanks Dreamora, I will look into it. I have uploaded a version of the game in the Showcase area,so anyone with accees to an Intel Mac please check it out! Showcase Entry |
| ||
| Oh, and there's now a Windows build too... See what you think! |
| ||
| I should have said that what I said applied to Windows only, I don't know about the Mac (yet) |
   |