Designing a game for HD

How would one go about making an application with SDL that would be HD? Meaning running in 720p format.

HD refers to resolution only, so set the resolution to 1280x720.

Can you refine your question more?On Tue, Mar 22, 2011 at 2:16 PM, HowardBlast wrote:

How would one go about making an application with SDL that would be HD?
Meaning running in 720p format.


SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

It shouldn’t really differ from any other game. You simply have a
standard framebuffer size.On 23 Mar 2011, at 03:26, Patrick Baggett <baggett.patrick at gmail.com> wrote:

HD refers to resolution only, so set the resolution to 1280x720.

Can you refine your question more?

On Tue, Mar 22, 2011 at 2:16 PM, HowardBlast <HowardBlastIsKing at gmail.com wrote:
How would one go about making an application with SDL that would be
HD? Meaning running in 720p format.


SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org


SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

You can make hd game just by setting the screen surface to the
appropriate resolution, just like patrick said, but make sure you have
images and textures which you plan to use in the game of appropriate
size, so that your game looks good.On 3/23/11, HowardBlast wrote:

How would one go about making an application with SDL that would be HD?
Meaning running in 720p format.


-Abhay Gupta
2nd yr Electrical IDD
Indian Institute of Technology Roorkee.

I find that setting the screen surface’s height to 720 and the width to 1280 causes massive slowdown whenever the background image is blitted because such a large number of pixels must be transfered. Is this my computer being slow? Or is setting the screen’s dimensions to 720 height and 1280 width even the right way to go about it?

You should probably plan how often you blit the full background to avoid
that. Like blit it once, then only blit regions you need to redraw from
then on.On Sun, Mar 27, 2011 at 1:33 PM, HowardBlast wrote:

I find that setting the screen surface’s height to 720 and the width to
1280 causes massive slowdown whenever the background image is blitted
because such a large number of pixels must be transfered. Is this my
computer being slow? Or is setting the screen’s dimensions to 720 height and
1280 width even the right way to go about it?


SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

just my 2 cents ( well i’m english so pence )

gmaking your stuff only update the screen only where and when needed can be
a bit of a head messer, but once you have it going it is well worth it for
saving on speed slowdowns.

That is a good point about updating the background only where necessary, however when the background image is scrolling, isn’t there no other way to scroll it without completely blitting it again? Or is there a way to “shift” an already blitted image?

If it’s a case of a scrolling background, then maybe it’s how you’re
designing the background - instead of using one huge static image, you
should divide it into smaller images, and use the rectangle blitting for a
solid background color, then imposing whatever background sprite images over
that. You’ll find that you’re able to do more cool effects this way, I
think, and you won’t have to redraw the full background with a single blit
each time.
I hope that helps,
-AlexOn Tue, Mar 29, 2011 at 2:06 PM, HowardBlast wrote:

That is a good point about updating the background only where necessary,
however when the background image is scrolling, isn’t there no other way to
scroll it without completely blitting it again? Or is there a way to "shift"
an already blitted image?


SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

Thanks. Very good point. I’ll try it out.

In this day and age, where graphics cards are measured in GBs of texture
memory and billions of texels/sec, if you’re still getting slow performance,
you might want to reconsider what it is, precisely, that you are doing
wrong. Scrolling/blitting a 720p background is nothing compared to rendering
100K 3D triangles/frame with full shaders at 1280x1024 with 16x FSAA.
Put more succinctly, if you are going to start doing programs that are high
resolution, you should consider actually making dramatic use of the hardware
available, and in SDL terms, that means OpenGL.

PatrickOn Tue, Mar 29, 2011 at 1:39 PM, HowardBlast wrote:

Thanks. Very good point. I’ll try it out.


SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

I’m using all the optimization tricks that I am aware of with SDL, so I don’t know if I’m doing anything wrong in that regard. Patrick, is what you’re saying that OpenGL would be able to render a huge background image of 1280 x 720 pixels faster than SDL alone is capable of?

Like, much faster right? At least twice as fast?

Depends on the video card, but generally, with anything that’s actually
designed to run 3D games, we’re talking layers upon layers of blended textures
at 100+ fps - compared to not even making 100 fps no matter what.On Wednesday 30 March 2011, at 16.20.58, “HowardBlast” wrote:

Like, much faster right? At least twice as fast?


//David Olofson - Consultant, Developer, Artist, Open Source Advocate

.— Games, examples, libraries, scripting, sound, music, graphics —.
| http://consulting.olofson.net http://olofsonarcade.com |
’---------------------------------------------------------------------’

Orders of magnitude faster are possible. SDL’s software mode’s speed
is proportional to the size of the images you are using. Some
operations like alpha blending can be relatively slow in software.
OpenGL typically isn’t, as most of the heavy work is done by the
graphics card - in parallel to the CPU. It does depend on what you are
doing and how you approach it.

However, on old machines with integrated graphics cards and out of
date drivers, OpenGL can be slower than this. This is because such
OpenGL implementations are often poor and may fall back to software
mode. Software mode OpenGL may be slower than SDL because it has to
account for rotation etc.On 30 March 2011 15:20, HowardBlast wrote:

Like, much faster right? At least twice as fast?


SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

Yes, that is true. I’ve come to believe that using large numbers of small images without using OpenGL is my best bet, as previously mentioned in this thread.

Brian Barrett wrote:> Orders of magnitude faster are possible. SDL’s software mode’s speed

is proportional to the size of the images you are using. Some
operations like alpha blending can be relatively slow in software.
OpenGL typically isn’t, as most of the heavy work is done by the
graphics card - in parallel to the CPU. It does depend on what you are
doing and how you approach it.

However, on old machines with integrated graphics cards and out of
date drivers, OpenGL can be slower than this. This is because such
OpenGL implementations are often poor and may fall back to software
mode. Software mode OpenGL may be slower than SDL because it has to
account for rotation etc.