Scrollery.

[plounted]

if i were to make an image, lets say 320 wide and 2000 long, how can i make that scroll as the background?
this would be for a shooter.

 

[reiboul]

if i were to make an image, lets say 320 wide and 2000 long, how can i make that scroll as the background?
this would be for a shooter.

I don't think that's a good idea to have such a large image...

(sorry if I can't help you more )

 

[sam fisher]

you could put it to screen and increment the x value of the image. That would make it scroll from right to left.

 

[purple_goat]

if i were to make an image, lets say 320 wide and 2000 long, how can i make that scroll as the background?
this would be for a shooter.

animated gif? (in flash)
what I'm saying is: the gif be [say] 320x240 but have it scroll (?)

 

[plounted]

i want to have a scrolling backgorund.
therefore, as time passes, i need the background to pass as well.
changing the x would most likely work the bes, but i didnt know if there was a special way to do it.

 

[PokeParadox]

I'd have tiled background segments. For example: say you have different 320x240 bgs but the edges match to be able to transition.

You could have on background with a field, then at a certain point have a background with a tree, then two trees. (course fields and trees are just for example...)

You just keep scrolling these past and transition between them. You won't use as much ram then.

 

[slaanesh]

Arcade games store images (sprites or background gfx) in either 8x8, 16x16 or in some cases 32x32 graphic elements. This is done for two good reasons; economy of storage (ie repeated graphics are only stored once) and it's fast to redraw the screen as generally each element would only need a few bytes changed to "draw" the object to the screen. Arcade machines tend to have specialized hardware to deal with this however you can still use a similar principle to achieve the same result.
MAME emulates these principles and achieves pretty good results in doing so. Screens are composed of a map and you draw the screen according to where you are on the map.
For example the GP2X has a 320x240 screen, in terms of 16x16 blocks that would be 20x15. If you want a really large vertical scrolling area you prepare (say) a 20x200 map. Each of these (20x200 = 4000) values holds a number which is an index to the graphic which appears in that position. In effect its like a large jigsaw puzzle. You would of course need to draw each 16x16 block so that they naturally fit next to each other.
You will also need to keep track of where you are on the map, incrementing this will "scroll" the map.
Assuming just vertical scrolling, at position 0 you are at the bottom of the map, at position 30 you have scrolled 30 pixels along already.

Example (ASCII ART WARNING!)
The tower of numbers represents your map of numbers.

1234
5678
9123
2345--\
5678 | current visible screen
1123--/
4235

I hope you get the idea!

 

[StarG]

If its some recurring statical background you can blit the visible part of your complete background into screen.

1) prepare complete background in the vast depths of memory
2) obtain / recalculate the currently visible part
3) blit the currently visible part to the offscreen buffer - maybe you have to split it into 2 parts if the current view crosses the boundary
4) put hud elements, ships and enemys on
5) swap buffers
6) goto 2

this is quite simple to prepare and program but memory hungry so consider the solution slaanesh offered.

I can recommend reading books about.
Maybe even old dustcatchers like andre lamothes "black art of 3d game programming" in which all major details of game programming are covered. (its very old but really helps as it concentrates not on getting apis working but on direct work)

 

[plounted]

just a thought, but i sort of suck at programming at this point.
im still in very alpha stages.

but any help would be great.

so im going to take all of this in mind and let you know if i need anything else.

but thankyou.

 

[HEP]

You don't have to adjust the x-position, but the source rectangle. Take a look at this code:

SDL_Rect rcDest;
SDL_Rect rcSrc;

rcDest.x = nPosX;  // these are the normal coordinates where you want 
rcDest.y = nPosY;  // the picture to display (independent from scrolling)
rcSrc.x = nScrollX;  // the horizontal scrolling coordinate
rcSrc.y = nScrollY;  // the vertical scrolling coordinate
rcSrc.w = nWidth;  // the width and height of the picture excerpt you want
rcSrc.h = nHeight;  // to display. If you want fullscreen they are 320 and 240
SDL_BlitSurface(pSurface, &rcSrc, pScreen, &rcDest);  // Blit the surface to the screen
if(nScrollY < 2000 - nHeight)  // scroll only down if we're not yet at the bottom
  ++nScrollY; // scroll down

This is what your drawing function could look like. The example scrolls down until it reaches the bottom. nScrollX and nScrollY are used to do the scrolling. Comments should explain it, I think.

 

[Racemaniac]

as long as we're talking fenix, the huge background is best i'm afraid.

fenix has no optimalisation of any kind for tiled graphics, so it'd become insanely heavy in the way fenix works, and is undoable.

and to make the big pic scroll, fenix has built in scrolling support, you can find some example code i made about scrolling on fenix on fire

if you want to make tiles, to reduce the space your game takes on the memory card, i think the only way is to assemble it into a large bitmap when you load the level, but if i remember correctly, it was pretty slow when i was trying such things (that was gp32 ofcourse, maybe the gp2x is fast enough to assemble the map in fenix fast enough not to become a huge loading time)

 

[plounted]

id rather do a big background personally.
can i get a link to that code you wrote?

 

[Racemaniac]

id rather do a big background personally.
can i get a link to that code you wrote?

just go to fenix on fire, it can't be hard to find ^^

 

[Vimacs]

hm, couldn't you mess with the rgb windows to do some inexpensive scrolling? though i think the max width is 600 something.

 

[HEP]

as long as we're talking fenix, the huge background is best i'm afraid.

Who said that we are talking about Fenix? The OP did not mention it.
If you always draw the the complete background, although only a part of it can be seen, it will be too slow.

 

[woogal]

as long as we're talking fenix, the huge background is best i'm afraid.

Who said that we are talking about Fenix? The OP did not mention it.
If you always draw the the complete background, although only a part of it can be seen, it will be too slow.

Why would he need to mention it? This is the Fenix forum.

 

[Racemaniac]

as long as we're talking fenix, the huge background is best i'm afraid.

Who said that we are talking about Fenix? The OP did not mention it.
If you always draw the the complete background, although only a part of it can be seen, it will be too slow.

1. as woogal said, this is the fenix forum, so guess
2. it's how fenix works. if you make tiles, every tile will be a process, and fenix can't handle that many processes (at least not on a gp32/gp2x). it has however got support for scrolling backgrounds, and i don't know if/how it optimalises it....

 

[HEP]

Why would he need to mention it? This is the Fenix forum.

Oops...How embarassing... :unsure: :wacko:
I got here through the portal and the caption was "General Forums", so I didn't notice it.

 

[yonni]

Fenix has inbuilt scroll commands, you can have up to 10 scroll windows at once (numbered 0 through 9).

Firstly, use this function to make a scroll window and display it:

Start_Scroll(int num,int fpg,int fore,int back,int region,int camset);

num - the number of the scroll window (0 through 9)
fpg - the id of the fpg file for the graphics (or 0 if they are loaded with load_map/load_png)
fore - the forground image
back - the background image (both fore and back can scroll independently)
region - the region in which to insert the scroll window (or 0 if no regions are used)
camset - +1 if fore is horizontally cyclical
			  +2 if fore is vertically cyclical
			  +4 if back is horiz cyclical
			  +8 if back is vertic cyclical
			  eg. 12 means only the background is cyclical (in both planes).

It sounds like you want camset to be 0 (neither graphic is cyclical, it just scrolls with one instance of the graphic).

similarly, you can stop a scroll window with stop_scroll:

stop_scroll(int number)

number - the scroll window number to stop

and you can move fore/back around with these variables:

scroll[number].x0 - fore x position
scroll[number].y0 - fore y position
scroll[number].x1 - back x position
scroll[number].y1 - back y position

All processes to be shown in the scroll window must contain this line of code:

ctype = c_scroll;

NOTE: this means that the coordinates of the process will refer to the coordinates relative to the scroll window, not the game window.

It may be easier to move the scroll window with this handy trick:

scroll[number].camera = *a process id*;

This will mean that the scroll window will automatically follow the process of which id you pass to it. So if you put this line of code into a process:
scroll.camera = id;
it will automatically follow that graphic's position within the scroll window (id is a local variable holding the process' id)

If only one scroll window is used (scroll number 0), there is no need to put the "[number]" bit in, simply use scroll variables as:

scroll.*variable*;

With a graphic so large however, fenix may give up and die, having a cyclical background graphic is much easier and you can change the appearence by adding processes within the scroll window.

I hope this helps, it is best to spend time experimenting with these functions. Don't hesitate to ask if you don't understand anything or need help.

 

[Quiest]

check the scroll.zip here. I hope it helps, you need a little knowledge of Fenix (or structs in Fenix).