Messages

16

Off Topic / Re: So, OUYA. Will YA?

« on: 2013-Jul-25 »

Sorry chaps - I've been so busy with work/life and Sony stuff that I've not had the time to devote to this.  I will continue and post a release as soon as I find a few spare minutes.

Spacefractal - sorry to hear about your phone!  Hope you don't put the OUYA in the washing machine

//Andy

17

Off Topic / Re: So, OUYA. Will YA?

« on: 2013-Jul-25 »

Hey FIVE: https://dl.dropboxusercontent.com/u/32204670/alphaed.png that is a nice little thing. This is my Immediate Mode GUI?

Hi Albert

Yes! Apologies, I should have stated that it was your GUI code - which works fantastically well by the way

18

Off Topic / Re: So, OUYA. Will YA?

« on: 2013-Jul-17 »

I've been so overloaded with work and trying to find time for Vita development that I've just not had time to test the OUYA code.  Controller is fully supported (including the analogue triggers and sticks), but I've not tested inapp purchasing at all.

I'm hoping to get some free time this weekend and will push out an update to AndroidExtras - even if it's just the controller support for now.

//Andy

19

GLBasic - en / Re: Is there a way to change the alphaMode of each PolyNewStrip?

« on: 2013-Jul-12 »

You can't switch between -ve and +ve in a polyvector operation (start/endpoly) as that means you're trying to change the blend mode.  It will use whichever you started with and then clamp to those limits.  If you're using -ve values then 0 is seen as a different mode, so you need to use a value less than this.  Similarly, if you're using +ve (additive blend) then you need to keep all values over 0.

20

GLBasic - en / Re: Is there a way to change the alphaMode of each PolyNewStrip?

« on: 2013-Jul-09 »

I don't use viewport, but can't see that being an issue.

Try putting ALPHAMODE -0.0001 after you've finished drawing (just before ENDPOLY)

//Andy

21

GLBasic - en / Re: Is there a way to change the alphaMode of each PolyNewStrip?

« on: 2013-Jul-09 »

Works fine for me with v414.

I use a single STARTPOLY/ENDPOLY to draw absolutely everything - including particles with varying levels of alpha:

Code: (glbasic) [Select]

ALPHATESTING 0.001

STARTPOLY ID_ATLAS, 2
map.draw()
particleManager.draw()
game.draw()

ALPHAMODE 0.999
Prnt("FPS:" + fps, 40*sX, 10*sY, 0xffffff, 0x00ff00, 0.3*sX, 0.3*sY)
ALPHAMODE -0.0001
ENDPOLY
Each of the draw commands (and the Prnt) all just draw with POLYVECTOR and POLYNEWSTRIP as you do. I wonder if it's how you're using the alphamode (haven't looked in ages, I got it working and left it!)

//Andy

22

Off Topic / Re: So, OUYA. Will YA?

« on: 2013-Jul-05 »

I think I'm ok for the SDK at the moment - all updated.  As soon as I've finished the IAP and tested it I'll pass the code to you to try.  Would also welcome any additions too

//Andy

23

Off Topic / Re: So, OUYA. Will YA?

« on: 2013-Jul-05 »

btw - icon size:

The application image that is shown in the launcher is embedded inside of the APK itself. The expected file is in res/drawable-xhdpi/ouya_icon.png and the image size must be 732x412 for games or 412x412 for apps.

//Andy

24

Off Topic / Re: So, OUYA. Will YA?

« on: 2013-Jul-05 »

Very strange how you're getting such poor performance.  I just sideloaded the android port (without any changes) to the ouya and it ran perfectly.

25

Off Topic / Re: So, OUYA. Will YA?

« on: 2013-Jul-05 »

I'm using a single start/endpoly for one full frame, with a LOT of polyvectors in-between (3 layers).  I scale the polyvector params according to the resolution.

I do not use createscreen/usescreen as that has really bad performance issues.

26

Off Topic / Re: So, OUYA. Will YA?

« on: 2013-Jul-05 »

Grrr.... wanted to test this IAP stuff but I need to submit the form w-8ben.  Can't do that without an EIN number and I can't get that as the IRS office is closed (something to do with a USA public holiday)

Sorry chaps - will release the updated AndroidExtras next week with the OUYA support.  It has full controller support and, hopefully, fully working IAP

//Andy

27

Off Topic / Re: So, OUYA. Will YA?

« on: 2013-Jul-05 »

does ouya uses software or hardware accelerated?

Its look like its only uses software acceleration, due the paint() uses around 45ms() and only can render 10-15 fps, even im only use 2048x2048 upscaled textures..... strange.

The OUYA is hardware accelerated.  I'm getting a solid 60fps (1920x1080 on 42" screen) so far, but my texture atlases are 1024x1024 - they're simple textures so no need for high definition!

https://dl.dropboxusercontent.com/u/32204670/getaway_ss1.png

I'm also working on an editor:

https://dl.dropboxusercontent.com/u/32204670/alphaed.png

which also ran brilliantly on the OUYA - even when I enabled hundreds of effects and had them animated

//Andy

28

Off Topic / Re: So, OUYA. Will YA?

« on: 2013-Jul-05 »

I've got most of the IAP code done but there is one big issue....

Once a user has purchased (upgraded) your game/app then every time you start your game, you either:

a) Check the purchase against the OUYA receipt (has to be done online so therefore this is an always-online requirement)

or

b) Store encrypted information on the OUYA (using the putData call).  You would have to do this yourself, and in your own format.  I've already added code to AndroidExtras to support the put/get calls and additional calls to get the unique console ID and game ID.  The problem with this approach though is that you have to be careful how you protect that data - and also, the OUYA data store does not guarantee your data will stay there - it can delete it if large or hasn't been used in a long while!

Apparently, the OUYA developers are looking to implement a local receipt cache; if the console can't go online to check for a receipt it will check the local cache instead. 

For now, I'm always checking for receipts on game startup.  You can disable this and check for your own via getData.  As soon as local cache is available then you shouldn't need to record data any more.

//Andy

29

Off Topic / Re: So, OUYA. Will YA?

« on: 2013-Jul-05 »

Yeah, the key processing via SDL is wonky.  I've implemented all of the controller buttons/sticks/analogue buttons within AndroidExtras and it works ok.

30

Off Topic / Re: So, OUYA. Will YA?

« on: 2013-Jul-05 »

Ok, I couldn't sleep last night so got up very early and built rudimentary support for the OUYA. 

I managed to get all of the controller buttons and joysticks working quite well.  I tried this in one of my own games and it worked nicely.

Hopefully this weekend I can tidy up and add IAP support.

I'm also going to put AndroidExtras onto GitHub so other people can contribute as I don't have much free time.

//Andy