Horizontal Scrolling: Easiest way?

GEM_Products · May 20, 2000, 7:18am

What might be the easiest way to do horizontal
scrolling? Thanks to all for your support. Linux
Outdoor Hunter is soon to be a playable, yet slightly
boring right now, demo version.__________________________________________________
Do You Yahoo!?
Send instant messages & get email alerts with Yahoo! Messenger.

Daniel2 · May 21, 2000, 4:09am

In article <20000520071821.22795.qmail at web107.yahoomail.com>, you say…

What might be the easiest way to do horizontal
scrolling? Thanks to all for your support. Linux
Outdoor Hunter is soon to be a playable, yet slightly
boring right now, demo version.

the easiest way would be to have a very large SDL_Surface (say

2000x600) and move the srcRect around as you blit:

mainLoop
{
	srcRect = {800x600}		// screen res

	// blit from large background to screen using the srcRect
	// as a moving 'frame' (this is where the scrolling
	// comes from).
	SDL_BlitSurface(bgSurface,&srcRect,videoSurface,&dstRect);

	++srcRect.x				// scroll right
	--srcRect.x				// scroll left
	--srcRect.y				// scroll up
	++srcRect.y				// scroll down

	...

}

do you understand the theory?

-dv

Nicholas_Vining · May 21, 2000, 4:36am

the easiest way would be to have a very large SDL_Surface (say
2000x600) and move the srcRect around as you blit:

Oy gevalte. I can’t help feeling that you’d run into some interesting cache
misses there.

I’d say “use tiles”, build yourself a tile-based map, and work from there.
But that’s not the easiest way; what Daniel’s suggested is probably about as
easy as it gets.

-dv

Nicholas

----- Original Message -----
From: daniel_v@bigpond.com (Daniel)
To: sdl at lokigames.com
Date: Saturday, May 20, 2000 9:26 PM
Subject: [SDL] Re: Horizontal Scrolling: Easiest way?

Gautier_Portet · May 22, 2000, 9:40am

the easiest way would be to have a very large SDL_Surface (say
2000x600) and move the srcRect around as you blit:

mainLoop
{
srcRect = {800x600} // screen res

// blit from large background to screen using the srcRect
// as a moving ‘frame’ (this is where the scrolling
// comes from).
SDL_BlitSurface(bgSurface,&srcRect,videoSurface,&dstRect);

++srcRect.x // scroll right
–srcRect.x // scroll left
–srcRect.y // scroll up
++srcRect.y // scroll down

…

}

hum ? and if the card doesn’t support wide surfaces in win32 directx ?

Daniel2 · May 22, 2000, 9:53am

In article <8gauvi$7pl$1 at ftp.lokigames.com>, impulse at citeweb.NOSPAM.net
says…

the easiest way would be to have a very large SDL_Surface (say
2000x600) and move the srcRect around as you blit:

// blit from large background to screen using the srcRect
// as a moving ‘frame’ (this is where the scrolling
// comes from).
SDL_BlitSurface(bgSurface,&srcRect,videoSurface,&dstRect);

++srcRect.x // scroll right
–srcRect.x // scroll left
–srcRect.y // scroll up
++srcRect.y // scroll down

hum ? and if the card doesn’t support wide surfaces in win32 directx ?

so tell me, what is the easiest way ? and before you answer assume

i don’t have 3 years of computer science and 5 years of industry
experience behind me. also consider that easy does not mean fast or
efficient or clever. it means easy.

-dv

slouken · May 22, 2000, 4:52pm

hum ? and if the card doesn’t support wide surfaces in win32 directx ?

You will get a software surface.

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

Mattias_Engdegard · May 22, 2000, 5:26pm

the easiest way would be to have a very large SDL_Surface (say
2000x600) and move the srcRect around as you blit:

mainLoop
{
srcRect = {800x600} // screen res
  // blit from large background to screen using the srcRect
  // as a moving 'frame' (this is where the scrolling
  // comes from).
  SDL_BlitSurface(bgSurface,&srcRect,videoSurface,&dstRect);

This is wasteful if videoSurface is a software surface (as in X11); you’d
end up copying everything twice. It would be better if bgSurface could
be used as the videoSurface directly, letting SDL_UpdateRect() do the
blitting.

Gautier_Portet · May 23, 2000, 11:02am

hum ? and if the card doesn’t support wide surfaces in win32 directx ?

You will get a software surface.

ok
software is slow…

in fact, what kind of scrolling do you can ?
one big surface can be an easy solution…
if you can, just one 640x480 surface that you blit 2 times

Sam_Hart · May 23, 2000, 10:22pm

the easiest way would be to have a very large SDL_Surface (say
2000x600) and move the srcRect around as you blit:

mainLoop
{
srcRect = {800x600} // screen res
// blit from large background to screen using the srcRect
// as a moving 'frame' (this is where the scrolling
// comes from).
SDL_BlitSurface(bgSurface,&srcRect,videoSurface,&dstRect);
This is wasteful if videoSurface is a software surface (as in X11); you’d
end up copying everything twice. It would be better if bgSurface could
be used as the videoSurface directly, letting SDL_UpdateRect() do the
blitting.

How do you go about doing something like this? Could I see a code
fragment?

(curious about this subject as well… been using a method similar to
above… which works fine on my 300Mhz 128Meg system, but grinds to a halt
on my 166Mhz, 42Meg work computer…)On Mon, 22 May 2000, Mattias Engdegard wrote:

–
Sam Hart http://www.physics.arizona.edu/~hart/
Web Page Highlights: Video Game History, Black Hole Simulation, & more.
OTHER WEB SITES MAINTAINED BY SAM HART
http://www.geekcomix.com/ - Geekcomix, the Daily Geek Comic Strip Site
http://www.physics.arizona.edu/~hart/gw/ - Ghostworks (Alt./Linux Computing)

Mattias_Engdegard · May 23, 2000, 10:53pm

This is wasteful if videoSurface is a software surface (as in X11); you’d
end up copying everything twice. It would be better if bgSurface could
be used as the videoSurface directly, letting SDL_UpdateRect() do the
blitting.

How do you go about doing something like this? Could I see a code
fragment?

You can’t do that in SDL (yet), but it would be trivial to add. It’s just
a question of making the back buffer (the software videoSurface in X11)
larger than the screen, and use a displacement in the XShmPutImage() calls.
The speedup can be noticeable sometimes.

Matt_Pekar · May 24, 2000, 2:16am

I have some bitmaps which I load using SDL_LoadBitmap, I’d like to use the
top left pixel as the transparent pixel for images. Using
SDL_SetColorKey, I can sort of get it to work: it blits black where it
should blit transparent.

Reading through the new documentation, I discover that a surface must be
in video memory to use transparency (SRC_COLORKEY is ignored if a surface
is in system memory). This seems a little strange to me, why can’t I have
bitmaps with transparency in system memory? What happens if a game runs
out of video memory? Do all the bitmaps just start overwriting each
other? Am I missing something really simple? Does anyone have any
awesome advice or suggestions?

slouken · May 24, 2000, 3:39am

Reading through the new documentation, I discover that a surface must be
in video memory to use transparency (SRC_COLORKEY is ignored if a surface
is in system memory).

This is incorrect. The colorkey is always respected, in both video and
system memory.

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

Matt_Pekar · May 24, 2000, 5:38am

Well then I’d like to propose changes to the documentation, which has
this (under the video function section):

"SDL_SRCCOLORKEY means that the surface will be used for colorkey blits
and if the hardware supports hardware acceleration of colorkey blits
between two surfaces in video memory, to place the surface in video memory
if possible, otherwise it will be placed in system memory.
SDL_SRCALPHA means that the surface will be used for alpha blits and if
the hardware supports hardware acceleration of alpha blits between two
surfaces in video memory, to place the surface in video memory if
possible, otherwise it will be placed in system memory.
SDL_SRCCOLORKEY and SDL_SRCALPHA will only be honored if the display
surface is in video video memory (the surface returned by
SDL_SetVideoMode() has the SDL_HWSURFACE flag set.) "

Does anyone know why my transparent pixel is being blitted as
black? Might it have something to do with the Be version of SDL? I have
1.1.2 for R5.> ----- Original Message -----

From: slouken@devolution.com (Sam Lantinga)
To:
Sent: Tuesday, May 23, 2000 11:39 PM
Subject: Re: [SDL] Color keys

Reading through the new documentation, I discover that a surface must
be

in video memory to use transparency (SRC_COLORKEY is ignored if a
surface

is in system memory).

This is incorrect. The colorkey is always respected, in both video and
system memory.

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

Gautier_Portet · May 24, 2000, 8:50am

I have some bitmaps which I load using SDL_LoadBitmap, I’d like to use the
top left pixel as the transparent pixel for images. Using
SDL_SetColorKey, I can sort of get it to work: it blits black where it
should blit transparent.

Reading through the new documentation, I discover that a surface must be
in video memory to use transparency (SRC_COLORKEY is ignored if a surface
is in system memory). This seems a little strange to me, why can’t I have
bitmaps with transparency in system memory? What happens if a game runs
out of video memory? Do all the bitmaps just start overwriting each
other? Am I missing something really simple? Does anyone have any
awesome advice or suggestions?

no, it must work…
try this:

SDL_LockSurface(surface);
Uint32 pixel=0;

switch (surface->format->BytesPerPixel)
{
case 1:
{
byte b = (byte) surface->pixels;
pixel=*b;
break;
}
case 2:
{
word w = (word) surface->pixels;
pixel=*w;
break;
}
case 3:
{
dword d = (dword) surface->pixels;
pixel=(*d)&0xffffff;
break;
}
case 4:
{
dword d = (dword) surface->pixels;
pixel=*d;
break;
}
}

SDL_UnlockSurface(surface);
SDL_SetColorKey(surface,SDL_SRCCOLORKEY,pixel);–

Gautier Portet - gautier at tlk.fr
lead programmer at TLK Games
http://www.tlk.fr

Mattias_Engdegard · May 24, 2000, 4:49pm

case 3:
{
dword d = (dword) surface->pixels;
pixel=(*d)&0xffffff;
break;
}

This is incorrect; it will only work on little-endian boxes.

(And, please: If you mean “a 32 bit int”, then use one of the nice, clear
typedefs provided by SDL, Uint32 etc instead of this homebrew stuff.
A word is the native bundle of bits that can be treated as a unit,
thus 32 or 64 on modern processors.)

Rainer_Deyke · May 24, 2000, 6:12pm

Gautier Portet wrote in message
news:8gg4ph$mp8$1 at ftp.lokigames.com…

case 3:
{
dword d = (dword) surface->pixels;
pixel=(*d)&0xffffff;
break;
}

This can’t be safe, can it? What if the surface is 1x1 in size and thus
only has three bytes of memory allocated to it?–
Rainer Deyke (root at rainerdeyke.com)
“In ihren Reihen zu stehen heisst unter Feinden zu kaempfen” - Abigor

Gautier_Portet · May 24, 2000, 8:12pm

case 3:
{
dword d = (dword) surface->pixels;
pixel=(*d)&0xffffff;
break;
}

This is incorrect; it will only work on little-endian boxes.

… sure ?
how to make it endian independant so ?

(And, please: If you mean “a 32 bit int”, then use one of the nice, clear
typedefs provided by SDL, Uint32 etc instead of this homebrew stuff.
A word is the native bundle of bits that can be treated as a unit,
thus 32 or 64 on modern processors.)

ok dad
thats right…

GEM_Products · May 24, 2000, 8:13pm

If that’s true i wonder what I’ll do on my 233mmx 64mb
ram?

— Sam Hart wrote:

the easiest way would be to have a very large
SDL_Surface (say

2000x600) and move the srcRect around as you
blit:
mainLoop
{
srcRect = {800x600} // screen res
// blit from large background to screen using
the srcRect
// as a moving 'frame' (this is where the
scrolling
// comes from).

SDL_BlitSurface(bgSurface,&srcRect,videoSurface,&dstRect);> On Mon, 22 May 2000, =?ISO-8859-1?Q?Mattias Engdeg=E5rd?= wrote:

This is wasteful if videoSurface is a software
surface (as in X11); you’d
end up copying everything twice. It would be
better if bgSurface could
be used as the videoSurface directly, letting
SDL_UpdateRect() do the
blitting.

How do you go about doing something like this? Could
I see a code
fragment?

(curious about this subject as well… been using a
method similar to
above… which works fine on my 300Mhz 128Meg
system, but grinds to a halt
on my 166Mhz, 42Meg work computer…)

–
Sam Hart
http://www.physics.arizona.edu/~hart/
Web Page Highlights: Video Game History, Black Hole
Simulation, & more.
OTHER WEB SITES MAINTAINED BY SAM
HART
http://www.geekcomix.com/ - Geekcomix, the Daily
Geek Comic Strip Site
http://www.physics.arizona.edu/~hart/gw/ -
Ghostworks (Alt./Linux Computing)

Do You Yahoo!?
Kick off your party with Yahoo! Invites.
http://invites.yahoo.com/

David_J_Goehrig · May 24, 2000, 11:30pm

Hello world,

I have a near complete set of bindings for SDL-1.x.x for perl,

with a decent Object layer on top. I would really appreciate it if
people who are interested, would download it and then send me feedback.

Basically, I wrote to help make small app, and custom web

based interfaces. It comes with a pair of sample image viewers and
a cdplayer app (since these are trivial to do…)

you will be able get the source at my homepage:

http://www.buffnet.net/~goehrig/projects/SDL-sdlpl-1.00.tar.gz

I’ve only tested it on linux.

BTW if someone could give me some advice on compiling SDL-1.1.1 for
FreeBSD, I’d gladly get a port out asap.

			Dave Goehrig

Mattias_Engdegard · May 25, 2000, 1:47pm

case 3:
{
dword d = (dword) surface->pixels;
pixel=(*d)&0xffffff;
break;
}

This is incorrect; it will only work on little-endian boxes.

how to make it endian independant so ?

This should really be an exercise, but ok:

#if SDL_BYTEORDER == SDL_LIL_ENDIAN
pixel = *d & 0xffffff;
#else
pixel = *d >> 8;
#endif

Note that this works when you access the first pixel, since it we can rely
on it being 32-bit aligned.

ok dad
thats right…

Good boy!

Horizontal Scrolling: Easiest way?

SDL_UnlockSurface(surface); SDL_SetColorKey(surface,SDL_SRCCOLORKEY,pixel);–

SDL_UnlockSurface(surface);
SDL_SetColorKey(surface,SDL_SRCCOLORKEY,pixel);–