I was actually aiming for 'Funny', but you raise an excellent point - I'd forgotten about private aerospace ventures. Yes, they would be a much more worthy recipient. Not a bad idea, in fact.
Hang on, the parent didn't mean a monoculture in the general phone market, they meant one *within* Apple's phones and tablets. The other manufacturers you describe (well not 100% certain about WP7 and WebOS) have, for starters, varying screen sizes. Their phones have different capabilities, in some cases to the extreme. Look at Blackberry - apart from branding, they are more fragmented than Android has ever been, and they are their own singular hardware vendor! For instance, they arbitrarily changed a function name in one version of their SDK which broke even the possibility of forwards / backwards compatibility between those versions. Their phone keypads differ between models, the touchscreen phones don't like non-touch apps and require much faffing about to disable the horrendous "compatibility mode". There is no monoculture within other major vendors.
The fact that Android runs on a huge variety of devices should not be seen as a problem, as properly designed apps will work across all devices, and the Android Market lets you target specific capability requirements anyway! (Disclaimer: If it's not obvious, I am somewhat pro-Android).
Yes. I wish the iPhone coders would stop putting things like if (iPad) and float x = 320 * some_magic_scalar; in our nice, platform-independent engine:-(
You've clearly never seen J2ME. Android is harder than iOS as you need to design for all screen resolutions, sizes and aspect ratios, and accept that there may not be a standard camera or gallery app, or mail client, and no guarantee of how much memory you have or the speed of the CPU / GPU. This is why people seem to think it's "fragmented". But the same assumptions hold true for web and desktop development too!
You hit the nail on the head with "iOS... for idiots" (if a little harsh). I suspect most, if not all, people who complain about Android fragmentation simply miss the training wheels that iOS gives them. Yes, it gives clear and simple ways of doing almost everything, which can make things really easy - but this makes for lazy code. People who have made the opposite journey (out of the hellhole of what mobile dev used to be) have no problems with Android.
Which basically means you don't know how to write generic apps that work on all screen sizes and aspect ratio and under different memory and CPU constraints, and are quite happy that Apple let you wallow in that.
Finally, someone who knows what they are talking about. Android is not fragmented at all - if you bother to write your app properly, then it will run on all Android devices. Trust me, I know - my company has just finished developing a cross-platform game on iOS and Android. The Android version Just Works on everything from the tiny Xperia "fridge magnet" phones through to the Sensation XE - we used OpenGL ES and JNI and designed it to be scalable from the start. There is *no* platform-specific code in the Android build.
The iPhone version, however, recently had to be backported to iOS 3.1.x, since our iOS team had used the boilerplate OpenGL ES code handily provided by XCode - that doesn't work on anything below iOS 4. (We're also doing a Symbian build, and from what I've heard, that's just been awful for the developers).
Compare this to the clusterfuck that was J2ME - most phones didn't implement the MIDP / CLDC spec properly. Some would fail to load certain PNGs, others would give you white images if you tried to generate them with transparency, some had arbitrary limits on Java class sizes, there were no standard key mappings (especially for softkeys!), some had bugs in their JVM implementations - a total and utter nightmare. Yet we (somehow) coped.
Anyone who says Android is fragmented doesn't know they're born and can get off my lawn.
I agree with doing things natively. I'm leading a small team currently developing a native game for Android and iOS, (written in C++, using the NDK and Java as a thin Android wrapper and Objective-C for the iOS wrapper).
Since our lowest common denominator is OpenGL ES 1.1 (it's a sprite-based game), we've not really had any cross-platform hiccups so far.
However, it's much easier for us than with non-game apps, since we are not using the native widgets.
It's not a typo, it's talking about rotations of a single microcrystal.
The previous article that is referenced records rates of 500 rotations per second - which is 30,000rpm.
I'm not sure which I dislike more.
Blackberry OS is horrible, inconsistent and not forwards- or backwards-compatible. XCode code-signing is a dark art, its SVN integration flaky and I (personally) just don't like Obj-C - at least it allows pure C.
Android is kind of awkward to get into, with their odd resource system and intents, as well as various bugs in their Eclipse integration, but at least has the JNI bridge and is free / open.
I never thought I'd say this, but Flash / Flex / Actionscript 3 actually feels quite nice to get into, from a 2D graphics point of view, with only minor oddities.
If the course will involve teaching 3D graphics programming, I highly recommend you look at RenderMonkey
I've found it to be really useful for prototyping shaders. One of its most useful features is that it allows developers to mark variables as "artist variables", which are then mapped onto sliders / colour-pickers etc. This allows a user to tweak parameters in the shader and view the results immediately, without having to recode it.
Assuming the engine you ultimately decide upon supports loading custom HLSL / GLSL shaders, your students could potentially apply their own shaders to assets in the games they create, allowing them full creative control over things such as lighting and blending.
This is true. I often wish some of the designers and artists I've worked with had more of a grasp of this sort of stuff, especially things like interface programming. Most of the time, just giving them specific information about limitations and preferences of implementing the design on the target platform gets the job done, but it'd be nice if they intuitively knew these kinds of things. With that in mind, my main concern about this course is that the students will walk away with a firm grasp of programming basics, but not how game code directly relates to the work they will be doing - why things like polygon budgets, texture formats matter, for instance, or how the interactions of multiple finite state machines are affected by adding or removing states.
If the course is going to include 3D graphics, I highly recommend looking at RenderMonkey. I've found it very useful for prototyping shaders, and it allows developers to define 'artist variables' that are mapped to sliders, colour-pickers etc., allowing users to change various shader parameters and see the effects instantly without needing to recode. This also helps open up the possibility of allowing your students to add their own shaders to games they create, assuming the engine / framework you eventually choose supports this.
(A) for purposes of commercial advantage or private financial gain;
(B) by the reproduction or distribution, including by electronic means, during any 180-day period, of 1 or more copies or phonorecords of 1 or more copyrighted works, which have a total retail value of more than $1,000; or
(C) by the distribution of a work being prepared for commercial distribution, by making it available on a computer network accessible to members of the public, if such person knew or should have known that the work was intended for commercial distribution.
So as long as I do not gain financially, infringe copies of works woth more than $1000 per 6 months or make my infringing copy available to others, it's not illegal?
For instance, watching videos of copyrighted TV shows on YouTube is legal? (whereas uploading, of course, is not)
As someone who has dabbled with raytracing before, I would have to agree. It's an interesting tech demo of something that's possible, but not really of practical use.
For instance, they showed the chandelier with a million polys - that's all well and good, but it's on the ceiling! If the game was actually being played, the player would never get close enough to see those clever refractions. (And even if they did, the demo shows the frame rate would drop to around 17-20 FPS).
Sure, sell hard copies, merchandise, etc. to profit from your creativity, but you can benefit mankind much more by releasing your art to the public domain.
If they do raytracing in Java, FPS will become the *only* major factor people worry about.
There are already numerous easy-to-use game development environments (such as DarkBASIC), but have these resulted in any games that are great-looking or innovative? Generally, lowering the entry requirements for making games just results in people who lack the required skills, knowledge and experience trying to make games - the results are not usually anything to write home about.
So IE was the more secure browser all along! Why didn't I see this twist coming?! Everyone stop using Firefox NOW! Mozilla are lulling us into a false sense of security!
I agree. In fact, with real-time photorealistic rendering, these slight deviations would probably make frames look more accurate, since real video is full of low-level random noise. The film-grain shader on Left 4 Dead wouldn't be necessary any more.
Slashdot Mirror
...until you've played Strip Call of Duty :D
I was actually aiming for 'Funny', but you raise an excellent point - I'd forgotten about private aerospace ventures. Yes, they would be a much more worthy recipient. Not a bad idea, in fact.
Put a NASA Mars mission on Kickstarter?
Hang on, the parent didn't mean a monoculture in the general phone market, they meant one *within* Apple's phones and tablets. The other manufacturers you describe (well not 100% certain about WP7 and WebOS) have, for starters, varying screen sizes. Their phones have different capabilities, in some cases to the extreme. Look at Blackberry - apart from branding, they are more fragmented than Android has ever been, and they are their own singular hardware vendor! For instance, they arbitrarily changed a function name in one version of their SDK which broke even the possibility of forwards / backwards compatibility between those versions. Their phone keypads differ between models, the touchscreen phones don't like non-touch apps and require much faffing about to disable the horrendous "compatibility mode". There is no monoculture within other major vendors.
The fact that Android runs on a huge variety of devices should not be seen as a problem, as properly designed apps will work across all devices, and the Android Market lets you target specific capability requirements anyway! (Disclaimer: If it's not obvious, I am somewhat pro-Android).
Yes. I wish the iPhone coders would stop putting things like if (iPad) and float x = 320 * some_magic_scalar; in our nice, platform-independent engine :-(
You've clearly never seen J2ME. Android is harder than iOS as you need to design for all screen resolutions, sizes and aspect ratios, and accept that there may not be a standard camera or gallery app, or mail client, and no guarantee of how much memory you have or the speed of the CPU / GPU. This is why people seem to think it's "fragmented". But the same assumptions hold true for web and desktop development too!
You hit the nail on the head with "iOS... for idiots" (if a little harsh). I suspect most, if not all, people who complain about Android fragmentation simply miss the training wheels that iOS gives them. Yes, it gives clear and simple ways of doing almost everything, which can make things really easy - but this makes for lazy code. People who have made the opposite journey (out of the hellhole of what mobile dev used to be) have no problems with Android.
Which basically means you don't know how to write generic apps that work on all screen sizes and aspect ratio and under different memory and CPU constraints, and are quite happy that Apple let you wallow in that.
Finally, someone who knows what they are talking about. Android is not fragmented at all - if you bother to write your app properly, then it will run on all Android devices. Trust me, I know - my company has just finished developing a cross-platform game on iOS and Android. The Android version Just Works on everything from the tiny Xperia "fridge magnet" phones through to the Sensation XE - we used OpenGL ES and JNI and designed it to be scalable from the start. There is *no* platform-specific code in the Android build.
The iPhone version, however, recently had to be backported to iOS 3.1.x, since our iOS team had used the boilerplate OpenGL ES code handily provided by XCode - that doesn't work on anything below iOS 4. (We're also doing a Symbian build, and from what I've heard, that's just been awful for the developers).
Compare this to the clusterfuck that was J2ME - most phones didn't implement the MIDP / CLDC spec properly. Some would fail to load certain PNGs, others would give you white images if you tried to generate them with transparency, some had arbitrary limits on Java class sizes, there were no standard key mappings (especially for softkeys!), some had bugs in their JVM implementations - a total and utter nightmare. Yet we (somehow) coped.
Anyone who says Android is fragmented doesn't know they're born and can get off my lawn.
In case anyone's unaware of what the parent is referring to... http://www.zdnet.com/blog/btl/rest-in-peace-roland-piquepaille/11430
I agree with doing things natively. I'm leading a small team currently developing a native game for Android and iOS, (written in C++, using the NDK and Java as a thin Android wrapper and Objective-C for the iOS wrapper).
Since our lowest common denominator is OpenGL ES 1.1 (it's a sprite-based game), we've not really had any cross-platform hiccups so far.
However, it's much easier for us than with non-game apps, since we are not using the native widgets.
As well as being the largest value storable in a signed 32-bit integer, aka MAX_INT / INT_MAX.
It's not a typo, it's talking about rotations of a single microcrystal.
The previous article that is referenced records rates of 500 rotations per second - which is 30,000rpm.
I'm not sure which I dislike more.
:-)
Blackberry OS is horrible, inconsistent and not forwards- or backwards-compatible. XCode code-signing is a dark art, its SVN integration flaky and I (personally) just don't like Obj-C - at least it allows pure C.
Android is kind of awkward to get into, with their odd resource system and intents, as well as various bugs in their Eclipse integration, but at least has the JNI bridge and is free / open.
I never thought I'd say this, but Flash / Flex / Actionscript 3 actually feels quite nice to get into, from a 2D graphics point of view, with only minor oddities.
Basically, I hate everything
I'm writing this from a crater in the ground below.
If the course will involve teaching 3D graphics programming, I highly recommend you look at RenderMonkey
I've found it to be really useful for prototyping shaders. One of its most useful features is that it allows developers to mark variables as "artist variables", which are then mapped onto sliders / colour-pickers etc. This allows a user to tweak parameters in the shader and view the results immediately, without having to recode it.
Assuming the engine you ultimately decide upon supports loading custom HLSL / GLSL shaders, your students could potentially apply their own shaders to assets in the games they create, allowing them full creative control over things such as lighting and blending.
This is true. I often wish some of the designers and artists I've worked with had more of a grasp of this sort of stuff, especially things like interface programming. Most of the time, just giving them specific information about limitations and preferences of implementing the design on the target platform gets the job done, but it'd be nice if they intuitively knew these kinds of things.
With that in mind, my main concern about this course is that the students will walk away with a firm grasp of programming basics, but not how game code directly relates to the work they will be doing - why things like polygon budgets, texture formats matter, for instance, or how the interactions of multiple finite state machines are affected by adding or removing states.
If the course is going to include 3D graphics, I highly recommend looking at RenderMonkey.
I've found it very useful for prototyping shaders, and it allows developers to define 'artist variables' that are mapped to sliders, colour-pickers etc., allowing users to change various shader parameters and see the effects instantly without needing to recode.
This also helps open up the possibility of allowing your students to add their own shaders to games they create, assuming the engine / framework you eventually choose supports this.
(A) for purposes of commercial advantage or private financial gain;
(B) by the reproduction or distribution, including by electronic means, during any 180-day period, of 1 or more copies or phonorecords of 1 or more copyrighted works, which have a total retail value of more than $1,000; or
(C) by the distribution of a work being prepared for commercial distribution, by making it available on a computer network accessible to members of the public, if such person knew or should have known that the work was intended for commercial distribution.
So as long as I do not gain financially, infringe copies of works woth more than $1000 per 6 months or make my infringing copy available to others, it's not illegal?
For instance, watching videos of copyrighted TV shows on YouTube is legal? (whereas uploading, of course, is not)
As someone who has dabbled with raytracing before, I would have to agree. It's an interesting tech demo of something that's possible, but not really of practical use. For instance, they showed the chandelier with a million polys - that's all well and good, but it's on the ceiling! If the game was actually being played, the player would never get close enough to see those clever refractions. (And even if they did, the demo shows the frame rate would drop to around 17-20 FPS).
A guy at my company made this for touch-screen Android phones a few months back.
Make it free.
Sure, sell hard copies, merchandise, etc. to profit from your creativity, but you can benefit mankind much more by releasing your art to the public domain.
If they do raytracing in Java, FPS will become the *only* major factor people worry about.
There are already numerous easy-to-use game development environments (such as DarkBASIC), but have these resulted in any games that are great-looking or innovative? Generally, lowering the entry requirements for making games just results in people who lack the required skills, knowledge and experience trying to make games - the results are not usually anything to write home about.
I will have to type "I know you're eavesdropping" every few sentences.
http://xkcd.com/525/
So IE was the more secure browser all along! Why didn't I see this twist coming?! Everyone stop using Firefox NOW! Mozilla are lulling us into a false sense of security!
Come back IE, all is forgiven...
I agree. In fact, with real-time photorealistic rendering, these slight deviations would probably make frames look more accurate, since real video is full of low-level random noise.
The film-grain shader on Left 4 Dead wouldn't be necessary any more.