Path: chuka.playstation.co.uk!scea!greg_labrec@interactive.sony.com From: dp310@earthlink.net (Brian Gilman) Newsgroups: scea.yaroze.beginners Subject: Re: A few requests Date: Tue, 13 May 1997 11:23:37 -0700 Organization: SCEA Net Yaroze News Lines: 55 Message-ID: References: <33788386.949380@205.149.189.29> NNTP-Posting-Host: pool052-max5.la-ca-us.dialup.earthlink.net X-Newsreader: Anawave Gravity v1.10 > I agree that we need to do several more examples that show the basics, > but I'll have to disagree with you on the manuals. I've done some work > with other console dev systems, and the documentation for Yaroze is as > good or better than the others I've seen. Yes, there have been (and > still are) some shortcomings, but they are being addressed and the > corrections and additions are being posted here. Ah, but your talking Apple's and Orange's. Zilog & Motorola CPU's are all extremely well documented, and systems that use them aren't nearly as capable as the PSX. There isn't a system before the current generation that hasn't been emulated on a PC by someone who had no access to special information. As a silly statement, if we had to program the PSX in R3000 assembly, we couldn't. I figure that you need to know at least the instruction set for that :p Also, there is a big difference between you and someone who has no prior console programming experince. I'm sure my post would be a non-issue if everyone who bought the Net Yaroze was used to reading Z80 code from hex dumps. In my logic, the documentation should be much longer and in-depth for something available to the public, and shorter for devolpers. Not vice-versa. > If you're having some specific problems, ask in one of the news > groups. There are several people here (Sony reps and not) who could > probably help you get started. Don't be shy about asking questions. > After all, none of us has been doing this for long. :), I have no questions. Most of the stuff I posted about makes little difference to me, since I'm past that point. I'm just relaying what would have made getting past that point easier, and what might make things easier for people who have less experince. > Actually, I find that more #defines makes the program easier to read. > For example, when setting the scale of a sprite to one, I use the > define ONE, not the constant 4096. I agree, but that's for my own code. IMHO code is a lot less readable by someone other than the coder when lots of #define's are used. > That might be nice, but it's going to be pretty hard to get all these > programmers scattered around the world to agree on the same standard > names. I can only speak for myself, but I try to make the variable > names self-explanatory. However, since I don't like to type any more > than necessary, I'd probably use WorldOT[]. Right, that would be hard. Instead, use search and replace :) > Please don't think that I'm dismissing your comments here. They all > make good sense. I try to standardize #defines, variable names and > function names in all my code; it makes cutting and pasting between > programs much easier. However, each programmer has his/her own take on > this stuff; it's like religon. I suspect that you'll be hard pressed > to get people to change too much. Your right, I wasn't implying that anyone change their general coding habits. When it isn't example code that others are going to be learning from, then do whatever you want. However, I think that examples are a special case, and need extra care. I didn't ask for anything that I couldn't do myself, if you want, I'll standardize the #define's and variable names for you.