Mac OpenGL rendering Glitch
BlitzMax Forums/BlitzMax Programming/Mac OpenGL rendering Glitch
| ||
| Hi My game is running at around 300~450 FPS I'm using a Fixed Rate Logic set to 60 FPS under OpenGL with Box2d and BlitzMax vSync on (or flip 1 if you prefer). Everything run smoothly on windows desktops, mainly because the refresh rate is higher than 60 hertz (most of the time 85 hertz, but even if I'm setting all CRT down to 60 hertz it's drawing and running smoothly at fullscreen and window mode). The problem is on Mac system. On a Macbook Air, the LCD is refreshing at 60 hertz (like with many laptop LCD). What I describe is not typical screen tearing (and since vSync is on it shouldn't happen anyway, no the graphic card isn't vSync disabled, why changing this default setting anyway ?). On desktop, in-game FPS is strictly identical to the screen refresh rate (no more, no less). But on the Macbook Air, you never get 60 FPS every time... I don't know why but every ~3 seconds my FPS counter drop to 49~52 FPS and at that very moment some game objects in movement are visually stuttering (not correctly drawn). It's not extremely perceptible but certainly not tolerable (it last 2 or 3 frames). I try to match greater FPS, use delta-timing instead of fixed rate logic (but it's certainly not the problem), turned off the garbage collector, shutdown every background task, but even without vSync turned on (at 450 FPS) the problem persist! It's maybe related to box2D under Mac (since nothing happen in Windows) but I didn't found any problem related to it while searching on the Internet (and anyway there is so much different optimized version out there that no comparison can be made anymore). I try to run a few similar 2d games to see if something like this happening but of course the answer is not... Does anyone already experience this before ?? |
| ||
| I would suspect a cleanup routine in the mac end of box2D personally. If you can make a portable sample to demonstrate the issue (if possible) you're more likely to get some more specific help. |
| ||
| Maybe you're doing too much processing (especially with lots of physics) and not giving the o/s a chance to do what it needs, so it has to take cpu time from you suddenly.... maybe if you put in a Delay 1 in your main loop it might have time to do what it wants more smoothly? |
| ||
| @ImaginaryHuman I tried but it's not a "suffocating" CPU, no luck :( @Ima747 Possibly, but then why should I notice this under a new MacBook Air and not under my old PC ? The engine is so big I would literally have to write another game to post a sample. So I know it's a bit hard to help this way :( It's probably totally unrelated due to the experimental nature of HTML5 but I already saw something similar on some Monkey examples : http://www.into-games.com/sledgenet/files/Multi-scrapper/MonkeyGame.swf |
| ||
| you would see it on the mac but not the PC because of the way they both handle memory, specifically cleanup. You noted you disabled the garbage collector but that is specifically the blitz GC, not the OS level cleanup routine. Things handled internally by Box2D would be released by Box2D, and as such would be handled between box and the OS. I'm unfamiliar with box so I don't know if this is a legitimate possibility in this case or not, but it's certainly technically possible... A simple example can be demonstrated under iOS where there is no GC. All memory must be manually managed, and that means explicitly freeing things when your done, however there's 2 ways to free things... you can either free them immediately or que them for collection on the next pass of the main thread by tagging them with autorelease which puts them in a collection pool... Why this is relevant: if you loop for a long time creating and freeing objects, but you're actually autoreleasing them rather than freeing them, the main loop never gets a chance to clean the pool and you can run out of memory... if you don't run out of memory but you've created a LARGE release pool it can cause a hiccup when the pool gets cleared. You can make the pool large enough the OS can't do it in one pass because it would take too long... With that said, factor in the overhead of a garbage collector, and the structure of the MacOS kernel compared to the windows kernel and how they manage things internally and there's tons of room for differences. On the other hand maybe it has nothing to do with Box. Maybe it's something with the openGL drivers on the macbook. Maybe you're triggering a lot of memory paging to the graphics card. Maybe your PC has more VRAM, or a better pipe for texture loading... maybe there's a background process on your mac, a service, etc. This is why tearing it apart is the only way to get a real solution, otherwise all you can do is guess and poke and hope you find it, which is usually good enough :0) |
| ||
| Damned ! ima747 you point in the right direction ! I'm now more confidant in the fact that it's the Mac version of Box2d that is responsible of that lag. I can clearly reproduce this problem while my player is moving on a fast treadmill or jumping high thanks to a giant spring. This is bad :( I'm sure I am not releasing or creating any physical body object around the moment this lag appears. But like you said it's maybe hidden deeper in the Box2d library. Which is bad because I'm not up to date and probably never be. I will have to release a demo version of my game and ask a few Mac owner to try on their machine (but one of the specificity of Apple is that every machine isn't so different one from another, so the lag will probably occur anyway). I hope for a background process or services but I seriously doubt about it. No that I can concentrate my research on something, I will head up to the box2d forum to see if I found solutions. otherwise all you can do is guess and poke and hope you find it, which is usually good enough :0) You are right, hopefully there is knowledgeable peoples on this community that can greatly help the brainstorming ^^ |
| ||
| What card are you using, sounds like micro-stuttering - http://en.wikipedia.org/wiki/Micro_stuttering Last edited 2011 |
| ||
| Gloups... I hope not ! It's a new MacBook Air with an Intel HD Graphics 3000 384 MB5 and the SSD harddrive. I robbed twelve Belgian grannies to pay me this machine in order to support Mac Os folks for my game. It's working perfectly under Windows in every window mode and on 3 different machines; working better in Fullscreen mode under Mac Os X Lion but it's atrocious in window mode... By the end of the week I could probably produce a little demonstration to let you try, think is I know practically nobody here with Mac. It's considered as a no gaming deluxe computer where I live ^^ |
| ||
| Old thread but since I found the answer to this question I answer myself. I'm using a fixed rate logic. Because of Box2d most movement are physics based. I tough first it would be enough but you still need to interpolate values (tween them) from old position/rotation to new one before rendering! The micro-stuttering was only appearing with a few tick delays on 60hz which is rather tight with a 60 FPS Fixe Rate Logic. I hooked this interpolation process to my overly modified scrollable camera and to moving objects as well and now everything is smooth as silk EVERYWHERE :) Doing this at the end is quite a pain and messing my framework a bit. Mainly with object composed of multiple shapes (you have to hold every shapes rotation/position, it's dirty). I will remember this on the next project for sure ! Last edited 2012 |
   |