I'm making my first game with cocos2d-js. I've made a nice title png for my game but when I load it in cocos2-js it has anti-aliasing that ruins the effect. I read on the internet that using setAliasTexParameters can turn off the anti aliasing. I can't get it to work though, I've tried many different ways. I'm sure it's a basic problem with my syntax but I can't work it out and it's driving me insane. Chrome gives me the error Uncaught TypeError: Cannot read property 'setAliasTexParameters' of null.
Here's the layer:
var game = cc.Layer.extend({
init:function() {
this._super();
backgroundLayer = cc.Layer.create();
this.addChild(backgroundLayer);
var title = new cc.Sprite.create("assets/ui/title.png");
backgroundLayer.addChild(title,0);
title.texture.setAliasTexParameters();
title.setPosition(160,240);
}
});
EDIT: I have realised the sprites are being made about 30% too big whether I use setAliasTexParameters or not, so pixel perfect anti aliasing ins't possible. I can't work out why this is happening.
EDIT2: If I remove the cc.ResolutionPolicy in my main js file the sprite is rendered perfectly without antialiasing, but my canvas is half the size it should be! I think this is a resolutionPolicy problem rather than a setAliasTexParameters problem.
I haven't been able to find a resolutionpolicy from the documentation that won't resize my sprite.
Related
I am working on a project that presents live data acquired in real-time using the QCustomPlot plug-in for Qt. The display has a black background color, and the multiple channels of data are colored differently. When taking a screenshot, we would like to make it printer-friendly, so the background is white and all data is black. I am thinking of a solution like this:
Change all colors the way I want by manipulating the pointers for the graphical objects
Grab the screenshot using QWidget::grab() to get a QPixmap
Change all the colors back to normal
This did not work at first, because the system could not change the colors in time for the screenshot to be taken. So I used a QApplication::processEvents(), and it all worked on my Mac.
However, it does not work on a Windows 7 (which is required). Any ideas what to do?
Code:
QSting fileLocation = "...";
toggleColors(false); //function to toggle the colors
QApplication::processEvents();
QPixmap shot = grab();
toggleColors(true);
shot.save(fileLocation, "png");
Again. It works on Mac, but not Windows.
Update 1. Content of toggleColors include:
if(enable)
ui->plot->setBackground(QBrush(Qt::black));
else
ui->plot->setBackground(QBrush(Qt::white));
ui->plot->repaint();
I also tried with ui->plot->update() instead.
I am not sure what is the problem on Windows specifically, but I recommend you calling QWidget::update() on the given widget. That forces the next update to re-render itself.
On the other hand, I'm not sure why toggleColors() didn't somehow cause that to happen.
Also, ensure that QWidget::setUpdatesEnabled(bool) wasn't set to "false."
It appears the problem lies with QCustomPlot. It was solved by performing a ui->plot->replot() which is specific to QCustomPlot and not QWidget.
I'm trying to make a Famo.us game where I have a background Image ( an ImageSurface ) and then I put a bunch of other ImageSurfaces over the top and animate them. However the background surface doesn't stay in the background, for starters new ImageSurfaces are drawn underneath, then weirdly they start getting drawn on top. Exact same code generating the surfaces.
the background image has a Transform.behind applied to it.
The image below kind of shows the problem, some of the small squares are behind, and some are on top.
If it makes any difference, the surfaces are all in a HeaderFooterLayout
Any ideas whats going wrong? or how I could debug this?
check the zIndex value of the surfaces isn't the same as the zIndex of the white surface you're attempting to hide them behind. If they are the same (or unspecified) the browser hazards a guess, and you end up with z-fighting where the GPU can't actually decide what to render (the white surface or the tabs?) You could have your tabs resting on one zIndex value, and the white surface on the other.
(The following is written by Keith) For anyone else, what I did was add the following to the ImageSurface
properties: {
zIndex: -1000000
}
Oddly I tried with a zIndex of -10 etc, which didn't work, only once I made that zIndex huge did it seem to fall behind everything else.
I currently have the following working fiddle
var moveAnim = Raphael.animation({ progress: 1 }, 5000, 'bounce').repeat(Infinity);
I animate a circle along a line.
I also want to make the circle flash at the same time but I can't seem to work out a way to do this?
I thought about adding the circle to a set and applying the additional animation to this but I can't see to get this either!
Any ideas?
This is a hack and I make no attempt to hide it, but it could be made a bit nicer.
There's a couple of problems depending on 'how' you want to animate the flash. The main problem is having 2 simultaneous animation on the same object, as Raphael doesn't do this (to my knowledge). Its easier if you want to animate an alternate attribute than the same one. If you want to animate a scale to indicate a flash, you will need to append the scale transform to the end of the path transform string ('t,s').
Example here, just uses opacity attribute.
Probably the nicest method would be to include something that figures out time running and amends an attribute manually within the animation function (paper.customAttributes.progress). However, that will probably take a bit longer.
Another alternative could be to animate another object off screen, that does all the calculations for you. It feels a bit ugly, but should work.
So earlier we create a dummy object off screen...
var dummy = paper.circle(-100,-100,10).attr({ opacity: 0 });
Within the progress func, you can then set the real circles opacity to be the same as the offscreen one.
this.attr('opacity', dummy.attr('opacity'));
And we get the dummy animation triggering later
dummy.animate(flashingAnim);
jsfiddle
As mentioned, I think there are cleaner ways, but may involve you writing a small linear animation func separately, but this may help if performance isn't an issue and you don't mind extra elements in the dom.
An alternative solution that I came up with is a looping callback. The very sound of a looping callback sounds ugly but I guess thats what an animation is?
It does appear that you can attach multiple animations to an element! Here's a an example
function animateIn() {
flashingCircle.animate({ fill: '#f00' }, 1000, animateOut);
}
function animateOut() {
flashingCircle.animate({ fill: '#fff' }, 1000, animateIn);
}
animateIn();
I'm creating a lot of little surfaces that get added to a layout ( int this case a header footer layout), animated, then need to go away. However, I'm not sure how to remove the surfaces once added?
Kraig is right about using a RenderController when possible, but I would not suggest it for your case. RenderController works well with large layouts and not so much for small particles and such. RenderController only shows one view at a time.
I have asked about this on the IRC channel and it turns out the way I do it, feels really hacky, but is still the recommended most straight forward approach. The idea is to just redefine the render function to return null.
// surface to remove
surface.render = function(){ return null; }
That's it!
Just make sure you remove all references in your code as well!
I often do it from an object..
delete littleSurfaces['little-surface-key']
FWIW The more advanced approach is to actually define a view that controls specifically the surfaces that get rendered. You do this by defining the render function on a custom view that returns what is known as a renderSpec. A renderSpec is a list of hashes that define the surfaces that will be rendered. The example everyone points to is the Flipper class. Take a look at Flippers render function..
https://github.com/Famous/views/blob/master/Flipper.js
Good Luck!
You can add/remove surfaces using a RenderController object. You can also apply an optional transition when things are shown and hidden.
The DOM may lie to you sometimes, as Famo.us repurposes and recycles DOM Elements for efficiency.
https://famo.us/docs/api/latest/views/RenderController
I have a cocos2d game that has a loading scene where we load a bunch of assets. The game starts with the splash screen, and then launches the loading scene. The loading scene starts by loading the background, so the user sees the loading scene background while the assets are being loaded.
I load the loading scene background by calling CCSprite::spriteWithFile: and passing the filepath: loadingbackground.pvr.ccz
It seems to work differently on different devices:
On iphone (3gs) simulator, I see the loading scene as expected.
On iphone retina simulator, I don't see the loading scene (there aren't many assets yet, so may be happening quickly) and it goes directly to the main menu scene.
On the ipad 3 device, the splash screen comes up, and then there is a half second of black screen, and then the main menu scene shows up.
I want to see what I can do to avoid that black screen showing up on iPad 3. I suspect this is because of the time taken to load the loading background.
I have tried the following optimizations (mostly based on #Steffen's blog post on memory optimization):
Moved the loading background (originally 2.3 MB RGB8 png file) into a pvr.ccz spritesheet by itself, which reduced its size to 1.8 MB.
Removed the image from the texture soon after use.
I still see a black screen on iPad 3. Any suggestions?
Update: Found the issue - I had some code where I was overriding OnEnter and calling [[CCDirector sharedDirector]replaceScene] in it, and also calling the same from the background thread. Removed the OnEnter overload and it worked without flicker.
Thanks
Ignore whatever happens in Simulator. That's not relevant, focus on the device.
When the loading scene initializes and you add the loading scene's background, make sure you schedule update and load your assets in the update method. Otherwise if you load the assets in init, the background won't be drawn because you're loading all the assets before cocos2d gets to redraw the screen.
If this still fails, simply send the visit message to the background sprite followed by [[CCDirector sharedDirector] drawScene]. This forces a redraw of the scene.
Is this cocos2d-iphone or cocos2d-x ? make sure the tags are correct :)
I think you're referring to the startup flicker, there are a few ways to avoid that.
first thing you need to make sure you're handling the rootViewController correctly for iOS 6 and iOS 5 and below, there are a little changes for each.
You can find a little reference here:
http://www.cocos2d-iphone.org/forum/topic/34471
Second thing you need to know that simulator's behaviour is not stable, you should always rely on real devices for testing, but it's very likely you'll still have the flicker issues.
Sorry I didn't provide example code, but you haven't supported enough information to know what's the real issue here.