# Changing the rendering resolution while maintaining the design layout

I would like to increase the FPS of my project.

Currently I would like to try reducing the resolution at which the scenes are rendered.

Let's say I never want to draw more than 1280*720. What ever the real resolution is. How should I proceed?

I tried pEGLView->setFrameSize(1280, 720); but only reduces the displayed size of the frame on screen (boxing).

In my activity I tried setting the size of the "surface" but this seems to completely break the layout (as defined by setDesignResolutionSize).

@Override
public Cocos2dxGLSurfaceView onCreateView() {
Cocos2dxGLSurfaceView surfaceView = new Cocos2dxGLSurfaceView(this);
surfaceView.getHolder().setFixedSize(1280, 720);
return surfaceView;
}


Is there a way to simply set the scene resolution and display the result full screen?

• Are you sure you are fillrate bound? Only in that case will reducing the resolution help improve the framerate. – Andreas Dec 10 '13 at 9:37
• And do yourself a huge favor: Measure frametime instead of framerate! – Andreas Dec 10 '13 at 9:38

## 3 Answers

Currently I draw into a texture (1280, 720) or adapted to the screen ratio. Then this texture is displayed upscaled.

• that's probably the best way – Timothy Groote Dec 9 '13 at 11:39
• Make sure you're using the filtering mode that's applicable to the desired effect. Don't use any filtering if you want a pixellated result. – Mokosha Dec 10 '13 at 20:39

My games had a "target resolution", say 1024x768. They were rendered to a texture. The video mode was set to the native resolution of the monitor, the texture would be scaled up so that it took the whole height of the mode (or width, but it's a less common case), and then drawn as a single quad. This made the game logic resolution-independent, and also did letterboxing in widescreen monitors as a bonus.

I did the same thing recently for retina- and non-retina iPads. Letterboxing is again useful with the iPhone 5.

• It's what i'm currently doing... but I'm not satisfied with the resulting quality, and the performance boost is not so great either. I fear I'm trading a lot in quality for little results in terms of performance boost. – Coyote Dec 6 '13 at 10:34
• Really? What do you mean by "quality"? With the right scaling filters, I was surprised by how good the quality was when doing it like this. Are you using bilinear filtering? – ggambett Dec 6 '13 at 11:40

on IOS as far as i know you can't create a framebuffer with a different resolution than the screen so the only approach is to render everything into a texture and draw it afterwards on the screen. Also targeting different resolutions is quite hard and there are a couple of things to take into accound:

Aspect ratio of the screen:

The texture you create should have the same aspect ratio as the screen otherwise thing will look stretched afterwards. If you don't want to do this you can fake the aspect ratio of the game from the projection matrix but in this case the pixels from your texture will be stretched unevenly creating aliasing artifacts that will just look bad.

Aspect ratio again:

It is important that the projection matrix takes into the account the screen also because on a wider screen you will see more on width so the projection has to be wider otherwise the content will look differently.

Menus:

This is a really hard topic but the general approach is to have the elements scaled evenly on width and height but this is not possible if you have different aspect ratios unless you split the menus into parts and apply uneven scale only on salable elements(like the empty space between buttons). Much like how html pages are made , you have the content that is fixed(or scaled evenly) and the borders are stretched until it fill the whole screen.

Artifacts generated by scaling:

When rendering to a texture and scaling it up you will get aliasing artifacts and they are hard to remove. You can use an upscale filter, but this can be expensive on mobile devices.

• Interesting, this is something I'll have take into account. The project which requires this runs currently on android. But I will port it back to iOS (where it started) soon. – Coyote Dec 5 '13 at 14:22