I have a Rajawali Cardboard renderer (texture painted on a sphere, similar to the example), and it works totally fine with sensor-based navigation. I'm also getting touch input, and accumulating in two variables the total angular horizontal and vertical movement. In monocular view, the idea is to allow both forms of navigation.
If, before setting camera orientation in onRenderEye, I do:
mSphere.rotateAround(Vector3.getAxisVector(Vector3.Axis.Y), Math.toDegrees(x), false);
mSphere.rotateAround(Vector3.getAxisVector(Vector3.Axis.X), Math.toDegrees(y), true);
Then I get the desired affect. However, If the device significantly changes its physical position prior to swiping (e.g. spinning around in chair), these manipulations cause the view to begin to rotate in a different plane than I would expect. What would be the most general way to combine x and y with cardboard's supplied eye view, or to otherwise get them to work together?
It seems like I need to incrementally apply a rotation, but I can't figure out what the standard way to do this would be.
Related
I have an app that's currently working with a single stage but i need to add a side display/section as a HUD, with scores/lives etc on it, so that the HUD is on the left, and the main hand screen on the right. The main game screen will be fixed and will not move around.
From researching I've found a couple of solutions.
1 - two stages
2 - a group with two groups to it, possibly using a horizontalgroup
3 - two cameras one stage
4 - one stage, one camera, but changing the position of the camera for each set of actors.
I think, option 1 is my preference, but i have some questions.
Do stages always fill the whole screen, or can i start then where i want? This would make it easier for the right hand screen to calculate positions based on 0,0 of that screen rather than always having to add the width of the HUD on to any calculations.
Do i need to work about viewports? Currently I'm not using one (which i think means my stage is set to scaling by default) but nothing looks stretched as a result of this. I don't know much about viewports, but there always seems to be a compromise to be made with them, i.e. black bars top or sides.
If I have two stages, do they each have their own camera? Do I need to with about this? Can I possibly aim the right hand camera at an offset so i can still draw things from 0,0 with that being the bottom left corner of the right stage, not the whole screen?
Finally, off topic, I am a little confused about spritebatch. I'm not currently using one, because I use a stage. Is that OK, or should i still be using one in conjunction with a stage somehow? And add all my actors to that?
It I understand correctly, you're using scene2d for your game world and also for your HUD. And the HUD doesn't overlay the game world, but rather uses its own portion of the screen exclusively.
Stages do not always fill the whole screen. They have no concept of filling or not filling anything, because they can have objects that are being drawn off screen. However, they are clipped to a rectangle defined by their Viewport.
In your case, it seems you need two Viewports, and therefore, two stages. You say you aren't using a Viewport, but you are...Stage automatically creates its own ScalingViewport that's set up like a StretchViewport. (ScalingViewport is not mentioned in the documentation, which is out of date.) StretchViewport is usually bad because your game will be distorted to fit whatever the aspect ratio of the device is.
ExtendViewports do not cause black bars as long as you don't set a max width/height on them and I think are usually the best choice for any game world view.
You can set your two Viewports to cover specific parts of the screen that you calculate yourself. Since this is a specialized case, I think you will have to directly subclass the Viewport class (not one of its subclasses) and manipulate each of them using viewport.setScreenBounds(...).
Regarding your last question: yes, each of the two stages has its own Viewport, and each Viewport has its own camera. Once you set up your two Viewports to each have their own portion of the screen, you can also set them to treat their respective bottom left corners as 0,0.
What is the best way to draw circles on a canvas that should have an alpha layer and change sizes? Should I use a View or a Surfaceview? The circles should also be clickable. And it should be smooth transitions when changing color size and position?
Should I put this in a runnable or use invlaidate in onDraw?
I would prefer that something like this also worked smoothly in low-end devices.
Any suggestions? I'm new to this kind of animations in Android.
If you are constantly drawing and taking user input at the same time, I would use a SurfaceView. However, if the only draw changes you plan on making to the circles happen when you touch them, then a simple View onDraw() override would probably do the trick. In the end it will just depend on what all is going on.
The point of the SurfaceView is to have that separate thread for drawing. If what you're doing could be in any way considered "game-like," then go for a SurfaceView; otherwise, stick with a View.
I say this because I'm currently working on a project with constant drawing using a View. The shapes that I'm drawing respond to touch and you can scroll through the View while it is still invalidating over and over. All this with a View and it still runs just fine on lower-end devices (I've only gone back to GingerBread, though).
Good luck!
I should also mention that in the project drawing in a View, almost everything has various alpha values and what not and runs fine.
I am trying to make a 3D-looking scrollable list, with elements stacking in a row moving forward and backwards, and all that needs to be 3D-looking (back elements faded out and scaled down, etc). Problem is that the front element, when moving out of the view (more to the front, that is) needs to rotate on X-axis and sort of "fall down", as if it was falling from an end of a conveyor belt.
I have searched far and wide for an elegant solution that does not involve developing a real 3D environment or applying whole code libraries, but could not find anything of the sort. I am really a noob at developing for Android, so I guess I might have overlooked something.
The only solution that came close to it was using a 0-duration animation that applied rotation transformation via Camera class onto View's canvas, but that wasn't a good enough 'cause the View's boundaries were clipping the rotated content, and let's face it - that's a crooked way to apply something as trivial as rotation.
Is there really no simple way to rotate Views? I mean, iOS has it, Flash has it - even CSS3 gives a way to do it without breaking a sweat.
My target is API 10 (2.3.3) and up.
I want to rotate an Android View with API level 8. For example, I want to rotate an EditText by 90 degrees so that when the user enters text into a left justified EditText, the first character is at the bottom (rotated 90 degrees) and subsequent characters are entered upwards.
I first tried using an animation with duration of 0, but you still see the field rotate. Unfortunately, this is a non-starter. If I could find a way to hide the animation completely, this method looks to be the simplest.
I then tried rotating the canvas in onDraw which works great for square Views but not so great for ones that aren't square (and I don't control the dimensions of the EditText). I tried various attempts at clipping and translating the canvas, but while I could get the cursor to come into view at the start of text input, it would do weird things once somebody started entering more content (usually the content would disappear out of view).
I also tried making the View square in onMeasure, then rotating the canvas in onDraw, then putting the View dimensions back in a subsequent onMeasure. The first two steps worked great. But the third step produced similar results as described above: things looked ok until the user started entering more text at which point the field text did strange things (usually disappearing).
Has anybody been able to successfully rotate a non-square Android View (an EditText for example) without animation, and with API level 8 or lower?
I've spent a pretty good amount of time trying to rotate a view exactly on API level 8 and I think it's impossible to make it work properly. FYI, it doesn't work correctly on android 3.2 either although there's a setRotation(int angle) method in the View class. This won't work correctly at all for VideoView for example.
P.S back then it seemed that I've managed to make the rotation thing work for anything other than VideoView though. Have you overriden the onTouchEvent method? If you have not your view won't be receiving the touch event since rotating the canvas will just make the view draw rotated but it will still receive the touch events in its old area. You have to manually apply rotation matrix to the touch event coordinates in order to offset them to the proper location.
I'm new to Android application development and I'm currently experimenting with various UI ideas. In the image below, you can see a vertically scrolling list of horizontally scrolling galleries (and also textviews as you can see). I'm also doing some matrix and camera transformations which I will come to in a minute.
For the background of the list elements, I use green. Blue is the background of the galleries, and red is the background for the images. These are just for my benefit of learning.
The galleries being used are extended classes where I overrode the drawChild method to perform a canvas scale operation in order for the image closest to the center (width) to be larger than the others.
The list view going vertically, I overrode the drawChild method and used the camera rotations from lack of depth dimension in the canvas functionality. The items in the list are scaled down and rotated relative to their position's proximity to the center (height).
I understood that scrolling and clicking would not necessarily follow along with the image transforms, but it appears as though the parent Gallery class's drawing is constrained to the original coordinates as well (see photo below).
I would love to hear any insight any of you have regarding how I can change the coordinates of the galleries in what is rendered via gallery scroll and the touch responsiveness of said gallery.
Images in the gallery are not same dimensions, so don't let that throw you in looking at the image below
Thanks in advance!
Ben
link to image (could not embed)
-- Update:
I was using my test application UI and noticed that when I got the UI to the point of the linked image and then I touched the top portion of the next row in the list, the gallery updated to display the proper representation. So, I added a call to clearFocus() in the drawChild method and that resulted in more accurate drawing. It does seem a tad slower, and since I'm on the Incredible, I'm worried it is a bloated solution.
In any event, I would still appreciate any thoughts you have regarding the best way to have the views display properly and how to translate the touch events in the gallery's new displayed area to its touchable coordinates so that scrolling on the actual images works when the gallery has moved.
Thanks!
As I updated earlier, the issue of the graphics of the gallery not fully refreshing was resolved by calling clearFocus in drawChild method for the ListView extending class.
The problem with registering the touch events turned out to be where I had used an example for the basis of my experimental program which called a pre-translation on the matrix used for painting. Once I removed that call and adjusted the post-translate call to compensate not having the pre-translate call any longer, I was able to scroll through the galleries regardless of their position, size or rotation (around x axis).