Path: chuka.playstation.co.uk!news From: sceetech Newsgroups: scee.yaroze.programming.2d_graphics Subject: Re: GsIMAGE pmode 8 (LARGE) Date: Mon, 07 Apr 1997 14:15:01 +0100 Organization: SCEE Lines: 89 Message-ID: <3348F355.6E8B@interactive.sony.com> References: <01bc289b$f6314fc0$c793989e@fourny.demon.co.uk> <33422052.4C18@interactive.sony.com> <01bc28b3$29e10100$c793989e@fourny.demon.co.uk> <33450DEC.7AE5@interactive.sony.com> <01bc29a2$9bf69300$c793989e@fourny.demon.co.uk> Reply-To: ps_yaroze@interactive.sony.com NNTP-Posting-Host: 194.203.13.10 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: Mozilla 3.01 (Win95; I) Since the last reply, Stuart has tried the code fragment and been unable to make it progress beyond the MW bload. Given the current temporary hitch in the robustness of that function, you could build a simple test program for your code fragment and test it using GNU/siocons; this should say if the problem is in code or in memory downloading. Or use other TIM initialisation procedures .... Good Luck Lewis grim wrote: > > Lewis wrote: > > > Firstly: code generated should be independent of the difference > > between siocons and CodeWarrior, so that people using either > > can run it easily. Hence, ALL CodeWarrior-specific functions > > should go in special procedures, only to be called > > (eg) ifdef CODEWARRIOR. Failure to make a clean separation > > will prevent people without Codewarrior from using your > > code. > > Is the PC-side of MWbload not supported in SIOCONS, only in PSCOMUTIL? I > kind of assumed it was in both. MWbload is useful. I was going to use it a > lot because then I wouldn't have to manually keep a map of where everything > is going in memory which kind of makes me gag. > > > but my real suspicion is the combination of > > memory loading only just before its use, > > and dubious casting for GetTimInfo; the memory loading > > MAY be implemented as non-blocking process, > > in which case the loading won't finish until > > DrawSync(0), with clearly disaatrous consequences. > > I tried putting in a DrawSync(0) after MWbload but it didnt affect > anything. I also changed the casting to make location a pointer to unsigned > long (so the GetTimInfo offet becomes 1). Made no difference > > > Remedy: do loading into main memory way before anything else > > and make certain in finishes before using anything; > > The main memory loading and texture page creation both have to get done in > the > initialisation, so I can use the texture page. I think you are on to > something with the loading images not finishing. When I accidentally > deleted the TIM file (so the load failed), LoadImage did not crash. > > > and for debugging, it is usually Much quicker to use > > printf to find the values of all things (and the > > point at which crash occurs) than it is to use the debugger. > > Print out all things and you're usually bound to find it; > > stepping through the debugger, it's very easy to not check > > all variables. > > IS the printf buffer to the PC flushed after every printf? I've had bad > experiences with this sort of thing before. I was actually using the > codewarrior debugger which has a rather nice watch window with all the > current variables in it. However, I have inserted some printfs. > > for information, the values printed are; > bytes=576 > x=640 > y=256 > w=8 (=32/4) > h=32 > > I'm going to go to Metrowerks support with the problem. I've extracted all > the lines that did anything in the C++ and turned them into a C file (since > I dont think they even bothered compiling any C++ files before releasing > the compiler). Could you look over the file and TIM and make sure the > problems not with Sony? (like the TIM file not being the correct format, > although in TIMutil its OK) > > Graeme > > Name: Small.tim > Part 1.2 Type: unspecified type (application/octet-stream) > Encoding: x-uuencode > > Name: Main.c > Part 1.4 Type: unspecified type (application/octet-stream) > Encoding: x-uuencode