how can I find the visible region of the layer, preferably in the form of CCRect because my sprite to move only in the visible region, regardless of what part of the background image is visible
It would be useful have to qualify "visible region" a bit further and tell us more about your CCLayer/CCNode hierarchical setup.
That said, I assume you have tried things like
CCSize size = CCDirector::sharedDirector()->getWinSize();
which gives you the screen frame, or
layer->getPosition()
layer->getContentSize()
on your layer to get its boundaries/origin, or even
layer->boundingBox()
which gives you a CCRect?
Related
In my appDelegate class i have code something like this,
while using cocos studio
auto glview = director->getOpenGLView();
if(!glview) {
glview = GLViewImpl::createWithRect("HelloCpp", Rect(0, 0, 960, 640));
director->setOpenGLView(glview);
}
director->getOpenGLView()->setDesignResolutionSize(960, 640, ResolutionPolicy::SHOW_ALL);
Where as in a normal cocos2dx project
with out cocos studio
the code in appDelegate class is like this.
auto glview = director->getOpenGLView();
if(!glview) {
glview = GLViewImpl::create("My Game");
director->setOpenGLView(glview);
}
My doubt is, is it mandatory to setDesignResolutionSize, and also should it be the same for every device size???
in cocos2dx all coordinates are based on design resolutions size. By doing so you can use the same coordinate system on all screen sizes. resolution policy SHOWALL displays the entire area without any change however, since not all devices are in same size, you will have black boarders depending on the screen size.
NO_BORDER policy will crop some of the surface but you will loose some part of the world depending on the device screen size. If you planning to do this then you have to make sure that important parts are in the safe zone so that your game is not effected. There is one thing you have to pay attention if you are using NO_BORDER policy. The design resolution will not be same as the visible area. If this is what you decided to go for a policy choice then you need visibleSize() and visibleOrigin() functions to help you out the location of sprites and game objects.
Perhaps the best method is to use FIXED_HEIGHT or FIXED_WIDTH policies. If you choose FIXED_HEIGHT policy then you simply telling the cocos2dx that you want to display the entire height with in the visible area of any device. The width can be cut off depending on the device. The width size of the Design resolution size will be recalculated. you can take this approach if you don't care about the width of the game. in other words, if your game requires the entire height for the game area FIXED_HEIGHT is your policy.
As you may have guessed FIXED_WIDTH policy works similar but for the width rather then the height.
Both FIXED_WIDTH and FIXED_HEIGHT modifies design resolution's width or height depending on what you choose. good thing about this is that the produced design resolution will be identical to the visible area. This makes it easier for you to locate, position your sprites on your game.
Some more info on these topics can be found on following links. with much clear explanations. although they are abit old, they give you an idea on how it all works.
http://www.cocos2d-x.org/wiki/Multi_resolution_support
http://cocos2d-x.org/wiki/Detailed_explanation_of_Cocos2d-x_Multi-resolution_adaptation
I am wondering how can I add a border & background to labels generated via CCLabelBMFont class in cocos2d.
I don't want to use sprites because my labels are generated on the fly and will keep changing and the size of labels are also different.
Also, I want user to touch and move these labels across the screen. When user picks a label it wiggles a bit like in free air. In that case, I wish to keep low complexity and preserve memory and cpu calculations.
Anyone knows best ways to achieve this?
IOS app LetterPress has similar effects.
Create your own class, that will incapsulate creation of complex node.
It will have several layers, for example, the first layer can be simple CCLayerColor of given rect with zOrder -2, the next layer will be your CCLabelBMFont with zOrder -1 and then you can overload draw method to draw border over your control. All that you draw in this method will be drawn with zOrder 0.
Then you can encapsulate any effects in this class. For example, you can rotate it a bit with method pick, etc. Whatever you want.
I am haveing trouble understanding the concept of the UpdateLayaredWindow api, how it works and how to implement it. Say for example I want to override CFrameWnd and draw a custom, alpha blended frame with UpdateLayeredWindow, as I understand it, the only way to draw child controls is to either: Blend them to the frame's Bitmap buffer (Created with CreateCompatibleBitmap) and redraw the whole frame, or create another window that sits ontop of the layered frame and draws child controls regularly (which defeats the whole idea of layered windows, because the window region wouldn't update anyway).
If I use the first method, the whole frame is redrawn - surely this is inpractical for a large application..? Or is it that the frame is constantly updated anyway so modifying the bitmap buffer wouldn't cause extra redrawing.
An example of a window similar to what I would like to achieve is the Skype notification box/incoming call box. A translucent frame/window with child contorls sitting ontop, that you can move around the screen.
In a practical, commercial world, how do I do it? Please don't refer me to the documentation, I know what it says; I need someone to explain practical methods of the infrastructure I should use to implement this.
Thanks.
It is very unclear exactly what aspect of layered windows gives you a problem, I'll just noodle on about how they are implemented and explaining their limitations from that.
Layered windows are implemented by using a hardware feature of the video adapter called "layers". The adapter has the basic ability to combine the pixels from distinct chunks of video memory, mixing them before sending them to the monitor. Obvious examples of that are the mouse cursor, it gets super-imposed on the pixels of the desktop frame buffer so it doesn't take a lot of effort to animate it when you move the mouse. Or the overlay used to display a video, the video stream decoder writes the video pixels directly to a separate frame buffer. Or the shadow cast by the frame of a toplevel window on top of the windows behind it.
The video adapter allows a few simple logical operations on the two pixel values when combining their values. The first one is an obvious one, the mixing operation that lets some of the pixel value overlap the background pixel. That effect provides opacity, you can see the background partially behind the window.
The second one is color-keying, the kind of effect you see used when the weather man on TV stands in front of a weather map. He actually stands in front of a green screen, the camera mixing panel filters out the green and replaces it with the pixels from the weather map. That effect provides pure transparency.
You see this back in the arguments passed to UpdateLayeredWindow(), the function you must call in your code to setup the layered window. The dwFlags argument select the basic operations supported by the video hardware, ULW_ALPHA flag enables the opacity effect, the ULW_COLORKEY flag enables the transparency effect. The transparency effect requires the color key, that's specified with the crKey argument value. The opacity effect is controlled with the pblend argument. This one is built for future expansion, one that hasn't happened yet. The only interesting field in the BLENDFUNCTION struct is SourceConstantAlpha, it controls the amount of opacity.
So a basic effect available for a layered window is opacity, overlapping the background windows and leaving the partially visible. One restriction to that the entire window is partially opaque, including the border and the title bar. That doesn't look good, you typically want to create a borderless window and take on the burden of creating your own window frame. Requires a bunch of code btw.
And a basic effect is transparency, completely hiding parts of a window. You often want to combine the two effects and that requires two layered windows. One that provides the partial opacity, another on top and owned by the bottom one that displays the parts of the window that are opaque, like the controls. Using the color key to make its background transparent and make the the bottom window visible.
Beyond this, another important feature for custom windows is enabled by SetWindowRgn(). It lets you give the window a shape other than a rectangle. Again it is important to omit the border and title bar, they don't work on a shaped window. The programming effort is to combine these features in a tasteful way that isn't too grossly different from the look-and-feel of windows created by other applications and write the code that paints the replacement window parts and still makes the window functional like a regular window. Things like resizing and moving the window for example, you typically do so by custom handling the WM_NCHITTEST message.
When I do page transition that shows the outside part of the stage (like CCTransitionFlipX), I can briefly see the sprites outside the screen while transition. It is really annoying. I thought I can manually check the position of the sprite in realtime and remove if it is off the screen. But that won't work if that sprite is partially outside. Is there something like UIKit's clipSubviews in cocos2d?
There's a ClippingNode class that might help.
Since the flip animation allows the user to see more than just the visible screen area, because the screen rotates, I think the behavior you observed may be expected.
This is related to one of my other questions.
If I am tiling a large image by creating a separate QGraphicsItem (with the raster data as its pixmap), how do I keep track of the QGraphicsItem's position within the scene? Obviously for raster data, it is important to keep all the tiles "touching" to make a continuous image and they also have to be in the right place so the image doesnt look jumbled.
Does each tile have to have positioning methods that move it in relation to it's neighbors on the top/left/bottom/right? This seems kind of clunky. Is there a better way to make them all move together?
In other words, if I pan the scene with scroll bars, or pick up the image and drag/move it around in the scene, I want all the tiles to also move and stay in the right position relative to each other.
What is the best approach for controlling the layout, which tiles need to be rendered (i.e. only the visible ones), and populating the data only once it is needed? Also, once a tile has been rendered, is the data from it ever dropped, and repopulated from the image file, say if it stays out of view for a while, then comes back later if someone pans to that section?
There are (more than) 2 ways of doing this:
Use QGraphicsItemGroup which
handles grouping of your tile items
for you. It moves, selects, updates
it's group members as if they are
one. I've never used it but from the
doc, it seems to work with typical
applications.
Paint the tiles yourself in the
paint() of one custom item. This
gives you total control on how to
place and draw the tiles while the
item truly acts as one item since it
is, well, one item. This is what I
do.