Slowing things down and breaking other apps is a great way to reduce the
market and success of your app. Don't create unnecessary hurdles for
yourself. Do it right. Spend the effort to improve your app.
--
James Cameron
http://quozl.linux.org.au/
___
2010/1/27 shivaprasad javali :
> Hi All,
> We are developing an Activity for the XO. During development we ran
> into an issue with the default screen depth on the XO. Our application
> assumes that the screen depth is 32 and does all the draw math. But as the
> screen depth on the XO is 16
Now I could not find the code I have used but here is the latest version
of the game I started developing for the XO-1. (The development stalled
because the xv bug in the Geode driver.)
https://docs.google.com/leaf?id=0B6XMYp250cOmZDhmOWNjMTQtMjNlNy00NDc0LTlhMmItNGI3M2NhMGFmNmVm&hl=en
The tric
We are allocating a 32 bit buffer and then using the X server calls to blit
it to the 16 bit screen. Even this is slowing down the application as the
draw in the application is very intensive. We commented out parts of our
draw code to find out the part which was slowing it down and found that the
Since you can only blit pictures on an X server and cannot get a direct
pointer to the video memory, I do not know what your problem is. You can
just allocate a 32 bit offscreen buffer in the address space of your
application and blit it via the X server to the 16 bit video memory
(draw). The X
Hi All,
We are developing an Activity for the XO. During development we ran
into an issue with the default screen depth on the XO. Our application
assumes that the screen depth is 32 and does all the draw math. But as the
screen depth on the XO is 16 we had to do constant 32 bit- 16 bit
con
