I'm trying to develop a scrollable tile map in Cocos2D which uses an UIPanGestureRecognizer to do the dirty work, but while developing it, stumbled upon some problems for which I would like to ask for an advice.
The basic scrolling management works fine, it's precise and accurate and works by adding the translation recognized by the pan gesture manager to the tiles of the map. The problem is that the map is large and I just draw a small viewport of it, while I want to manage it like it's scrollable without any problem.
What I was thinking about is that, as soon as a whole row or column get out of the visible screen, it is moved to the opposite side, the corresponding texture rects are updated (I'm working entirely with a CCSpriteBatchNode), so that it will continuously update the viewport to make the whole thing work. This seems fine but I've found many problems in dealing with when to move the row/column, how to keep track of this issue (eg when pan changes direction from forth to back) and many little details which make me think that I should find a better approach.
Is there a common solution to my problem? That is: managing a scrollable viewport of a tilemap which should move over the whole map so the to the end user it seems like as if the map is infinite.
Thanks in advance
I solved my issue by developing a viewport in which rows and columns are effectively moved from left side to right side and from top side to bottom side.
This is done automatically when a new column or row enters the viewport and it's made by expanding the drawn viewport over the real one by an amount which is enough to avoid any graphical issue to the user.
Related
I've been Googling like crazy for a while now, and I simply can't find any answers to the question: is it possible to implement the Android List scrolling, without using an actual list UI?
I'm trying to make a grid of rectangles such as the kind you would find in a typical game app respond to finger movement in the same way that it does using Android lists (bounce on the bounds, the 'flick' effect, etc), but all of the approaches I've found involve over-complicated solutions involving extending the list, defining XML layouts, etc.
Would it not be possible to simply give an object variables for 'document' height, 'viewable' height and y-offset? I'm happy to give the delta (MS since last update) to the object on every update. It would also be good if the actual interactive region was also definable.
Additionally; are there strong advantages to using the ListView instead that I'm missing? I assume responsiveness comes into play, but I'm quite happily managing that manually at the moment.
Just use ScrollView directly, assuming you only need vertical scrolling.
I want to make an endless vertical scrolling layer that gives the impression that the main character is moving upwards. I have been brainstorming on how to achieve this.
My issue is that I want objects to appear as if they are coming from above and below the screen at the same time. Secondly, I want to be able to move the main character to create and destroy box2d joints between it and some of the objects appearing on the screen. What is the best way to achieve this with consuming too much memory? I would appreciate any help on this.
Apple did a wonderful tutorial of this in a WWDC 2011 video session. It was "UITableView Changes, Tips & Tricks" and it's about 35m40sec into the video.
Since the use of the UITableView is really just a UIScrollView for the purposes of the background, you could just use a UIScrollView and you can either have it move on timer or events as needed.
Think of your player as moving within a stationary bounding box. The background can scroll using the aforementioned pooling method (as the background tile scrolls off the screen it is placed into a pool, and before a new tile is instantiated the pool is checked for available reusable tiles). Thirdly, your enemy objects will simply approach from either the bottom of the screen or the top.
Imagine your idea without the scrolling background (flying effect) and you should find that the problem is relatively straightforward.
I also needed and endless scrolling background layer. This can do exactly that, and it is super simple to set up and use. Just copy the four files in to the cocos2d folder in your project, then follow the quick tutorial seen on the github. Make sure the image you use is seamless (when you line them up vertically you can't tell where one ends.
I'm having some issues with the constraints in my app. Here is how it looks on the iPhone 4 (that's how i want it to look, and how i usually setup my interface, is this the proper approach or not?)
Now, when i switch to the iPhone 5 screen it looks like this
and as you can see, the blue dots (which is UIButtons) are not placed where i want them to be. I made my constraints rely solely on the right side of the view (since that is the one re-sizing, i found that in order for you'r views to align themselves accordingly, it doesn't help to align them to the left side). I don't really know how to fix this. I am finding this new iPhone screen to be a real pain in the arse. Any good advice on how to work with this new screen without a lot of headache would be appreciated :)
Thanks on advance
It looks to me like the are still the same distance from the right side of your view, as you said you set them to be, while the background has stretched to fit the new size. I suspect it's actually the background that isn't doing what you want it to do (keep the same aspect ratio and show more stuff on the left), or try keeping the buttons relating to left and right to stay aligned with the stretched background image.
Am working on a project where we have a Bing map being resized depending on whether or not a panel is shown/hidden on the left-hand side of the map. Because of this, and Microsoft's terms preventing overlaying anything over the logo/copyright, etc, I'm using the VEMap.resize method to resize the map, and then am moving the panel out of the way. The issue is that there's an awkward autopan that occurs as part of the resize - because we're declaring a center point to determine the resize, the map pans to include this point in the center without any control over it. Without declaring a center, the map doesn't pan, but it also doesn't pull the new data (map tiles) in our resize in either, resulting in an awkward grey bar on the right-hand side..
Is there a simple way to either resize the map and disable that autopan, moving the center prior to the panning, or to force the map tiles to be rendered upon the resize itself? Any help would be appreciated.
You may want to try the new version 7.0 as you could get rid of this annoyance by using "map.setView({center: map.getCenter(), animate:false})" after resizing; that should override the nice but annoying pan movement on resize.
However there are a few features (like infoboxes or client-side clustering) currently missing in 7.0 when migrating from 6.3 however and the classnames changed, so you may want to wait for now, however it would be the good moment to prepare yourself for 7.
I'm using cocos2d for the iPhone to create an infinitely scrolling horizontal tile map. To achieve this, I've generated a library of 'segments', which are basically horizontal chunks of levels that I randomly choose from and append to the end of that particular levels tile map. When tiles scroll off of the left of the screen they are removed from the layer and released. This all works fine.
My question revolves around the legitimacy of the scrolling method I've chosen. Following guidance from this article, I've been scrolling my map by updating the layers position at regular intervals (subtracting from the x axis to move the layer to the left). And while this works, I'm concerned that there's probably some finite limit to the positioning of a layer. Am I going to run into issues after a certain amount of time has passed (when the layers x-axis position is considerably large?)
Any thoughts on my approach would be appreciated.
This is a good question. What I would do is run some tests on how far you can position the layer. I placed a sprite and focused the camera to ccp(1000000000000000, 1000000000000000) with no issues.
Do you really think this would be an issue in real gameplay? Seems like it would take a very long game to reach a position like that.