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.
Will all apps have to be updated to take advantage of GPU UI rendering, or will Android be able to render all apps via the GPU natively? I desperately hope every app won't require an update to stop using the CPU to render the app's UI with, but I'm afraid that is probably the case. Anyone know for sure?
Roland Deschain said:
Will all apps have to be updated to take advantage of GPU UI rendering, or will Android be able to render all apps via the GPU natively? I desperately hope every app won't require an update to stop using the CPU to render the app's UI with, but I'm afraid that is probably the case. Anyone know for sure?
Click to expand...
Click to collapse
If you look at honeycomb you have to enable hardware rendering in the manifest. But that was because some things don't work properly. Hopefully they've either fixed it so all hardware rendering works, or added a new manifest option to turn off hw instead of turning it on.
Ok; thanks.
HomerSp said:
If you look at honeycomb you have to enable hardware rendering in the manifest. But that was because some things don't work properly. Hopefully they've either fixed it so all hardware rendering works, or added a new manifest option to turn off hw instead of turning it on.
Click to expand...
Click to collapse
This is true, but just wanted to add a bit from what I understand the reason they put it so you had to manually enable it in your app was because HW acceleration caused slowdows on certain types of 2D drawing, especially lines. So this may not change for ICS. If the HW for 3D stuff is still designed around triangles, then the 2d stuff would still be slow.
Basically I think they wanted people to manually enable it to be aware of how and when to use it. If Android were to move to a 3D interface, then there would be more use for it on UI components.
Anyways this is basically what the Google engineers were telling me at the Developer Labs a couple weeks ago. (This is as far as I understood it, I'm no expert in this area, so I may be getting some bits wrong).
Basically this may not really be a "bug" that will ever get "fixed" so to speak. It may be intentional to not use 3d rending when lower-power, faster, 2d rendering would do.
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.
Unfortunately Niantic contacted me to abort this mod. More info: http://forum.xda-developers.com/showthread.php?p=42027875#post42027875
TL;DR version: I have created an Ingress app mod, it is awesome and will make you coffee. You can download it below.
OVERVIEW
Hi,
after more than a 2 years of inactivity in the modding field I'm back with a new mod. This time it's Ingress app. I think and hope it'll be much greater and more advanced than Google Maps mod. There are a lot of things to improve and I think some of them won't be ever added by Niantic, so it's a good idea to mod this app.
First I want to clarify I will never add any kind of cheating to this mod. My goal is to make Ingress game more enjoyable, not less. Questions about location faking, items cloning, etc. are not welcome here. I'm serious. Still if you think this mod is a bad thing and/or if you're from Niantic then please read a section about my motivations below and feel free to ask, suggest or criticize. I make it for Ingress players and I'm very interested in their opinions.
DOWNLOAD
First: you do this at your own risk! I'm sure it won't brick your phone, but remember you may be banned by Niantic. My mod doesn't do any kind of cheating behavior, it doesn't do anything that original app doesn't do, but there is always the risk.
Also if you downloaded apk from different site then check sha1 of this file to make sure it's ok. Unfortunately such mods create good opportunity to inject some malware, because users search for an application in the internet and anyone can redistribute it. I sign this app with my own keys, so if you have installed my mod earlier, now you have downloaded newer version from the internet and Android says it has different certificates then don't install it!
"Mute" variant has all sounds removed, so apk is ~2.5 times smaller and most likely it uses less memory.
ingress-1.26.1-broot-0.2.0-mute.apk
SHA1: 976342081c963998f8a6e56b735fe97581ab335f
ingress-1.26.1-broot-0.2.0.apk
SHA1: dce5399802c8f11287a7cf399c1bb5265f8251e2
Older versions:
ingress-1.26.0-broot-0.1.0.apk
SHA1: ea95d8e36324c6c4a175e0cf254cd65a4797049f
If you have original Ingress app installed then you have to uninstall it first. Same if you want to install original app over a modded one.
FEATURES / TODO LIST
I know simplifying and automation of too many things may be considered cheating, so I have divided all features into several categories: from the most "innocent" ones to some smart assistants. As I stated above, if you think some of them are just too much then feel free to write about it. For me features up to 3. category are ok. Category 4. may be controversial and I'm not sure if I want to implement it. I'm glad for your opinions. Some features (e.g. 2.11., 3.7.) aren't actually related to category descriptions, but I "feel" them as category 2., 3., etc.
I don't want to force people to use every modification, I'll try to make them all opt-in, so modded app will work exactly as the original one until you change this in the mod menu. If you see e.g. "Fullscreen" feature below then read it as "An option to enable fullscreen mode".
Below is just a list of features to make it clear. Descriptions, notes, statuses, implementation proposals, etc. are here.
Legend:
green - completed
orange - not sure about it
red - rejected
black - waiting / todo
1. Changes strictly technical and/or 4fun - they don't affect gameplay at all:
UI for small screens, but this is never ending task
Disable some graphics effects to make it less GPU consuming:
portal particles
xm particles
Fullscreen.
Remove globe intro.
Change colors of factions.
Exit confirmation dialog - it's good for low memory devices.
Keep sceen on.
Disable vibrator.
2. UI changes: new screens, shortcuts, etc. - it makes things easier, but it won't do anything for you:
New screen with mod settings, credits, etc.
New inventory screen with items presented as a clear table.
Number of all items in the inventory - it's very important because of items limit.
New portal keys screen.
Remove original items screen.
Shortcuts to various actions from the main screen.
Modify chat to make it easier to read and harder to accidentally send private message to public channel.
Link to portals from system messages in the chat.
Real-time distance to portal on details and upgrade screen - its necessity is obvious to anyone who played Ingress
Additional info about the portals directly on the map screen.
Logging and statistics.
Circles around the player similar to one at 40m - just for better feeling of the distance.
Number of keys on portal info, upgrade and linking screens.
Config: update interval.
Config: maximum scanner zoom out.
Deploy button uses highest available resonator, not lowest.
3. Automation of some more complicated or repetitive tasks - it delegates multi-clicking to the squad of highly trained monkeys, but it won't think for you:
Dropping/recycling multiple items of the same type at once.
Firing multiple XMP
Picking up all items in the range - with above it's very easy to give items to other agents.
Hacking all portals in range - not very useful because of timers
Auto deploy resonators using a template.
Templates specific to a portal.
Other agents presence detector.
4. Smart assistants:
Hacking timers for each portal: both 5m and 4h ones.
Auto hacking portals in range while moving (using timers).
Smart auto-deploy.
XMP damage assistant.
Linking assistant for optimum CFs in a specific area.
Continuous linking assistant.
Bugs:
The maps are gray when submitting new portals or reporting bad ones.
NEWS
v1.26.1-broot-0.2.0 has been released!
2013.05.26
Updated Ingress to 1.26.1.
Added layouts for small screens: Eugene's 1.26.0.20130526
Added mute version - for smaller size and likely smaller memory usage.
Added fullscreen mode.
Added option to disable portal particles and xm particles.
Added restart button - it's useful for reloading UI changes (fullscreen mode, layouts, etc.).
Fixed gray maps problem.
v1.26.0-broot-0.1.0 has been released!
2013.05.22
Initial version.
New screen with mod settings, credits, etc.
New inventory screen with items presented as a clear table.
Number of all items in the inventory.
CREDITS
Eugene Kartashov - layouts for small screens.
Of course Niantic Project for this awesome game!
Thanks!
FEATURES DESCRIPTION AND NOTES
1.5. Change colors of factions.
I did this before and it's kind of cool: https://plus.google.com/u/0/106080343103638200670/posts/a9krpWApjz5
2.4. New portal keys screen.
I have some ideas, e.g.:
keys grouping/tagging
group/tag keys manually or automatically by their location, name, etc.
filters and sorting by: name, distance, level, owner, etc.
, but I think Niantic want to improve keys management, so I wait for their move.
2.5. Remove original items screen.
For now even if you prefer new items screen the original one is still needed to access portal keys. We can wait for 2.4. or at least add an option to limit original items screen to portal keys and rename it accordingly.
2.6. Shortcuts to various actions from the main screen.
I think it's one of the most important additions, so it has to be well designed. I see it as a HUD-like buttons similar to "FIRE XMP" when you long-press on a map, but much smaller, probably square with icons. Things to consider:
toolbar at the top or the bottom of the screen - I think it's better than left/right
fixed with 5-6 icons (4" screen) or scrolling horizontally
fixed icons or customize them and their positions
an option to open a full semi-transparent menu with all available actions
Actions could be:
fire last XMP
fire highest/lowest XMP
fire XMP of specific level
same for power cubes
hack portal - click button then click portal. This way you don't have to enter portal details screen which is faster and you don't lose the map.
link portal - same as above
set target? It's in a long-press menu already, but we can add it here for consistency and maybe to remove long-press menu.
actions from other mod additions
2.7. Modify chat to make it easier to read and harder to accidentally send private message to the public channel.
Current problems are:
is there anyone who has never sent a private message to the public channel? Is there anyone who did this only once or twice?
it's hard to read conversations between agents, especially public ones, because they're mixed up with system messages
I was considering adding some kind of filters to select which types of messages you want to see, but it doesn't fix first problem. Now I think of something else - 4 tabs/channels:
faction - as normal
public - public conversation only, so system messages won't disturb you and you don't accidentally respond [secure] messages
system - you can't send a message here
all - all above, so it's similar to current "All", but you can't send a message here - you have to choose proper channel intentionally. It can have additional filters to select messages to show.
This feature may be hard to do or even impossible, because most probably Ingress server doesn't have API to filter messages as above. Of course I can read "All" channel and filter it on the app side, but it may not be that good.
Also I won't be surprised if Niantic itself will redesign chat in the near future, because it's definitely wrong.
2.10. Additional info about the portals directly on the map screen.
E.g.: level, if you have a key (how many?), etc. It could be customizable and there could be a shortcut to toggle showing this info.
2.11. Logging and statistics.
I love this one I can log all kind of actions like: hacking, attacking, dropping and picking up items and XM, deploying resonators and portal mods, adding custom "snapshot points" to organize above, etc. and then create a lot of various statistics:
how many hacks did you do (faction, enemy, neutral) today, in last week or month?
how many items did you get from these hacks?
what were the levels of hacked portals and items?
how many XM did you get?
how did you spend this XM?
how many resonators did you deploy and what were their levels?
how many resonators did you destroy, how many portals did you capture?
how many links and CFs did you create/destroy, what were their MU values?
which portals do you hack/attack/build most often?
how much time you was playing?
what items did you spend to build up a farm and what items did you get from it?
Statistics could be tabular, graph, pie and very flexible. I'm also considering two things:
sending some of above statistics to my server to create global statistics for all users. It would let us do some research, e.g.: what is the probability to get L7 item from L6 portal, etc. Of course sending these statistics would be fully optional, you would have to enable it by yourself.
optional paid application to read these statistics - in addition to the free one. It could let you remove ads or just say "thank you" (i.e. it would be the same as free one), but I don't want to piss off someone in Niantic. I think it would be fair, because statistics app would be quite complicated and time consuming and there will be free version, but you never know what's the opinion of other people.
What do you guys think about above two things?
3.5. Auto deploy resonators using a template.
Agent can configure multiple templates and choose one of them when doing an auto-deploy. Template could be defined by:
its name
minimum and maximum level for each resonator
prefer lower/higher level for each resonator
Examples:
"Lowest portal" - each resonator set to L1-L8 and prefer lower for all - it's the same as clicking "deploy" 8 times.
"Highest portal" - L1-L8 and prefer higher for all
"Highest <L7" - L1-L6, prefer higher for all
"Standard L4" - L1-L6, L1-L4, L1-L5, L1-L4, L1-L6, L1-L4, L1-L5, L1-L4, prefer higher for all - it's standard 4xL4 2xL5 2xL6 and it'll use lower resonators if you don't have all of them
another "Standard L4" - same as above, but L6-L6, L5-L5 and L4-L4 - it won't automatically downgrade resonators, but warn you about the lack of resonators
Also some templates could be predefined by default.
It won't work well with existing resonators, it won't choose optimal way to upgrade them, but this is how it should be - it's just: "do it using a template", not: "Calculate optimal situation".
3.6. Templates specific to a portal.
Extension to above: sometimes you know that e.g. NE resonator of some portal is harder to destroy, so you want to place highest resonator there. You can create a template specific to a portal, so it won't mess up main list of templates and it will be auto selected when doing auto deploy for this portal.
3.7. Other agents presence detector.
It read system messages log to find the last actions and positions of other agents (actually positions of portals they've built/attacked). This information could be used to e.g.:
show last position and action of specific agent
show a list of nearby agents: allied or enemy
alert if some other agent will show up below specific distance from you
4.3. Smart auto-deploy.
E.g.:
calculate max level of a portal that you can build alone - depending on your inventory and already deployed resonators
deploy minimum number and optimum resonators to get to specific portal level
prioritize excess resonators and save scarce ones
deploy high and low resonators evenly to make attacking a little harder
if upgrading existent resonators, prefer to upgrade ones with low XM
4.4. XMP damage assistant.
E.g.:
approximate damage dealt using specific XMP in current position
calculate the best spot to fire XMP of some level
4.5. Linking assistant for optimum CFs in a specific area.
You select a group of nearby portals, assistant build links and guide you through place to get as many CFs and AP as possible.
4.6. Continuous linking assistant.
You see an icon near the portal if it's possible to create a link(s) from it to create a CF. It let you create this CF with few clicks.
It may be not possible to do, because it would have to scan big area to know if there are a link between remote portals.
MOTIVATIONS AND FEW WORDS TO NIANTIC
As I stated above my goal is to make Ingress game better and more enjoyable for people. If you think it's evil then please read my motivations and explanation below:
There aren't and never will be features for cheating: location faking, sending same action several times, automatic passcode submitter, etc.
As I said above I have divided mod features into categories of different "dirtness level". I focus on "clean" features and I'm open to suggestions or criticism from players or even from Niantic itself.
I don't share my code and I obfuscate it to not make Ingress easier to hack by other people.
A whole game and world of Ingress is about hacking and reading between lines. I think my mod fits this world perfectly. There are some people who leak Ingress app from NIA and there is some guy somewhere in the internet who tries to get even more from it. It makes perfect sense
I think there are many good features that will be never added by Niantic. I see several reasons: statistics won't be added because it doesn't make much sense for storyline. Why NIA would add such feature? Intro skipping or new items screen won't be added because these features prioritize quick access over a nice look. Niantic can't do the same because Ingress would look like a game for nerds. But there are many people who don't care about the look because... they're nerds ;-P
And finally: I won't fight Niantic, so if they don't like my mod and decide to react then there will be no mod anymore.
If you're from Niantic then please think what is the best for Ingress users. If you don't like one or two of my features then I'll remove them and keep the valuable ones. If you still think this mod isn't good and it's a matter of time before you react then please do it sooner, not later. Mod won't be very popular yet, Ingress players won't be disappointed so much and I won't lose a lot of my time
FINAL NOTES FOR USERS
Once more: feel free to suggest new features or changes to existent ones. You can also criticize a whole mod idea. I want to know what do you guys think about it.
If you get a force close then post a logcat and mod version here.
If something doesn't look ok then post a screenshot. I have a 320x480 and 480x800 devices, but I can't test it on 240x320 and >480x800 resolutions.
You can also report language faults in the app or even here. English isn't my native and I often write something that doesn't seem natural even to me. I would be happy if someone would suggest better names or descriptions for configuration options, etc.
Of course you can redistribute this mod, but please don't do that if you don't have a good reason. I just want to know how popular it is. Also if you redistribute it then please add a link to this thread to give users a full context.
If you want to make a donation then link is in my signature, but remember that this mod may be killed by Niantic at any time.
[RESERVED]
[RESERVED2]
Very amazing
I'm gonna try it out on a new account just to be safe, but I love the work and holy cow you did a lot and I can't believe it.
Niantic better sit down and learn some must needed features and options. The globe one for sure
Sent from my MI 2 using Tapatalk 2
Keep up outstanding work. I just installed this mod and I confirm that it works flawless.
I'm looking forward to future updates.
iBotPeaches: I did a lot? But you have noticed that above features list is mostly a TODO and for now there are just new items screen and intro skipping? I'm not sure if this is clear from above posts.
I wanted to release it early to get some ideas from people.... or be banned
What about a nosound version? It reduces the app size and removes the annoying sounds for people that are tired of hearing those squeaks
Please find attached a nosound version prototype.
it will be possible to have screen: "exit. are you sure?" when accidentally using back button?
Brut.all said:
iBotPeaches: I did a lot? But you have noticed that above features list is mostly a TODO and for now there are just new items screen and intro skipping? I'm not sure if this is clear from above posts.
I wanted to release it early to get some ideas from people.... or be banned
Click to expand...
Click to collapse
Ahh, I thought you did all that stuff that was bolded in the features list Guess I didn't read it well enough.
Hi, on mine HTC Desire it crash suddnly..
EDIT: Reinstalled, work like a charm..
One thing possibly worth pointing out: I think this version will not handle the new push messages, as I believe those are restricted by the certificate used to sign the app. Are you able to confirm this?
Otherwise, very cool work
phyreskull said:
One thing possibly worth pointing out: I think this version will not handle the new push messages, as I believe those are restricted by the certificate used to sign the app. Are you able to confirm this?
Otherwise, very cool work
Click to expand...
Click to collapse
They do work for me, at least the "@" notifications
Needs further testing.
Jackos said:
What about a nosound version? It reduces the app size and removes the annoying sounds for people that are tired of hearing those squeaks
Click to expand...
Click to collapse
Usually more variants = more problems, but I think mute version may be worth it. It's almost 3 times smaller and space is crucial on many devices. It might also use less RAM and start up faster, because sfx are usually preloaded into memory. I'll do some benchmarks.
ataru said:
it will be possible to have screen: "exit. are you sure?" when accidentally using back button?
Click to expand...
Click to collapse
Sure, but what for? If you accidentally exit application, you can return to it in no time.
phyreskull said:
One thing possibly worth pointing out: I think this version will not handle the new push messages, as I believe those are restricted by the certificate used to sign the app. Are you able to confirm this?
Click to expand...
Click to collapse
I'm not sure about it. I got comm notification today, but I was using Ingress just moments earlier, so it might be background service, not push. We'll see.
Brut.all said:
Usually more variants = more problems, but I think mute version may be worth it. It's almost 3 times smaller and space is crucial on many devices. It might also use less RAM and start up faster, because sfx are usually preloaded into memory. I'll do some benchmarks.
Click to expand...
Click to collapse
Exactly my point of view
However it's a pity that the app uses this same amount of RAM. It might get better if you remove corresponding baksmali lines, I just removed the sound files.
Brut.all said:
Sure, but what for? If you accidentally exit application, you can return to it in no time.
Click to expand...
Click to collapse
I guess it's because on low ram devices the app gets closed instantly. So a back fail-safe button would save him the app loading time.
Impressions and suggestions
Nice mod!
I am an addicted Ingress player and I really appreciate your work!
The new item tab is awesome!!
I only want you to know that there is a G+ user that is modding Ingress too:
Have a look here.
He did a version even for 240x320 screen.
Maybe you can have a look at his work
I hope you can keep this up to date
Works perfectly!
I'll keep an eye on that, your features list sounds extremely promising!
ingress-1.26.1-broot-dev1.apk
It's muted and should work on all screen sizes. Layouts for 240x320 and 320x480 were created by Eugene Kartashov (thanks!), but I have integrated them into single universal apk. It's just ~0.5MB larger than Eugene's separate apks. I can't test it on 240x320 because I don't have such device. Please confirm if it's ok or not. I'll add fullscreen feature before 0.2.0 release, so upgrade button won't overflow on some devices.
Also I can confirm sounds are loaded on demand, they aren't preloaded, so muted version shouldn't boot up faster. It should take less memory though.
Is there anyone who miss these sounds? As I said I would like to avoid fragmentation and I think muted version is just better.
And if you have 240x320 device then please tell me if new items screen looks ok, especially if you have 100+ items of one type. 320x480 seems to be ok.
I'm interested in getting one of the Android PC sticks to use in my kitchen for basic web surfing and email use, as well as a little but of miscellaneous stuff. I'm wondering how much different the experience is, if any, between different makes/models. If this were a traditional PC (Windows, Linux, etc) I would normally run the screen resolution as high as possible, and make what ever other adjustment were available, to minimize on screen elements like title bars, tool bars, browser tabs, etc. They just (sometimes) seem to get in the way, and reduce the amount of area available to show the body of a document, or contents of a web page. So, is there any difference between different Android PC sticks?
Thanks,
Jon
jdnandroid said:
I'm interested in getting one of the Android PC sticks to use in my kitchen for basic web surfing and email use, as well as a little but of miscellaneous stuff. I'm wondering how much different the experience is, if any, between different makes/models. If this were a traditional PC (Windows, Linux, etc) I would normally run the screen resolution as high as possible, and make what ever other adjustment were available, to minimize on screen elements like title bars, tool bars, browser tabs, etc. They just (sometimes) seem to get in the way, and reduce the amount of area available to show the body of a document, or contents of a web page. So, is there any difference between different Android PC sticks?
Thanks,
Jon
Click to expand...
Click to collapse
There are screen adjustments built into the android o/s but differ from manufacturer as to the extent. Basically what you can do is utilize the on device adjustments and then go to the play store for any others you might need. For example there is a (free) app called full screen that may do all you are requiring. Different browsers also have different features you may be looking for. Android can be customized more than windows but with all the options available comes a bit of a learning curve. I recommend diving in, you will not be disappointed!!!
GigaRack said:
There are screen adjustments built into the android o/s but differ from manufacturer as to the extent. Basically what you can do is utilize the on device adjustments and then go to the play store for any others you might need. For example there is a (free) app called full screen that may do all you are requiring. Different browsers also have different features you may be looking for. Android can be customized more than windows but with all the options available comes a bit of a learning curve. I recommend diving in, you will not be disappointed!!!
Click to expand...
Click to collapse
Thanks GigaRack. So it sounds like I don't have to be concerned which stick I get, I will have about the same ability to adjust things with all of them. That makes it a little easier. Now all I have to do is figure out which stick will work best for me .
Jon
For the kind of basic use you describe, I'd say you want a cheap, well-supported rk3066 stick. Resolution is usually hard-coded in the kernel for Android sticks, but the most common rk3066 sticks have custom ROMs (which usually have automatic fullscreen for apps) and kernels (720 and 1080). The mk808 (~$42) is probably a good choice.
Sent from my Nexus 7 using xda app-developers app
ragesoss said:
For the kind of basic use you describe, I'd say you want a cheap, well-supported rk3066 stick. Resolution is usually hard-coded in the kernel for Android sticks, but the most common rk3066 sticks have custom ROMs (which usually have automatic fullscreen for apps) and kernels (720 and 1080). The mk808 (~$42) is probably a good choice.
Sent from my Nexus 7 using xda app-developers app
Click to expand...
Click to collapse
I have been debating on just what approach to take, something like what you mentioned above are go for a 'higher' end device (like the IMITO QX1 (at least I think it's supposed to be somewhat better than average reliability)). My concern is a) wifi, and b) general device reliability. Both of which sound like they can be pretty iffy on some of these sticks. I will need good wifi since this will be on my kitchen counter and there is no way I'm running an ethernet cable there .
I do want a well supported stick also, with good custom rom support (I rooted and put custom roms on my old Droid Incredible before, so I'm at least familiar with the basic idea). I understand it can be better to stick with Rockchip processor's rather than Allwinner as far as having lot's of custom roms available, is this true?
Thanks,
Jon