Please help me speed up my game

  • create an SDL_SWSURFACE

unlimited loop

  • blank the screen using Sdl_FillRect()
    22 players’ loop

    • directly draw pixels of the players to this surface
    • updating each rect corresponding to each player displayed from
      their both latest and newest position
      next player
      next
  • free the surface

It works fine but now I need to had a background able to move , and
that’s where it gets hard…

For a moving background (scrolling), you need to repaint the entire
screen each frame (for now - I’m working on a solution). If both the
background and the screen are HWSURFACEs this isn’t a big deal since
accelerated blits are fast enough. Scrolling also looks better if
page flipping is available (removes tearing artifacts), so keep that
possibility in mind.

Also, if possible, try not to draw the players manually but use
the SDL blitting functions if possible. This way you can use accelerated
drawing where it is supported and fall back to software (RLE) otherwise.

I assume you are coalescing update rectangles as needed (we had a
brief discussion on the list a while back, check the archives).

[…] But, as you may expect, it’s slower than on my old C64.

Heh, this is in fact what drove me to writing games for X11/Unix;
I felt that a 200x faster machine should be at least on par with an
old C64 :slight_smile: But the comparison isn’t totally fair:

  • The C64 had at best 320x200 resolution - you have probably
    at least 640x480, maybe more
  • The C64 had 1 or 2 bit colour - you have at least 8 bit depth
  • The C64 had hardware scrolling, a tiled framebuffer and hardware sprites

The trick in successful SDL use is to make use of hardware acceleration
where available, and fall back to software otherwise. The way SDL is
designed makes this quite easy: just ask for hardware surfaces and
you will get it if possible. Use RLE otherwise.

I thought of using a tiled background for the grass of the stadium but I
really don’t know what would be the fastest method to do it.

That is a workable idea. The advantage in using tiles is that you
reduce memory requirements and may improve performance (because of
better locality or because you can fit more images into video memory).
It takes a bit more blitting to fill a large surface but this might
not be a problem. You will have to try out various methods.

does God exist ?

I asked him last week but he just kept joking about it, impossible to have
a serious discussion with that guy

hi

I’m making a football (soccer) game using SDL and I need some advice to
increase the speed of the display.

In fact, I’m a newbie and all I do for the moment is :

  • create an SDL_SWSURFACE

unlimited loop

  • blank the screen using Sdl_FillRect()
    22 players’ loop

    • directly draw pixels of the players to this surface
    • updating each rect corresponding to each player displayed from
      their both latest and newest position
      next player
      next
  • free the surface

It works fine but now I need to had a background able to move , and
that’s where it gets hard…
Actually, I tried blitting a bmp instead of blanking the screen and ,
then , updating the whole screen instead of updating little rects for
each player. But, as you may expect, it’s slower than on my old C64.
I’m used to OpenGL programming and I’m far to be a demo-maker so I’m
lost when talking about 2D graphics.
I thought of using a tiled background for the grass of the stadium but I
really don’t know what would be the fastest method to do it.

Will I need to update all the screen each time ? Do I need to allocate
hardware surfaces for each sprite and each tile ? does God exist ?
(sorry, the last was easy …)

Thanks by advance.

mmmhhh…
I heard that it was possible to reuse part of the past frame instead of
redrawing everything.

It may help…

Ingenu.

Mattias Engdeg?rd a ?crit :> >- create an SDL_SWSURFACE

unlimited loop

  • blank the screen using Sdl_FillRect()
    22 players’ loop

    • directly draw pixels of the players to this surface
    • updating each rect corresponding to each player displayed from
      their both latest and newest position
      next player
      next
  • free the surface

It works fine but now I need to had a background able to move , and
that’s where it gets hard…

For a moving background (scrolling), you need to repaint the entire
screen each frame (for now - I’m working on a solution). If both the
background and the screen are HWSURFACEs this isn’t a big deal since
accelerated blits are fast enough. Scrolling also looks better if
page flipping is available (removes tearing artifacts), so keep that
possibility in mind.

Also, if possible, try not to draw the players manually but use
the SDL blitting functions if possible. This way you can use accelerated
drawing where it is supported and fall back to software (RLE) otherwise.

I assume you are coalescing update rectangles as needed (we had a
brief discussion on the list a while back, check the archives).

[…] But, as you may expect, it’s slower than on my old C64.

Heh, this is in fact what drove me to writing games for X11/Unix;
I felt that a 200x faster machine should be at least on par with an
old C64 :slight_smile: But the comparison isn’t totally fair:

  • The C64 had at best 320x200 resolution - you have probably
    at least 640x480, maybe more
  • The C64 had 1 or 2 bit colour - you have at least 8 bit depth
  • The C64 had hardware scrolling, a tiled framebuffer and hardware sprites

The trick in successful SDL use is to make use of hardware acceleration
where available, and fall back to software otherwise. The way SDL is
designed makes this quite easy: just ask for hardware surfaces and
you will get it if possible. Use RLE otherwise.

I thought of using a tiled background for the grass of the stadium but I
really don’t know what would be the fastest method to do it.

That is a workable idea. The advantage in using tiles is that you
reduce memory requirements and may improve performance (because of
better locality or because you can fit more images into video memory).
It takes a bit more blitting to fill a large surface but this might
not be a problem. You will have to try out various methods.

does God exist ?

I asked him last week but he just kept joking about it, impossible to have
a serious discussion with that guy

Julien Olivier wrote:

hi

I’m making a football (soccer) game using SDL and I need some advice to
increase the speed of the display.

In fact, I’m a newbie and all I do for the moment is :

  • create an SDL_SWSURFACE

unlimited loop

  • blank the screen using Sdl_FillRect()
    22 players’ loop

    • directly draw pixels of the players to this surface
    • updating each rect corresponding to each player displayed from
      their both latest and newest position
      next player
      next
  • free the surface

It works fine but now I need to had a background able to move , and
that’s where it gets hard…
Actually, I tried blitting a bmp instead of blanking the screen and ,
then , updating the whole screen instead of updating little rects for
each player. But, as you may expect, it’s slower than on my old C64.
I’m used to OpenGL programming and I’m far to be a demo-maker so I’m
lost when talking about 2D graphics.
I thought of using a tiled background for the grass of the stadium but I
really don’t know what would be the fastest method to do it.

Are you using nested for-loops to draw the pixels? If so, strongly
consider breaking the background into tiles and using SDL_BlitSurface.
It’s extremely fast, especially if you’ve used SDL_DisplayFormat to
create optimal surfaces for blitting. You can use the SDL_SetColorKey
function to specify RLE acceleration, which can speed up transparent
blits significantly.

Will I need to update all the screen each time ? Do I need to allocate
hardware surfaces for each sprite and each tile ?

It is feasible to do full screen refreshes at a decent framerate in SDL,
so long as you are very careful about your drawing. SDL gives you enough
rope to hang yourself with :slight_smile: Take a look at
http://www.lokigames.com/~overcode/lgp/book1.htm, chapter 4. It explains
fullscreen performance issues.

Hardware surfaces may help on some platforms. Don’t count on them.

-John–
John R. Hall | “The error of our eye directs
Student, Georgia Tech (2nd year CS) | our mind: What error leads
Contractor, Loki Entertainment Software | must err.” -Shakespeare

Julien Olivier wrote:

hi

I’m making a football (soccer) game using SDL and I need some advice to
increase the speed of the display.

In fact, I’m a newbie and all I do for the moment is :

  • create an SDL_SWSURFACE

unlimited loop

  • blank the screen using Sdl_FillRect()
    22 players’ loop

    • directly draw pixels of the players to this surface
    • updating each rect corresponding to each player displayed from
      their both latest and newest position
      next player
      next
  • free the surface

Hmmmmmmmm, well, this probably isn’t much to do with the topic, but:

Maybe don’t use unlimited loop of the normal sort. I assume you mean a loop
that uses timers, otherwise your game won’t run at a consistant speed and
will vary from machine to machine. Sue me if you already know this shit :slight_smile:

It works fine but now I need to had a background able to move , and
that’s where it gets hard…
Actually, I tried blitting a bmp instead of blanking the screen and ,
then , updating the whole screen instead of updating little rects for
each player. But, as you may expect, it’s slower than on my old C64.
I’m used to OpenGL programming and I’m far to be a demo-maker so I’m
lost when talking about 2D graphics.
I thought of using a tiled background for the grass of the stadium but I
really don’t know what would be the fastest method to do it.

Will I need to update all the screen each time ? Do I need to allocate
hardware surfaces for each sprite and each tile ? does God exist ?
(sorry, the last was easy …)

Well, for updating your surface to the screen, as I understand it, that
only need be done once you’ve totally finished writing everything to the
screen. And as for that final punt, don’t be so sure. I’m an atheist, and
most of the people in my area are blasted christians, so I feel like quite
a heretic now and then, but wtf, it’s my right not to have a god :-)>

Thanks by advance.


OOPMan (@OOPMan)
“He who fights with monsters should look to it that he himself
does not become a monster…When you gaze long into the abyss,
the abyss also gazes into you…” - Frederich Nietzsche

For a moving background (scrolling), you need to repaint the entire
screen each frame (for now - I’m working on a solution).

What kind of solution?
In our game we blit part of the backbuffer onto itself. This helps because
we have alot of alpha that won’t have to be redrawn. To make this safe
I have used memove()'s instead of SDL_BlitSurface(). Performance is ok
on my machine but lower cpu’s might benefit from an accelerated blit.
Is it safe to SDL_Blit a surface onto itself?

Is there a better approach to smooth scrolling?

Is it safe to SDL_Blit a surface onto itself?

Yes. And it’s usually faster than memmove().

See ya!
-Sam Lantinga, Lead Programmer, Loki Entertainment Software

Hello,

it depends what you need.
If you just wanna do bl?t with color key, yes, create HWsprites, use
doublebuffer, than Flip the screen.
I suppose in some times you would like to use background for screen, like
grass ??? so you’ll replace the fill by this.

Stephane

for scrolling, just do sprite bounding box and just draw what you need, and
don’t update rect when you are in HW and fullscreen, just do a SDL_Flip()
(which is equivalent to an UpdateRect(screen,0,0,0,0) ) when drawing in
windows or software, you’ll get much faster framerate.
Another plint is if you are using win2k with some strange driver(I have a
banshee), UpdateRects takes a LOT of time, don’t know why, just some
strange things with my driver, so also try on another computer if you are in
this situation.

Stephane

For a moving background (scrolling), you need to repaint the entire
screen each frame (for now - I’m working on a solution).

What kind of solution?

What I have been doing in an X11 game is to have a back buffer
slightly larger than the displayed window, and updating from an offset
within that back buffer. I still have to update the whole window (with
XShmPutImage), but I don’t need to scroll the back buffer until the
window has moved to the edge of it (and then I can scroll it in
tile-sized steps, which is faster and simple and in turn enables
more optimizations).
It works nicely for a 600x600 window on a 100MHz Pentium in XFree 3.1.x.

For this to work in SDL, we would need a way to tell SDL_SetVideoMode()
to create an oversized shadow surface, and also a way to make
SDL_UpdateRects() use the correct offset when updating. Ideally the same
code should be able to take advantage of hardware surfaces if available,
especially since scrolling games benefit a lot from page flipping.
If there is enough video memory the oversized backbuffer could fit in
vidmem and an update would just do an accelerated copy to the screen or
to the currently not visible screen page. Would this be a good way to
do it?

Of course, I use Sdl_GetTicks to synchronize my game but I haven’t
mentionned it because it’s off topic.

And I think you misunderstood what I said about god : for me , what’s
obvious is that it doesn’t exist , I’m the atheistest (hmm, I’m not sure
that exists…) man in the world :slight_smile:

“OOPMan” <oop_man_za at yahoo.com> a ?crit dans le message
news:<39D36DE7.51784DBD at yahoo.com>…

Julien Olivier wrote:

hi

I’m making a football (soccer) game using SDL and I need some advice
to

increase the speed of the display.

In fact, I’m a newbie and all I do for the moment is :

  • create an SDL_SWSURFACE

unlimited loop

  • blank the screen using Sdl_FillRect()
    22 players’ loop

    • directly draw pixels of the players to this surface
    • updating each rect corresponding to each player displayed from
      their both latest and newest position
      next player
      next
  • free the surface

Hmmmmmmmm, well, this probably isn’t much to do with the topic, but:

Maybe don’t use unlimited loop of the normal sort. I assume you mean a
loop
that uses timers, otherwise your game won’t run at a consistant speed
and
will vary from machine to machine. Sue me if you already know this
shit :-)>

It works fine but now I need to had a background able to move , and
that’s where it gets hard…
Actually, I tried blitting a bmp instead of blanking the screen and
,

then , updating the whole screen instead of updating little rects
for

each player. But, as you may expect, it’s slower than on my old C64.
I’m used to OpenGL programming and I’m far to be a demo-maker so I’m
lost when talking about 2D graphics.
I thought of using a tiled background for the grass of the stadium
but I

really don’t know what would be the fastest method to do it.

Will I need to update all the screen each time ? Do I need to
allocate

hardware surfaces for each sprite and each tile ? does God exist ?
(sorry, the last was easy …)

Well, for updating your surface to the screen, as I understand it,
that
only need be done once you’ve totally finished writing everything to
the
screen. And as for that final punt, don’t be so sure. I’m an atheist,
and
most of the people in my area are blasted christians, so I feel like
quite
a heretic now and then, but wtf, it’s my right not to have a god :slight_smile:

Thanks by advance.


OOPMan (oop_man_za at yahoo.com)
“He who fights with monsters should look to it that he himself
does not become a monster…When you gaze long into the abyss,
the abyss also gazes into you…” - Frederich Nietzsche

You’re rite, I tested it on win2000 with an ATI Rage 128 and it’s SLOW
while on the same PC with linux, it’s fast and on another PC with a
Voodoo3 and both linux and win95, it works fast too. So the problem
probably comes from win2000.

“Stephane Magnenat” a ?crit dans le message
news:<006701c029f1$b15ec890$0a01a8c0 at K6450>…

for scrolling, just do sprite bounding box and just draw what you
need, and
don’t update rect when you are in HW and fullscreen, just do a
SDL_Flip()
(which is equivalent to an UpdateRect(screen,0,0,0,0) ) when drawing
in
windows or software, you’ll get much faster framerate.
Another plint is if you are using win2k with some strange driver(I
have a
banshee), UpdateRects takes a LOT of time, don’t know why, just some
strange things with my driver, so also try on another computer if you
are in> this situation.

Stephane

just a little question : do you think I can download the doc
http://www.lokigames.com/lgp as a file ?
It would help me a lot.

“John R. Hall” a ?crit dans le message
news:<39D35FD6.118DEFDD at lokigames.com>…

Julien Olivier wrote:

hi

I’m making a football (soccer) game using SDL and I need some advice
to> > increase the speed of the display.

In fact, I’m a newbie and all I do for the moment is :

  • create an SDL_SWSURFACE

unlimited loop

  • blank the screen using Sdl_FillRect()
    22 players’ loop

    • directly draw pixels of the players to this surface
    • updating each rect corresponding to each player displayed from
      their both latest and newest position
      next player
      next
  • free the surface

It works fine but now I need to had a background able to move , and
that’s where it gets hard…
Actually, I tried blitting a bmp instead of blanking the screen and
,

then , updating the whole screen instead of updating little rects
for

each player. But, as you may expect, it’s slower than on my old C64.
I’m used to OpenGL programming and I’m far to be a demo-maker so I’m
lost when talking about 2D graphics.
I thought of using a tiled background for the grass of the stadium
but I

really don’t know what would be the fastest method to do it.

Are you using nested for-loops to draw the pixels? If so, strongly
consider breaking the background into tiles and using SDL_BlitSurface.
It’s extremely fast, especially if you’ve used SDL_DisplayFormat to
create optimal surfaces for blitting. You can use the SDL_SetColorKey
function to specify RLE acceleration, which can speed up transparent
blits significantly.

Will I need to update all the screen each time ? Do I need to
allocate

hardware surfaces for each sprite and each tile ?

It is feasible to do full screen refreshes at a decent framerate in
SDL,
so long as you are very careful about your drawing. SDL gives you
enough
rope to hang yourself with :slight_smile: Take a look at
http://www.lokigames.com/~overcode/lgp/book1.htm, chapter 4. It
explains
fullscreen performance issues.

Hardware surfaces may help on some platforms. Don’t count on them.

-John


John R. Hall | “The error of our eye
directs
Student, Georgia Tech (2nd year CS) | our mind: What error leads
Contractor, Loki Entertainment Software | must err.” -Shakespeare

Mattias Engdeg?rd wrote:

For a moving background (scrolling), you need to
repaint the entire screen each frame (for now -
I’m working on a solution).

What kind of solution?

What I have been doing in an X11 game is to have a
back buffer slightly larger than the displayed window,
and updating from an offset within that back buffer.
I still have to update the whole window (with
XShmPutImage), but I don’t need to scroll the back
buffer until the window has moved to the edge of it

I am using a back buffer the same size as the viewing area and applying a
"2-axis rotary buffer" algorithm to it. You have to do four blits to
transfer the back buffer to the screen but you never have to scroll the back
buffer.

Screen

|-------------|-------|
|             |       |
|             |       |
|      A      |   B   |
|             |       |
|             |       |
|-------------|-------|--
|             |       |
|      C      |   D   | dy
|             |       |
|-------------|-------|--
              |  dx   |

Back Buffer

|  dx   |

–|-------|-------------|
| | |
dy | D | C |
| | |
–|-------|-------------|
| | |
| | |
| B | A |
| | |
| | |
|-------|-------------|

This is the situation after scrolling down and to the right. Block A in the
back buffer contains the remnants of the original unscrolled image. Blocks
B, C, and D contain the newly exposed regions of the image.

The concept is borrowed from normal rotary buffers (1-axis) used for data
queuing. You have to really watch what you are doing (especially when
blitting near the boundaries) but the results are well worth the effort
involved in the implementation.

  • Randi

Regimental Command
Generic Armored Combat System
http://regcom.sourceforge.net

I am using a back buffer the same size as the viewing area and applying a
"2-axis rotary buffer" algorithm to it. You have to do four blits to
transfer the back buffer to the screen but you never have to scroll the back
buffer.
[munch]

This is an interesting method, but requires all straddling sprites to
be drawn twice and each time clipped the subrectangle boundaries. Same
thing with all pixel-rendered effects. Another disadvantage is that
frame updates may be slightly slower since each scan line is split in
two parts.

But it is still an interesting scheme and I’ll compare it to the big-buffer
method when I get some time.

julien wrote:

Of course, I use Sdl_GetTicks to synchronize my game but I haven’t
mentionned it because it’s off topic.

Hehehehe, me stoopid to have even asked. I’m prolly more of a newbie than
you :slight_smile:

And I think you misunderstood what I said about god : for me , what’s
obvious is that it doesn’t exist , I’m the atheistest (hmm, I’m not sure
that exists…) man in the world :slight_smile:

Hehehehe, same as above. Me being stoopid. Man, I hate being young. You say
such stupid things, read things the wrong way and generaly
just screw up in your social undertakings :-(>

“OOPMan” <@OOPMan> a ?crit dans le message
news:<39D36DE7.51784DBD at yahoo.com>…

Julien Olivier wrote:

hi

I’m making a football (soccer) game using SDL and I need some advice
to

increase the speed of the display.

In fact, I’m a newbie and all I do for the moment is :

  • create an SDL_SWSURFACE

unlimited loop

  • blank the screen using Sdl_FillRect()
    22 players’ loop

    • directly draw pixels of the players to this surface
    • updating each rect corresponding to each player displayed from
      their both latest and newest position
      next player
      next
  • free the surface

Hmmmmmmmm, well, this probably isn’t much to do with the topic, but:

Maybe don’t use unlimited loop of the normal sort. I assume you mean a
loop
that uses timers, otherwise your game won’t run at a consistant speed
and
will vary from machine to machine. Sue me if you already know this
shit :slight_smile:

It works fine but now I need to had a background able to move , and
that’s where it gets hard…
Actually, I tried blitting a bmp instead of blanking the screen and
,

then , updating the whole screen instead of updating little rects
for

each player. But, as you may expect, it’s slower than on my old C64.
I’m used to OpenGL programming and I’m far to be a demo-maker so I’m
lost when talking about 2D graphics.
I thought of using a tiled background for the grass of the stadium
but I

really don’t know what would be the fastest method to do it.

Will I need to update all the screen each time ? Do I need to
allocate

hardware surfaces for each sprite and each tile ? does God exist ?
(sorry, the last was easy …)

Well, for updating your surface to the screen, as I understand it,
that
only need be done once you’ve totally finished writing everything to
the
screen. And as for that final punt, don’t be so sure. I’m an atheist,
and
most of the people in my area are blasted christians, so I feel like
quite
a heretic now and then, but wtf, it’s my right not to have a god :slight_smile:

Thanks by advance.


OOPMan (@OOPMan)
“He who fights with monsters should look to it that he himself
does not become a monster…When you gaze long into the abyss,
the abyss also gazes into you…” - Frederich Nietzsche


OOPMan (@OOPMan)
“He who fights with monsters should look to it that he himself
does not become a monster…When you gaze long into the abyss,
the abyss also gazes into you…” - Frederich Nietzsche

Mattias Engdeg?rd wrote:

For a moving background (scrolling), you need to repaint the entire
screen each frame (for now - I’m working on a solution).

What kind of solution?

What I have been doing in an X11 game is to have a back buffer
slightly larger than the displayed window, and updating from an offset
within that back buffer. I still have to update the whole window (with
XShmPutImage), but I don’t need to scroll the back buffer until the
window has moved to the edge of it (and then I can scroll it in
tile-sized steps, which is faster and simple and in turn enables
more optimizations).
It works nicely for a 600x600 window on a 100MHz Pentium in XFree 3.1.x.

For this to work in SDL, we would need a way to tell SDL_SetVideoMode()
to create an oversized shadow surface, and also a way to make
SDL_UpdateRects() use the correct offset when updating. Ideally the same
code should be able to take advantage of hardware surfaces if available,
especially since scrolling games benefit a lot from page flipping.
If there is enough video memory the oversized backbuffer could fit in
vidmem and an update would just do an accelerated copy to the screen or
to the currently not visible screen page. Would this be a good way to
do it?

I can’t imagine a nice cross-platform means of doing this. It
almost simulates the use of hardware scrolling, but not quite.
Maybe we should try to expose hardware scrolling, and use this
method to emulate it.

-Ray

Ray Kelm wrote:

Mattias Engdeg?rd wrote:

For a moving background (scrolling), you need to repaint the entire
screen each frame (for now - I’m working on a solution).

What kind of solution?

What I have been doing in an X11 game is to have a back buffer
slightly larger than the displayed window, and updating from an offset
within that back buffer. I still have to update the whole window (with
XShmPutImage), but I don’t need to scroll the back buffer until the
window has moved to the edge of it (and then I can scroll it in
tile-sized steps, which is faster and simple and in turn enables
more optimizations).
It works nicely for a 600x600 window on a 100MHz Pentium in XFree 3.1.x.

For this to work in SDL, we would need a way to tell SDL_SetVideoMode()
to create an oversized shadow surface, and also a way to make
SDL_UpdateRects() use the correct offset when updating. Ideally the same
code should be able to take advantage of hardware surfaces if available,
especially since scrolling games benefit a lot from page flipping.
If there is enough video memory the oversized backbuffer could fit in
vidmem and an update would just do an accelerated copy to the screen or
to the currently not visible screen page. Would this be a good way to
do it?

I can’t imagine a nice cross-platform means of doing this. It
almost simulates the use of hardware scrolling, but not quite.
Maybe we should try to expose hardware scrolling, and use this
method to emulate it.

-Ray

I might err on this point, but maybe this could work :

Lets say we have a game screen of 640x480x32. Now we create a
"Buffer-Surface" with 1280x960x32 via SDL_CreateRGBSurface. This one
stores the background for 4x4 Tiles of a whole screen. Now we can
SDL_BlitSurface (*myBufferSurface,SDL_Rect
{Actual.AbsoluteX,Actual.AbsoluteY,640,480}, *screen, NULL); So this
might be what was posted before. And when doing that you can update the
Dummy_Surface in the Background. You just have to create
"hypothetic"-coordinates, that store the Absolute-Position (on the
Dummy-Surface) and calculate them back on the visual Screen.
By the way: I was testing with this for an “easy anti-aliasing”, by
resizing the 4x4 Tiles to a 1x1 size, so the colors of 4 pixels would be
mixed. This made me think of using this as a solution. But my
"anti-aliasing-approach" seems to be much too slow

Greetings,

Sascha

Sorry, in my first reply was a mistake. You don’t have 4x4 Tiles of the
original sized screen, you have 2x2 (I am a bit tired, so sorry :).
There is another idea: what about creating just many surfaces of the
original screen size ? so if you need to handle a “virtual screen” of
4x3 visual screens, just set up 12 Surfaces before (!) the game starts,
of the visual screen size. You can merge them by blitting parts of
maximum 4 different “buffer-screens” to the visual surface. See graph:±----±----±----±----+
| 1 | 2 | 3 |4 |
| | | | |
| | | | |
±----±----±----±----+
| 5 | 6 | 7 | 8 |
| | |* | |
| | |* | |
±----±----±----±----+
| 9 | |* | 12 |
| | |* | |
| | 10 | 11 | |
±----±----±----±----+

**** - VISUAL SCREEN SO YOU HAVE TO BLIT PARTS OF 6,7, 10 AND 11 TO THE
VISUAL SCREEN.

Can you use SDL_CreatRGBSurface for full color Images,
like mountain scenery? Might be a silly question, I
just imagine color loss when I think RGB. Also, if
anyone has such an example of efficient/simple
scrolling in source code using SDL, I would really
appreciate a link. My Scrolling background is 640x480
or really 640x960 so it will scroll left/right. It
would be an extreme help!

Thanks
Tony

— Sascha G?nther <s.guenther at lives.de> wrote:> Sorry, in my first reply was a mistake. You don’t

have 4x4 Tiles of the
original sized screen, you have 2x2 (I am a bit
tired, so sorry :).
There is another idea: what about creating just many
surfaces of the
original screen size ? so if you need to handle a
“virtual screen” of
4x3 visual screens, just set up 12 Surfaces before
(!) the game starts,
of the visual screen size. You can merge them by
blitting parts of
maximum 4 different “buffer-screens” to the visual
surface. See graph:

±----±----±----±----+
| 1 | 2 | 3 |4 |
| | | | |
| | | | |
±----±----±----±----+
| 5 | 6 | 7 | 8 |
| | |* | |
| | |* | |
±----±----±----±----+
| 9 | |* | 12 |
| | |* | |
| | 10 | 11 | |
±----±----±----±----+

**** - VISUAL SCREEN SO YOU HAVE TO BLIT PARTS OF
6,7, 10 AND 11 TO THE
VISUAL SCREEN.


Do You Yahoo!?
Yahoo! Photos - 35mm Quality Prints, Now Get 15 Free!