After some poking and prodding at my A7+, I was surprised by some of it's short comings. A couple in particular are easily rectified. The following changes require root access and some means of editing your /system/build.prop file (Root Explorer is real nice).
The first problem was that the screen was not as sharp and crisp as I would have expected for a 7 inch tablet running at 1024x600. As someone on these forums pointed out the LCD density is set incorrectly for the display, and that causes some problems with position/size of things in various apps. To fix this you need to change a line in /system/build.prop.
Code:
Default: ro.sf.lcd_density=200
Correct: ro.sf.lcd_density=160
The next problem is that the device reports OpenGL ES 1.1 when queried through the Android APIs, but when queried through the OpenGL APIs it reports OpenGL ES 2.0. This is a kinda big problem if you like playing indie games because few programmers will bother with low level calls when there is a decent framework to take care of that for them (let's them focus on their product instead of the boilerplate under it). To change this so that it reports correctly in the Android APIs you must add the following to the bottom of /system/build.prop.
Code:
ro.opengles.version=131072
The last problem I've not found an elegant solution for. The tablet doesn't seem to want to engage the second processing core unless a program explicitly demands it. The workaround for this is to install System Tuner, go to CPU, and slide the second CPU (left slider) all the way up, it will not keep this setting upon reset, it does keep it through sleep though. It is much more battery intensive with the CPU full engaged like that, so you'll want to kick it back down when you don't need it. One example where this made a huge difference: I was trying to watch a video encoded in x264 hi10p, without the second CPU engaged the video played slowly while the audio played full speed, with the second CPU engaged it played full speed without so much as a stutter.
I'm going to dig into the tablet a bit more now that I have a terminal emulator and ssh server set up on it. If there are power profiles like the stuff I've had to tweak on my laptop, can likely squeeze out a lot more performance with some fine tuning.
eideticex said:
After some poking and prodding at my A7+, I was surprised by some of it's short comings. A couple in particular are easily rectified. The following changes require root access and some means of editing your /system/build.prop file (Root Explorer is real nice).
The first problem was that the screen was not as sharp and crisp as I would have expected for a 7 inch tablet running at 1024x600. As someone on these forums pointed out the LCD density is set incorrectly for the display, and that causes some problems with position/size of things in various apps. To fix this you need to change a line in /system/build.prop.
Code:
Default: ro.sf.lcd_density=200
Correct: ro.sf.lcd_density=160
The next problem is that the device reports OpenGL ES 1.1 when queried through the Android APIs, but when queried through the OpenGL APIs it reports OpenGL ES 2.0. This is a kinda big problem if you like playing indie games because few programmers will bother with low level calls when there is a decent framework to take care of that for them (let's them focus on their product instead of the boilerplate under it). To change this so that it reports correctly in the Android APIs you must add the following to the bottom of /system/build.prop.
Code:
ro.opengles.version=131072
Click to expand...
Click to collapse
Wow. The lcd change is really nice- everything is much smaller but fits and looks sharper and cleaner. I saw that same post awhile ago but didn't pay much attention to it. Videos also look better.
I'm going to dig into the tablet a bit more now that I have a terminal emulator and ssh server set up on it. If there are power profiles like the stuff I've had to tweak on my laptop, can likely squeeze out a lot more performance with some fine tuning.
Click to expand...
Click to collapse
I really hope you continue to work on this tablet- it definatly needs some work. You should talk to Jam4 over at TR about this. He is making a HC ROM, and I bet he could bake the CPU changes right into the ROM.
I'm new to this stuff but where does the density come from? when I did my own math it seemed closer to 170.
Naidosh said:
I'm new to this stuff but where does the density come from? when I did my own math it seemed closer to 170.
Click to expand...
Click to collapse
Sorry been busy with my coding projects, so haven't popped into the forums in awhile. If I'm right in assuming you calculated that based on the visible screen space and resolution, you have to consider that screens have a metal trim around the edge which covers a few pixels of width and height on each border. If you dig through the source code that eLocity released, there are padding values in place to compensate for those when rendering to the screen. Almost every display out there does this, LCDs are pretty good about minimal over size, but old CRTs would have as much as 20% of the screen tucked behind the bezel for a nice border.
Related
Has anyone ran into problems with Opengl textures on Froyo 2.2, cant seem to get the textured triangle sample to display a texture on my 2.2 nexus one, works fine on the 2.1 emulator. But when I build and run the API demos from the SDK and select the texture triangle it works fine, this is driving me crazy why the same code doesnt display any textures if it’s built as a standalown app. I have tried adding ‘nodpi’ and ‘drawable’ dir’s with the texture images too.
Oh I'm pretty sure it worked fine when my nexus one was running 2.1.
Thanks
Think I solved it, i will post the fix later.
So what was the problem? I'm experiencing this to. I noticed the issue happens if I have ndroid:anyDensity="true" in my app manifest, but if I use anything else, I don't get the full 800x480 screen resolution available to me.
Same issue is happening to me as well. My little opengl 2D test app ran fine in my Nexus 2.1 and after upgrading to 2.2 textures are completely white. Would you please tell us what was your problem?
Thanks!
I think I have your solution.
First, as people may already know, to get the full resolution you want <supports-screens android:anyDensity="true" /> in your application manifest.
The textures are white because when you load them from a Bitmap, android has resized them and the resizing has made them a size that is not a power of 2, so it borks when you load the texture into opengl.
So how to you stop Bitmap from doing that?
create a folder in your "res" directory called "drawable-nodpi" and move your images in to that folder and the system will stop resizing them.
this is only an issue if you are using resources, if you load your images from assets or some other place, then I don't think the system resizes them.
Hope this helps, it worked for me.
-James
Hey James, thanks for your insight
However I just did as you said but I'm still getting the same result. I never used power of 2 textures and they were perfectly rendered; I'm guessing GLUtils.texImage2D already does the dirty work.
anyDensity is set to true, bitmaps are inside drawable-nodpi, all screens are set in SupportedScreens... dunno; I'll guess I'll try to load the texture from elsewhere, not the resources, and see if I can pinpoint the problem.
Hi,
I almost forgot to post here. All James said is true and doing as he said (and using power of 2 widths & height for textures) made it work, but a special circumstance was blurring my point of view here.
The circumstance is that NPOTs seem to be supported in Nexus One with Android 2.1, but not 2.2. Why this support was removed remains a mystery to me
Sorry about not posting what I found and I dont have thread update email reminders turned on. All I did was strip down the api demo (which works) to just a single project and used it as a template.
Let the ports commence
I would prefer to have CM7 Gingerbread stable finished so that we can have something. Porting Honeycomb will be a hard endeavor, and I think the manpower of the modding community of the Vega-ViewSonicGTablet-POVMobii-WhatsItsNameAgain is not too big. I'd rather encourage them to continue what they're doing right now and keep an eye open for a later chance to port the Bee.
bit worried about the scaling issues of 1024 x 600 ran in emulator
problems so far
- scaling on home screen (google search cut off at top)
- apps are a bit large in drawer
- adding widgets/wallpapers/shortcuts function does not scale properly in this res.
ps great fun with the emulator but my god does it run slowly on my laptop for some reason even assigned with 512mb ram :S
wobblydoggy said:
bit worried about the scaling issues of 1024 x 600 ran in emulator
problems so far
- scaling on home screen (google search cut off at top)
- apps are a bit large in drawer
- adding widgets/wallpapers/shortcuts function does not scale properly in this res.
ps great fun with the emulator but my god does it run slowly on my laptop for some reason even assigned with 512mb ram :S
Click to expand...
Click to collapse
Don't worry about the speed - it's due to the emulator emulating the arm architecture and more.
Also, the scaling problems are probably happening because the SDK image was created to a higher resolution - maybe 1280x800, which our tablet does not have.
If LCD density is set to 120 in emulator it works fine
this question is actually about a small network of things: what the default android framework permits, how users use it and what engines can do.
after getting into android programming, it soon seemed to me that the android framework would require me to manage a lot of things i simply don't want to put up with for a simple game (e.g. i don't care about managing intents, creating xml-layouts and stuff like that... slap a couple of images on the screen and i'm fine - well... basically), i started looking for game engines.
after almost a month of research and tests (with default framework, andengine and libgdx), i finally whipped up a little prototype of the game i want to program using libgdx in just two days.
but then i noticed something...
the following issue might make the last third of this post irrevelant:
this game runs at 70% cpu usage on my desktop. even though i would only need to render on user input (it's a puzzle game). so i'm guessing it would use 20 times (or whatever) the battery of the phone it actually should.
since it seems to me "render on demand" isn't possible with libgdx, i figured i'd take another stab working with the default android framework and hope that this doesn't redraw like crazy even though it's not needed.
if such a thing is simply impossible, please tell me and i'll just keep on working with libgdx.
now, the most compact open source game example to learn from that i found is this:
http://code.google.com/p/asqare/source/browse/#svn/trunk/a2
after i tried it out and studied the code, i was stunned by how much stuff is being handled for this very, very simple game (pretty much as simple as mine). so i counted the lines of code... ~4200! while my libgdx prototype has roughly 800. sure, it doesn't have a preferences menu, no about screen and doesn't handle what happens on things like pause/resume but even with those things i highly doubt i'd get anywhere near that amount of code.
so:
IF it is indeed possible to produce a full-screen android app that draws images only on demand, is it possible to do that in a less convoluted fashion than in that 4200 line example?
i'm hopeful that this guy has simply overdone it and i've just been looking in the wrong places for slim examples.
Fyi I did not read 100% of your post, but I think I can help you out.
Imo do not waste your time with game engines. If you are serious about game dev then learn opengl. Its worth it.
With the glsurfaceview you can ether render on demand or as fast as possible. Also as with all opengl u have full control over what is rendered. If need be I can provide an example but it will have to wait a few days.
Sent from my MB860 using Tapatalk
actually, i've learned opengl in the past (but forgotten a lot already - didn't use those skills much) but a) i'll only do 2d games anyway and b) opengl isn't really the problem. getting to where i can actually render things is. and engines allow you to focus on gameplay/rendering without dealing too much with the whole setup and management of things.
i don't feel like libgdx takes control away from me, since i can still use all the opengl-commands i want. and i will definitely look up glsurfaceview and see how it fits into what i currently have. thanks!!
btw - i'm not really "serious". i'm a fulltime artist who happened to have learned about eight years of programming in the past and just wants to try to make a little extra on the side. and create some games i'd like to see but simply aren't out there yet.
and i don't want to spend more time programming all the management nonsense around it than the gameplay itself and working on the design.
I wouldn't rely on the cpu usage on the desktop. The emulator isn't efficient at all...
libgdx is a multiplatform engine, so that cpu usage is based on the desktop-version.
but it does use continuous rendering and can't be switched to on demand. tried to extend the classes of the engine and adapt them so that it renders in on demand for the last three hours without success...
but i've found a neat blog post on the android developers website called "The Simplest GLSurfaceView Application" and hope that i'll be able to find my way from there. after all, i now already at least have a nice full screen canvas with just 54 lines of code... that's something i did not expect i would ever see happening.
Can somebody please tell me whether it is possible to use the yotaphone 2's EPD as a (small) display to do some basic word processing outdoor out in the sun? I.e. to attach a keyboard/mouse to it (e.g. via bluetooth), to open some simple word processing app or even sthg like google docs, and then to just start working.
I have actually been looking for quite some time for some way to do this and I can't for the life of me understand why there aren't better solutions out there. I am always pleasantly surprised when I type notes on my Kindle Paperwhite. Of course it's a lot slower than on an LCD, but I am not a fast typer anyway, and I could live with some lag - if that's the price I'd have to pay to finally be able to work outside. I have thought of the Raspberry Pi x Kindle solution (but you can only type on sthg like vim); of ebook readers with an open OS that you can attach a keaboard/mouse to (like Onyx Boox that runs on Android 4.0 - and I'm still thinking about that); or of an e ink monitor (too expensive). But it is time for me to change phones, and if this works, I might actually consider it.
If anybody has any experiences or thoughts or - better yet - videos to share on this, I'd be very grateful... Thanks!
-Stephan
I haven't tried this personally, but I am fairly certain that this would work. Android supports bluetooth keyboards. The only limitation would be that you have to use mirrored mode, because there are no proper word processing apps made native for the EPD. Plus the system might not enable external keyboard for EPD apps only. Not sure on the latter though, I don't have any bluetooth keyboard/mouse to test this with.
Jeopardy said:
I haven't tried this personally, but I am fairly certain that this would work. Android supports bluetooth keyboards. The only limitation would be that you have to use mirrored mode, because there are no proper word processing apps made native for the EPD. Plus the system might not enable external keyboard for EPD apps only. Not sure on the latter though, I don't have any bluetooth keyboard/mouse to test this with.
Click to expand...
Click to collapse
Thanks Jeopardy. Can you (or anybody else) tell me whether there is an active developer community working on those EPD apps? And also - if you have to use mirrored mode, does this mean you have to open the phone and the AMOLED screen has to be 'on'? On can all of this just stay in the 'background'? And does mirroring to an additional lag beyond the usual - and much slower - e-ink refresh rate? If anybody has any first-hand experience with this, I'd really be curious... Thanks!
sdspieg said:
Thanks Jeopardy. Can you (or anybody else) tell me whether there is an active developer community working on those EPD apps? And also - if you have to use mirrored mode, does this mean you have to open the phone and the AMOLED screen has to be 'on'? On can all of this just stay in the 'background'? And does mirroring to an additional lag beyond the usual - and much slower - e-ink refresh rate? If anybody has any first-hand experience with this, I'd really be curious... Thanks!
Click to expand...
Click to collapse
Well there are some developers, myself included, working on EPD applications. But not a lot. There should be more once Yota releases the device in USA around mid-August.
Mirrored mode does not need the color screen to be turned on. Of course behind the scenes it will wake up the system to similar state as if the AMOLED screen was on, but that's handled automatically. This means more battery use, but you should get a lot more out of it than using the color screen, especially on static apps like word processors which don't update often.
You can handle everything from the EPD. You can, for example, create a shortcut on the EPD for a word processing app, which will automatically enable mirroring and open that application. The lag on EPD when mirroring should be about the same as on native EPD applications, but of course you will notice it more because you can easily compare it to the non-laggy color side. There's only a few extra algorithms for turning the color image to nice greyscale, and some logic for creating additional "flashes" to fix ghosting when switching between apps etc. Should be fine for word processing, especially on external keyboard, provided you can write without constantly checking which letter you just pressed. The refresh rate on the EPD is about 8 frames per second, or one frame every 0.12s.
If you're seious about outdoor word processing may I suggest a rooted Nook Simple touch? It is small and light and a fraction of the price of a Yotaphone... as well as having a much bigger screen! You can pick these up for around 40GBP in good/new condition and although it will be a fair bit of messing around with rooting you are unlikely to come totally unstuck, and there is a lot of support on XDA to get you help if you do. With the NST device, you use the OTG USB mode to attach a bluetooth dongle, hard wired full sized keyboard or whatever to your desire. Pop over to the NST forum and there are many threads on this topic, but to whet your appetite here's someone who is doing that with a solar panel to power the setup!
http://forum.xda-developers.com/nook-touch/general/nook-simple-touch-solar-power-t3068849
Alright, I'm reaching out to the community for help on this one. With the recent sale on Daydream VR (they're $50 from Google and Verizon right now), I have been trying to optimize my 6P with the VR set. I have tried some of the suggestions on the form, but I'm still having stuttering issues. So I had the idea about lowering the resolution. So I used the "wm size 1080x1920" trick and successfully dropped by resolution down, and adjusted the DPI accordingly. It runs well, however, when I put it in the VR set, the viewing angles are messed up. When I put the headset on, both eyes are not lined up with each other. I fiddled around with all the wm settings I could find (overscan, scaling, etc), and I can confirm that the viewing angle is messed up in the opposite direction when I set the size over 4k.
I used a Display Settings app to look at my settings, and it seems as though the device thinks the actual screen size is changing when I change the resolution, which may be why Daydream is maligning the eye points.
Is there a way to change the resolution while making the device think the screen size has stayed the same? Or is there a way to change this info just for Daydream?
If it's any encouragement, the Daydream apps ran very smoothly with one eye closed at 1080p. The Google Photos app stuttered at 4k but had no problem at 1080. So if we can figure this out, we could have a smoothly running Daydream setup.
razgriz8426 said:
Alright, I'm reaching out to the community for help on this one. With the recent sale on Daydream VR (they're $50 from Google and Verizon right now), I have been trying to optimize my 6P with the VR set. I have tried some of the suggestions on the form, but I'm still having stuttering issues. So I had the idea about lowering the resolution. So I used the "wm size 1080x1920" trick and successfully dropped by resolution down, and adjusted the DPI accordingly. It runs well, however, when I put it in the VR set, the viewing angles are messed up. When I put the headset on, both eyes are not lined up with each other. I fiddled around with all the wm settings I could find (overscan, scaling, etc), and I can confirm that the viewing angle is messed up in the opposite direction when I set the size over 4k.
I used a Display Settings app to look at my settings, and it seems as though the device thinks the actual screen size is changing when I change the resolution, which may be why Daydream is maligning the eye points.
Is there a way to change the resolution while making the device think the screen size has stayed the same? Or is there a way to change this info just for Daydream?
If it's any encouragement, the Daydream apps ran very smoothly with one eye closed at 1080p. The Google Photos app stuttered at 4k but had no problem at 1080. So if we can figure this out, we could have a smoothly running Daydream setup.
Click to expand...
Click to collapse
It's just a guess, but have you tried to edit the build.prop file in order to "mess around" with declared display density over there?
chk27 said:
It's just a guess, but have you tried to edit the build.prop file in order to "mess around" with declared display density over there?
Click to expand...
Click to collapse
Yes, I messed with any of the build.prop settings that dealt with display. I long ago gave up and now have an Axon 7. Good luck to anyone else trying it!