Contest FAQ (last updated 8/16)

Started by
3 comments, last by cbenoi1 19 years, 8 months ago

Background

Who is Qualcomm, and what do they have to do with gaming and graphics? Qualcomm is a world leader in wireless technology. They are the primary developers of CDMA, which is the underlying technology used in many cell phone networks around the world, particularly in Asia, and by Verizon and Sprint in the US. Recognizing the growth of 3D gaming on mobile platforms, Qualcomm has made a commitment to providing cutting edge 3D graphics technology by developing internal solutions as well partnering with industry leaders. They have also created a game developer program to directly support developers making games for phones using Qualcomm chipsets. What is the purpose of this contest? Qualcomm has two primary objectives in sponsoring this contest:
  1. Getting developers interested in developing for BREW and for Qualcomm platforms, in particular 3D games and other applications using OpenGL ES.
  2. Acquiring 3D content to use for demos and testing. Entries may be shown at tradeshows, analyst meetings, and other venues to highlight the graphics and other capabilities of Qualcomm platforms.

BREW SDK

Where can I get the BREW SDK? The BREW SDK can be downloaded from the BREW website. You have to register first, but registration is free. I'm having problems downloading the BREW SDK The BREW website uses an ActiveX component that requires IE 5.5 or higher. There is currently no way around this. Which version of the BREW SDK should I use? Use version 3.0. You'll also have to download and install the OpenGL ES extension. Is the BREW SDK available for platforms other than Windows? Unfortunately, no. The BREW SDK currently only runs on Windows 2000 or higher. If you don't have access to one of these operating systems, you'll be unable to participate in the contest. There is nothing GameDev.net can do about this. Which device skin should I use? For now, use the Blackcap16 skin. We'll be uploading a skin that is closer to the target platform in a few days.

Target Platform

What phones will these games and demos be used on? Qualcomm does not produce phones. They produce chipsets that are used in millions of phones by dozens of handset manufacturers, including LG, Samsung, Sanyo, Nokia, Kyocera, and others. The entries for this contest will not initially be run on commercial phones, but rather demo phones, known as FFAs, intended as reference devices. These FFAs will include QVGA displays capable of 16-bit color, some hardware support for 3D, and use ARM 9 processors with no native floating point support. Will I be required to port my entry to the demo phone? No. Qualcomm engineers will be porting entries after the contest ends. What kind of controls are available on the target platform? In addition to the keys available on typical cell phones, the demo FFAs will include a joystick and several shoulder buttons. These are not currently exposed through the BREW SDK. It's recommended that you use the standard buttons as best as possible. When the entry is ported to the FFA, Qualcomm engineers will map controls to these new buttons and joystick as appropriate.

Legal

Do I have to provide source code with my entry? Yes. You need to include everything we'll need to build the entry, since we'll be porting it to other platforms. Who owns my entry? We'll be providing a more complete document as soon as we can providing the details of this. The gist of it is that by submitting an entry, you're granting Qualcomm the right to use your entry and everything associated with it in any way they see fit. They may use it for demonstration purposes, they may use it for testing, they may provide it to OEMs, and they may even provide it to other developers as sample code. However, you will retain ownership of it as well, so you will also be able to use it in any way you like.

Misc

Can we participate in all 3 categories? You can enter as many categories as you like, and can submit more than one entry per category. However, you are more likely to win if you focus on quality over quantity. What's the difference between a game and an interactive demo? An interactive demo can be controlled in some ways by the user (moving the camera, modifying parameters, etc.), but does not contain key elements present in a game, such as a score, victory conditions, opponent(s), etc. Are team entries allowed? Yes, although the prizes will be awarded per entry, not per individual. Can I use third party libraries? The use of third party libraries will make it very difficult to port your entry to an actual cellphone. It's recommended that you limit yourself to using BREW interfaces and the C standard library included with BREW. What criteria will be used for judging? Given the purpose for which entries will be used, visual quality and polish will weigh heavily in the judging. The use of non-graphical components of BREW (e.g. audio) will be beneficial as well.
Advertisement
Quote:
It's recommended that you limit yourself to using BREW interfaces and the C standard library included with BREW.


So using STLport, Direct3d and winsock is not recommended, but not actually against the rules?

Just asking... :-)

Alan
"There will come a time when you believe everything is finished. That will be the beginning." -Louis L'Amour
If we can't easily port an entry to a phone, it'll be useless to us, so your odds of winning will be negligible.
Quote:Original post by Myopic Rhino
If we can't easily port an entry to a phone, it'll be useless to us, so your odds of winning will be negligible.


As you can imagine I was only joking, but this does raise a concern. I've been writing BREW apps for a while now so I know the agony that is getting stuff to work on real hardware, especially an entire application that was only ever developed on an emulator. It seems a bit arbitary to say "If we can't easily port an entry", how much effort is going to be put into it? If someone used std::string, will you go through and replace it with a less memory trashing alternative?

I hope Im not sounding too negative, but I dont really want (me or anyone else) to spend a two months writing an entry, only for someone to say "I spent a hour, but could get this to work on hardware. Disqualified". I appreciate that the point of the contest is to get actual working code, but most people who enter are probably going to be writing BREW code for the first time.

So to clarify, the rules say that it must trarget hardware or the emulator. But you are saying that unless it can easily be made to run on hardware you can't win?

Alan
"There will come a time when you believe everything is finished. That will be the beginning." -Louis L'Amour
We'll make every effort to port every entry to work on target, especially those that are particularly promising in the emulator. We actually have several engineers who will be working on this full time once the contest ends.

There will be programs that won't run on target intially simply due to differences between the emulator and a real phone. We're prepared to spend a lot of time on those programs getting them to work, and if we can't, we'll still consider them for the contest.

There may be programs (though I hope not) that can't reasonably be expected to work on target without significantly rewriting the program. The two main factors that would cause this are (1) using far too much memory (which is why we're including conservative memory guidelines), or (2) using 3rd party libraries.

Basically, if you follow the posted guidelines there's very little chance that your entry will be disqualified. The farther you stray from those guidelines, the greater chance you have of being disqualified.

There's a big difference between a program not working on target because of differences between it and the emulator, and a program not working because it wasn't designed from the beginning to work on an actual phone. We're willing to spend a lot of time on the former, and even if we can't get it to work, we'll still include it in the competition. The latter will pretty much require us to rewrite the apps, which isn't a reasonable expectation. The

This topic is closed to new replies.

Advertisement