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 wrote:
> I did the same with my app, The Gube, an OpenGL app.
>
> It too
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
o
On Mon, Mar 9, 2009 at 4:51 PM, kbeal10 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 solutio
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
U, 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'l
Views (except SurfaceView's surface) can NOT be used from background
threads. Besides, it would not help at all.
On Sun, Mar 8, 2009 at 8:38 PM, kbeal10 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 wi
6 matches
Mail list logo