I have a jQuery Mobile slider. Let's say the range is 1 to 100. What I need is to make the scale exponential. In other words, moving the thumb by a given number of pixels on the left side would have a smaller effect than moving it the same number of pixels on the right side, towards 100. My goal here is to make it easy to pick values like 1, 2, 3, 4, 5. Differentiating between 96 and 100 is not necessary. So I want to devote more of the slider's range to the lower values.
Anyone have any ideas on how this might work? Or alternative approaches to solve this problem?
I ended up implementing a solution by modifying the jQuery Mobile source to their slider widget to fit my needs.
Here's a link to a working version if anyone is interested:
http://media.pokerslug.com/js/jqm/eslide.js
It uses a simple x*x relationship to scale. To use it, call $(element).eslider(), but make sure the target doesn't have a "type=range" attribute.
A short demo can be found here: http://jsfiddle.net/4XrhA/
Related
I have 19451 points exported by coordinates in a JSON file. I am trying to render them in an efficient way on the map with circles. How can I achieve this? It is the first time I am using https://github.com/react-native-maps/react-native-maps with expo, so I am not that experienced in using maps services. I don't even know where to start from. I was thinking of something like rendering the points dynamically, based on whether one point is to be found in the region of the map that is currently shown on the screen, although I have no idea how to actually achieve this. The first thing I tried was to obviously render them at once: it takes ages and it is very buggy!
You have several options:
Use some kind of clustering when there are multiple circles in the same area, for example when you're zoomed out. Have a look at react-native-maps-clustering. Performance wise is decent enough but it may lag on older devices.
When you go over a zoom level you can limit the number of circles you draw, I guess they overlap anyways. When your limit has been reached, you can display some warning to let the user know that the number of circles was limited and he should zoom in. From my experience, drawing max 50 custom markers was the upper limit to avoid lag on older devices. With circles, that limit might be different.
Manually filter your data and decide whether the circle belongs to the current viewport (visible part of the map) or not.
Some code would help me to give you some more hints.
So I have my game, made with SpriteKit and Obj-C. I want to know a couple things.
1) What is the best way to make scroll-views in SpriteKit?
2) How do I get this special kind of scroll-view to work?
The kind of scroll-view I'd like to use is one that, without prior knowledge, seems like it could be pretty complicated. You're scrolling through the objects in it, and when they get close to the center of the screen, they get larger. When they're being scrolled away from the center of the screen, they get smaller and smaller until, when their limit is met, they stop minimizing. That limitation goes for getting bigger when getting closer to the center of the screen, too.
Also, I should probably note that I have tried a few different solutions for cheap remakes of scroll views, like merely adding the objects to a SKNode and moving the SKNode's position relative to the finger's, and its movement . . . but that is not what I want. Now, if there is no real way to add a scroll-view to my game, this is what I'm asking. Will I simply have to do some sort of formula? Make the images bigger when they get closer to a certain spot, and maybe run that formula each time -touchesMoved is called? If so, what sort of formula would that be? Some complicated Math equation subtracting the node's position from the center of the screen, and sizing it accordingly? Something like that? If that's the case, will you please give me some smart Math formula to do that, and give it to me in code (possibly a full-out function) format?
If ALL else fails, and there is no good way to do this, what would some other way be?
It is possible to use UIScrollViews with your SpriteKit scenes, but there's a bit of a workaround involved there. My recommendation is to take a look at this github project, that is what I based my UIScrollView off of in my own projects. From the looks of it, most of the stuff you'd want has actually been converted to Swift now, rather than Objective-C when I first looked at the project, so I don't know how that'll fare with you.
The project linked above would result in your SKScene being larger than the screen (I assume that is why it would need to be scrolled), so determining what is and is not close to the center of the scene won't be difficult. One thing you can do is use the update loop in SpriteKit to constantly update the size of Sprites (Perhaps just those on-screen) based on their distance from a fixed, known center point. For instance, if you have a screen of width and height 10, then the midpoint would be x,y = 5,5. You could then say that size = 1.0 - (2 * distance_from_midpoint). Given you are at the midpoint, the size will be 1.0 (1.0 - (2 * 0)), the farther away you get, the smaller your scale will be. This is a crude example that does not account for a max or min fixed size, and so you will need to work with it.
Good luck with your project.
Edit:
Alright, I'll go a bit out of my way here and help you out with the equation, although mine still isn't perfect.
Now, this doesn't really give you a minimum scale, but it will give you a maximum one (Basically at the midpoint). This equation here does have some flaws though. For one, you might use this to find the x and y scale of your objects based on their distance from a midpoint. However, you don't really want two different components to your scale. What if your Sprite is right next to the x midpoint, and the x_scale spits out 0.95? Well, that's almost full-sized. But if it is far away from the midpoint on the y axis, and it gives you a y scale of, say 0.20, then you have a problem.
To solve that, I just take the magnitude or hypotenuse of the vector between the current coordinate and the coordinate of the current sprite. That hypotenuse gives me an number that represents the true distance, which eliminates the problem with clashing scale values.
I've made an example of how to calculate this inside Google's Go-Playground, so you can run the code and see what different scales you get based on what coordinate you plug in. Also, the equation used in there is slightly modified, It's basically the same thing as above but without the maxscale - part of the front part of the equation.
Hope this helps out!
Embedding Attempt:
see this code in play.golang.org
Now I could be wrong about this but after testing it all day, I have discovered...
When adding a widget and setting the z-index, the value "0" seems to be the magic depth.
If a widget's Z is at 0, it will be drawn on top of everything that's not at 0, Z wise.
It doesn't matter if a widget has a z-index of 99, -999, 10, -2 or what ever... It will not appear on top of a widget who's z-index is set to 0.
It gets more strange though...
Any index less than -2 or greater than 2 seems to create an "index out of range" error. Funny thing is...when I was working with a background and sprite widget, the background's Z was set to 999 and no errors. When I added another sprite widget, that's when the -2 to 2 z-index limitation appeared.
Yeah I know...sounds whacked!
My question is, am I right about "0" being the magic Z value?
If so, creating a simple 23D effect like making a sprite move being a big rock will take some unwanted code.
Since you can only set Z when adding,a widget, one must remove and immediately add back, with the new Z value...a widget.
You'll have to do this with the moving sprite and the overlapping object in question. Hell, I already have that code practically written but I want to find out from Kivy pros, is there a way to set z-index without removing and adding a widget.
If not, I'll have to settle for the painful way.
My version of Kivy is 1.9.0
What do you mean by z-order? Drawing order is determined entirely by order of widgets being added to the parent, and the index argument to add_widget is just a list index at which the widget will be inserted. The correct way to change drawing order amongs widgets is to remove and add them (actually you can mess with the canvases manually but this is the same thing just lower level, and not a better idea).
I found a working solution using basic logic based on the fact widgets have to be removed and added again in order to control depth/draw order.
I knew the Main Character widget had to be removed along with the object in question...so I created a Main Character Parent widget, which defines and control the Main Character, apart from its Graphic widget.
My test involves the Main Character walking in front of a large rock, then behind it...creating a 23D effect.
I simply used the "y-" theory along with widget attach and detach code to create the desired effect.
The only thing that caught me off guard was the fact my Graphic widget for my Actor was loading textures. That was a big no no because the fps died.
Simple fix, moved the texture loading to the Main Character Parent widget and the loading is done once for all-time.
PS, if anyone knows how to hide the scrollbars and wish to share that knowledge, it'll be much appreciated. I haven't looked for an API solution for it yet but I will soon.
Right now I'm just trying to make sure I can do the basic operations necessary for creating a commercial 23D game (handhelds).
I'm a graphic artist and web developer so coming up with lovely visuals won't be an issue. I'm more concerned with what'll be "under the hood" so to say. Hopefully enough, lol.
https://www.youtube.com/watch?v=CmftPUqQ0nE at 3:42 suddenly the photo becomes grainy or something. I can't replicate it since the uploader disabled the comments section and description is not helpful as well.
An effect like this can be achieved with a high pass filter. To do this, duplicate the layer (Ctrl+J, Cmd+J on a Mac). Put a high pass filter on the top layer (fairly small radius, i.e. less than around 2 pixels) and then set the blend mode of the layer to overlay.
EDIT: If you convert to a smart object before applying the high pass filter, you can play with the radius afterwards.
I want to create a Windows 8 Metro application that has a fancy "hub" page similar to the following:
http://blogs.msdn.com/cfs-file.ashx/__key/communityserver-blogs-components-weblogfiles/00-00-01-51-31-metablogapi/3482.landing_2D00_branded_5F00_thumb_5F00_287109A4.jpg
The key elements are: Horizontal Panorama style scrolling page but with "sections" that are data bound. I've had a look around for implementations and have come up short.
Seems to me it would be possible to do with a ScrollViewer that contains a Horizontal Stackpanel that has the elements that make up each section. But seeing as this is such a common Metro design pattern, I figure there is probably an easier / recommended way of implementing.
Just wondering if someone can give me some tips. How would you do it?
When you start using VariableSizedWrapGrid all things get their own relative sizes. http://msdn.microsoft.com/en-us/library/windows/apps/br227651.aspx
Set the ColumnSpan and RowSpan properties to make things double size, tripple size etc...
For me I make the first item in the collection double width, double height by setting ColumnSpan and RowSpan to 2. All other items get this ColumnSpan and Rowspan to 1, and it's getting a nice effect.
In addition to what Hans mentioned, I would highly recommend going through the existing Metro Style App Samples. Learning from working examples works better than any documentation.