glutSolidSphere lighting issue when further away - glut

For some reason I get weird patchy lighting effects/flickering when using glutSolidSphere and the camera is relatively far away from the object. See below:
This also happens with glutSolidCube and I assume the others as well.
I've tried everything I could find in similar questions but no luck with that
Glusphere giving strange lighting
Lighting does not work with gluSphere
I've tried enabling all of the below and different combinations of the below and tried doing so in multiple places
glEnable(GL_BLEND);
glEnable(GL_DEPTH_TEST);
glEnable(GL_LINE_SMOOTH);
glEnable(GL_NORMALIZE);
glDepthFunc(GL_LEQUAL);
And also removed all glEnable(GL_TEXTURE_2D); anyhere
The problem happens when I turn on lighting with glEnable(GL_LIGHT0); and occurs with glShadeModel(GL_SMOOTH) and glShadeModel(GL_FLAT) and also if I don't enable GL_COLOR_MATERIAL and even occurs with just a positional light like so:
float light_position[] = {100.0f, 100.0f, 100.0f, 1.0f};
glLightfv(GL_LIGHT0, GL_POSITION, light_position);
What else could this be?

Finally figured out the problem after forever. Apparently using a very low value (even if above zero) for zNear in the gluPerspective view causes this problem.
The following fixed the problem:
gluPerspective(90, (float) width / (float) height, 0.1f, Z_RANGE);
See: https://gamedev.stackexchange.com/a/55516

Related

libgdx camera position using viewport

I am rather experiences libgdx developer but I struggle with one issue for some time so I decided to ask here.
I use FillViewport, TiledMap, Scene2d and OrtographicCamera. I want the camera to follow my player instance but there are bounds defined (equal to mapsize). It means that camera will never ever leave outside of map, so when player comes to an end of the map camera stops following and he goes to the edge of the screen itself. Maybe sounds complicated but it's simple and I am sure that you know what I mean, it's used in every game.
I calculated 4 values:
minCameraX = camera.viewportWidth / 2;
minCameraY = camera.viewportHeight / 2;
maxCameraX = mapSize.x camera.viewportWidth / 2;
maxCameraY = mapSize.y - camera.viewportHeight / 2;
I removed not necessary stuff like unit conversion, camera.zoom etc. Then I set the camera position like this:
camera.position.set(Math.min(maxCameraX, Math.max(posX, minCameraX)), Math.min(maxCameraY, Math.max(posY, minCameraY)), 0);
(posX, posY is player position) which is basically setting camera to player position but if it's to high or too low it sets it to max or min defined before in right axis. (I also tries MathUtils.clamp() and it works the same.
Everything is perfect until now. Problem occures when aspect ratio changes. By default I use 1280x768 but my phone has 1280x720. Because of that bottom and top edges of the screen are cut off because of the way how FillViewport works. Because of that part of my map is cut off.
I tried to modify maximums and minimums, calculate differences in ratio and adding them to calculations, changing camera size, different viewports and some other stuff but without success.
Can you guys help?
Thanks
I tried solution of noone and Tenfour04 from comments above. Both are not perfect but I am satisified enough i guess:
noone:
camera.position.x = MathUtils.clamp(camera.position.x, screenWidth/2 + leftGutter, UnitConverter.toBox2dUnits(mapSize.x) - screenWidth/2 + rightGutter);
camera.position.y = MathUtils.clamp(camera.position.y, screenHeight/2 + bottomGutter, UnitConverter.toBox2dUnits(mapSize.y) - screenHeight/2 - topGutter);
It worked however only for small spectrum of resolutions. For strange resolutions where aspect ratio is much different than default one I've seen white stripes after border. It means that whole border was printer and some part of the world outside of border. I don't know why
Tenfour04:
I changed viewport to ExtendViewport. Nothing is cut off but in different aspect ratios I also can see world outside of borders.
Solution for both is to clear screen with same color as the border is and background of level separatly which gave satisfying effect in both cases.
It stil has some limitations. As border is part of the world (tiled blocks) it's ok when it has same color. In case border has different colors, rendering one color outside of borders won't be a solution.
Thanks noone and Tenfour04 and I am still opened for suggestions:)
Here are some screenshots:
https://www.dropbox.com/sh/00h947wkzo73zxa/AAADHehAF4WI8aJ8bu4YzB9Va?dl=0
Why don't you use FitViewport instead of FullViewport? That way it won't cut off your screen, right?
It is a little bit late, but I have a solution for you without compromises!
Here width and height are world size in pixels. I use this code with FillViewport and everything works excellent!
float playerX = player.getBody().getPosition().x*PPM;
float playerY = player.getBody().getPosition().y*PPM;
float visibleW = viewport.getWorldWidth()/2 + (float)viewport.getScreenX()/(float)viewport.getScreenWidth()*viewport.getWorldWidth();//half of world visible
float visibleH = viewport.getWorldHeight()/2 + (float)viewport.getScreenY()/(float)viewport.getScreenHeight()*viewport.getWorldHeight();
float cameraPosx=0;
float cameraPosy=0;
if(playerX<visibleW){
cameraPosx = visibleW;
}
else if(playerX>width-visibleW){
cameraPosx = width-visibleW;
}
else{
cameraPosx = playerX;
}
if(playerY<visibleH){
cameraPosy = visibleH;
}
else if(playerY>height-visibleH){
cameraPosy = height-visibleH;
}
else{
cameraPosy = playerY;
}
camera.position.set(cameraPosx,cameraPosy,0);
camera.update();

iOS cocos2D Chipmunk Body's velocity is invalid

In cocos2d-spritebuilder 3.4 I've create my physicworld and my player like many of the official examples.
self.sprite.physicsBody = [CCPhysicsBody bodyWithCircleOfRadius:10 andCenter:self.anchorPoint];
self.sprite.physicsBody.type = CCPhysicsBodyTypeDynamic;
etc...
So, when I try to move my sprite to the right for example with
[self.sprite.physicsBody applyImpulse: CGPointMake(32,0)];
my app going in crash reporting this:
Aborting due to Chipmunk error: Body's velocity is invalid.
Failed condition: v.x == v.x && v.y == v.y
Source:.../Source/libs/cocos2d-iphone/external/Chipmunk/src/cpBody.c:106
Chipmunk source's have:
-(void)applyImpulse:(CGPoint)impulse { _body.velocity = cpvadd(_body.velocity, cpvmult(CCP_TO_CPV(impulse), 1.0f/_body.mass));}
So, I knew MASS was setted by default to 1.0f, but I want to try to set this value by hand..) :
self.sprite.physicsBody.mass = 1.0f
Same error, same results...
But if I try to set:
self.sprite.physicsBody.body.mass = 1.0f
It work great.
So, what's the differences btw these two parameters?
Why applyImpulse take only body.mass?
As far as I know, Chipmunk doesn't play nice when applying a "big" impulse. What you should try and do is build up velocity over several frames.
Edit: Check this link http://forum.cocos2d-swift.org/t/ccphysics-applyimpulse-not-working/12151/12

applyBlurWithRadius working on iPhone 6, not 6+ (UIImage+ImageEffects)

I'm using Apple's UIImage+ImageEffects category from WWDC (2013?)
This method works just fine on iPhone 6, but creates a really strange unblurred, oversaturated image on iPhone 6 Plus:
[self applyBlurWithRadius:60 tintColor:[UIColor colorWithWhite:1.0 alpha:0.3] saturationDeltaFactor:2.4 maskImage:nil];
iPhone 6 (proper):
iPhone 6 Plus (weird):
Any idea what's going on?
Update: I've determined through trial and error that setting the blurRadius to anything less than or equal to 50 shows up OK, so it's related to the radius. I'd still like to know what exactly is causing it to goof on the larger screen.
I know this question is old and the OP has since moved on, but I would like to explain why it's different on each phone... for future generations.
The iPhone6 and the iPhone6+ have different screen resolutions. Mainly, the iPhone6 is has a scale of 2.0, while the iPhone6+ has a scale of 3.0.
Why does this matter?
In the source code for applyBlurWithRadius in the source file UIImage+ImageEffects.m, you will find these lines:
CGFloat inputRadius = blurRadius * [[UIScreen mainScreen] scale];
uint32_t radius = floor(inputRadius * 3. * sqrt(2 * M_PI) / 4 + 0.5);
if (radius % 2 != 1) {
radius += 1; // force radius to be odd so that the three box-blur methodology works.
}
You can see that the inputRadius will be different based on what the scale of the screen is. So, on the iPhone6, this value will be 60*2 (end result for radius will be: 227), and on the iPhone6+ the value will be 60*3 (end result for radius will be 339). This will obviously produce the different results since they are different values.
As for why the color difference? I am pretty sure the radius shouldn't exceed 255 otherwise undefined results may occur (probably integer overflow, causing color components to wrap back to zero). Since the iPhone6+'s screen scale value pushes it above this value, you see weird results, but not on the iPhone6 since it's below that threshold.
You should be able to see the same weirdness happen on an iPhone6 by using the value of 90 for the blurRadius parameter.
Side note: You shouldn't need values above 30 for parameter blurRadius anyway -- the results won't be much different beyond that point.
Hope this helps you.

Sprite-kit - Facing the hero? ( rotating to the direction of another node)

I have two spriteNodes hero and the enemy, both with rectangular physicsBody applied.
In the update, when the hero gets to the certain point, e.g hero.position.y <= 300 I want the enemy to rotate and face the the hero as it moves down.
the only sample code I found was the Adventure from Apple which has a faceTo class but I found it very complicated to use. I am looking for a nice and clean solution for it.
Thanks in advance.
The most basic implementation should look something like this:
- (void)rotateNode:(SKNode *)nodeA toFaceNode:(SKNode *)nodeB {
CGFloat angle = atan2f(nodeB.position.y - nodeA.position.y, nodeB.position.x - nodeA.position.x);
if (nodeA.zRotation < 0) {
nodeA.zRotation = nodeA.zRotation + M_PI * 2;
}
[nodeA runAction:[SKAction rotateToAngle:angle duration:0]];
}
It's important that you understand what is happening. Look up and read about atan2 (http://en.wikipedia.org/wiki/Atan2) and try to understand how the code above works.
You can use the xScale property of SKNode to make the sprite face the other way. This can be done by setting:
sprite.xScale = -1.0;
However, this has been proved to cause problems with the physicsBody, as can be seen from this question:
Flipped x-scale breaks collision handling (SpriteKit 7.1)
The solution for this problem is given there itself by JKallio.
He suggests keeping your sprite as a child of another SKNode (to which you apply the physicsBody) and changing the xScale property of the child node where needed. This is what I am using in my own project as well.

How to correctly paint a huge image

I'm fairly new to wxWidgets so please bear with me. Let's say I have a 10Kx10K image and my wxScrolledWindow has a size of 640x480. I load the whole image into a wxBitmap which I use in my paint function.
Now in my OnPaint function I just say
wxPaintDC dc(this);
dc.DrawBitmap(_Bitmap, 0, 0 );
This somewhat works for the first few paints but soon the Window content is out order and artifacts appear. This happens very fast when I move a scroll bar back and forth very quickly.
I use the latest wxWidgets on a Windows 7 machine.
So, how can I improve my painting code?
Many thanks,
Christian
Using a 10000x10000 wxBitmap is a bad idea on its own, it may simply fail to be created on an older system (that's 400MiB of video RAM!). Drawing it entirely is sheer madness.
I don't know where does your data come from but in a typical case of e.g. a map to be shown on screen, you should break it into tiles, convert the tiles that are currently visible on screen to wxBitmap (or several of them) and draw only those.
Then you may optimize your drawing by using double buffering (which is relatively useless under Windows 7 that double buffers everything on its own) and otherwise, but you should be using a reasonably-sized backing store bitmap.
This sounds like something that might be helped by using double buffering.
The first thing to start trying is to replace wxPaintDC with wxBufferedPaintDC
For more suggestions, here is a wiki article on the subject: http://wiki.wxwidgets.org/Flicker-Free_Drawing
As Ravenspoint kindly pointed out, there is an article on wxWidgets' wiki. So according to that article two things need to happen. First override the EVT_ERASE_BACKGROUND with an empty function.
void Canvas::EraseBackground( wxEraseEvent& WXUNUSED(event))
{
}
And second to implement a basic double buffering scheme. Here is how I did it.
void Canvas::OnPaint(wxPaintEvent& WXUNUSED(event))
{
int x, y;
GetViewStart(&x, &y);
wxRect Client_Area = GetClientRect();
int width = Client_Area.width;
int height = Client_Area.height;
wxBitmap Current = _Bitmap.GetSubBitmap(wxRect( x * 10, y * 10, width, height ));
wxPaintDC dc(this);
dc.DrawBitmap(Current, 0, 0, false );
}
My scroll rate for both x and y is set to 10. That's why I multiply the view start coordinates.
Any more insight is very welcome.
Thanks,
Christian