Related
For progress on the development of a gamepad for blackstone please go to the end of the thread.
was pondering the problem of playing non-touchscreen games on the hd and the lack of control options.
In a basic form what is needed is 8 way direction control and a number of buttons that can be pressed simultaneously:
There are three options that I think are worth investigating:
1) general g pad controls simulated by g sensor plus additional buttons created on a SIP or shell for the games.
2) a software shell that places a touchscreen dpad on one side of the landscape screen and have the light sensor and front camera on the other side as buttons. A keypress would be simulated when the ssensor is covered by a finger. Perhaps the back camera too? This would allow many games to be played, I think.
3) Calculated multitouch. When a resistive screen is multitouched I think this produces an intermediate result between the two touches.
If you created a shell that had precise positions of all the buttons worked out multitouches could be mathematically calculated and then sent as simulated keypresses... n effect creating a virtual and invisible keypad in the middle that only becomes active when more than one button is pressed.
For example pressing up and the (a) button creates a virtual touch in the red circles etc.
If actual touches are intercepted and only virtual touches sent as keypresses this could also work.
{
"lightbox_close": "Close",
"lightbox_next": "Next",
"lightbox_previous": "Previous",
"lightbox_error": "The requested content cannot be loaded. Please try again later.",
"lightbox_start_slideshow": "Start slideshow",
"lightbox_stop_slideshow": "Stop slideshow",
"lightbox_full_screen": "Full screen",
"lightbox_thumbnails": "Thumbnails",
"lightbox_download": "Download",
"lightbox_share": "Share",
"lightbox_zoom": "Zoom",
"lightbox_new_window": "New window",
"lightbox_toggle_sidebar": "Toggle sidebar"
}
My question is for the technical people out there who know much more about this device than me... is there any obvious reason you can see that one or all of these methods would not work?
Theoretically combinations could allow for great flexibility... for example - in a first person shooter - look direction could be controlled by the g sensor, actual body direction controlled by a virtual d pad and firing and jumping by simulated key presses.
Or in a driving simulator left right accelerate and brake could be controlled by the g sensor and a gearstick and other controls by virtual buttons.
Very versatile.
I'm working on it
http://forum.xda-developers.com/showpost.php?p=3373604&postcount=19
The current version has a fully functional dpad and mouse.
I'm intending to make a specialised version for gaming, with just a dpad and maybe a couple of "A" and "B" type action buttons, probably customisable.
V
Hey, this sounds really awesome! Keep it up!
Anyway all that games are 640x480 at most so we have 160 pixels to put software DPAD for playing them (instead of doing scaling) and I think that in the future when 800x480 games will come out there will be better solution to play those games . All we need is someone who is gonna write the codes for that software DPAD to fill rest of the screen.
This is my point... a solution to access the many great vga games. However the control system is problematic... hence this post to determine the best solution. A standard sip will not do.
vijay555 said:
I'm working on it
The current version has a fully functional dpad and mouse.
I'm intending to make a specialised version for gaming, with just a dpad and maybe a couple of "A" and "B" type action buttons, probably customisable.
V
Click to expand...
Click to collapse
Looks great, mate. For your gaming version will it integrate with wvgafix?
vijay555, I may have just fell in love with you! We're getting closer and closer to being able to play emulator games, flash games, and all sorts of other games! Wheee!
Kizmet said:
Looks great, mate. For your gaming version will it integrate with wvgafix?
Click to expand...
Click to collapse
It would definitely be cool if that black space at the bottom that's not used when switching to VGA/QVGA could be used by the pad.
Just out of curiosity, vijay, does the app you're working on simulate multi-touch like Kizmet is suggesting here? (Kudos to you, Kizmet, for illustrating this idea so wonderfully by the way!)
I'm investigating WVGAFix right now - I've been out of the scene for a while, and so much new stuff has come out, so it's the first time I've seen this app.
I currently use a different solution which achieves a similar result to WVGAFix, but in a different way. When VJVirtualMouseWinFX loads, the screen will shrink up to make space for my control zone, in a similar way to WVGAFix.
However, WVGAFix is very interesting, and possibly a better solution for fullscreen games, but it may interfere with receiving "mouse clicks" in the area of the screen that is made black, as that black area doesn't "exist" as far as the OS is concerned.
Another problem is that WVGAFix won't work neatly with landscape orientations - unless you really want the DPAD control zone to be stuck on the right of the screen while playing in landscape. As I said elsewhere, I'm investigating some other neater layouts when in landscape.
I may try to find a neat hybrid solution between WVGAFix and my method.
The multitouch concept IS incorporated in another version - a dpad only version specialised for games (as you want more space so you don't accidentally click the mouse).
The multitouch DOES work, but is not as comprehensive as the recent G1 hack for Android multitouch (well, as far as I know, I don't have a G1). Calculated multitouch on Windows Mobile works in some situations, but for instance the iPhone "pinch" gesture cannot be well emulated. However, "pinching" with one finger while leaving the other one still DOES work, so multitouch is about 80% functional.
Also, simultaneously rotating two digits around a static centre point (eg Minority Report) also doesn't work well, but that's not a very comfortable gesture anyway!
V
vijay555 said:
I'm investigating WVGAFix right now - I've been out of the scene for a while, and so much new stuff has come out, so it's the first time I've seen this app.
I currently use a different solution which achieves a similar result to WVGAFix, but in a different way. When VJVirtualMouseWinFX loads, the screen will shrink up to make space for my control zone, in a similar way to WVGAFix.
However, WVGAFix is very interesting, and possibly a better solution for fullscreen games, but it may interfere with receiving "mouse clicks" in the area of the screen that is made black, as that black area doesn't "exist" as far as the OS is concerned.
Another problem is that WVGAFix won't work neatly with landscape orientations - unless you really want the DPAD control zone to be stuck on the right of the screen while playing in landscape. As I said elsewhere, I'm investigating some other neater layouts when in landscape.
I may try to find a neat hybrid solution between WVGAFix and my method.
The multitouch concept IS incorporated in another version - a dpad only version specialised for games (as you want more space so you don't accidentally click the mouse).
The multitouch DOES work, but is not as comprehensive as the recent G1 hack for Android multitouch (well, as far as I know, I don't have a G1). Calculated multitouch on Windows Mobile works in some situations, but for instance the iPhone "pinch" gesture cannot be well emulated. However, "pinching" with one finger while leaving the other one still DOES work, so multitouch is about 80% functional.
Also, simultaneously rotating two digits around a static centre point (eg Minority Report) also doesn't work well, but that's not a very comfortable gesture anyway!
V
Click to expand...
Click to collapse
Exactly... calculated multitouch works on half the distane between the touched points.... a pinch gesture would essentially provide the same result all through the pinch.
But in limited control circumstances it can work to simulate a dpad press and simultaneous firing press.
I think your version of shrinking the screen may actually be more flexible than wvgafix... because it would allow you theoretically to have a shell on either side of a landscape screen.. right?
This is what is needed.. dpad on the left buttons on the right.
The spare space of 160 pixels may not be enough... so if the screen can be shrunk slightly then that may allow for better controls.
Alternatively.. using the sensors (light and camera) as simultaneous buttons would give two available buttons with very little coding. But the question is how much battery does that drain and are the sensors sensitive enough?
Kizmet: yes exactly re the pinch.
WVGAFix's solution is good for making other software compatible with WVGA, but my solution is generally compatible with normal Windows Mobile software.
I think regarding fullscreen games, I envisage placing a dpad on one side of the screen, the A and B buttons on the other in the bottom corner, and these can be physically overlaid over whatever's on the screen. I think that feels quite comfortable.
V
that sounds good. That may clash with some games and obscure something, though... perhaps semi-transparent controls may work?
@Kizmet: I have considered semi transparent, but it's a big amount of work.
Windows Mobile doesn't support layered/alpha blended windows well, so the blending has to be done manually. This is CPU intensive, and so is likely to slow the game down.
And even then, it's not very easy to achieve - VJVirtualMouseWinFX supported an alpha blended mouse pointer, but it was too crufty to rely on, and not worth the work, so I removed this feature.
And of course - if your thumbs are covering the control pads, you can't see through them anyway on to the screen!
I'll have to test how well, if at all, this can be achieved on a fullscreen high motion game.
I have some other ideas how to implement the control mechanism, but I think we should all think of any other ideas of how to implement it.
Personally, I'd rather lose say a 100x100 pixel square in each corner, than 100x480 rectangle on the left and right of the screen, so I think an overlaid control pad in each corner makes most sense.
Unfortunately this screenshot doesn't demonstrate this well, but it's a mockup to give you an idea of what I'm thinking.
V
I'm a little confused. If we had a game that would normally take up all 800x480 of the screen are you talking about keeping the game that size and then placing the controls on top of it (which would hide the image behind the controls) or are you saying you can shrink the application's display giving unused screen space on either side that can be used for the controls?
Keeping in mind a game controller that would have a d-pad and left bumper on the left side, and 4 buttons and a right bumper on the right side I would say the shrunken display in landscape would be great.
Too bad that transparent controls wouldn't work though since there's some wasted screen space. Although that's not a concern I suppose since most games/emulators/etc wouldn't use the full screen anyhow.
@sschrupp: obviously if all games are made in WVGA, then that would be great, but as some games are only designed to support a maximum of VGA, it means that we have blank space anyway, that's being wasted.
The suggestion is to find a way to make use of the blank screen, perhaps by placing the controls in the blank areas.
However, what I'm saying, is that whether the game is QVGA, VGA or WVGA, somehow, if you want to emulate a DPAD etc over the game, it needs to occupy some screen space, obviously.
Whether we want to overlay those controls on top of the full screen game, obscurring the screen underneath, or shrink the game screen, either way we have to live with some inconvenience.
Personally, given as many games will either be VGA, or will have some "chrome" already, ie will already have some non game space on screen, personally I think we just stick the dpad controls in some definable position on screen and hope we're not covering much (if any) of the actual game.
V
sschrupp said:
I'm a little confused. If we had a game that would normally take up all 800x480 of the screen are you talking about keeping the game that size and then placing the controls on top of it (which would hide the image behind the controls) or are you saying you can shrink the application's display giving unused screen space on either side that can be used for the controls?
Click to expand...
Click to collapse
In this instance we don't need to worry about games that are already 800x480 - they will have been designed for devices with predominant touchscreens... so the control system will be part of the game. But don't hold your breath for too many releases like that. Without buttons the type of games available is limited.
The need arises to allow some way for the hd to be able to play games already available for similar devices - these are typically in vga 640x480 but need hardware keys the blackstone doesn't have.
So the question is how do we best utilize the screen space and how do we best emulate buttons?
Answer these two questions without slowing down the performance and then you will have the killer shell that will make the blackstone an awesome gaming machine as well as multimedia device.
Someone needs to make something like this for the Touch HD...
http://www.icontrolpad.com/
vijay555 said:
@Kizmet: I have considered semi transparent, but it's a big amount of work.
Windows Mobile doesn't support layered/alpha blended windows well, so the blending has to be done manually. This is CPU intensive, and so is likely to slow the game down.
And even then, it's not very easy to achieve - VJVirtualMouseWinFX supported an alpha blended mouse pointer, but it was too crufty to rely on, and not worth the work, so I removed this feature.
And of course - if your thumbs are covering the control pads, you can't see through them anyway on to the screen!
I'll have to test how well, if at all, this can be achieved on a fullscreen high motion game.
Click to expand...
Click to collapse
Although I think blended buttons would be lovely to look at.. as you say it's not very practical.
The essence is speed here, I think. Speed and simplicity.
I have some other ideas how to implement the control mechanism, but I think we should all think of any other ideas of how to implement it.
Personally, I'd rather lose say a 100x100 pixel square in each corner, than 100x480 rectangle on the left and right of the screen, so I think an overlaid control pad in each corner makes most sense.
Click to expand...
Click to collapse
I think we're just going to need more space than that.
The control can't be too small otherwise it will be fiddly and hard to use.
I did a couple of mock ups of two of the alternatives:
Calculated Multitouch:
A shell program that places a bar of 100 px on the left and 60px on the right... with buttons set onto it.
Multitouches can be calculated and only touches registering at positions 1,2 or 3 (for example) would be sent to the program by the shell as button presses.
An 8 way controller with 2 buttons would need 16 virtual centre points to be calculated (with some margin for error) they must not overlap but they can be tight against each other as they will not be used.
Although it's called calculated - there is actually no need for calculation on the fly - positons would be stored in a simple look-up table. And thus it could be coded to be fast!
It's also very flexible since there is theroretically no reason you couldn't have more buttons.
However only two touches can be registered simultaneously.
Sensor Method
This is more of a quick fix to me since it only allows for two buttons... but if the light sensor and camera are up to it this is a faster and easier method:
The control centre on the left is 160 px wide and the two sensors held to the right.
Covering a sensor with a fingertip would register as a button press as would covering the camera.
The question here is can the light sensor be polled fast enough? Does it drain battery too fast and is it sensitive enough?
Same q's for the front camera... in fact the back camera could also be used if needed.
This method is slightly less flexible but potentially faster and more accurate. The larger dpad this allows would be better for blokes with large fingers, like me.
Now.. take either of these solutions and throw in a gsensor button simulator that calibrates on touching the d pad and then gives you 4 more directions with accelerations and you have a powerful game control system. Powerful enough to handle complex games like driving/air sims and first person shooters.
Jim_Fear said:
Someone needs to make something like this for the Touch HD...
http://www.icontrolpad.com/
Click to expand...
Click to collapse
Yeah they are cool.. I saw one shaped like a joypad with a hole perfect for the iphone in it.
A software solution is going to becheaper and more practical, though.
Ok I have seen a lot of confusion over the months regarding the LCD Panel fitted to the Kaiser, I will attempt to answer most of these issues here.
Hardware: The kaiser series is fitted with a 2.8 inch 240x320 TFT LCD panel, which means that it 240 pixels wide by 320 pixels deep, the optimum density of this LCD panel is 143 Pixels per Inch.
Resolution: This refers to the screen resolution that the Operating System will use to display on the LCD panel, the 3 most common being 240x320, 320x428 and 320x480, the reason this is possible is that the OS is capable of fooling the display into using the fixed 240x320 panel to display more pixels, ( it does not really have more pixels, it just looks like it).
DPI: DPI or Dots Per Inch, also known as Density, and correctly known as PPI or Pixels Per Inch, this refers to the number of pixels the screen displays in a One Inch Square on the screen. As I noted above, the actual PPI of the LCD panel is 143 PPI, this is fixed by the hardware, and cannot really be changed, however since the LCD is software driven, it can be persuaded to look as if it is displaying more or less pixels in that same area.
Panel Type: This refers to the actual LCD panel fitted to your device, there are 3 types fitted to the Kaiser series, one manufactured by Sony, the other two by Topoly. While the 3 different types of panel are functionally identical, they differ at the electronic level. On Windows Mobile this difference can be detected by the OS, however on Android this is not possible, so the panel type must be set in the parameters passed to the kernel at boot time, either in default.txt when booting from SD, or hardcoded in the NBH when booting from Nand. Also there is no easy way of telling which panel type is fitted to any given Kaiser, since the panel type was chosen by HTC depending on price and availability and stock at the time of manufacture, so any model of Kaiser can have any of these types fitted.
The main problems encountered with the display are usually solved by changing the Panel Type, either by editing default.txt, or reflashing the correct NBH, ( note that you can also edit the kernel parameters of an NBH using a Hex Editor, however this would be a relatively advanced method, since an error could cause major issues).
Changing screen resolution and density: As noted above there are 3 main resolutions used, 240x320, 320x428 and 320x480. These easy to change either by editing default.txt, or flashing an NBH, depending on how you run Android, resolution is usually a personal choice. Density is not as easy to change, although Rogue Tools by Myn, (available in Market, and discussed here: http://forum.xda-developers.com/showthread.php?t=667581), is excellent for this purpose, there are various common PPI settings, and again mostly personal choice, a little experimentation with resolution and density will allow you to find what you prefer.
Hope this helps clear things up a little
Thanks for this, it helps alot!
vertical lines issue
just to add to the above: the vertical lines issue some have is related to choosing the wrong panel type. Chosing the correct one will solve the problem.
Wrong panel make errors display, ok! But Can it lead to additional consumption of the battery?
Dark-Side said:
Wrong panel make errors display, ok! But Can it lead to additional consumption of the battery?
Click to expand...
Click to collapse
I suspect it may, since display errors such as vertical streaks, pixel errors, colour issues etc are actually caused by a mismatch between the OS drivers and the actual physical electronics, and it's possible that the panel may demand more power than it would normally, I'd have to bench test this to be sure, but it's probably easier just to use the correct panel type setting.
The correct panel type should lead to a 'normal' demand on the battery.
zenity said:
I suspect it may, since display errors such as vertical streaks, pixel errors, colour issues etc are actually caused by a mismatch between the OS drivers and the actual physical electronics, and it's possible that the panel may demand more power than it would normally, I'd have to bench test this to be sure, but it's probably easier just to use the correct panel type setting.
The correct panel type should lead to a 'normal' demand on the battery.
Click to expand...
Click to collapse
I use panel 2... I go to use panel 3 to test this. panel 1 make for me pixel errors. I'll report here.
Thank you
EDIT: no difference between panel 2 or 3 on my kais130
Thanks! That helps a lot.
I havd a thought, which is to change a physical LCD panel for my kaiser, HVGA or VGA... Is that possible? I would look into some electronic files later...
i guess that our chip has max resolution only 320x240 so no higher resolution
but as I look in the pdadb.net there are some devices with higher resolution and same chipset as ours so perhaps it is possible
It is unlikely to be possible to use another panel, since there are a lot of differences with the interface, it's not just the chipset, but how it's wired, plus higher resolution panels may need extra address lines which are not present in our kaisers.
For those of you experimenting with LCD Density settings. You may wish to try the following density settings.
100
121
144
169
196
Remember, pixels are square, so the density settings should reflect this, also the extreme ends of this table are just that, extreme
zenity said:
For those of you experimenting with LCD Density settings. You may wish to try the following density settings.
100
121
144
169
196
Remember, pixels are square, so the density settings should reflect this, also the extreme ends of this table are just that, extreme
Click to expand...
Click to collapse
density 106 works very well with 240x320 if the build is designed for 320x480. I'm using that on the CyanogenMod port. Haven't tried it with other builds though. I did try 107 once with another build but that did not turn out very well.
106? that should really look a little blurry, but I think it depends on the resolution that the build was designed for, however I think I'd find it a little small personally, have you tried 100? it should look clearer than 106, although I have noticed that some people just prefer a certain density regardless of the actual mathematically 'correct' one.
zenity said:
...
Panel Type:....
.... On Windows Mobile this difference can be detected by the OS, however on Android this is not possible, ...
Click to expand...
Click to collapse
So how do I detect which panel in winmo?
I don't like the idea of just stabbing blindly in the dark and hoping I get it right.
Basically? Stab in the dark, there is no way in wm or android to know which type is fitted, type 2 seems most common, and is usually a 'safe' default, if the graphics/colours are wrong, you probably have type 1, if you have issues waking from sleep then you probably have type 3. So try panel 2 first.
Sent from my HTC Dream using Tapatalk
I'm running Android on my HTC Tilt and am using panel 2. I tried panel 1 and the colors were off so Panel 2 seems good.
But the problem I am having is that when I open up the dialer, it doesn't fit correctly on the screen, the bar which shows which numbers you have entered covers up the numbers 1,2,3 and the sides are cropped.
Everything else seems to be fine why is the dialer messed up?
Should I try changing density its at default right now.
I personally like to use 110, but every time I open detail application on Market, it gave me force close. Facebook for Android does that too (I mean FC) whenever I open detail message or upload picture from gallery.. I've tried 106, 104 and 100 and still having the same problem.. it's not happening when I use 120 for density, everything seems work properly normal.. is that common or I have to do something to fix that problem?
Thats not normal behaviour for market, although it has been known to be a little flakey on some builds, however this is unlikely to be related to lcd density, since density only affects the visual appearance of the screen, not the OS itself.
Which Panel?2 or 3?
Am using HTC Tytn II and recently i tried almost all Android builds(donut,eclair,froyo) on my device.panel 1 shows some pixel errors and panel 2 and 3 makes no big difference for me, both settings showing a white flash screen on wake up!
and panel 3 i feel little smudge,not sure.panel 2 wake up with white flash screen and follows by grains(just like noisy TV screen).All these for two seconds.after that TYTN II behave normally.Any body can help me please?
stajan said:
Am using HTC Tytn II and recently i tried almost all Android builds(donut,eclair,froyo) on my device.panel 1 shows some pixel errors and panel 2 and 3 makes no big difference for me, both settings showing a white flash screen on wake up!
and panel 3 i feel little smudge,not sure.panel 2 wake up with white flash screen and follows by grains(just like noisy TV screen).All these for two seconds.after that TYTN II behave normally.Any body can help me please?
Click to expand...
Click to collapse
As previously stated, panel 2 is the most common of all.
As for the white flash and grainy display, this is due to the fact that we have to "fake v-sync" in order to display anything on our screens. Remember, Android was not designed for our Kaisers, but developers got it to run, piece by little piece, really well on our devices. There will always be drawbacks to this as the hardware doesn't really meet the requirements of what Android was developed for.
If you want to see whats going on when you have a white screen or snow, slide the keyboard open and press "Fn-left softkey". this brings up a screen that shows you what Android is doing.
To return to the main screen, press "Fn-right softkey".
Hope this helps...
Hello,
I'm trying to make a little app made of several screens (say from 1 to 5).
When the application is launched, it will display screen 1, and users will be able to go to screen 2 by clicking on 'Next', then 3, and so on. They will also be able to go back.
To improve user-friendliness, I want to make those different screens slide. I saw some software doing it smoothly, so it should be possible.
So I tried to do the same, using a panel wider than the screen and changing his 'Left' attribute. But the result was very bad (it's CPU-killing and it's not smooth at all). I've enclosed the project if someone wants to have a look.
My question is: How I can get these screens slide smoothly?
P.S.: I saw two SDKs making nearly what I want (XFControl and SliderList), but it seems that one screen have to be parent of the other, and that's not what I want
There seems to be very little actual documentation on the various eInk update modes.
Most of the information seems to have been extracted from working code.
Some of that code does not seem to be optimal in any case.
I'd like to start this thread on a discussion of the update modes.
You can look at all the code posted, but the bottom line is that eInk mode is configured by passing six discrete pieces of information to the EPD driver.
These six pieces may be wrapped up into a single static entity.
Name of entity requesting change (for logging purposes only)
Region, one of enumRegion[] (Region 4-7)
A rectangle, normally {0, 0, 600, 800}
Wave, one of enumWave[] (GC, GU, DU, A2, GL16, AUTO)
Mode, one of enumMode[] (INACTIVE, ACTIVE, ONESHOT, CLEAR, ACTIVE_ALL, ONESHOT_ALL, CLEAR_ALL)
Threshold, an int 1-15, only applies to A2 mode
A2 is the one bit, fast drawing method. It leaves ghosting behind.
In some applications, you would like to enable faster scrolling in A2 mode and then have it revert to "normal" upon completion.
I have an application with a full screen scroll.
After experimenting with the values, these two configs seem to do the job nicely.
Code:
configA2Enter = makeConfig(rpc, waveEnums[WAVE_A2], regionEnums[REGION_6], modeEnums[MODE_ACTIVE_ALL], THRESHOLD);
configA2Exit = makeConfig(rpc, waveEnums[WAVE_AUTO], regionEnums[REGION_6], modeEnums[MODE_ACTIVE_ALL], 0);
No user intervention is necessary, it scrolls quickly and redraws a clean image when done.
(A view.invalidate() is necessary after you invoke configA2Exit)
Does anybody have any further insight into these values or suggestions for improving them?
Some additional information on the A2 ("no refresh", 1 bit) mode.
Some of the other modes can be selectively applied to portions of the screen.
The A2 mode may only be applied to the entire screen.
The threshold value, which some may construe as "brightness" or "contrast"
is the cutoff threshold between black and white of the original image.
A value of 1 will only generate black in the darkest areas of the original image.
A value of 15 will only generate white in the whitest areas of the original image.
That is, 1 will give you a light image, 15 a dark image.
Renate NST said:
Some additional information on the A2 ("no refresh", 1 bit) mode.
Some of the other modes can be selectively applied to portions of the screen.
The A2 mode may only be applied to the entire screen.
The threshold value, which some may construe as "brightness" or "contrast"
is the cutoff threshold between black and white of the original image.
A value of 1 will only generate black in the darkest areas of the original image.
A value of 15 will only generate white in the whitest areas of the original image.
That is, 1 will give you a dark image, 15 a light image.
Click to expand...
Click to collapse
Nice find! I didn't know that was a B/W threshold. But I think you meant "1 gives a light image and 15 a dark image".
I've just tried using this in NoRefreshToggle, but the result was not as good as before. The image is much more just solid black and white because you can't see the dither patterns that represent grey (they appear only at very specific white levels, which would be nice to tweak too).
What I actually use for "contrast" adjustment in NoRefreshToggle is a different approach. Using a fixed threshold of 14 (dark image), I've managed to lower the black level (turning it more greyish) to achieve a smaller color range. This way, the dither patterns appear more often. However, my technique to achieve this effect is not so elegant: I overlay the entire screen with a semi-transparent white pane. This has the inconvenient of controlling the pane visibility: whenever A2 mode is turned off (by user or system), I need to hide the pane View.
If I could temporarily avoid the automatic changing of screen modes by the system, this would be much simpler. I've had no success at this issue so far.
marspeople said:
I think you meant "1 gives a light image and 15 a dark image".
Click to expand...
Click to collapse
Yup, good catch. The preceding two sentences were correct. I edited the third.
I have a demo panning grayscales. It's easy to see where the threshold is occurring. Shown below.
Oh! I did see something about the dither modes.
They would certainly be useful for video, less so for text.
I think a system-wide use of A2 would be a bit counterproductive.
The fonts look better with 16 shades.
The best use would be to have browsers and viewers use A2 for panning and zooming.
And another thing:
I don't know how you are getting the dither in there, but since you are doing an overlay anyway,
maybe you should try a halftone screen approach to see how it would work.
The simplest halftone screen would be a checkerboard with two different transparencies.
That wouldn't sacrifice too much resolution.
Renate NST said:
I think a system-wide use of A2 would be a bit counterproductive.
Click to expand...
Click to collapse
i seems to me that n-r mode would be much more usefull if would could regulate when its on a and when off. Its quite pain running the app again and again. it seems to me that quicker reaction is much better than nicer pictures in average use - pdf reading, browsing, video, managing system...
marspeople said:
I've just tried using this in NoRefreshToggle, but the result was not as good as before. The image is much more just solid black and white because you can't see the dither patterns that represent grey (they appear only at very specific white levels, which would be nice to tweak too)
Click to expand...
Click to collapse
I don't think the dithering can be 'tweaked' as such. It's caused by the reduction of 24-bit color images to the 16-bit colorspace of the OS. Dithering is performed by the graphics hardware to prevent obvious colour banding, and there's no OpenGL functions to control dithering parameters.
The A2 mode seems to choose a threshold value for black in the 16-bit colorspace. Values above this are white. In order to obtain black and white dithering we have to pick values in the 24-bit colorspace which all lie in the same 16-bit band.
The easiest way I've found is to keep the R and G values at 255 and vary the B value. I think the default threshold lies at 255,255,198. If you start at that and increase the B value you get 7 dithered grey shades before you reach white.
Guys, as far as i know, eink display is build of tiny capsules, much smaller that one pixel is, and a chip is joining them into pixels. So mayby there is a way to divide single pixel into 2 or even 4? It is much much work, but it would make us easier draw some tones of monochrome? Example: to get dark gray, instead of displaying one of five black pixels white, we can make one's "subpixels" 3/4 black, 1/4 white.
Does it make sense/do you get it?
Renate NST said:
I think a system-wide use of A2 would be a bit counterproductive.
The fonts look better with 16 shades.
The best use would be to have browsers and viewers use A2 for panning and zooming.
Click to expand...
Click to collapse
I agree with you. But having temporary exclusive control of A2 mode would make my application more efficient. I don't intend to use A2 system-wide.
Renate NST said:
And another thing:
I don't know how you are getting the dither in there, but since you are doing an overlay anyway,
maybe you should try a halftone screen approach to see how it would work.
The simplest halftone screen would be a checkerboard with two different transparencies.
That wouldn't sacrifice too much resolution.
Click to expand...
Click to collapse
I just tried this but I've got nothing more than a simply darker and checkered image. I don't understand how it would be better.
marspeople said:
I don't understand how it would be better.
Click to expand...
Click to collapse
Well, halftone screens have been around forever.
Think of it this way, it would give you two different thresholds.
With a bigger pattern you would get more thresholds but a coarser pattern.
That is always the way with dithering or halftone.
Probably a screen would not work well with an underlying dither.
A useful observation from http://forum.xda-developers.com/showthread.php?t=1502723&page=11 is that by listening to the screen you can hear screen activity.
After a quick test I suspect ONESHOT mode allows the screen to enter a power saving mode (in which the screen is completely silent) after a few hundred ms of inactivity, while ACTIVE prevents it. No idea whether there are other issues involved.
The native Reader.apk uses GU, ONESHOT_ALL when turning pages.
Every 6th page it uses GC, ONESHOT_ALL.
In an overnight test with the nook screensaver / lock screen mode inhibited by my application and no screen updates, I obtained power consumption of 0.75% / hour with ONESHOT mode. In a previous test with ACTIVE mode I got ~7% / hour with the same scenario(!)
With fast screen updates of ~ 1Hz ONESHOT does not appear to give any power saving benefit over ACTIVE mode, and a quiet hiss can be heard from the screen at all times in both modes at this refresh rate. I think this indicates the ONESHOT mode allows the screen to enter a power saving mode after a period of inactivity.
Neither of these were scientific tests but I strongly suggest trying ONESHOT mode in favour of ACTIVE whenever using A2 mode.
Well, there must be some benefit sometime to the ACTIVE mode or they wouldn't have it.
It's hard to differentiate the different modes, but it seem that ACTIVE responds quicker with less delay.
I switch to ACTIVE_ALL, A2 for panning and switch back to ONESHOT_ALL, AUTO afterwards.
(I don't use full-time A2).
See my demo of panning: http://forum.xda-developers.com/showthread.php?t=1563645
I'm running about 7%/hour drain. My Nook is not suspending when I do a simple power button click. I don't know why.
A few folks seem to be using EpdController in a useful manner.
Their use of Java reflection is clever, but it's not supposed to be that difficult.
I wrote a Java stub (basically declarations) for EpdController and wrapped it in a jar.
If you just put this jar in your compilation classpath with your normal android.jar
then you will be able to use the EpdController without all the fuss and muss.
For example, in my latest (unreleased) version of UsbMode I want the blinker to go on and off cleanly:
Code:
EpdController.setRegion("UsbMode", EpdController.Region.APP_3, blinker, EpdController.Wave.DU);
That's it, one line, no initialization.
The EpdController class was designed to handle such trivial uses.
Note: This jar itself has no functionality, all the method bodies are {}.
You will have to import android.hardware.EpdController
The 1.2 update uses a different EpdController and has a new EpdRegionParams.
This may or may not break code written for previous versions.
The best way to write code to use EpdController is to have it detect if there is no Epd
(i.e. for other devices), the old version or the new version.
Wrap a try/catch around a Class.forName("android.hardware.EpdController").
Wrap a try/catch around a Class.forName("android.hardware.EpdRegionParams").
The new epd.jar in the signature will allow you to compile without using redirection both the old and the new.
For details on the changes, see: http://forum.xda-developers.com/showpost.php?p=35390192&postcount=8
Bump & additional info.
By experimenting and reading documentation for other eInk controllers I've figured out the following:
Controllers support different algorithms for updating the pixels depending on the precision of the gray scale required and the compensation for previous ghosting.
On the Nook, we have the choice of waveform modes:
GC
GU (gray update)
DU (direct update)
A2
GL16
AUTO (auto selection of algorithm)
The screen can be divided up into regions where different algorithms may be used.
Some controllers support 15 regions, ours supports 8.
4 of these regions are earmarked for system usage, specifically:
Toast (popups)
Keyboard (soft keyboard layout)
Dialog (popups)
Overlay
The remaining 4 regions are left for the user.
Note: "HwRegion" is an enum for the complete 8 regions, "Region" is an enum for the 4 user regions.
An example: In my audio recorder I have two regions set aside for the VU bar graphs.
By setting these two regions to DU I get rid of update clutter and the response is quicker.
Currently, the EpdController in the Nook only operates with portrait coordinates.
If you wish to use this while in landscape mode you will have to rotate the coordinates first yourself.
It's sometimes hard to see exactly what/if some EPD setting is doing.
A good way to check it is to set a region for one half the width of whatever active graphic element you are trying to improve.
The difference can be very clear.
Renate NST said:
There seems to be very little actual documentation on the various eInk update modes.
Most of the information seems to have been extracted from working code.
Some of that code does not seem to be optimal in any case.
I'd like to start this thread on a discussion of the update modes.
You can look at all the code posted, but the bottom line is that eInk mode is configured by passing six discrete pieces of information to the EPD driver.
These six pieces may be wrapped up into a single static entity.
Name of entity requesting change (for logging purposes only)
Region, one of enumRegion[] (Region 4-7)
A rectangle, normally {0, 0, 600, 800}
Wave, one of enumWave[] (GC, GU, DU, A2, GL16, AUTO)
Mode, one of enumMode[] (INACTIVE, ACTIVE, ONESHOT, CLEAR, ACTIVE_ALL, ONESHOT_ALL, CLEAR_ALL)
Threshold, an int 1-15, only applies to A2 mode
A2 is the one bit, fast drawing method. It leaves ghosting behind.
In some applications, you would like to enable faster scrolling in A2 mode and then have it revert to "normal" upon completion.
I have an application with a full screen scroll.
After experimenting with the values, these two configs seem to do the job nicely.
Code:
configA2Enter = makeConfig(rpc, waveEnums[WAVE_A2], regionEnums[REGION_6], modeEnums[MODE_ACTIVE_ALL], THRESHOLD);
configA2Exit = makeConfig(rpc, waveEnums[WAVE_AUTO], regionEnums[REGION_6], modeEnums[MODE_ACTIVE_ALL], 0);
No user intervention is necessary, it scrolls quickly and redraws a clean image when done.
(A view.invalidate() is necessary after you invoke configA2Exit)
Does anybody have any further insight into these values or suggestions for improving them?
Click to expand...
Click to collapse
Excellent work! Do you happen to understand/can write up what the various fast mode/no refresh hacks do/how they use these different modes?
I've had X 'running' on my nook but only by triggering a full refresh every few seconds, and wondered how I could be more selective.
My reading of Norefresh was that it was doing something like parsing android log structures for areas that have changed.
Is there an easy way to trigger a refresh of part of the display from userspace, preferably directly on the driver or fb?
As for where the dithering is done, my guesswork is this is done by a blob running on the DSP module within the OMAP (which is perhaps the only interesting use of it I've seen).
Dave
Just done some playing writing directly to the entires in /sys/class/graphics/fb0 ; so for example:
echo -n 100,100,200,200,0,14 > epd_area
echo 2 > epd_refresh
causes the square 100,100->200,200 to be refreshed
the 14 being REGION(8)+CLEAR(4)+ONESHOT(2)
the 0 is wvfid+threshold*65536 I think.
I've put some code that runs under X to trigger updates; here (actually the comment is wrong, it's currently using oneshot+clear);
I never managed to get active to work.
http://forum.xda-developers.com/showthread.php?p=42393733#post42393733
Dave
Hi all, please see the below thread. Only sharing the info as this was posted on the Verizon N4 forum.
http://forum.xda-developers.com/note-4-verizon/general/root-want-to-modify-dpi-t2960644
Hope this helps...
As indicated below some touchwiz native apps are affected.
List of known affected applications by changing DPI settings:
S-View (for S-View covers -- slightly misaligned but functional)
Touchwiz Stock Dialer (slightly misaligned but functional -- other non-stock options exist such as Hangouts or ExDialer)
Fingerprint lockscreen (arrow pointing to finger print scanner off center)
Exchange email (stock Samsung Email)
Stock Camera App
Just FYI to get some easy download links:
http://forum.xda-developers.com/note-4-verizon/general/root-want-to-modify-dpi-t2960644
Enable USB debugging on yer phone
-> http://www.mediafire.com/download/a4hd8y0c1iakysk/Samsung-Usb-Driver-v1.5.49.0.exe
Samsung USB drivers you'll need installed
-> http://forum.xda-developers.com/showthread.php?p=48915118#post48915118
ADB / Fastboot installer
navigate to C:\adb\ and then run the command they give in the thread
adb shell wm density 540
(not confirmation will be sent but your phone should prompt you to 'allow' your computer to send adb commands to it.).
Restart phone
DPI settings are now at 540. original DPI settings are 640 BTW
imnoob55 said:
Hi all, please see the below thread. Only sharing the info as this was posted on the Verizon N4 forum.
http://forum.xda-developers.com/note-4-verizon/general/root-want-to-modify-dpi-t2960644
Hope this helps...
Click to expand...
Click to collapse
I came across that thread a few hours ago. It's pretty neat to be able to drop the density and make more use of display space (could even drop it down to 384 and make it look more like a tablet), but it has its problems. Samsung apps (Dialer, camera, S Note, S-View, etc) will lose their screen alignment and/or only cover a portion of the screen when altering the density. Finding an alternate dialer was easy enough, but I'm having trouble finding a camera app similar to stock in quality, and was unsuccessful at replacing the S-View...
redphazon said:
I came across that thread a few hours ago. It's pretty neat to be able to drop the density and make more use of display space (could even drop it down to 384 and make it look more like a tablet), but it has its problems. Samsung apps (Dialer, camera, S Note, S-View, etc) will lose their screen alignment and/or only cover a portion of the screen when altering the density. Finding an alternate dialer was easy enough, but I'm having trouble finding a camera app similar to stock in quality, and was unsuccessful at replacing the S-View...
Click to expand...
Click to collapse
Yup unfortunately that is a side-effect of doing this. Only way to do it that I am aware of conventionally would be via xposed or loading in custom TW apps, both not possible. Hangout dialer works well, for this. TW stock browser is not affected. My S-Note is not affected either, too. Dialer and S-View are (not unusable, they just are not center-aligned any longer as their height/width are set on static widths rather than proportional % when Samsung set up the layout.) Maybe they'll change that in L.
BTW I use Nova for launcher and Hangouts as my dialer. I do use an s-view case, though, which is of course impacted.
imnoob55 said:
Yup unfortunately that is a side-effect of doing this. Only way to do it that I am aware of conventionally would be via xposed or loading in custom TW apps, both not possible. Hangout dialer works well, for this. TW stock browser is not affected. My S-Note is not affected either, too. Dialer and S-View are (not unusable, they just are not center-aligned any longer as their height/width are set on static widths rather than proportional % when Samsung set up the layout.) Maybe they'll change that in L.
BTW I use Nova for launcher and Hangouts as my dialer. I do use an s-view case, though, which is of course impacted.
Click to expand...
Click to collapse
I'm also using Nova Launcher. I did download ExDialer at first, but I went to Hangouts Dialer instead since ExDialer has a trial period and costs money.
S Note is largely unaffected yes, but when you open the camera for copying documents, the square used for aligning the camera with the document is off-center. It doesn't seem to hurt functionality in any way, though. Oddly enough, the camera when used in S Note is fullscreen...
As far as S-View goes, I'm thinking about removing the flip cover. S-View is nice, but I'm always trying to not get smudges on the cover screen on top of the phone display, so the cover is a little bit cumbersome to me when holding it. Seeing how much better the phone looks at a lower density makes me lean even closer to just getting rid of it. That leaves me with just the camera replacement...
Exchange email is also broken... when you reply to an email, the screen font is set to eleventybillion.
-----
Sent with my Galaxy Note 4
Can anyone confirm if this impacts the play store? Typically changing the dpi on the whole device would prevent the play store from downloading some apps.
Sent from my SAMSUNG-SM-N910A using XDA Free mobile app
jfenton78 said:
Can anyone confirm if this impacts the play store? Typically changing the dpi on the whole device would prevent the play store from downloading some apps.
Sent from my SAMSUNG-SM-N910A using XDA Free mobile app
Click to expand...
Click to collapse
I haven't seen any problems with the Play Store yet, though I haven't been installing much of anything, either. The few apps I've installed so far gave me no trouble.
Also, just found out that the stock camera has no problems with accurate button detection when the phone is turned sideways for landscape rotation, though it's still not fullscreen. You have to guess where the buttons are on the screen in portrait when the density is changed.
Couple of tips:
if you get an error about the device being offline make sure you've got the current ADB installed. The link provided for the adb and fastboot didn't work for me because the file didn't install. The program is just an auto run zip file. you can open with 7-zip and just extract the adb files.
also if you get an error about the device being unauthorized you must select no action on the windows pop up and always perform this action. the phone should then get a pop up with the RSA key number and ask you to authorize. hope this helps.
540 DPI is pretty nice.
I was okay with the dialer and lockscreen, but the camera made me go back to 640. In vertical shooting mode, the touch points for all the icons, including the shutter button, is misaligned and is very annoying. What a shame as 540 looked AWESOME.
cj00ta said:
Exchange email is also broken... when you reply to an email, the screen font is set to eleventybillion.
-----
Sent with my Galaxy Note 4
Click to expand...
Click to collapse
Thanks! Just added to the top thread under impacted apps
Does this effectively change the resolution? I'm curious if lowering the DPI would give positive improvement to high-end game performance. Can anyone shed some light here?
Conkrete said:
Does this effectively change the resolution? I'm curious if lowering the DPI would give positive improvement to high-end game performance. Can anyone shed some light here?
Click to expand...
Click to collapse
It doesn't change the resolution. What it changes is the drawing size of on-screen content which is directly from the 'dpi setting' of the phone.
It's a little complicated to explain but this is how it works;
The phone's default screen density (DPI) setting 640, this is done because that's how many dots per inch of the physical screen there is (a phone of similar screen size would have a similar dpi). This value is stored in your phone's build.prop and is read by numerous applications, it might not match exactly the 'real' dpi of the screen but its normally very close to it.
By changing it lower in dpi you're instructing to applications you actually have a smaller screen size, thus to fit content (i.e words not being HUGE on a small screen) content is drawn to that dpi setting you're providing in build.prop.
Now to go into why we have certain issues when changing the dpi.
This is basically due to how the app did its layout sizing (do I base content on "actual size" of the screen-size or do I base it on "actual density" of the screen density in build.prop? Most apps, since they're targeting to be used with dozens of devices of all sorts of different sizes, will be designed where the layout of content is dependent upon dpi. A layout would be I want a rectangular box on the bottom that has height 10px and width 100%, so that effectively means the width is based on the proportion of the screen size (the OS controls this, its just a matter of scaling). This is why you once had 5 items to show now has 8 items to show in a listbox. The size of the listbox in this case would be based on actual density while the content (text etc.) inside would be based on actual size (scaling I would think is limited to a min/max actual size for text).
Samsung can get away with this on their stock apps because in their mind when they build their roms they are only going to be used on that specific device. They're starting to go away from this, however, and are starting to make their layouts more typical that of a normal application. You have somewhat less control of the layout going from actual size to actual density.
*keep in mind you can actually set parameters for both. Such as if I wanted something to be 10% in width but only up to 2.5 inches in actual size this effectively means that it will scale until it reaches 2.5" and then scale no longer.
I hope that makes sense. Resolution really doesn't have a role at all in this, you're always at the same resolution (4K) and this is handled by the lower-level kernel and GPU firmware. I don't think there's a way to change this at the app layer but than again I have really no background in android development.
*please if anything comes off as inaccurate please point out, I am from a XAML/.NET development background and linux/unix embedded systems and really I focused on back-end/databases/services and not really front-endy stuff. This is how it is handled in XAML though and I have seen android uses the same principals.
imnoob55 said:
It doesn't change the resolution. What it changes is the drawing size of on-screen content which is directly from the 'dpi setting' of the phone.
It's a little complicated to explain but this is how it works;
The phone's default screen density (DPI) setting 640, this is done because that's how many dots per inch of the physical screen there is (a phone of similar screen size would have a similar dpi). This value is stored in your phone's build.prop and is read by numerous applications, it might not match exactly the 'real' dpi of the screen but its normally very close to it.
By changing it lower in dpi you're instructing to applications you actually have a smaller screen size, thus to fit content (i.e words not being HUGE on a small screen) content is drawn to that dpi setting you're providing in build.prop.
Now to go into why we have certain issues when changing the dpi.
This is basically due to how the app did its layout sizing (do I base content on "actual size" of the screen-size or do I base it on "actual density" of the screen density in build.prop? Most apps, since they're targeting to be used with dozens of devices of all sorts of different sizes, will be designed where the layout of content is dependent upon dpi. A layout would be I want a rectangular box on the bottom that has height 10px and width 100%, so that effectively means the width is based on the proportion of the screen size (the OS controls this, its just a matter of scaling). This is why you once had 5 items to show now has 8 items to show in a listbox. The size of the listbox in this case would be based on actual density while the content (text etc.) inside would be based on actual size (scaling I would think is limited to a min/max actual size for text).
Samsung can get away with this on their stock apps because in their mind when they build their roms they are only going to be used on that specific device. They're starting to go away from this, however, and are starting to make their layouts more typical that of a normal application. You have somewhat less control of the layout going from actual size to actual density.
*keep in mind you can actually set parameters for both. Such as if I wanted something to be 10% in width but only up to 2.5 inches in actual size this effectively means that it will scale until it reaches 2.5" and then scale no longer.
I hope that makes sense. Resolution really doesn't have a role at all in this, you're always at the same resolution (4K) and this is handled by the lower-level kernel and GPU firmware. I don't think there's a way to change this at the app layer but than again I have really no background in android development.
*please if anything comes off as inaccurate please point out, I am from a XAML/.NET development background and linux/unix embedded systems and really I focused on back-end/databases/services and not really front-endy stuff. This is how it is handled in XAML though and I have seen android uses the same principals.
Click to expand...
Click to collapse
Extremely helpful and great info. Possibly the best response I've received from XDA. Thank you for the info. I have found a couple root apps that claim to change resolution but I've been hoping to find a non-root alternative.