Sorry your browser is not supported!

So, I'm trying to target the Ouya for my next project, and here's the issue I'm facing design-wise:

I would like my game to look like a retro NES/SNES/Genesis style RPG. The tiles used in these games were small (8x8 or 8x16 or 16x16 in size, etc) and that I'm a functional basic artist when it comes to small resolutions. Because it's easy to do art when your canvas size is limited to 16x16 square.

However, designing for 1080p means I have 1920x1080 pixels on-screen to work with. Having tiles that are 8x8 would be dumb, and I'm guessing that I'd need 64x64 to cover the screen and have it be zoomed in enough for the player to not squint.

Now, design problem. Designing art at 64x64 means there's a lot more detail to involve. Tiles will take more size in memory (because they're at 64x64 resolution). However, I could also just design my maps using 16x16 tiles and then blow up the map at 400% scale during runtime.

What do you guys think? This is purely a theoretical design question. I'm leaning on just blowing everything up 400%, but I'd like some feedback first.

EDIT: I could also just use the Virtual Resolution function and let AppGameKit automatically blow up everything on-screen, but I heard that you need to program specifically at 1920x1080 for Ouya or the FPS goes to heck. What do you guys think? This could be another option as well, if I decide not to target Ouya (this app is designed to be used on a TV).

EDIT2: Or could I use VirtualResolution and set it to (854x480) and set the screen size in the setup.agc to 1920x1080?....

There is a third option, Design the tiles 16x16 and then scale up with an art package to 64x64 and save on the run-time processing.

That depends on how AppGameKit is implemented on the Ouya. I have seen mention of controller tweaks and whatnot, so there are tweaks in there.

As to Virtual Resolution in general, I wouldn't worry to much about that - since AppGameKit does the VR to device scaling, the actual resolution used is down the AppGameKit not you.

Code for 320, 640, 1920 or whatever based on what it looks like, not what you think the device wants it to be.

The player typically doesn't care what resolution the game was written for, but is more concerned with how good it looks and how well it plays.

edit: typos

Currently AppGameKit does not support altering the frame buffer. Paul mentioned a workaround in another thread where you can manually set the frame buffer. But I'm not that skilled outside writing the code in T1 and just don't have the time to learn this. Hopefully we'll get a command to alter this in v2 but no confirmation yet. There will be a render to image command which could be used to render to a smaller image and then draw that to the screen. But altering the frame buffer would be even faster.

What is this frame buffer thing? Most devs set the frame buffer lower than 1080p and the Ouya scales this up. It is very performance effective. The problem is that the fillrate on Ouya is quite low. Using a 1080p frame buffer requires a lot of fillrate once you start adding layers of transparent sprites. It will drop below 60 FPS if you fill the screen twice. Non transparent sprites are like 2-3 times faster to draw IIRC.

Altering the virtual resolution does not change the frame buffer size, or the drawing speed. setup.agc is only to alter the size of the window on computers. Running the game in a small window means a smaller frame buffer and increased drawing speeds, but it does not work on Ouya or other devices.

If you want to use a 1080p virtual resolution to get the speed boost you can scale your sprites and/or use SetViewZoom().

This may be totaly wrong, but this is how I understand it. The framebuffer is what Open GL uses to draw things to, which then get passed to the screen. If you have a framebuffer that is set to 1920x1080 it means that each frame the GPU will have to calculate every pixel in the framebuffer which is about 2 milion pixels each frame. If you set a smaller framebuffer, the GPU will have less pixels to calculate per frame and be able to fill the framebuffer faster.

I also believe that the sprites in AppGameKit are actually open GL 3d objects , with some optimisation of course. Scaling a sprite results in the sprite covering more of the screen, which means that the GPU will have to calculate the color of the sprite in more pixels. If the GPU has a problem with calculating large amounts of pixels, performance will take a hit when you cover more screen area with a sprite. Hopefully im not totaly misstaken and you get a better idea of why the performance takes a hit.

Regarding scaling the backbuffer helping performance is probably because tegra 3 has problems calculating the color of "pixels" in the framebuffer. When it comes to scaling a 720p backbuffer to a 1080p screen, it's just a matter of actually scaling an image.

Yeah, that's how it works. Fillrate is how fast the GPU can draw pixels to the framebuffer. Basically if you get 30 FPS at 1080p you are likely to get close to 60 FPS at 720p, because that's about half as many pixels. As long as your code isn't a bottleneck. I have done some tests that confirms drawing twice as many pixels takes twice as long. Regardless of the amount and sizes of the sprites. It also doesn't matter if you draw them on top of each other or cover the screen. You can only draw so many million pixels per second.