Path: chuka.playstation.co.uk!scea!peter_alau@playstation.sony.com From: Elliott Lee Newsgroups: scee.yaroze.programming.2d_graphics Subject: Re: Different approaches to scrolling a tiled background Date: Tue, 08 Sep 1998 17:32:42 -0700 Organization: SCEA News Server Lines: 87 Message-ID: <35F5CCAA.169BA921@shell.jps.net> References: <35F3DCA5.3D5ADA21@easynet.co.uk> NNTP-Posting-Host: 171.70.208.195 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: Mozilla 4.05 [en] (Win95; U) Your approach may be memory-efficient, but it may just turn out to be slow. I'm working on something where I've calculated that the "world" will probably be a bunch of 2D tiles spanning maybe 128x64. If each cell takes a byte, then I only need 8K of RAM to hold the data. And, 256 sprites are probably more than enough to describe the world. ^_^ Plus, it's very easy to calculate which tiles should be on-screen and which aren't. While you may save quite a bit of memory with your approach, remember that each of your pointers are probably 4 bytes each and that will afford you about 1K worth of world tiling if you stick to the same 8K space. Then again, if your world is changing---e.g. you drive offroad and leave tire tracks in the dirt---you're going to be dealing with tiles being added/removed. That could mean the source of nasty pointer bugs plus slower calculations to resolve memory addrs. My biggest concern is that if your array gets corrupted somehow that you will end up generating memory faults. With an array, it's pretty hard to generate faults if you check your array bounds consistently. Plus, it's easier (for humans) to visualize and that may translate into easier debugging. Just some thoughts, - e! Phil Gooch wrote: > > I was just wondering how people handle the scrolling of a tiled > background, say for a 2-d driving game. > What I have done is break my array into sections, and then have an array > of pointers to different sections, rather than have a huge array > containing all the map data, avoiding all the duplications that would > ensue. > > E.g. say I have: > > char road01[][NUM_COLS] = {'1', '2', '0'...... > ... > } > > char road02[]NUM_COLS] = {'4', '1', '0'... > ... > } > > So I can then do > > char *mapData = {&road01[0][0], &road01[0][0], &road01[0][0], > &road02[0][0], &road02[0][0], &road02[0][0]. > &road01[0][0].....} > > This allows me to repeat sections lots of times without having to repeat > the data in the array, and also, depending on how the sections join up, > have a random map that is generated for each game, where the section > data is constant but the order, combination and number of sections can > be random. > > However, this makes the scrolling algorithm tricky because you need to > work out which section you need to display as well as which row of the > section's array. At any one time you could be displaying (allowing for > two offscreen rows, one just off the screen at the top, and one just off > the screen at the bottom) data from up to 3 sections at once. > > I've solved this though, but what is causing me a bit of grief is > collision detection, because at any instant I need to be able to convert > a sprite's screen coordinate (whether it is on-screen or way off-screen) > into a mapData coordinate that tells me which section it is on as well > as which row and column of the section, all while the screen is being > scrolled up or down. > > So this approach has some advantages but, for me, quite raises quite a > few programming problems. > > So, how do other people handle large array data sets for scrolling > worlds? Should I ditch my memory-efficient approach and just repeat the > data in one large array so I only need to worry about rows and columns, > or is there another way? > > Cheers > > Phil -- Mata ne, ... ... - e! ::' tenchi@shell.jps.net ':: (Protocol) :: ACiD -/- ACS -/- pHluid -/- Yaroze :: (Tenchikun) ::. http://www.jps.net/tenchi .:: ''' '''