Home | Code | Gallery | Articles | AMVs | Studio Bebop | iManga | Find Me Food!
Wednesday, March 21, 2012 01:02 AM
Ever since I started developing the iManga Reader app back in 2009, I've had the chance to read a lot of different manga. So, listed below in no particular order are five manga that I recommend you check out.
|
Yotsuba&!
My Thoughts Series Description Yotsuba&! received an Excellence Award for Manga at the 2006 Japan Media Arts Festival. In 2008 Yotsuba&! was nominated for the 12th Osamu Tezuka Culture Award and the Eisner Award "Best Publication for Kids" category, but did not win either, and was runner-up for the first annual Manga Taisho award. Status |
|
Full Metal Panic! Sigma
My Thoughts Series Description However, Sousuke and Kaname's lives are about to change when they meet Leonard Testarossa, a high ranking member of a mysterious group named Amalgam. After their meeting, Leonard warns her that he would do anything to recruit her even if it means war in the streets of Tokyo. Status |
|
Beck
My Thoughts Series Description Status |
|
Ibitsu
My Thoughts That being said, I loved Ibitsu. Remina Kanbe (pictured to the left) sets the standard for what it means to be yandere, and makes Yuno from Mirai Nikki seem reasonable and well adjusted. Because it's so short, Ibitsu's story wastes no time getting things started, and presses forward at a rapid pace that only intensifies as it progresses. It's a great story, and will have you thinking twice about telling people whether or not you have a sister by the time you've finished with it. Series Description Status |
|
Bio-Meat: Nectar
My Thoughts There are two things that I really enjoy about Bio-Meat. The first, is that the inevitable loss of control of the BM monsters isn't some unexplained world-wide all hope is lost apocalypse like a zombie outbreak always seems to be. Instead, the outbreak is portrayed as more of a war with the BM, where the balance of power on both sides shifts back and forth as the plot progresses. The other thing I really enjoyed about this manga, is that its story spans a lot of time with the same characters. There are three major story arcs, which are each separated by about 5 to 10 years, and it's nice to read an end-of-the world manga where you get to see how things progress (and fall apart) as time marches forward. Series Description Status |
Wednesday, March 14, 2012 09:11 PM
I started developing mobile apps back in early 2009 after a friend suggested I try it out. Well I jumped in head first with no idea what I was doing, and it wasn't until August later that year that I finally had my first app approved and out onto the Apple App Store, getting my first real taste of app development success. Ever since then, I've made app development my career, have seen a lot of success, and have loved every minute of it.
A lot has changed since those early days. Smartphones are everywhere these days, and while that's great news for app developers, it seems like it's starting to become more and more difficult for indie developers to be able to get a foothold in the app world and actually make money. For this reason, I decided to write this article in an effort to help my fellow developers and entrepreneurs have a better understanding of what they need to do to make their apps successful and profitable.
[ The Two Most Important Factors to Consider ]
Alright, so you have a killer idea for a killer app that will make millions of dollars! Something that nobody has ever seen before, and something that is sure to set you up with a nice retirement spot on a beach somewhere warm and sunny. Or maybe not? Maybe your app is something a little more simple. Something that would be great for you and your friends, but has the potential to make money with others as well. Whatever the case may be, when it comes to making money on apps, there are two very important things that you need to consider before starting development.
As dramatic as this may sound (and setting aside dumb luck), your answers to these questions could very well make or break the success of your app, and your company.
[ Choosing the Right Platform for Your Project ]
The only options that you should really even consider for this question is either Android (Google) or iOS (Apple), since they are the ones that dominate the smartphone market. Their creators also happen to provide the most robust third party developer tools, which means that you'll be able to do a lot more with your apps with a lot less work.
Some of you might be thinking, "Wait, what about other platforms like Blackberry or Windows Phone? There are lots of people who still use those!" While this might technically be true, it still doesn't make them serious competitors with Apple and Google. Their market share is nothing compared to Android and iOS who control 78% of the market, and who will continue to expand their control as time presses forward. So unless you feel there is a very important reason that your app should support one of the lesser platforms, your choice of what to develop for should only be between Android and iOS.
Here is where the great divide begins to manifest itself. Everybody seems to have their own idea about which platform is the "best". Truth be told, at least from a purely technical standpoint, both Android and iOS are solid platforms to develop apps on. However, when it comes to making money selling apps, they are miles apart.
I can confidently say that based on my own personal experience, if you are developing an app for distribution to the general public with the intent of making money, and you aren't a major corporation like ESPN or EA Games, you should develop your app for iOS before you ever consider porting it to Android. There are several reasons that lead me to this conclusion, both programming and business related, but the bottom line is simply this. As an independent developer, you will make more money with an app developed for iOS than you will with an app developed for Android. Now, allow me to explain further.
Android users do not buy apps.
It's a harsh thing to say, but unfortunately it's the truth. I believe that the root of the problem stems from the fact that apps are intangible goods, and as such their perceived value is entirely dependent on the conditions of the market that they're sold in.
For example, Google loves to brag about how Android is an open source mobile OS, and how they have such open market standards for app development. In fact all you need to do to publish an app to the Android Marketplace (or Google Play as it's called now), is pay a $25 developer license fee, and then upload your app. That's it.
While this approach might sound great in theory, it has led to a major influx of poorly designed apps that do little more than saturate the market, making it harder for quality apps to be noticed. Moreover because there is no mandatory review process for app submissions, and Java developers are a dime a dozen, lots of companies have chosen to develop quick one-off apps filled with ads that they release for free. The idea being that since there are so many Android users on so many different devices, that the sheer volume of usage will generate enough ad revenue to make their apps profitable.
The problem with this is that because so many companies have taken this approach, the Android app market has become flooded with so many free apps that do the same thing, that it's created an end-user mentality of, "Why would I buy your app when there are six others that do the same thing for free?" Even if your paid app is far and away the greatest app ever for what it does, 99% of the time it's going to lose to its free competitors.
Apple on the other hand, requires that every new app submission and update be subject to a mandatory review process in order to ensure that the app in question adheres to all human interface guidelines and development standards set out for their platform. This helps to stem the flow of one-off freebie apps, which in turn helps to level the playing field for people selling paid apps.
For further reading on the subject of why Android apps make less money than their iOS counterparts, take a look at the article Android Users Like Apps, But Don't Like Paying For Them
How about some statistics?
I have an app called Find Me Food! that I've released for both iOS and Android. The Android version of Find Me Food! has had a grand total of 14 sales between the dates of February 8 2012 and March 14 2012 (a little over one month). Whereas the iOS version has sold 61 units between the dates of March 5 2012 and March 11 2012 (one week). Or in other words, the iOS version of my app makes nearly five times as much money in a single week as the Android version makes in an entire month.


Marketing your apps, the App Store vs Android Marketplace (now Google Play)
When it comes to making money with apps, I've found that the first 90% of the work comes from developing the app, and the other 100% of it is in the marketing. A large part of your product's success will hinge on the the distribution platform you choose for it. For iOS you have the Apple App Store, and for Android you have the Android Marketplace (now called Google Play). I personally feel that the App Store is the better choice of the two, at least from a marketing standpoint, for two reasons.
With the App Store, you can generate promo codes for any of your apps that people can use once to download them for free. This is useful when submitting your app to review websites, as well as for special app giveaways and the like. Google Play however does not have this feature. If you want to give someone a free copy of your app, you actually have to provide them with a copy of your app binary. I don't know about you, but I'd much rather just give someone a one-time use promo code, instead of a full copy of my app that they could freely distribute to anybody they like without me ever knowing.
With Google Play, if you ever decide to make your app free, it's stuck like that forever. Which means that you won't ever be able to quickly bolster your paid app's popularity and user base by making it free for a weekend.
iOS offers uniform hardware standards.
One of the major reasons that Android has been able to come to control nearly 50% of the smartphone market, is because it is an open mobile OS designed to be able to run on just about any hardware. Which makes it possible for handset manufacturers to be able to put out cheap smartphones. However, this open attribute of Android's is a double edged sword.
Because Android isn't designed to run on specific hardware, it loses a lot of finer performance optimizations that iOS has. It also forces developers to choose between either designing their apps to support the majority of handsets by tailoring their performance to the slowest device, or designing their apps to only work with specific handsets. Depending on the kind of app you are developing this may or may not be that big of an issue for you. However as you start to develop more resource intensive applications such as games, or augmented reality apps, it starts to become a real concern.
On the other hand, developers making apps for iOS (for the most part) don't have to worry about this issue since Apple designs their mobile OS specifically to their own hardware (iPhone, iPod Touch, and iPad). This guarantees your apps the least amount of operating overhead between the OS and hardware, and the knowledge that all of your users are using the same hardware with only minor deviations in performance capabilities.
One example of how this advantage can have a major effect on your app, is if the app does a lot of mathematical calculations, such as real time video data processing for augmented reality. If you were developing your app for iOS, then you would know for certain that any supported Apple device that would be running your app (read: anything newer than an iPhone 3G), would have a Cortex A8 (or better) CPU. Which would mean, that you could implement a video processing algorithm that uses ARM NEON intrinsic functions to process eight pixels of a video frame at a time, instead of just one.
However, developing this same app for Android would require that you implement an additional non-intrinsic (and much slower) video processing algorithm for those devices that don't have Cortex A8 CPUs. In addition, because you have no way of knowing what the processing power is of the devices your users will be running your app on, its performance could vary greatly from device to device.
More iOS users are running the same, and often the latest, firmware.
Every time Apple or Google releases an update to their mobile OS, there are lots of awesome new APIs and other things added which help developers make even better apps. The only drawback to this is that these updates are only useful if people are actually using them. That being said, most iOS users on average are running the latest and greatest version, or are only one or two minor releases behind. Unlike Android, who the majority of its users are still running very old revisions of the OS.


The Bottom Line
There is nothing wrong with developing an app for Android. Despite the flaws and issues discussed above, it's still a solid mobile platform. That being said, I would highly recommend that you develop your app for iOS first, before you ever consider porting it to Android. You will make a lot more money doing so.
[ Choosing the Right Monetization Strategy ]
There are a few different ways that you can make money selling apps. It's important that you choose one or more strategies that play to the individual strengths of your app, so that you can squeeze as much revenue out of it as possible. Below are some different monetization strategies you could employ, as well as my thoughts and experiences using them.
Direct Paid App Sales
The tried and true method of selling your apps for a fee. It's straightforward and simple, and if you've got a high quality app, it's the way to go (usually).
Ad Supported Free App
With this strategy, you release your app for free, but fill it with ads. The idea is that because your app is free, it will get a lot of downloads (which is usually the case), and that all of those users seeing ads will generate a ton of ad revenue. While this may sound like a great approach in theory, in reality it's a fool's bet.
Ad revenue is a joke. Unless you've created the next Angry Birds or the very first Flashlight App, your ad revenue isn't going to be nearly enough to constitute a reasonable return on your investment. To illustrate this point, let's take a look at some statistics from my app iManga Reader Lite, which uses the Freemium App Sales strategy (outlined below).

Freemium + Paid App Sales
A freemium app is a fully featured paid app that you release for free with certain features disabled, and ads placed throughout the user interface. The idea behind it being that lots of people will download it because it's free, and then they can opt to remove the ads and/or enable the advanced features of the app by making one or more in-app purchases.
This is a strategy which really shines when you release a fully featured paid version of an app, and a freemium version of it as well. Some examples of this include my own apps iManga Reader Pro and iManga Reader Lite, as well as other apps like Words With Friends and Words With Friends Free, or Angry Birds and Angry Birds Free.
A huge benefit to employing a paid and freemium app monetization strategy, is that it effectively doubles your app store presence (and potentially your overall revenue) instantly. Moreover, word of mouth marketing for your app will also flourish due to the fact that people can (and will) download your freemium app for well... free. It's important to understand though, that the majority of your actual sales will come from people buying the paid version of your app, while the freemium version will serve more as a way of drawing in potential customers.
For example, the iManga Reader Lite usually sees between 125 to 200 downloads a day, and between 3 and 7 in-app purchase "upgrades" to the full version. Where as the iManga Reader Pro sees between 10 and 20 downloads a day.
Supplemental In-App Purchases
Another great way to pad out your monthly app revenue, is through ancillary in-app purchases. These would be things that users could purchase to enhance their app experience, such as power ups, new characters, additional content, etc. The ideal supplemental in-app purchase item is something that is consumable, i.e. something that users can buy, use up, and then (hopefully) buy again.
[ And That's a Wrap ]
Well I hope this article was helpful to you. If you have anymore questions, or would like to talk to me about developing an app, feel free to contact me at brandon.smith@studiobebop.net
Happy coding!
Tuesday, March 06, 2012 09:29 PM
Just bought this today, suuuuper stoked to play it. I will say this though, I am not very happy that EA has chosen to hold my game hostage until I install their Steam rip-off, and register an account with them.
At least they aren't making me install Gamespy or Banzai Buddy :/
IP hostage negotiations aside, it's time to go save the universe, and make this happen.
Sunday, March 04, 2012 08:57 AM
It's been quite the eventful few months since last I made a "real" blog post. Except, most of those events have just been me being hard at work making apps, writing some sweet h4x, marketing apps, watching some anime, improving apps, yelling at apps, and playing video games.
Studio Bebop has started to really take off, and is seeing more and more success each month. These last few months have been a major learning experience for me, not just in programming, but for business in general. One lesson that's been repeatedly bashed into my head ever since I got home, is that when you are a self-employed app developer, 90% of your job is programming, and 100% of it is marketing.
The app market has EXPLODED these last two years, and since I decided that my old methods of product advertising (READ: using all the spambots I wrote as a freelancer) aren't exactly the most effective/ethical options anymore, I've had to start from square one! Well it's been a long (and sometimes expensive) process, but I feel like I've finally started to get a grip on how to market apps semi-reasonably well. I'm planning on writing an article about this very subject in the near future, so I'll abstain from going into detail here. However, I will say that one really good idea to get your app to stand out, is to put together a promo video. I knew that one day all of that time spent making AMVs would one day come in handy!
On the pr0 h4x side of things, I completely rewrote my heuristic brute force password cracker Gentle-Brute. For those of you wondering what the heck "heuristic brute force password cracking" is, it's essentially a method of brute force cracking wherein the algorithm skips attempts for potential passwords like 'aaaaaa', 'asdf7777772dn', etc. Which in turn leads to a shorter number of potential password permutations to try before finding the correct one, thereby (potentially) drastically reducing the amount of time necessary to crack a password using brute force. This is accomplished by only generating potential passwords that adhere to the rules of English-like words and phrases. I just recently found out that 2600: The Hacker Quarterly is going to publish the article I wrote on this very subject, so once that happens, I'll link to a proper explanation about HBF. (It's super cool I promise.)
Rewriting Gentle-Brute was a lot of fun. It gave me a chance to try my hand at a few things I'd never done before. Like creating my very own super awesome Rubygem. Or using Curses to fulfill a secret lifelong dream of making my own super-hacker looking hash cracker. It's beautiful ;_;
Moving on in the world of h4x, I recently put together a neat little article discussing how to use intrinsic functions on iOS devices with Cortex A8 (and later) CPUs to perform super fast BGRA to Grayscale conversions on CVPixelBuffer frame data. Or as I like to put it, how to use ASM black magic to process eight pixels at a time of a video frame. You should read it, I think it's fascinating.
My brother and I went to Ikkicon over the new years weekend. The con itself was pretty mid-tier, but I got a lot of great ideas for ways to market apps, and I had a great time with my brother and some other friends in Austin. I had to make some adjustments since I last wore it, but I busted out my Emillio cosplay both nights for some good old fashioned self-esteem building. After a bit of coaxing, my brother decided he'd cosplay Castiel from Supernatural, and he looked marvelous.
While we were there, I made the acquisition of some super awesome (and tax-deductible because they are for market research) figures, and a moe moe keychain. Gaze upon their glory!
Finally, to wrap things up, here are the highlights of the anime I've been watching and my thoughts on it.
I finished watching School Rumble, it was magnificent. I had mentioned earlier that the dub was pretty good (which it is), but following the admonition of my friend Preston, I switched to the sub and it was glorious! I love School Rumble, and you should too.
I watched Puella Magi Madoka Magica or (just Madoka if you're not super lame), and it was awesome. So awesome in fact, that I had this 16x20 poster made to adorn my wall with its greatness. The show is basically Cardcaptor Sakura, but with a darker more adult-focused plot full of twists, a la Evangelion. (Maybe that's why there's going to be a Rebuild movie?)
The music is done by one of my favorite anime musicians, Yuki Kajiura. (Noir, Tsubasa Chronicle, .hack//SIGN) The animation was done by SHAFT, and it's not only gorgeous, but also incredibly stylized. Watch Madoka now.
Speaking of super stylized and beautiful animation, I recently finished watching Katanagatari. I really really really liked it. It's one of the most unique anime I've ever watched both in terms of visual presentation, and story. What's even better, is that while Katanagatari may be super unique, it's not a case of all flash and no substance. (Unlike say Dead Leaves for instance.) A word of warning, do not watch the dub, or I will find you and hurt you.
Also, CHEERIO!
^^^ Kinda sorta spoilers FYI ^^^
Sunday, February 26, 2012 08:29 AM
==========
For a practical example of this algorithm, you can check out my app See It - Video Magnifier.
==========
I thought I would share a little tidbit of iOS development trickery that I finally got worked out today.
I'm working on an app at the moment that takes in a live video feed from a device's back-facing camera, and does some filtering to each frame before displaying it on the device's screen for the user. One of the filtering options my app does, is converting the video feed from color, to grayscale.
Before I go any farther, I'm going to assume that you are familiar with AVCaptureSession, and setting up everything to access a device camera, and display a live preview feed. If not, take a look at Apple's RosyWriter example, and the AVCamDemo example from the WWDC 2010 example code.
The method I was using at first to accomplish this, was to iterate through each pixel in a frame, calculate that pixel's weighted average of Red, Green, and Blue values, and then apply that weighted average to the red, green, and blue channels of the pixel.
Like so,
- (void)processPixelBuffer: (CVImageBufferRef)pixelBuffer
int BYTES_PER_PIXEL = 4;
int bufferWidth = CVPixelBufferGetWidth(pixelBuffer);
int bufferHeight = CVPixelBufferGetHeight(pixelBuffer);
unsigned char *pixels = (unsigned char *)CVPixelBufferGetBaseAddress(pixelBuffer);
for (int i = 0; i < (bufferWidth * bufferHeight); i++) {
// Calculate the combined grayscale weight of the RGB channels
int weight = (pixel[0] * 0.11) + (pixel[1] * 0.59) + (pixel[2] * 0.3);
// Apply the grayscale weight to each of the colorchannels
pixels[0] = weight; // Blue
pixels[1] = weight; // Green
pixels[2] = weight; // Red
pixels += BYTES_PER_PIXEL;
}
}
This above snippet of code will take a BGRA format CVImageBufferRef, and convert it to grayscale. Unfortunately for us, it's not very fast. Using the AVCaptureSessionPresetMedium video input setting, I was getting ~7fps on my 4th generation iPod Touch. (Which isn't necessarily bad, but could be better.)
So whilst Googling about for a method to increase my BGRA to Grayscale conversion algorithm's speed, I came across two articles discussing RGB to Grayscale conversion using ARM NEON intrinsic functions. Specifically,
ARM NEON intrinsic functions is not only a mouthful to say, but is also some sort of serious low-level coding black magic available to devices with ARM Cortex A8 (and later) CPUs, that allows you to be able to perform multiple computations at once. I couldn't explain the theory of it all to you to save my life, so I won't even bother tyring. Suffice it to say that using intrinsic functions will allow us to be able to process eight pixels at a time, as opposed to just one.
Those interested in learning more about the nitty gritty of ARM NEON, should take a look at "Introduction to NEON on iPhone" over on Wandering Coder.
So this article explains how to perform a BGRA to Grayscale conversion on an AVCaptureSession video feed, but it doesn't do it very well. So allow me to help fill in the gaps.
First, prepare your project to use NEON intrinsics by adding '-mfpu=neon ' to your project's "Other C flags", and setting your project's compiler to "LLVM GCC 4.2" (Which you should be using already, since all the cool kids use Automatic Reference Counting these days.)
Next, make sure you add this line to your video processing class' header file, otherwise you're going to get all sorts of frustrating compile errors.
#import "arm_neon.h"
Finally, implement the intrinsic BGRA to grayscale method outlined in this article. (Show below.)
void neon_convert (uint8_t * __restrict dest, uint8_t * __restrict src, int numPixels)
{
int i;
uint8x8_t rfac = vdup_n_u8 (77);
uint8x8_t gfac = vdup_n_u8 (151);
uint8x8_t bfac = vdup_n_u8 (28);
int n = numPixels / 8;
// Convert per eight pixels
for (i=0; i < n; ++i)
{
uint16x8_t temp;
uint8x8x4_t rgb = vld4_u8 (src);
uint8x8_t result;
temp = vmull_u8 (rgb.val[0], bfac);
temp = vmlal_u8 (temp,rgb.val[1], gfac);
temp = vmlal_u8 (temp,rgb.val[2], rfac);
result = vshrn_n_u16 (temp, 8);
vst1_u8 (dest, result);
src += 8*4;
dest += 8;
}
}
This last step however, is the trickiest of all! Because unfortunately that article doesn't really tell you how to use this function, and it also leaves out one very important tidbit of information you're going to need. That being, the result that the BGRA to grayscale method actually creates.
You see, you pass the method a CVPixelBuffer of image data (An array of pixels wherein each pixel has four values representing levels of Blue, Green, Red, and Alpha), along with an empty memory buffer. What the method then does, is fill that buffer with the grayscale value for each pixel in the CVPixelBuffer, which by itself is totally useless.
So in order to actually make your video feed appear grayscale, you have to not only run each preview frame through your intrinsic method, but then apply the created grayscale values to each pixel in your preview frame.
So enough talk, here's all the code you're going to need to make it all happen!
void neon_convert (uint8_t * __restrict dest, uint8_t * __restrict src, int numPixels)
{
int i;
uint8x8_t rfac = vdup_n_u8 (77);
uint8x8_t gfac = vdup_n_u8 (151);
uint8x8_t bfac = vdup_n_u8 (28);
int n = numPixels / 8;
// Convert per eight pixels
for (i=0; i < n; ++i)
{
uint16x8_t temp;
uint8x8x4_t rgb = vld4_u8 (src);
uint8x8_t result;
temp = vmull_u8 (rgb.val[0], bfac);
temp = vmlal_u8 (temp,rgb.val[1], gfac);
temp = vmlal_u8 (temp,rgb.val[2], rfac);
result = vshrn_n_u16 (temp, 8);
vst1_u8 (dest, result);
src += 8*4;
dest += 8;
}
}
// Method that processes a CVPixelBuffer representation of a preview frame
- (void)processPixelBuffer: (CVImageBufferRef)pixelBuffer
{
// lock the pixel buffer into place in memory
CVPixelBufferLockBaseAddress( pixelBuffer, 0 );
// Get the dimensions of the preview frame
int bufferWidth = CVPixelBufferGetWidth(pixelBuffer);
int bufferHeight = CVPixelBufferGetHeight(pixelBuffer);
// Turn the CVPixelBuffer into something the intrinsic function can process
uint8_t *pixel = CVPixelBufferGetBaseAddress(pixelBuffer);
// Allocate some memory for the grayscale values that the intrinsic function will create
uint8_t * baseAddressGray = (uint8_t *) malloc(bufferWidth*bufferHeight);
// Convert BGRA values to grayscale values
neon_convert(baseAddressGray, pixel, bufferWidth*bufferHeight);
// Iterate through each pixel in the preview frame, and apply the weighted value of that pixel's RGB color channels
for (int i = 0; i < (bufferWidth * bufferHeight); i++) {
pixel[0] = baseAddressGray[i];
pixel[1] = baseAddressGray[i];
pixel[2] = baseAddressGray[i];
pixel += BYTES_PER_PIXEL;
}
// Release the grayscale values buffer
free(baseAddressGray);
// Unlock the pixel buffer, we're done processing it
CVPixelBufferUnlockBaseAddress( pixelBuffer, 0 );
}
And that's it! Using this method, I'm able to get ~25fps on the same preview frame that I was getting ~7fps using my original method.
[ Kick it up a notch, with inline assembly! ]
While the performance boost you get from using intrinsic functions is pretty great, you can get even more performance out of your app by using an inline ASM BGRA to Grayscale conversion method! Which is exactly what this article talks about doing, but again, the author doesn't explain how to do it (and there's a bug in his code that makes it unusable).
Luckily for you, myself (and a kind anon), have worked out the kinks, and everything works super smooth now.
All you need to do, is add this method to your existing code,
static void neon_asm_convert(uint8_t * __restrict dest, uint8_t * __restrict src, int numPixels)
{
__asm__ volatile("lsr %2, %2, #3 \n"
"# build the three constants: \n"
"mov r4, #28 \n" // Blue channel multiplier
"mov r5, #151 \n" // Green channel multiplier
"mov r6, #77 \n" // Red channel multiplier
"vdup.8 d4, r4 \n"
"vdup.8 d5, r5 \n"
"vdup.8 d6, r6 \n"
"0: \n"
"# load 8 pixels: \n"
"vld4.8 {d0-d3}, [%1]! \n"
"# do the weight average: \n"
"vmull.u8 q7, d0, d4 \n"
"vmlal.u8 q7, d1, d5 \n"
"vmlal.u8 q7, d2, d6 \n"
"# shift and store: \n"
"vshrn.u16 d7, q7, #8 \n" // Divide q3 by 256 and store in the d7
"vst1.8 {d7}, [%0]! \n"
"subs %2, %2, #1 \n" // Decrement iteration count
"bne 0b \n" // Repeat unil iteration count is not zero
:
: "r"(dest), "r"(src), "r"(numPixels)
: "r4", "r5", "r6"
);
}
And replace
neon_convert(baseAddressGray, pixel, bufferWidth*bufferHeight);
with
neon_asm_convert(baseAddressGray, pixel, bufferWidth*bufferHeight);
and you're done!
[ Here's some benchmarks ]
==========
For a practical example of this algorithm, you can check out my app See It - Video Magnifier.
==========
Sunday, December 11, 2011 12:46 AM
"iManga Reader is an unbeatable bargain. Where else will you find almost seven thousand titles available for your reading pleasure on both the iPhone and iPad? How about for less than the cost of a Starbucks latte? If you're a fan, this is a must-have, barre none."
-- Luke Patrick of The iPhone App Review
Read the full review of the new and improved iManga Reader on The iPhone App Review
Sunday, November 20, 2011 07:03 PM
I have lots of things to talk about, I've been busy this last month!
I got my new computer put together (specs here), and it is awesome. Newegg didn't process my order for some reason the first time around, so I had to wait an extra week and reorder. I decided to splurge and add another 8gb of RAM (for just $50!), now I'm rolling with 16gb of RAM on this machine, and it feels just great. I'm still totally blown away at how far tech has come, and how low prices have become, since I built my last PC in 2005. I remember the ballin' ASUS motherboard I put in my first PC supported a maximum of 4gb of RAM, and now my new PC does that in just one stick! I love it!
Needless to say, my new command center is way legit. I've uploaded some pictures of it to my Photobucket, check it out!
Since I have such a manly computer right now, I figured I might as well capitalize on that, and play some games with all their bells and whistles cranked up to maximum. Unfortunately for me, I've forgotten what my Steam password is. What's worse, I don't know what the answer is to my secret question! Oh well. So I created a new Steam account, and now I only have one game.
At the behest of a few of my friends, I decided to purchase a copy of Batman: Arkham Asylum, and then proceeded to play the crap out of that game. Arkham Asylum is a fantastic game, and I loved every second of it. There's just something magical about lurking in the shadows, picking off the Joker's henchmen one by one, and watching in glee as they start to freak out as their numbers dwindle. Definitely good times.
Once I have some more disposable income, I plan on buying a copy of Skyrim, as well as a copy of Amnesia: The Dark Descent. I'm looking forward to playing Amesia, apparently it is supposed to make me crap my pants in absolute terror, which definitely sounds like my idea of a good time on a Thursday afternoon.
Also at some point I need to pick up a Wii Motion Plus Wiimote, and a copy of Skyward Sword.
According to IGN, it is the greatest Zelda game of all time, which is definitely a big claim, but I hope it's true. I love Ocarina of Time, and if this game surpasses it, it's a total win-win for me. Also one to one motion control sword fighting sounds just wonderful.
On the anime front, I've seen/am watching a lot of new things, and in the spirit of brevity, I'll just give you the highlights a la bullet point.
I've been doing lots of neat programming things too. The great majority of my time has been dedicated to revamping my existing iOS apps, and working on some new ones as well. I won't say anything about the super cool top secret new apps I'm working on right now, since they're still in a pre-release state, but suffice it to say they're going to rock your world.
A major accomplishment for Studio Bebop, that I can talk about, is what has recently happened with the iManga Reader series. Over the last two days, Apple has approved a major update to the free version, and finally approved the pro version for sale again!
I'm very excited about these releases, not only because they're my primary bread winners right now, but also because I really am proud of the improvements and additions I've made. Along with a bunch of miscellaneous bug-fixes and performance tweaks, I've revamped a lot of the UI code to be a lot more 'iOS like', and have added full support for sharing your favorite manga series via Facebook or Twitter. (The recently added native Twitter API for iOS 5 is gloriously simple by the way, and I'm in love with it.)
The feature I'm most proud of though, is the addition of automatic reading statistic tracking for a user using MyAnimeList. For those of you who don't know, MyAnimeList is a website that allows people to keep a detailed log of all the anime and manga that they have watched or read, as well as the stuff they're watching or reading at the moment. It's kinda like if Facebook swallowed Wikipedia, and crapped out a database driven spreadsheet. It's surprisingly fun once you get into it, you can see my profile here.
So in the latest release of the iManga Reader, a user can now just enter their MyAnimeList username and password in the app settings, and the app will automatically track what they're reading and update their MyAnimeList for them every time they start a new series, or finish reading a chapter!
Glorious iManga updates aside, I've also added a new project to the code page. In short, it's a Python application that allows you to automate creating user accounts for any phpBB forum. It also has full support for CAPTCHA cracking via Decaptcher.com.
Thursday, October 27, 2011 04:39 AM
It's been a good day.
I started working on updating/revamping the iManga Reader, using the new Xcode 4 and iOS 5 SDK, and had a great time doing it. There's a bit of a learning curve going from Xcode 3 to Xcode 4, but so far I'm very impressed. It has a very unique UI for an IDE, it looks and feels a lot like iTunes and Komodo Edit had a baby. Also, it's definitely geared a lot more towards iOS development, and has in-app Git tracking support. I'm pretty smitten to be honest with you.
I came across a very useful tool for OSX today. It's called SpeedLimit, and what it does is allows you to simulate different network speeds on your machine for a given port and/or host name. Which is great if you're trying to get a feel for how your iOS app will function when a user is on a slow network connection. Check it out.
While we're on the subject of super useful resources to aid in iOS development, I also found a great website called Glyphish that has lots of free images you can use for all of your UITabBarButtonItem icon needs.
Lastly, as I mentioned earlier, almost all of my old computer hardware is toast and I need a new rig. Well I ordered the parts for a new one today, and it should all be here this weekend! For anyone interested, here are the specs:
I'll post pictures of the new command center once everything gets here and built.
Wednesday, October 26, 2011 06:25 AM
Howdy folks, I'm back.
It's been a long time since I last posted on Teh-1337 (just a bit over two years to be exact), but I'm back and making blog posts once again! For those unaware, I've spent the last two years serving as a missionary for The Church of Jesus Christ of Latter Day Saints (the Mormons) in the Colorado Denver South Mission. It's been a wild and crazy two years full of adventures and awesome stories. I'm still sorting through all of the pictures and videos I took, two years is a long time after all, but I'm planning on doing a multi-part writeup on the adventures of my mission that should be pretty awesome.
Some of you may or may not have noticed, but things look just a little bit different on Teh-1337 than they did before. The reason for this is because I cooked up an awesome new blog engine! (The source code of which you can check out over on my Github.) The new engine is pretty spiffy, and I'm pretty proud of it. It's all still in Python, I was planning on doing it in Ruby with some awesome Sinatra h4x, but that wasn't working out right on my host. One of the spiffy new features of this blog engine is that it actually uses databases now, talk about sophisticated amirite?
So many things have changed over the last two years, it's awesome! So awesome in fact, that I feel the need to make a list.
Honestly there isn't too much else for me to talk about right now. Things have been pretty quiet since I got back. I've been spending my time getting back into living a normal life, figuring out what hardware I can salvage from my old rigs, slowly getting back into the swing of things with Studio Bebop, visiting with family, and catching up on all the anime, TV shows, and movies I've missed these last two years.
More legit blog posts will come soon, I promise!
Sunday, July 12, 2009 01:33 AM
This was probably the most intense four minutes and thirty seven seconds of my life.
Search Teh-1337
Copyright © Brandon Smith