Thanks Boston, but I'm doing the app in 2D. I would've liked to have done 3D (and probably my prof.) but the added complexity didn't mesh with the time constraints of a college student.
On Mar 9, 12:17 pm, Streets Of Boston <[email protected]> wrote: > I did the same with my app, The Gube, an OpenGL app. > > It took me a while to figure out how to translate swipes of finger > into the rotation of the entire rubik's cube or to have a swipe > initiate the rotation of just one layer. > > If your app is OpenGL (3D) as well, let me know if you need some help > on this (translating onTouch events into motions/gestures in 3D > space). > > On Mar 9, 10:51 am, kbeal10 <[email protected]> wrote: > > > I agree, having more than 2 threads seems to break from the > > traditional paradigm, which is part of the reason it didn't seem like > > a good answer. > > > Since I wouldn't be able to have a ViewGroup in it's own thread, I > > suppose the best solution is to create a SurfaceView that handles > > drawing all of the dice. This is the way I had started, but liked the > > idea of each die being a View in order to handle onTouchEvents. > > Instead, the dice would simply be Drawables. Selecting one would mean > > getting the coords of the onTouchEvent, and determining if that is on > > top of a die. > > > On Mar 9, 4:14 am, Stoyan Damov <[email protected]> wrote: > > > > Ummmm, I don't want to sound insulting in anyway but being a complete > > > newbie in game programming I can *assure* you you're about to do > > > something fundamentally wrong. > > > Your game only needs 2 threads - the UI (main) thread, and a secondary > > > which runs your game loop. > > > If you are a newbie as well, you'll need to read a couple of books, or > > > at least a dozen of articles on game programming before even thinking > > > of creating your own game. > > > > Cheers > > > > On Mon, Mar 9, 2009 at 5:38 AM, kbeal10 <[email protected]> wrote: > > > > > I'm currently designing a game that will be displaying several dice. I > > > > would like to know the wisest course of action. The dice will extend > > > > View (or SurfaceView), so that each will be able to be touched, etc. > > > > My question is should I: > > > > > A.) Spawn one child thread to draw all of the dice (up to 6). I would > > > > do this by writing a class that extends ViewGroup or one of the > > > > Layouts and having it create a new thread. Or... > > > > > B.) should I spawn a new thread for each die? Each die would extend > > > > View, or possibly SurfaceView and have its own thread to perform the > > > > onDraw() (i.e. the LunarLander example). > > > > > Which solution would yield better performance/responsiveness? Would up > > > > to 6 child threads be necessary, or a detriment? > > > > > I'm asking because I understand how I would implement the B.) solution > > > > already. It closely follows the LunarLander example and I have already > > > > implemented another section of the game in the same fashion. Other the > > > > other hand, creating up to 6 child threads seems like it may be a bit > > > > much on resources. However, I am unsure how I would implement a > > > > ViewGroup that does its work in a child thread.- Hide quoted text - > > > - Show quoted text - --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Android Developers" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/android-developers?hl=en -~----------~----~----~----~------~----~------~--~---
