Path: chuka.playstation.co.uk!scea!pro1-142.barrie.connex.net!user From: skennedy@bconnex.net (Sean Kennedy) Newsgroups: scea.yaroze.freetalk,scee.yaroze.freetalk.english Subject: Re: Net Yaroze Tutorial Preview Date: Tue, 22 Sep 1998 21:27:14 -0500 Organization: Wooden Tulip Ltd. Lines: 104 Message-ID: References: <360587BD.5668FFB0@bigfoot.com> <36064067.123D@manc.u-net.com> <3606F3E4.6ECC48B8@bigfoot.com> NNTP-Posting-Host: pro1-142.barrie.connex.net Xref: chuka.playstation.co.uk scea.yaroze.freetalk:993 scee.yaroze.freetalk.english:2453 In article <3606F3E4.6ECC48B8@bigfoot.com>, Darco wrote: > Long. *sigh* Well. Perhaps it might help me get into DigiPen Institute > of Technology. If I show them this and they like it, then that might > help me out alot. (I feel tired already. But that's not gonna stop me) > Ho-boy... ;) > Don't Give Up. The road to Interactive Computer Entertainment careers is a long but fruitful one. The Digipen Institute may be the first in the many steps up the hill. > > Organisation of the display area should be a *massively* important > > piece of a Yaroze tutorial, and really needs a chapter all to itself. > > But I agree, the "this is a good place to put the screen" would make > > a good intro to it at this stage. An example diagram as an "aside" Hyperlink would allow a quick browse at the users choice. Just keep "crucial" information out of it. Win32 Help files are a good examples of Asides. > The basic introduction to the display hardware and VRAM is covered in > Lesson 1. (The lesson I posted was a partially finished version of > Lesson 2) A more indepth overview of the display hardware, including > double buffering, ordering tables, and such will be in Lesson 3. Then in > Lesson 4 we will go step-by-step through writing a sample program that > does something simple using what we discussed in Lesson 3, such as > displaying a rectangle on the screen using ordering tables. Great, Keep it as simple as possible. Use "Asides" sparingly to illustrate a concept. > When chapter 1 is over, I hope to have a version of the familiar "balls" > demos. (Except it'll probably have small squares instead. At least at > first... I don't want to go over sprites in chapter 1). Simply indicate that the squares are "run-time" sprites on the screen. > And I'm not sure what chapter this will go into, but I eventually want > to have a version of the Net Yaroze balls demo with colision detection, > gravity, scrolling backgrounds... The works. Eventually that is. And > from this process, hopefully the reader will learn something. > > Hmmm. personally I do almost all my RECTs as something like:- > > static RECT screen = {SCN_VRAM_X,SCN_VRAM_Y,SCN_WIDTH,SCN_HEIGHT}; {Blah Blah} > > optimising since last time I checked its output), and taking up about > > half the memory. > > But all this kinda thing is ultimately personal preference. Uh Oh, Avoid Personal Prefs in Newbie Docs.! > True, it may be faster and more code efficient. However this is a newbie > tutorial... Code needs to be as readable as possible rather than > optimized. Yep. > > While we're critisising, if a newbie doesn't know about "\n", they're > > *certainly* not going to know that the gcc "c" compiler understands > > c++ "//" comments... Though they could prolly guess that from the > > context! > Oh. ... Huh? I've always used both "//" and "/* */" for commenting... I > wasn't aware that "//" was exclusive to C++... I've just always done it > like that. My personal code makes heavy use of both comment denotors. I see both interspersed in a LOT of code examples I see on the net. I suggest using things like: NOTE: The // Comment content and /* Comment Content */ designators are for Comments in C/C++ > > I pretty much love it, really. The colour coding works (though I'd've > > used different colours ;) ) Oh, and the "to recap" cut'n'paste bit at > > the end is *essential*, coz I find interspersed code & discussion pretty > > difficult to follow as code. Bravo for remembering it. Optional discussion and code snippets are good so long as the font is adjusted accordingly. Using COURIER for code segments, and TIMES for discussion is a neat way of doing this. {In HTML 1.0 and 2.0 this was limited to "fixed-width" fonts and "proportional" font in HTML 3.0 I think that you can specify a common font.} > I'll also have a zip file for downloading, containing working source > that you can compile and run. No need to cut and paste. My own experience has found that re-writing the critical segments of code is FAR more valuable than cutting and pasting. keeping the code in "Snippet" form makes the user fill in the blanks. Just be careful when introducing new things, test the code build to see if it works. Don't do source code extractions, Newbies {including myself} get lost trying to put it together. Instead intersperse discussion like you have, and leave comments beside critical portions of the code intact. > Or maybe that's making it too easy... Perhaps it shouldn't be that easy. > Anyone have some input on this? > 'Darco Remarkably when you ask this, it means that you have a good balance. Great work. If there are graphics you want to try with this, let me know, and I'll do a few in Pshop and send you the JPEGS. -sean