I tried rendering using Libgdx's DecalBatch on my phone and my friend's phone. It's rendering a 2D image with thickness.
A decal at the front and back side is created, then individual decals for every pixel at its side.
Then, I flush (render) the decals.
On my phone, it gave this result:
It worked as expected.
However, on my friend's phone, it didn't render at all:
It didn't work as expected.
How do I fix this? Or is it a bug in Libgdx?
I've got it working now!
I forgot to add this one line of code:
Gdx.gl20.glClear(GL20.GL_COLOR_BUFFER_BIT | GL20.GL_DEPTH_BUFFER_BIT);
I mainly forgot to put the depth buffer bit.
Anyways, thank you to everyone who has helped.
Related
When using HTML 5 drag and drop, i have noticed that on firefox, the ghost image tends to fly in from far away to the right. I have not been able to reproduce using a small scale example, so i assume it has something to do with the CSS involved. Unfortunately, this is part of a huge application, so teasing out a sandbox wasnt possible, but i included a gif of the behavior. Drag and drop seems to function correctly on chrome and other browsers. This is the code that occurs on dragstart (sectionalGrid is the div that comprises the 5x5 grid)
document.getElementById('sectionalGrid').addEventListener('dragstart', e=> {
const gridItemRoot = findAncestor(e.target, 'mxt-grid-item');
e.dataTransfer.setData("grid_x", gridItemRoot.dataset.x);
e.dataTransfer.setData("grid_y", gridItemRoot.dataset.y);
this._dragStartMode = 'gridItem';
document.getElementById('sectionalRemovePiece').classList.add('sectionalHighlightRemove');
});
No problems when running my app from Eclipse, but when exporting and running on desktop, all images from my TextureAtlas gets glitched, getting displayed as a black/gray boxes, as well as some weird stuff like white gradient boxes and lighting overlays.
Heres some screenshots of what I mean:
Wherever I'm suppose to have an image, thats some of the stuff I see instead.
I checked my .jar archive to see if the TextureAtlas resources made it through to the right directory that's not the issue.
app configs
cfg.useGL20 = true;
Anyone familiar with whats going on?
This problem was caused by a mismatch with the TexturePacker2 version used to create the altas, and the version used to load the atlas.
Any ideas why my app would draw a black screen when it's dormant/suspended (user presses window-key, and then long-presses back-key to view all dormant apps)?
It's Directx113D app, and should be very close to the implementations of Marble Maze and Direct3D samples. They show up just fine.
I've done my best to break these two samples in a similar fashion but no luck. Any ideas?
Okay, I've got this one solved.
The problem was with alpha. I don't know why, but when the app has the focus, it draws alpha just fine. However, when send to background alpha blending somehow is turned of and alpha for each pixel remains 0. For my blendstate I changed:
SrcBlendAlpha = D3D11_BLEND_ZERO
DestBlendAlpha = D3D11_BLEND_ZERO
to
SrcBlendAlpha = D3D11_BLEND_ZERO
DestBlendAlpha = D3D11_BLEND_ONE
I developed a mobile app inside Adobe Flex (4.6) and it includes using pinch-to-zoom functionality to zoom in on pictures to make it easier to read words in the pictures. In previous android versions (2.1 to 2.3.3 and 2.3.4 if you're running cyanogenmod) the pinch-to-zoom works fine. But if the app is run on an ICS (Android 4.x) device, the axes seem to handle the enlargement of the picture individually. i.e. when you move your fingers apart horizontally, the image gets very wide, but stays the same vertical size, and vice versa.
First, does anyone know why this is happening?
And second, does anyone know of a way to fix it to work as it did before?
I will update to include screenshots.
Update: I have confirmed this is also an issue with Honeycomb. i.e., 3.x OS acts the same as 4.x ICS.
Sense, running the latest HTC update:
ICS, on AOKP, but verified this is an issue with standard ICS distros as well:
Solved this. Code was previously:
protected function onZoom(e:TransformGestureEvent, img:Image):void
{
DynamicRegistration.scale(img, new Point(e.localX, e.localY), img.scaleX*e.scaleX, img.scaleY*e.scaleY);
}
change the final e.scaleY to e.scaleX. This makes it scale based on only one portion of the zoom (in the x direction) and scales both X and Y accordingly. Not exactly perfect, but it works very well in practice.
Final code is this:
protected function onZoom(e:TransformGestureEvent, img:Image):void
{
DynamicRegistration.scale(img, new Point(e.localX, e.localY), img.scaleX*e.scaleX, img.scaleY*e.scaleX);
}
I'm experiencing a possible bug with the path element in Chrome. I have copy/pasted what RaphaelJS has rendered here: http://petesaia.com/work/svg-chrome-bug/
In Safari & Firefox
(source: petesaia.com)
In Chrome (19.0.1084.46)
(source: petesaia.com)
Obviously there are very many points in this file which is why I limited 50 points per path element. As you can see, 2 paths are missing from the right side and 2 very small paths are missing from the left side. I found one of the paths that is not displaying and singled it out. You can see that here: http://petesaia.com/work/svg-chrome-bug/singled.html
You will notice that even when the path is singled out it still doesn't show. So Chrome must dislike something with that path.
I also noticed that sometimes it displays correctly, usually when I open and close the javascript console. It's very flimsy. I've experimented with changing stroke and weight and also no luck.
Has anyone experienced anything like this?
New discovery: These x/y values are the coordinates that break the single.html sample: 620.3536711111101,232.16932207146056 I know this because when you truncate the path up to that point it works perfectly. However, I still have no idea as to why they would break it.
Thanks,
Pete
PS: I do plan on simplifying the shape(s) but this has caught my attention first.