C++ and OpenGL on Windows Phone
category: code [glöplog]
You are always an angry man. :)
I give you that. Sucks. I wish Google would/could do something about, Android being open source and all.
Apples' leash is very very tight, converted stinking hippies that are now yuppies. The worst.
In 3 years apps will all be HTML5 browser-based shit anyway...
Quote:
Another major problem Android has is that every clown phone vendor can take some version, rape it with their own skinning shit and then release it to the public without owing Google any responsibility in terms of update mechanisms or, very important, strict usability QA (such as console games have been doing for the past 20 years). Because obviously second parties aren't really keen at doing their own QA.
I give you that. Sucks. I wish Google would/could do something about, Android being open source and all.
Apples' leash is very very tight, converted stinking hippies that are now yuppies. The worst.
In 3 years apps will all be HTML5 browser-based shit anyway...
@superplek: I could write a thousand word essay about this. but let's just say:
true. I truly do not like GCs, btw.
true. but:
times change. from my experience modern mobile CPUs are very well capable of handling VMs/scripting languages.
but FFS: keep it simple, use it as glue code, place time-critical stuff in native code and pleeez don't try to reinvent the OS in that VM/language.
(i.e. no layer cakes, s’il vous plaît)
Quote:
Maybe I don't want every fucking clueless nitwit writing an app. and rather have the stuff that really matters run a bit faster and use less memory.
true. I truly do not like GCs, btw.
Quote:
Bringing a VM or interpreted language to a mobile platform is one of the dumbest idea I've ever seen.
true. but:
times change. from my experience modern mobile CPUs are very well capable of handling VMs/scripting languages.
but FFS: keep it simple, use it as glue code, place time-critical stuff in native code and pleeez don't try to reinvent the OS in that VM/language.
(i.e. no layer cakes, s’il vous plaît)
Quote:
In 3 years apps will all be HTML5 browser-based shit anyway...
Good one -- I hope so!
xyz: Shows you have good sense about it and that's probably exactly what intention behind it is -- it's just that many don't. And now they're all able to rape our phones with subpar apps, and apparently even relatively major phone apps are developed by idiots or at the very least "unsupervised journeymen". Sorry to say, but that's all I can make of it given circumstantial evidence.
-_-
I don't think that they are "idiots".
It's just that they are given that 'platform of choice' without understanding the greater implications.
I don't think that they are "idiots".
It's just that they are given that 'platform of choice' without understanding the greater implications.
Quote:
In 3 years apps will all be HTML5 browser-based shit anyway...
In 3 years time many of the apps we run now will be HTML5 browser based shit, but we'll be too busy running the awesome new apps of the 3-year-distant future to care about that. We've been promised that it'll be all browser based for years, and this is always the way it goes.
Quote:
It's just that they are given that 'platform of choice' without understanding the greater implications.
One could argue that major app. developers have adequate funding to hire programmers who *do* understand what they're working with. It's clear that some do, most don't.
yep, not many have debugged a GC alloc' network in their life-time. welcome to hell. it's worth funding.
On the high-level language + first time coders thing.. careful what you wish for. Would you rather they wrote shitty apps in a high level language with GC or a low level language where they'll neglect to free memory after using it?
Speaking of which, anyone used apple's ARC stuff in anger? I'm tempted to try it, but I have some pretty nasty retain/release cases that really throw the static analyser and would really fuck things up if handled badly.
Speaking of which, anyone used apple's ARC stuff in anger? I'm tempted to try it, but I have some pretty nasty retain/release cases that really throw the static analyser and would really fuck things up if handled badly.
Quote:
Would you rather they wrote shitty apps in a high level language with GC or a low level language where they'll neglect to free memory after using it?
I hear this a lot. The answer is simple: I'd rather they'd a) learn what the fuck their doing, be it in school or wherever because it's not *that* hard or b) not be hired by CTOs/tech. directors.
Programming is becoming a pussy profession this way because it's being squashed by loads of fucktwats incapable of telling how to spell their last name. And of course mobile shit is an excellent magnifying glass since as said before, there actually *are* limitations that will trip bad shit up all the time.
I'm not sure where you've worked before but I can't recall even journeymen or absolute beginners being hired if they weren't wise to the concept of memory allocation.
But maybe that's sheer luxury nowadays.
But maybe that's sheer luxury nowadays.
heh! a real pouet amongst our mids. cheers, my friend!
plek: i've not worked in a big coding team. But that's not really relevant here, because you don't need to get hired to publish on the app stores. You need just enough knowledge to write something that works for a couple of minutes while it goes through the app store QA - and not even that for android market.
And I am actually speaking from experience there - I published my first app while learning obj-c. I did have a few years of coding in other languages then though and I had learned the basics at that point.
I've seen other people do the same thing with near zero knowledge of the basics though, no previous coding experience and no clue as to how the release retain system works. They'll copy + paste code with only half an idea of what it does, then find out they can delete parts and it still works - therefore there's no need for that bit of code. It's amazing how far you can get with a youtube tutorial or two and some google skill :(
And I am actually speaking from experience there - I published my first app while learning obj-c. I did have a few years of coding in other languages then though and I had learned the basics at that point.
I've seen other people do the same thing with near zero knowledge of the basics though, no previous coding experience and no clue as to how the release retain system works. They'll copy + paste code with only half an idea of what it does, then find out they can delete parts and it still works - therefore there's no need for that bit of code. It's amazing how far you can get with a youtube tutorial or two and some google skill :(
Yeah and where I'd expect that kind of shit from random apps. I would hope that major news sites and even Facebook would shell out a few bucks for better apps. That's all I was saying.
I think they tend to just want a basic app that does what the website does - or at least the basics. So they get people who can do a basic app. Then, later, they realise that some small crew built a really kick-ass app that does more than theirs, and does it better. So they buy them.
1. Steal dwarf's pants
2. Build decent Facebook app
3. Sell pants to Facebook
4. Profit
1. Steal dwarf's pants
2. Build decent Facebook app
3. Sell pants to Facebook
4. Profit
That still does not explain why by now the mobile Android/iOS FB apps are fucking horse shit with a Yeti-like memory footprint. I hear it's a bit better on iOS, but thats of course the obvious difference between roughly the same quality of ideas implemented natively vs. running on a layer of shit called a Java VM.
@raer
About a year ago I was making a simple test-app that had about 4 additions and 6 multiplications of floats on every touch event. I first made in Java, as I thought it would take me less time compared to deploying NDK and all that. But then I quite surprisingly found out that it's running way too slow on my lower-bound-test 200Mhz phone. Maybe I'm just don't know Java and its techniques to work with simple floating point numbers good enough, but when I copy-pasted exactly the same code into native, it ran considerably faster -- that means not taking any time at all for these 10 float ops -- even though there was all that JNI glue.
I was like, wtf.
Well, compared to Symbian, yes, they are quite good. But it all breaks when you get to do some native code (due to speed issues mentioned above, and reusability of existing huge codebase), and then you find yourself writing custom shell scripts and code in vim. Documentation too has some huge holes in it -- there's nothing for input methods, for example, so for implementing a custom EditText widget you're stuck with browsing poorly-commented sources.
While this is in general may be a good thing, I am very afraid that this will make us more dependent on a stable internet connection. Maybe I'm getting old or live in a country where LTE is available only in the centers of major cities, but I really hate all this cloud-web shit that makes me personally more dependent on internet connection for stuff, that doesn't have even slightest reason to be online. Fuck you, future.
@xyz
Yes, they are, when you're talking about tossing text or widgets around. But when you have some numbers to crunch, you're fucked. This makes you push all these heavy tasks to Cloud™, if you can, and bringing my nightmare closer. As for the stuff you can't offload (graphics, for example), you stuck with 2-3 times less performance (numbers aren't random, but based on latest JS engines vs native code benchmarks, so this is the best case you could hope for). And then there's stuff like this.
Quote:
… but Java and the VM is not to blame. I'm not a Java-fanboy AT ALL, but with a JIT it is actually quite fast.
About a year ago I was making a simple test-app that had about 4 additions and 6 multiplications of floats on every touch event. I first made in Java, as I thought it would take me less time compared to deploying NDK and all that. But then I quite surprisingly found out that it's running way too slow on my lower-bound-test 200Mhz phone. Maybe I'm just don't know Java and its techniques to work with simple floating point numbers good enough, but when I copy-pasted exactly the same code into native, it ran considerably faster -- that means not taking any time at all for these 10 float ops -- even though there was all that JNI glue.
I was like, wtf.
Quote:
The SDK and the toolchain is good, the documentation is too. What's there not to like?
Well, compared to Symbian, yes, they are quite good. But it all breaks when you get to do some native code (due to speed issues mentioned above, and reusability of existing huge codebase), and then you find yourself writing custom shell scripts and code in vim. Documentation too has some huge holes in it -- there's nothing for input methods, for example, so for implementing a custom EditText widget you're stuck with browsing poorly-commented sources.
Quote:
In 3 years apps will all be HTML5 browser-based shit anyway…
While this is in general may be a good thing, I am very afraid that this will make us more dependent on a stable internet connection. Maybe I'm getting old or live in a country where LTE is available only in the centers of major cities, but I really hate all this cloud-web shit that makes me personally more dependent on internet connection for stuff, that doesn't have even slightest reason to be online. Fuck you, future.
@xyz
Quote:
times change. from my experience modern mobile CPUs are very well capable of handling VMs/scripting languages.
Yes, they are, when you're talking about tossing text or widgets around. But when you have some numbers to crunch, you're fucked. This makes you push all these heavy tasks to Cloud™, if you can, and bringing my nightmare closer. As for the stuff you can't offload (graphics, for example), you stuck with 2-3 times less performance (numbers aren't random, but based on latest JS engines vs native code benchmarks, so this is the best case you could hope for). And then there's stuff like this.
One more funny thing -- it is totally possible to make purely offline stuff that is generally considered to be heavy and online-only.
For example, the company I work for makes an offline maps+localsearch application both for PCs and several mobile platforms. The mobile application itself takes about 15MiB of compiled and stripped code (mostly due to it not being size-optimized at all; this is another thing that makes users of old android phones unhappy -- they had very little storage for apps, another thing that is retarded in Android) and requires separate bases for each city. A base for city with 1.5m population and area of 500km^2 with all map geometry and info about _all_ local businesses (tens of thousands) and POIs including ATMs and kiosks takes about 55MiB uncompressed. The application is capable of presenting an interactive (down to softrendered 5-10fps on old ~200Mhz Symbian phone) 3D-map, performing search for businesses with different criteria, and even completely offline routing for public transport and car almost in realtime (most difficult routes took me no more than 15 seconds on slowest phones). Memory footprint -- about 35MiB tops.
Cloud™ my ass.
For example, the company I work for makes an offline maps+localsearch application both for PCs and several mobile platforms. The mobile application itself takes about 15MiB of compiled and stripped code (mostly due to it not being size-optimized at all; this is another thing that makes users of old android phones unhappy -- they had very little storage for apps, another thing that is retarded in Android) and requires separate bases for each city. A base for city with 1.5m population and area of 500km^2 with all map geometry and info about _all_ local businesses (tens of thousands) and POIs including ATMs and kiosks takes about 55MiB uncompressed. The application is capable of presenting an interactive (down to softrendered 5-10fps on old ~200Mhz Symbian phone) 3D-map, performing search for businesses with different criteria, and even completely offline routing for public transport and car almost in realtime (most difficult routes took me no more than 15 seconds on slowest phones). Memory footprint -- about 35MiB tops.
Cloud™ my ass.
w23, people want that data online because roads, points of interests, restaurants, etc move. it's got nothing to do with a device's storage capacity.
well, and google does it online because they're google and can't think offline.
Ideally, you'd get both (everything local, but updates sent periodically).
well, and google does it online because they're google and can't think offline.
Ideally, you'd get both (everything local, but updates sent periodically).
btw, plek, i don't at all understand why you crap all over Java (which makes sense, btw) but then say that a move to HTML5 would be great. Do you actually prefer JavaScript to Java? Sounds like five steps backwards to me.
I quite like how waze works - everything online, but it caches stuff. Seems to work fine so long as you've got internet at the start of the route or you've done the journey before. (I have an off-line GPS app as a backup that has the full maps for the UK - haven't needed it yet).
I think the whole web apps thing comes down to this: the browser is always going to be slower than native code. That means a native app is always going to run better, and there's always going to be more overhead to take it to the next level. Therefore the native version is always going to be better than the web app, and that's not going to change unless we can run native code in the browser.
I think the whole web apps thing comes down to this: the browser is always going to be slower than native code. That means a native app is always going to run better, and there's always going to be more overhead to take it to the next level. Therefore the native version is always going to be better than the web app, and that's not going to change unless we can run native code in the browser.
psonice, you (and others in this thread) are taking a very demoscene approach here.
most phone users don't even know that their app could be faster. they get an app for its functionality, not for whether a list of whatever the app manages loads in 1 second on 0.7.
i think you're all overrating speed.
most phone users don't even know that their app could be faster. they get an app for its functionality, not for whether a list of whatever the app manages loads in 1 second on 0.7.
i think you're all overrating speed.
I guess we're aware of it and understand it, but I think most people appreciate a phone that works smoothly and has a long-lasting battery. And they notice when one app looks fantastic and works perfectly, and another regularly crashes and lags all over the place.
@skrebbel
Database updates is more of a business question rather than technical. Existing solution is to release updates every month and force user to update every three. App is fully capable of doing it by itself via internet if available, but you can also get a datafile by other means and just upload it to a phone through whatever you prefer.
As for 0.7 vs 1.0 -- try to force any active iOS user to use pretty much any Android phone for a while. Ofcourse, this is only indirectly related to actual application number-crunching speed, but what user will notice is the lack of overall smoothness of UI. Some months ago I've read somewhere that Android developers were to address this problem, and that they had to switch to native code for all the fancy animation interpolations to be able to accomplish it. Can't recall the source, sorry.
@psonice
Does waze allow user to pre-upload selected regions? Does it cache POI data? Does it perform search in cache?
<rant>
Honestly, this online dependency becomes a huge problem even nowadays already. Every single time I go abroad, for example, whereinternet via roaming costs me like 20$/100kb. And then there is no known alternative to what I'm used to at home, except totally unusable Google (due to onlineness), and some Belarussian app that allows to download vector OSM data (and not retarded raster tiles taking huge terabytes) for entire countries, but lacks POI data.</rant>
sorry, i seem to be somewhat angry today.
Database updates is more of a business question rather than technical. Existing solution is to release updates every month and force user to update every three. App is fully capable of doing it by itself via internet if available, but you can also get a datafile by other means and just upload it to a phone through whatever you prefer.
As for 0.7 vs 1.0 -- try to force any active iOS user to use pretty much any Android phone for a while. Ofcourse, this is only indirectly related to actual application number-crunching speed, but what user will notice is the lack of overall smoothness of UI. Some months ago I've read somewhere that Android developers were to address this problem, and that they had to switch to native code for all the fancy animation interpolations to be able to accomplish it. Can't recall the source, sorry.
@psonice
Does waze allow user to pre-upload selected regions? Does it cache POI data? Does it perform search in cache?
<rant>
Honestly, this online dependency becomes a huge problem even nowadays already. Every single time I go abroad, for example, whereinternet via roaming costs me like 20$/100kb. And then there is no known alternative to what I'm used to at home, except totally unusable Google (due to onlineness), and some Belarussian app that allows to download vector OSM data (and not retarded raster tiles taking huge terabytes) for entire countries, but lacks POI data.</rant>
sorry, i seem to be somewhat angry today.
w23: not sure on the internals of waze, but today my data plan expired (finally - it was supposed to expire in November so I got 4 months free :D). When I arrived at work it failed to re-route (the postcode for the office points at the rear entrance for some reason, so when I turn in to the front entrance it tries to re-route). Not sure if that's because I was "off the road" or because it couldn't connect to the cloud to reroute though. It was still showing cached traffic + incident data though, so I'm guessing it caches those and POIs.
Either way, I wouldn't use that and not have a decent off-line solution as a backup. I actually find waze *better* than co-pilot (which cost a fair bit of money) for regular use, despite it being free + cloud based, but it's never going to be as reliable.
On the android UI smoothness thing: From what I vaguely remember, the UI was all software rendered before android 3.0 (maybe it was 4.0, but I think it was 3). Redrawing a complex UI and animating it on a slow mobile CPU is obviously going to hurt speed (and battery as a result) - that's probably why lots of android owners are exited about getting a quad core phone :)
Android 3 was a tablet OS though (more fuckedupness - OS 1 + 2 for phones, 3 for tablets, 4 for both) so no phones use it. OS 4 is still new and only just starting to appear on devices.
Either way, I wouldn't use that and not have a decent off-line solution as a backup. I actually find waze *better* than co-pilot (which cost a fair bit of money) for regular use, despite it being free + cloud based, but it's never going to be as reliable.
On the android UI smoothness thing: From what I vaguely remember, the UI was all software rendered before android 3.0 (maybe it was 4.0, but I think it was 3). Redrawing a complex UI and animating it on a slow mobile CPU is obviously going to hurt speed (and battery as a result) - that's probably why lots of android owners are exited about getting a quad core phone :)
Android 3 was a tablet OS though (more fuckedupness - OS 1 + 2 for phones, 3 for tablets, 4 for both) so no phones use it. OS 4 is still new and only just starting to appear on devices.
Quote:
In 3 years apps will all be HTML5 browser-based shit anyway…
My hope is that in 2 years browsers will actually SUPPORT HTML5 and WebGL on mobile devices properly and have fast JS support. Also the abstraction layers/libraries like PhoneGap/MoSync will have improved significantly. And those apps don't NEED to be online only. Local storage, things like PhoneGap/MoSync etc. will make more things possible.
Fuck online dependency and the cloud btw. Clouds from my ass, seriously. I can see the point for some applications/services, but the whole thing is totally overhyped and people will realize that in the next years...
Quote:
I was like, wtf.
So. 200MHz. Really?! I'm not saying a JIT is the solution and a VM can give you the speed of native code, but they're getting closer and it will become more irrelevant in the future.
I can understand your point though: For a performance-critical application; Having to code a math library in native code plus making the glue code is more work, slower and more error prone than writing it all in native code. But then again Android runs on different ARMs and now x86 too...
Also I haven't really done anything fancy with the NDK, so I can't tell if it's really that crappy.
I liked the Meego concept, because it had a linux base, native C++ code and I'm developing with Qt, so that all seemed pretty nice, but it died prettly quickly (sadly, after 1 Phone, which I've actually tried and it's not too bad if you're interested).
Quote:
That is pretty subjective imo. I think my phone's working quite smooth (1GHz single core) and I can't see much of a differency when I use an iPhone3/4...try to force any active iOS user to use pretty much any Android phone for a while
Plus what plek said about the UI modification crap some companies are doing to distinguish their phones from others. Google should really do something there...
...we all probably could go on for hours... ;)