I'm trying to recreate the "tutorial" explained on the site below. It's 5 dices bouncing around on the scene. But i'm stuck at the very beginning :)
papervision3d-jiglib-dice-demo
My problem is the bounding box. I want to create a box with a floor and 4 walls based on the size of the stage. I can get it the right size using zoom/focus on the camera. But the problem is the dices go through it.
How can i build 4 walls and make sure a dice doesnt go through it when i apply forces to it?
I tried the solution in the following source, but somehow the dices keep going through :(
throwing-dice-with-the-jiglib-physics-engine-and-away3d
Anybody knows how to do it? Or a better way to keep the dices on screen?
I solved the problem. Just to share with others who want to try the same:
Set camera zoom = 2
Set camera focus = distance / zoom
// now the scene width and height match the actual size of the stage.
add the planes for all sides and make sure you make the segments smaller then the dice size. (EG: dice size = 30; stage width = 300; segments = stage width/ dice size = 10).
make sure you ceil the results because segments require int
Ofcourse you can make it larger, but then it will be harder to render.
I made the height of the planes a little smaller then twice the dice size to make sure they never get on top of eachother.
And finally add a ceiling by placing another plane with small segments on top of the other planes
Related
I made an interface for a game, using extended viewport and when i resize the screen the aspect ratio changes and every element in scene is scales, but when this happens this is what i get :
This is the most annoying issue i dealt with, any advice ? I tried making the tower n times bigger and then just setting bigger world size for the viewport but same thing happens, idk what is this extra pixels on images..
I'm loading image from atlas
new TextureRegion(skin.getAtlas().findRegion("tower0"));
the atlas looks like this:
skin.png
size: 1024,1024
format: RGBA8888
filter: Nearest,Nearest
repeat: none
tower0
rotate: false
xy: 657, 855
size: 43, 45
orig: 43, 45
offset: 0, 0
index: -1
In the third picture, you are drawing your source image just slightly bigger than it's actual size in screen pixels. So there are some boundaries where extra pixels have to be filled in to make it fill its full on-screen size. Here are some ways to fix this.
Use linear filtering. For the best appearance, use MipMapLinearLinear for the min filter. This is a quick and dirty fix. The results might look slightly blurry.
Draw your game to a FrameBuffer that is sized to the same aspect ratio as you screen, but shrunk down to a size where your sprites will be drawn pixel perfect to their original scale. Then draw that FrameBuffer to the screen using an upsampling shader. There are some good ones you can find by searching for pixel upscale shaders.
The best looking option is to write a custom Viewport class that sizes your world width and height such that you will be always be drawing the sprites pixel perfect or at a whole number multiple. The downside here is that your world size will be inconsistent across devices. Some devices will see more of the scene at once. I've used this method in a game where the player is always traveling in the same direction, so I position the camera to show the same amount of space in front of the character regardless of world size, which keeps it fair.
Edit:
I looked up my code where I did option 3. As a shortcut, rather than writing a custom Viewport class, I used a StretchViewport, and simply changed its world width and height right before updating it in the game's resize() method. Like this:
int pixelScale = Math.min(
height / MIN_WORLD_HEIGHT,
width / MIN_WORLD_WIDTH);
int worldWidth = width / pixelScale;
int worldHeight = height / pixelScale;
stretchViewport.setWorldWidth(worldWidth);
stretchViewport.setWorldHeight(worldHeight);
stretchViewport.update(width, height, true);
Now you may still have rounding artifacts if your pixel scale becomes something that isn't cleanly divisible for both the screen width and height. You might want to do a bit more in your calculations, like round pixelScale off to the nearest common integer factor between screen width and height. The tricky part is picking a value that won't result in a huge variation in amounts of "zoom" between different phone dimensions, but you can quickly test this by experimenting with resizing a desktop window.
In my case, I merged options 2 and 3. I rounded worldWidth and worldHeight up to the nearest even number and used that size for my FrameBuffer. Then I draw the FrameBuffer to the screen at just the right size to crop off any extra from the rounding. This eliminates the possibility of variations in common factors. Quite a bit more complicated, though. Maybe someday I'll clean up that code and publish it.
Here is my background image:
And here is some code that I would assume scales this image to fully fit the screen.
Size visibleSize = Director::getInstance()->getVisibleSize();
auto bg = Sprite::create("grad.png");
bg->setScale(visibleSize.width / bg->getContentSize().width, visibleSize.height / bg->getContentSize().height);
bg->setAnchorPoint(Vec2(0,0));
addChild(bg);
I would expect those 4 lines to create a background sprite that would cover the entire screen size. However, here's a screenshot of what I am actually getting on my iPhone6+:
If I change the first line to
Size visibleSize = Director::getInstance()->getWinSize();
Then this is what I get, which isn't quite right either:
Using VisibleSize is correct, you just need one more change:
bg->setPosition(director->getVisibleOrigin());
By default, cocos2d-x uses ResolutionPolicy::NO_BORDER, so the bottom part of winSize is likely to be cropped.
getVisibleSize() returns the visible origin in Point rather then pixel.
In a certain point when you want to see things closer, can you zoom in the whole screen without changing the games' levels and items' size and scale?
In an swf file, you can right click to zoom in, but I want the same feature for the game using code.
Thanks.
You can play with the scaleXand scaleY properties of the DisplayObject, which holds your graphic elements.
Assumed,holder contains your stuff:
holder.scaleX = holder.scaleY = 2;
will scale the holder and all its children to double size.
I am trying to 3d transform a floor tile pattern in flash, But when i do so the tile lines become dotted (dashed) here is the screenshot
The best solution is as LDMS said, thickening your lines (even if it is an image), or if you can, enable Anti Aliasing (which i think is what smoothing does)
As for why this happens, this is due to texture sampling. You will probably see that if you move your camera around the gaps/dots in the lines move. Now without going into too many details these are the basics:
Close to your camera the amount of pixel from your image that fit into a pixel on your screen will be less then 1, meaning that one pixel from your image is bigger then an actual pixel on your screen, so it will just display that color from the image. But what happens, if your image is so far away that multiple pixels from your image are so small that they combined fit into one pixel on your screen? With smoothing and Anti Aliasing you run an algorithm to combine colors and get en estimated result. But if you do not do this it will have to pick a color, say we have 2 pixels of black (your line) and 2 of the red background for the same pixel on screen, it will (randomly or based on some variable) pick a color and display it without regard of the other colors.
This is why you sometimes see your line and sometimes the background.
I have a mask i'm using for a continuous scroll type thingy, and notice that when my masked sprite gets past a certain pixel size in height (2878) the mask does not mask. Has anyone experienced this? is this a bug?
to reproduce:
create a sprite over 2878 px in height and apply mask, mask breaks
create a sprite 2877 px in height and apply mask, mask works
I can't verify if that is a hard limit, but there are a bunch of similar size limits for bitmaps in Flash that crop up in various areas. One potential solution would be to use the scrollRect property of your content display object. When you set scrollRect you are essentially creating a rectangular mask and I'm almost positive I've done it with 5000+ pixel wide sprites in the past.