for digital ebook using cocos2d, triangles are shown when the page is turning. It's bug?
(cocos2d sdk demo has same symptom)
This is documented, tut tut :)
Look for these lines in your AppDelegate...
// Create the EAGLView manually
// 1. pixelFormat can be RGB565 or RGBA8.
// 2. depth format of 0 bit. Use 16 or 24 bit for 3d effects, like CCPageTurnTransition
EAGLView *glView = [EAGLView viewWithFrame:[window bounds]
pixelFormat:kEAGLColorFormatRGB565 // kEAGLColorFormatRGBA8
depthFormat:GL_DEPTH_COMPONENT16_OES // GL_DEPTH_COMPONENT16_OES, use 0 if you don't need page transition
];
And make sure your depth format is at least GL_DEPTH_COMPONENT16_OES.
Related
I'm learning from the example of osgpackeddepthstencil of OSG. This example first renders a mask square into a RTTI camera, affacting the stencil buffer while leaving the color buffer untouched. The stencil test is:
osg::Stencil *stencil = new osg::Stencil;
stencil->setFunction(osg::Stencil::ALWAYS, 1, ~0u);
stencil->setOperation(osg::Stencil::KEEP, osg::Stencil::KEEP, osg::Stencil::REPLACE);
osg::StateSet *ss = geode->getOrCreateStateSet();
ss->setAttributeAndModes(stencil, osg::StateAttribute::ON|osg::StateAttribute::OVERRIDE);
ss->setAttribute(new osg::ColorMask(false, false, false, false),osg::StateAttribute::ON|osg::StateAttribute::OVERRIDE);
Then it renders a larger square into the same RTTI camera, setting the stencil test as not equal to 1. Then use the texture to render a square. The second stencil test codes are below:
osg::Stencil *stencil = new osg::Stencil;
stencil->setFunction(osg::Stencil::NOTEQUAL, 1, ~0u);
stencil->setOperation(osg::Stencil::KEEP, osg::Stencil::KEEP, osg::Stencil::KEEP);
osg::StateSet *ss = geode->getOrCreateStateSet();
ss->setAttributeAndModes(stencil, osg::StateAttribute::ON|osg::StateAttribute::OVERRIDE);
Everything goes fine, and the result is shown below. The clear color is green. The center of the square is green since the stencil buffer values are 1 in this small square due to the first round of rendering.
However, question comes when I change the second stencil test to be not equal to 0. According to my knowledge of stencil test, the result should be a reversed image of the previous one, which has a green boundary and a grey inner square. Quite confusing, the result is as follows which is a whole green:
What am I missing? How to interpret the second result? Any suggestions would be appreciated. Thanks! My OSG version is 3.4.0. My environment is : NVIDIA GTX 750 TI, Windows 10 64bit, Visual Studio 2013.
I created a rounded rectangle on illustrator and export in to png , then added this image to texturepacker and import to cocos2d here is my rectangle,
Have you any idea why there are white pixels on the corner.
Here is image https://dl.dropboxusercontent.com/u/9018754/Screen%20Shot%202014-07-31%20at%2023.28.52.png
Might be that the image was written as png8 with blending towards a white background in Illustrator.
Can you also post the png you created from Illustrator?
-- update --
The image looks fine. I think we can rule out problems with exporting the image.
In your settings "Premultiply Alpha" is off. When importing the image into cocos2d, did you enabled premultipled alpha?
Both values must be matching. Otherwise you will get some strange behaviour.
If it's on in TexturePacker and off in cocos2d you get black outlines.
If it's off in TexturePacker and on in cocos2d you get white outlines.
So: Try enabling it in TexturePacker.
Yes Premultiply Alpha solved my problem
Changing ccConfig.h to
#ifndef CC_FIX_ARTIFACTS_BY_STRECHING_TEXEL
#define CC_FIX_ARTIFACTS_BY_STRECHING_TEXEL 1
#endif
and setting premultiply alpha + exclude 1 solved my problem ,
It is written in the comment line
**
` If enabled, the texture coordinates will be calculated by using this formula:
- texCoord.left = (rect.origin.x*2+1) / (texture.wide*2);
- texCoord.right = texCoord.left + (rect.size.width*2-2)/(texture.wide*2);
The same for bottom and top.
This formula prevents artifacts by using 99% of the texture.
The "correct" way to prevent artifacts is by using the spritesheet-artifact-fixer.py or a similar tool.
Affected nodes:
- CCSprite / CCSpriteBatchNode and subclasses: CCLabelBMFont, CCTMXLayer
- CCLabelAtlas
- CCParticleSystemQuad
- CCTileMap
To enabled set it to 1. Disabled by default.
**
I couldnt figure out what is going on at the moment but I will check code deeper ,
Thank you Andreas Löw
Thanks for reading.
I'm working on a setup in Cocos2D 1.x where I have a huge CCLayerPanZoom in a scene with free panning and zooming.
Every frame, I have to additionally draw a CCRenderTexture on top to create "darkness" (I'm cutting out the light). That works well.
Now I've added single sprites to the surface, and they are managed by Box2D. That works as well. I can translate to the RenderTexture where the light sources ought to be, and they render fine.
And then I wanted to add a HUD layer on top, by adding a CCLayer to the scene. That layer needs to contain several sprites stacked on top of each other, as user interface elements.
Only, all of these elements fail to draw where I need them to be: Exactly in the center of screen. The Sprites added onto the HUD layer are all off, and I have iterated through pretty much every variation "convertToWorldSpace", "convertToNodeSpace", etc.
It is as if the constant scaling by the CCPanZoomLayer in the background throws off anchor points in the layer above each frame, and resetting them doesn't help. They all seem to default into one of the corners of the node bounding box they are attached to, as if their transform is blocked or set to zero when it comes to the drawing.
Has anyone run into this problem? Is this a known issue when using CCLayerPanZoom and drawing a custom CCRenderTexture on top each frame?
Ha! I found the culprit! There's a bug in Cocos2D' way of using Zwoptex data. (I'm using Cocos2D v 1.0.1).
It seems that when loading in Zwoptex v3 data, sprite frames' trim offset data is ignored when the actual sprite frame anchor point is computed. The effect is that no anchor point on a sprite with trim offset in its definition (eg in the plist) has its anchor point correctly set. Really strange... I wonder whether this has occurred to anybody else? It's a glaring issue.
Here's how to reproduce:
Create any data for a sprite frame in zwoptex v3 format (the one that uses the trim data). Make sure you actually have a trimmed sprite, i.e. offset must be larger than zero, and image size must be larger than source.
Load in sprite, and try to position it at center of screen. You'll see it's off. Here's how to compute your anchor point correctly:
CCSprite *floor = [CCSprite spriteWithSpriteFrameName:#"Menu_OmeFloor.png"]; //create a sprite
CCSpriteFrame *frame=[[CCSpriteFrameCache sharedSpriteFrameCache] spriteFrameByName:#"Menu_OmeFloor.png"]; //get its frame to access frame data
[floor setTextureRectInPixels:frame.rect rotated:frame.rotated untrimmedSize:frame.originalSizeInPixels]; //re-set its texture rect
//Ensure that the coordinates are right: Texture frame offset is not counted in when determining normal anchor point:
xa = 0.5 + (frame.offsetInPixels.x / frame.originalSizeInPixels.width);
ya = 0.5 + (frame.offsetInPixels.y / frame.originalSizeInPixels.height);
[floor setAnchorPoint:ccp(xa,ya)];
floor.position=(where you need it);
Replace the 0.5 in the xa/ya formula with your required anchor point values.
How do I make allegro 5 use anti-aliasing when drawing? I need diagonal lines to appear smooth. Currently, they are only lines of shaded pixels, and the edges look hard.
To enable anti aliasing for the primitives:
// before creating the display:
al_set_new_display_option(ALLEGRO_SAMPLE_BUFFERS, 1, ALLEGRO_SUGGEST);
al_set_new_display_option(ALLEGRO_SAMPLES, 8, ALLEGRO_SUGGEST);
display = al_create_display(640, 480);
Note that anti-aliasing will only work for primitives drawn directly to the back buffer. It will not work anywhere else.
On OpenGL, your card must support the ARB_multisample extension.
To check if it was enabled (when using ALLEGRO_SUGGEST):
if (al_get_display_option(display, ALLEGRO_SAMPLE_BUFFERS)) {
printf("With multisampling, level %i\n",
al_get_display_option(display, ALLEGRO_SAMPLES));
}
else {
printf("Without multisampling.\n");
}
You have two options: line smoothing or multisampling.
You can activate line smoothing by using glEnable(GL_LINE_SMOOTH). Note that Allegro 5 may reset this when you draw lines through Allegro.
The other alternative is to create a multisampled display. This must be done before calling al_create_display. The way to do it goes something like this:
al_set_new_display_option(ALLEGRO_SAMPLE_BUFFERS, 1, ALLEGRO_REQUIRE);
al_set_new_display_option(ALLEGRO_SAMPLES, #, ALLEGRO_SUGGEST);
The # above should be the number of samples to use. How many? That's implementation-dependent, and Allegro doesn't help. That's why I used ALLEGRO_SUGGEST rather than REQUIRE for the number of samples. The more samples you use, the better quality you get. 8 samples might be a good value that's supported on most hardware.
I am creating a simple 2D OpenGL game, and I need to know when the player clicks or mouses over an OpenGL primitive. (For example, on a GL_QUADS that serves as one of the tiles...) There doesn't seems to be a simple way to do this beyond brute force or opengl.org's suggestion of using a unique color for every one of my primitives, which seems a little hacky. Am I missing something? Thanks...
My advice, don't use OpenGL's selection mode or OpenGL rendering (brute force method you are talking about), use a CPU-based ray picking algorithm if 3D. For 2D, like in your case, it should be straightforward, it's just a test to know if a 2D point is in a 2D rectangle.
I would suggest to use the hacky method if you want a quick implementation (coding time, I mean). Especially if you don't want to implement a quadtree with moving ojects. If you are using opengl immediate mode, that should be straightforward:
// Rendering part
glClearColor(0,0,0,0);
glClear(GL_COLOR_BUFFER_BIT);
for(unsigned i=0; i<tileCout; ++i){
unsigned tileId = i+1; // we inc the tile ID in order not to pick up the black
glColor3ub(tileId &0xFF, (tileId >>8)&0xFF, (tileId >>16)&0xFF);
renderTileWithoutColorNorTextures(i);
}
// Let's retrieve the tile ID
unsigned tileId = 0;
glReadPixels(mouseX, mouseY, 1, 1, GL_RGBA, GL_UNSIGNED_BYTE,
(unsigned char *)&tileId);
if(tileId!=0){ // if we didn't picked the black
tileId--;
// we picked the tile number tileId
}
// We don't want to show that to the user, so we clean the screen
glClearColor(...); // the color you want
glClear(GL_COLOR_BUFFER_BIT);
// Now, render your real scene
// ...
// And we swap
whateverSwapBuffers(); // might be glutSwapBuffers, glx, ...
You can use OpenGL's glRenderMode(GL_SELECT) mode. Here is some code that uses it, and it should be easy to follow (look for the _pick method)
(and here's the same code using GL_SELECT in C)
(There have been cases - in the past - of GL_SELECT being deliberately slowed down on 'non-workstation' cards in order to discourage CAD and modeling users from buying consumer 3D cards; that ought to be a bad habit of the past that ATI and NVidia have grown out of ;) )