Path: chuka.playstation.co.uk!scea!greg_labrec@interactive.sony.com From: jamin1@psu.edu (Jamin Frederick) Newsgroups: scea.yaroze.programming.2d_graphics Subject: Re: pixels Date: Tue, 08 Jul 1997 20:52:59 GMT Organization: SCEA Net Yaroze News Lines: 103 Message-ID: <33c29ffb.95879061@news.scea.sony.com> References: <33c122d9.168381829@news.scea.sony.com> <33c14f5a.23551302@205.149.189.29> NNTP-Posting-Host: nb4ppp107.cac.psu.edu X-Newsreader: Forte Free Agent 1.11/32.235 On Mon, 07 Jul 1997 20:36:33 GMT, mperdue@iquest.net (Mario Perdue) wrote: >On Mon, 07 Jul 1997 17:13:32 GMT, jamin1@psu.edu (Jamin Frederick) >wrote: > >>Hi, how's it going? I'm working on my pixel-by-pixel collision >>detection algorithm, and I've run into a problem of actually trying to >>access pixel data of sprites. It seems like I won't be able to access >>the data the lies in the video memory once it has been transferred >>from the main memory, since there are no api calls to do this, plus, >>trying to access this memory probably interferes with the video >>syncing and drawing mechanism. The only thing left to do is use the >>pixel data that's been in main memory from the loaded TIM. >>The only thing is, that this memory could be otherwise used for >>something else. > >You can transfer image data from the frame buffer to main memory using >StoreImage(). > Right, but wouldn't StoreImage() be too slow to be doing it every time a sprite bounding-box collides with another sprite? (This is when the pixel-comparison algorithm comes into effect). In general, are the functions that tranfer memory (fb to mm, mm to fb, and fb to fb) too slow to be doing at every frame or so? I've heard that LoadImage() is fast enough to be doing animation with, so that you can just blast your stuff from main memory onto the display buffer...why even use frame buffer memory then (besides linking up sprite and background images)? >>So I have pixel data both in the video memory AND in main memory, >>which is sort of redundant, but main memory is the only way to go. >> >>My question is, is there any way to replace data that's already been >>loaded from siocons? For example, if I loaded my TIM at 0x80090000, >>and then during program execution, I transfer this from main memory to >>video memory, so that I no longer need what's at 0x80090000, is there >>any easy way to reload data back into this position for use? > >Since you have a pointer to the memory in question, you can pretty >much do anything you want with it. I'm told the Japanese web site has >a program for loading overlays, but I havn't seen it. Is it easy? >..Define easy. :^) > By "overlays", you mean modular data that can be loaded in at will, such as game levels, correct? There would need to be some I/O done with the PC there, but the only way I know of is the CW lib functions, but I haven't messed around with them yet. >>The reason I want this to be answered is that I guess I'm planning to >>make my pixel-by-pixel algorithm based on pixel data in main memory, >>and I don't want it to be a silly approach. I mean, if someone >>actually does want to reclaim use of that main memory, that is, then >>the algorithm will totally fail! >> >>In general, is it a waste of space to have all your image data sitting >>in main memory? > >That depends on the program. If you're short of memory, then it's a >waste. If you've got memory to spare, then it's not a waste. > I'm sure not short of memory. I'll just do the main memory thing, I guess. Speaking of memory, I've been sticking all my stuff at 0x80090000. This is the bottom of what we get to use. This grows upward with picture and sound data and stuff until it hits something...but what's up there, the program stack? I don't know what's going on up there towards the top of the mapped main memory...the top of main memory, according to the manual, is 0x801fff00. You can tell your compiler to put the program at, say, 0x801e3000. But this gets loaded upwards, starting at 0x801e3000, up to the top 0x801fff00 (adjust this according to your executable size). So your program stack grows downwards from 0x801e3000, until it hits data? What about the resident "bricks" loader program...where's that stored? >>Is there any way your program heap can plow past some >>of this data, once it's been utilized? Or perhaps have a spot just >>for incoming data and use I/O to reload into that spot during program >>execution...which only CodeWarrior people can do at this point? > >As I said above, you've got a pointer to this area and you own the >machine (i.e. you don't have any other programs to share resources >with.) You can do whatever you want with it. Right. It's just that if I make a library out of a set of routines, I have to make sure the user know what effects on memory the functions have. The user has to know that his TIMs will have to remain in main memory for the functions to work. --Jamin > >Mario >