Net Yaroze Frequently Asked Questions (FAQ)

Confidential documents, images and information by Sony and miscellaneous hackers for the Net Yaroze
Post Reply
User avatar
Shadow
Verified
Admin / PSXDEV
Admin / PSXDEV
Posts: 2564
Joined: Dec 31, 2012
PlayStation Model: H2000/5502
Discord: Shadow^PSXDEV

Net Yaroze Frequently Asked Questions (FAQ)

Post by Shadow » June 25th, 2012, 1:29 am

Net Yaroze FAQ
==============
V 1.0 (97 01 17)

(c)1997 Sony Computer Entertainment America (SCEA)

Compiled by: Bill Rehbock, John Phua, Don Thomas,
Brian Dawson, Greg LaBrec, Mike Fulton,
Peter Alau, Sarah Lodge and Molly Smith.

Information herein applies to North America only. Any
tradenames used within this document are trademarks or
registered trademarks of their owning companies.

===============================================

NOTE: MOST COMMON QUESTION OF ALL...
How do I register my interest in Net Yaroze?

E-Mail: [email protected]
(U.S. and Canada only)
[email protected]
(All of Europe and Australia
including France, Germany, Norway,
Switzerland and U.K.)
[email protected]
(Japan)


Sections
--------
I. HOW, WHAT, WHEN, WHERE
II. COST, PAYMENTS, CONDITIONS
III. TECHNICAL
IV. COMPLETED WORK
V. WHERE DO I SIGN-UP?


I. HOW, WHAT, WHEN, WHERE
----------------------

Q. What does Net Yaroze mean? How is it pronounced?

A. YAROZE (yarozei), or phonetically (ya row zey) vb. means
"let's do it together" or "let's work together" in
Japanese origin. The term embraces the Net Yaroze concept
of getting members to work together and share their work
to reach meaningful objectives in what they do.

Q. When will Net Yaroze be available in the U.S. and Canada?

A. Net Yaroze is currently targeted for release within the
U.S. and Canada by late March 1997. It is possible this
may change. Interested persons should make certain they
register their interest so that they are automatically
updated when news becomes available.

Q. Is Net Yaroze planned for Mexico?

A. We want to support and service programmers in Mexico,
however, plans to do so are not in place at this time.

Q. Can I license the U.S. version of Net Yaroze to be
shipped outside of the U.S. or Canada?

A. Sony Computer Entertainment America will not accept
international transactions. Interested persons outside of
North America will be referred to other Sony facilities
for support if they exist for that region. See the answer
to the most popular question of all at the top of this
document.

Q. What is the difference between Net Yaroze and a
professional developers' program?

A. SCEA's professional developers' program is much more
intensive. The commercial package includes higher level
hardware/software tools, hardware with greater RAM
capacity, an in-depth array of on-site assistance and
on-call technical help.

Q. How will the Net Yaroze system differ from the Japanese
version?

A. All the basic elements provided in the Net Yaroze program
are universal with the exception of translated text
within support materials and the Internet address where
members go for support.

Q. Hardware-wise, how is the Net Yaroze unit different from
the North American PlayStation which is sold in stores?

A. The retail (grey) North American PlayStation hardware
unit can only read commercially developed PlayStation
game titles from licensed PlayStation developers and
publishers. The Yaroze hardware offers no territorial
lock-out, which means that that it can play both PAL
(Europe) and NTSC (Japan, U.S.) PlayStation discs.
However, the user will need a multi-format TV to do this
properly.

Q. Will Net Yaroze be available in stores?

A. Net Yaroze is an extension of the services provided by
SCEA's Research & Development department. In many ways,
Net Yaroze members become a part of SCEA's R&D
activities. This unique relationship with Sony on a
developer level will not be available from any
independent retailer to insure members get support direct
from SCEA and no where else. In short, Net Yaroze is not
a commercial product and will not be available from
retailers.

Q. Where can I get support while a member of Net Yaroze?

A. Net Yaroze integrates a World Wide Web Site with support
areas, file download areas, message areas and more. No
live telephone support is available as part of the Net
Yaroze program. Access to the Web Site is limited to one
year and renewable for a modest fee.

Q. I have a Web Site and want to interview someone about
Net Yaroze. Who should I contact?

A. Contact Molly Smith by e-mail at:
[email protected]

Q. May I post this FAQ file on my web site?

A. This document may be redistributed in whole in any
environment that is supportive of Net Yaroze and Sony
Computer Entertainment America.


II. COST, PAYMENTS, CONDITIONS
--------------------------

Q. How much does Net Yaroze cost?

A. Net Yaroze is anticipated to be made available for under
$1,000 in North America plus applicable taxes and
shipping. Other costs may be associated to using
Net Yaroze if the developer does not have other tools
that may be required such as a personal computer or,
perhaps, a more robust C compiler than the one provided.

Q. Can I save any money if I already own a PlayStation?

A. The Net Yaroze black PlayStation is different from those
sold in stores. It is not interchangeable for
development purposes.

Q. Can I purchase more than one Net Yaroze PlayStation?

A. The unique PlayStation designed for the Net Yaroze
program is not for sale. It is only available as a
licensed tool from Sony Computer Entertainment America.
It is possible for one individual to obtain more than one
for unique applications, however each one must be
registered separately and all terms and fees remain the
same for each.

Q. Can I purchase the Net Yaroze PlayStation for resale?

A. Net Yaroze is a developers network available and serviced
directly by Sony Computer Entertainment America. It will
not be licensed to any party for the purpose of resale.

Q. So, I can only sign-up for Net Yaroze from Sony Computer
Entertainment America?

A. Within the United States and Canada, yes. Members will
demand and expect support tools which can only be made
available under license directly from SCEA.

Q. Why does Net Yaroze cost as much as it does?

A. Net Yaroze is an economical version of professional
packages which are licensed for many, many thousands of
dollars. Net Yaroze includes all the essential elements
of a comprehensive development package plus support tools
have been streamlined to bring the price down to a level
that dedicated enthusiasts and aspiring developers can
afford. Net Yaroze is not a toy. It should be considered
only by those people wishing to seriously engage in
software development projects.

Q. Will SCEA accept planned payments?

A. Sony Computer Entertainment America will only ship
Net Yaroze products when paid in full. SCEA will not have
a financing program available.

Q. What forms of payment will SCEA accept?

A. It is anticipated that American Express, Discover, Visa
and MasterCard may be used to pay the required licensing
fees. Of course, money orders and cashier checks are
always welcome.

Q. Is Net Yaroze refundable if I don't like it?

A. Net Yaroze is not a mass market consumer item and will
not be available on any trial basis. SCEA will stand
behind every unit from a manufacturing point of view,
honoring any warranty (90 days) issue that may arise. On
the other hand, Net Yaroze is a license. The black
PlayStation is just one small part of the entire
agreement to share information. It is not refundable and
members are held accountable for their agreement to
protect proprietary information shared with them. Those
interested in Net Yaroze should consider their investment
carefully in advance.


III. TECHNICAL
---------

Q. What else is required to develop software using
Net Yaroze?

A. A 486 DX2 66MHz IBM-compatible personal computer with one
or more serial ports, 28.8 bps speed modem, an Internet
connection, 2X CD-ROM, 10MB of hard disk space, 4MB of
RAM, mouse and an SVGA monitor is minimally required for
Net Yaroze. In addition, members will need to be familiar
with the operation of such a computer as well as a basic
background using the C programming language and the
ability to access the Internet and the World Wide Web.
SCEA does not offer any training for using a computer or
the use of the programming language.

Q. Why 66MHz? How about on slower systems?

A. We recommend a minimum of 66MHz for optimum performance.
Choosing any configuration other than the minimums
recommended are at the developer's risk.

Q. Can I use the Yaroze system on my Macintosh?

A. Yes. The Net Yaroze system can run on an Apple Macintosh
with the aid of a complete development environment called
Code Warrior designed by Metroworks Software. More
information will become available soon.

Q. Can I use international CDs on a Net Yaroze PlayStation?

A. One of the "bonus" features of the black Net Yaroze
PlayStation is its ability to play software distributed
anywhere in the world.

Q. Can anyone with a PlayStation play the games I write?

A. Net Yaroze applications are only capable of being
executed by other Net Yaroze members who have a black
developers' PlayStation; however, the use of Net Yaroze
applications will be strictly subject to the terms of a
license agreement. It will not be possible to develop,
publish and distribute software created by Net Yaroze by
circumventing SCEA's established quality guidelines
applicable to commercial products that are sold through
retailers.

Q. How long does it take for a competent person to learn "C"
as a programming language?

A. That's very similar to asking how long it may take to
learn to speak French (unless you already know it). It
depends on your background, how good you want to be, how
much time per day you allocate to the learning process
and what learning skills you have. Please do not purchase
Net Yaroze to learn C. You can learn the same C on a PC
then consider applying your skills to dedicated platforms
at a later time. There are no components of the
Net Yaroze package to teach the use of C.

Q. Why is "C" the development language on Net Yaroze instead
of C++?

A. C++ may be used, however, C is usually more efficient in
a game programming environment where active programming
space may be an important issue.

Q. Is it true that the code for each Net Yaroze program
developed cannot be greater than 3.5 MB?

A. Primary RAM in Net Yaroze is 2 megabyte PLUS there are
secondary RAM locations that grant programmers up to
3.5 megabyte of working space. Game code, graphics,
audio samples and run-time libraries are limited to
3.5 megabyte because Net Yaroze drivers must be
installed. There are many commercial PlayStation titles
that are entirely RAM-resident and could have been
developed with Net Yaroze while using the CD strictly to
spool Red Book audio.

Creative developers apply compression and run-time
techniques that accomplish virtually anything they strive
for. Again, Net Yaroze can be used as a professional
tool, but it is not intended to be as robust as much more
expensive machines.

Q. How can Net Yaroze programs be made to run on a normal
(grey) PlayStation?

A. Net Yaroze participants can share their work with other
Net Yaroze members throughout the world by posting that
work on SCEA's designated server, Web Site or any other
location authorized by SCEA. The standard consumer
PlayStation is not designed to run Net Yaroze titles
directly. All commercially available PlayStation
titles are developed by "licensed developers" and
published by "licensed publishers" using a specialized
professional PlayStation development environment. Of
course, Net Yaroze members can eventually apply to become
a fully licensed commercial developer at later time.

Q. What kind of software can I develop that is most likely
to be published commercially?

A. This is hard to answer. On one hand, there seem to
be enough baseball games already. On the other hand
someone will create a new baseball game like none other
before. Successful games seem to be those that offer a
high degree of immersion and virtual world interaction.
Sports games need to be fast and lifelike. Fantasy and
arcade games need to be visually stunning and full of
surprises. Some developers start with a remake of an old
favorite and hope they can acquire a license later or
change it enough to be different such as Doom II or Duke
Nuke 'em. Other developers begin with a premise that some
completely new idea is marketable such as Tetris, Klax or
Zoop.

Q. Is the link cable supported in hardware and software?

A. There are two links that may be referred to by this
question. There is the serial link to the PC for the
Net Yaroze package and there is the game link cable
intended for head-to-head gaming between two different
PlayStations. In either case, Net Yaroze does not include
library functions to directly address either link
described above, but determined Net Yaroze members may
likely hack out solutions if they feel their applications
would benefit.

Q. Can I develop a networked application with the Yaroze?

A. Creative and experienced developers will accomplish many
things using Net Yaroze tools. Many things are possible.
That's what makes a talented developer valuable.

Q. We are mainly interested in applications of the Yaroze
outside of games, mostly visualization applications using
this technology. Is there any restriction on development
outside of games?

A. We hope the Net Yaroze program will allow a lot of
freedom in creativity in regard to what content will be
created. SCEA does not place restrictions on Net Yaroze
members as to what kind of applications to develop.

Q. Does Net Yaroze interface with any memory cards?

A. The Net Yaroze package includes the tools needed to
interface with PlayStation compatible Memory Cards which
are used in the slots above the controller ports just as
they are on the commercial versions of the game system.

Q. Can we access the CD to play audio and/or video?

A. During the boot-up of Net Yaroze, a special CD is
required on the PlayStation that contains information for
the system. After boot-up, the PlayStation CD may be used
to play Red Book audio from a standard audio CD.

It may be possible to control the CD-ROM on the PC,
however, it would be up to the developer to devise such
protocols if practical.


IV. COMPLETED WORK
--------------

Q. Who owns the rights to software developed written using
the Net Yaroze system?

A. The original author retains legal ownership of all source
code that he or she creates as part of Net Yaroze except
as protected by applicable copyright law. For instance,
users who create copies of Crash Bandicoot or Asteroids
cannot assume rights to that work. Individual authors are
legally responsible for the work in terms of infringement
of copyright, etc.

In particular, source code can be freely shared among
Net Yaroze members as desired by its creators -- in
accordance with their agreement with SCEA. Indeed, a
cornerstone of Net Yaroze is the concept of members
sharing their work and ideas, and participating in joint
projects. Note that distributed code through the
Net Yaroze program can only be downloaded by other
Net Yaroze members throughout the world. To formally
publish software for all PlayStation owners, Net Yaroze
members will need to look at becoming licensed as
commercial developers.

Q. Will my software be published commercially?

A. We hope to publish commercial products containing
software developed through the Net Yaroze program;
statiscally, however, it is not very likely that any one
project will be published.

Even a great number of projects which begin as commercial
projects never make it to store shelves. It would be
misleading to promise a great likelihood, but many of the
"big guys" do have modest beginnings. Bear in mind that
commercial software must be compelling and not infringent
on anyone else's copyrights.

Q. Is there any interest by Sony in working with companies
to develop specific applications?

A. SCEA also offers a professional developer program.
Serious developers should consider whether a hobbyist
grade package really fits their needs. SCEA will not be
looking to partner with development programs originating
from the Net Yaroze program. When commercial grade work
evolves from Net Yaroze members, SCEA will counsel with
the developer on an individual basis.

Q. Where should I start if I'm not a programmer?

A. If you are not presently a programmer, Net Yaroze will
probably not be for you right away. The best thing to do
would be to purchase some books on programming and a
BASIC or C programming package for development on the
computer. You may wish to look into some local college
courses that may be offered.


V. WHERE DO I SIGN-UP?
-------------------

Q. Where can I go for more information?

A. People interested in Net Yaroze can register their
interest by e-mailing their name, address, phone number
and email address to:

[email protected]

Sony Computer Entertainment America is also developing a
Web Site in which users can obtain more information about
Net Yaroze. The address of this site will be announced
soon. See the top of this document for registering
interest in other parts of the world.

### END OF FILE ###
Development Console: SCPH-5502 with 8MB RAM, MM3 Modchip, PAL 60 Colour Modification (for NTSC), PSIO Switch Board, DB-9 breakout headers for both RGB and Serial output and an Xplorer with CAETLA 0.34.

PlayStation Development PC: Windows 98 SE, Pentium 3 at 400MHz, 128MB SDRAM, DTL-H2000, DTL-H2010, DTL-H201A, DTL-S2020 (with 4GB SCSI-2 HDD), 21" Sony G420, CD-R burner, 3.25" and 5.25" Floppy Diskette Drives, ZIP 100 Diskette Drive and an IBM Model M keyboard.

User avatar
Rubber131186
Interested PSXDEV User
Interested PSXDEV User
Posts: 9
Joined: Aug 14, 2018
I am a: Very Amateur Programmer, Gamer.
PlayStation Model: Net Yaroze
Location: England

Post by Rubber131186 » April 6th, 2022, 9:22 am

Net Yaroze Frequently Asked Questions 2 (FAQ2)
Found this and thought it would be useful posted here.
Original web link https://www.engr.uvic.ca/~seng499/Faq1.htm

Path: scea!hobbes
From: [email protected] (Jamin Frederick)
Newsgroups: scee.yaroze.programming
Subject: New Yaroze Dev FAQ
Date: Mon, 29 Jun 1998 22:51:52 GMT
Organization: SCEA News Server
Lines: 1445
Message-ID: <[email protected]>
NNTP-Posting-Host: JAMINFRE.hq.ensco.com
X-Newsreader: News Xpress 2.01

I am reposting this (was in scea.yaroze.announce), apparently there's problems
writing to the SCEA server sometimes:

"I tried to post the mail I sent you before to the newsgroup
scea.yaroze.announce, but repeatedly got the error message 'permission
denied'. Is it a moderated group, or do SCEE members not have write
permission?"


***
Also, some extra info:

If you would like to help out with this FAQ, and you have an answer to one of
the questions, email me the question, along with the answer. I will include
it in the next version of the FAQ.

If you have a question, email it to me and I will also include it in the next
version of the FAQ. At the bottom of each new version I will post all of the
unanswered questions.

Sorry about some of the formatting (extra carriage returns), the ascii version
is a lot better.

Thanks!
[email protected]

***




From: [email protected] (Jamin Frederick)
Subject: New Yaroze Dev FAQ
Date: Mon, 29 Jun 1998 03:28:13 GMT
Organization: SCEA News Server

Hi, I've been working on a Yaroze Development FAQ. Here is a preliminary
version of it, and I was hoping that anyone that would wish to contribute to
it would let me know. I'm especially looking for answers to some questions
I've provided. It would be nice to have one common resource to go to for
any technical Net Yaroze questions, and I'm hoping this can be the start of
it. If there's any more questions/answers/comments you could provide, please
email at [email protected], thanks!


Jamin



Yaroze Dev FAQ 0.5


DEFINITIONS
-----------

In this FAQ, I would like to keep some definitions consistent so that there is
no confusion about terminology. If you are adding something to this FAQ,
please use the following conventions, thanks.



CLUT - color look-up table (4-bit or 8-bit)

display buffer (or display area or frame buffer) - portion of video memory
that actually gets displayed when the playstation is running

main memory - memory used for normal program storage and operation; also the
initial place for all incoming code and data when a yaroze project is
downloaded

model - the information making up the 3D representation of a game object; it
includes orientation of the primitives making up the object and their coloring
attributes

object - the arbitrary game object in a Yaroze game, which can have state
information attached to it, including sprite and 3D model references

OT - ordering table, the thing that sorts primitives such as lines, sprites,
triangles, and quads

texture - image for sprite or image for mapping onto a model

translucency - image or polygons appear "clear", meaning you can see through
it, but not invisible

transparency - doesn't show up at all, like the black background pixels of a
sprite

video memory - memory physically apart from main memory, used for image
storage and blitting to display area of video memory





TIM = image file
RSD = intermediate model file
TMD = playstation format model(s) file



TROUBLESHOOTING
---------------

See the following:
http://www.netyaroze-europe.com/yaroze/ ... rblsht.htm

1) Why is display from my Net Yaroze is completely grey and grainy / shudders?

"You may be running an NTSC configured program on a PAL configured monitor.
If you have the source, make sure that the program contains a
SetVideoMode(MODE_PAL) command and does not contain a SetVideoMode(MODE_NTSC)
command.

If you only have the executable, you can pick up the 'Screen Mode Changer'
(N!K/Napalm) from the Napalm hacker site (see link section) - it is able to
change executables which contain a SetVideoMode(...) command.
If, like me, you own an old Amiga monitor (1084/1084S/CM1884), an RGB to SCART

cable should do the trick - forget your old Amiga lead!" -- James Rutherford


2) I am trying to use graphic functions, but the screen locks / judders?

"These kind of effects can occur when you haven't allocated enough GPU packet
space." -- James Rutherford



ORDERING TABLE, SORTING, DISPLAY LOOP, ETC.
-------------------------------------------

1) How does priority work in the ordering table?

For each "primitive" that you "sort", you can give a priority of 0 to
2^MY_OT_LENGTH - 1, where 0 is the frontmost to the screen, and 2^MY_OT_LENGTH

- 1 is backmost on the screen. So obviously, increasing MY_OT_LENGTH gives
you more layers, or priorities, to work with.

If you sort primitives at the *same* priority, then the ones you sort first
are drawn last, meaning they will appear frontmost (at that priority level)
when displayed.


2) How does the display loop work? Do I sort stuff and update stuff every
single cycle, or what?


3) Why would you want to "turn off" a primitive/object for display instead of
just not sorting it?


SPRITES
-------


1) How do sprites work?

Sprites are simply references to rectangular regions in video memory that are
transferred to the "display" or "frame buffer" position in video memory when
they are "sorted" into the ordering table. So to make these images appear,
you must load textures (also called bitmaps or TIMs) into the video memory
first, and set up your sprites so that they reference portions of these
textures. So what the playstation does is simply make use of the information
stored in the sprite to "blit", or transfer, the pixels from one part of video

memory to the other. The reason it is done this way is that copying from
video mem to video mem is much faster than main mem to video mem.


2) What's the deal with video memory -- what's with the 4-bit, 8-bit, and
16-bit stuff?

TIM images can be specified as either 4-bit, 8-bit, or 16-bit (or 24-bit, but
that will be covered later) meaning that there are 4, 8, or 16 bits of
information, respectively, for each pixel in the image. However, all image
colors on the playstation (besides the 24-bit true color picture mode) are
displayed using 15 bits of information for the actual RGB values altogether --

5 bits for R, 5 bits for G, and 5 bits for B. However, unsigned shorts are 16

bits, meaning there's one bit left over when storing a color -- and this is
used for "translucency". This bit is '1' if the color is to be considered for
translucency (the docs call it "transparency", but I reserve this word for
something else). In other words, if a sprite or model texture using this
color would like to be translucent, then the translucent color will be
calculated. Otherwise, if the bit is '0', the color will not even be
considered for translucency, even if the sprite or texture feels like being
translucent. Note that there's a special case if each R,G,B value is 0, and
then the remaining bit is considered as something totally different -- which I

call "transparency", which is what is used to draw sprites without the black
background. In this case, the 0 and 1 stand for the color black to be
considered transparent or not when blitting the image.

So even though 16 bits are used for color, what about 4-bit and 8-bit TIMs?
Well, obviously, 4-bit and 8-bit TIMs take up less space than 16-bit TIMs,
which have a 16-bit value for each pixel, which is the actual color of the
image pixel. 4-bit and 8-bit TIMs work differently, though. Instead of using

their data bits for actual color, their data bits are used to reference a
*table* of 16-bit colors (remember, I said all object colors are really
16-bit). This is where the term "CLUT" comes into play. With 4 bits, 16
different CLUT entries can be accessed, and for 8 bits, 256 different CLUT
entries can be accessed. So 4-bit TIMs need to include a 16-value CLUT, and
8-bit TIMs need to include a 256-value CLUT. The CLUT values themselves are
16-bit, though, since they're referring to an actual color (well, actually
15-bit color...this is where some confusion sometimes arises). There are
tools to edit the pixel positions and CLUT positions of the TIM image in video
memory -- the TIM must include both the pixel information and the CLUT itself.

What about video memory? Well, the video memory is considered to be 1024 x
512 *pixels* -- where a pixel is an unsigned 16-bit color value. But the TIMs

contained in video memory (when transferred with LoadImage()) are actually
compressed, so that one "video memory pixel" takes up *two* 8-bit TIM pixels,
and *four* 4-bit TIM pixels. But remember, these pixels represent CLUT
look-up values, not actual 16-bit colors. So the TIM sprites are actually
"squished" in video memory, before they get to have fun in their decompressed
state over in the display buffer.

So what this means is that all of the sprites you see on the screen are
actually 16-bit pixels, not 4-bit or 8-bit CLUT pixels -- so what actually
happens when a blit occurs in the video memory with a 4-bit or 8-bit image, is

that the playstation automatically references the TIM's pixel color by
referencing the CLUT, and expands the pixel in its true color on the display
buffer. Pretty neat, huh?


3) How do the 24-bit images work?

4) What's (x,y), (mx,my), and (u,v) for in the sprite structure GsSPRITE?

The vars x and y refer to the sprite's position on the screen when it is
sorted to the OT. However, note that this x and y is with respect to the
sprite's center, which is denoted by the vars mx and my. These vars describe
the "center" of the sprite, which is the thing that gets placed at x and y on
the screen. This can be used if you want to refer to some other part of the
sprite as the center, instead of the upper left corner. Note that x and y can

be negative, or even larger than the screen, but this does not cause an error.

The OT compensates and automatically "clips" the sprite if it is partially or

even totally off screen.

The u and v refer to the *pixel* location of the sprite's upper left corner
with reference to its parent image (or texture page, or TIM). This can be
considered as if the sprite is already expanded from its original 4-bit or
8-bit compressed image size. So if my sprite starts on pixel 20 over and on
pixel 10 down in my TIM (just like it is painted, not worrying about
compression), then you just specify (u,v) = (20, 10). The playstation takes
care of the actual referencing in video memory, which takes into consideration

the compression and the texture offset in video memory, via the information
included in the TIM file.


5) Why are my sprites colored wrong?

Check the CLUT position in TimTool. All CLUTS must have unique positions in
video mem; if any of them are the same, one CLUT will get loaded over another,

using the color scheme of the other picture.


6) Why do my sprite textures look misaligned on the screen?

Double check the alignment of the texture in TimTool. Sometimes TimTool nudges

the texture down some, messing up what you might think is the proper offset
for the texture.


7) Why is my sprite losing pixels, especially along the vertical axis?

Change sprite scaling from 4096 to 4095.


8) How can I cycle colors on my sprites?

Use MoveImage() to make a copy in video memory of the CLUT of the image that
the sprite is using (to somewhere below the original CLUT), and between update

frames, use MoveImage() to copy colors from the copied CLUT into the original
CLUT, and the palette colors that are mapped to the sprite will give it an
appearance of cycling, if it's set up right. Check out Jamin Frederick's Pt
(Palette) library, which you can use to do this.


7) How can I do pixel-by-pixel collision detection on my sprites?

Typically, you can use just bounding boxes to see if sprites collide, but
sometimes it is necessary to get down to the pixel level. One way to do this
is to first see if the bounding boxes intersect, and if they do, then you can
do a pixel-by-pixel collision detection on the intersection rectangle of the
corresponding sprite images. The only problem is that these images are in
video memory, unless you haven't written over the images that are in main
memory when they originally were copied over from the com utility. In other
words, we don't really have byte-by-byte access to the video memory for close
comparisons, so we are forced to work with main memory. So once you get
access to the intersection rectangles of the sprite images, all you have to do

is compare corresponding pixels in the rectangles, one at a time, until you
get a "hit" (non-black) pixel from one image with a "hit" pixel from the other

image. However, this involves some rather tricky interpretation of the TIM
image data in main memory. This is implemented in the CollisionDetect()
function available on Jamin Frederick's web page.


8) What other methods of collision detection are there?

From a newsgroup discussion:

"Have you considered whether a pixel-by-pixel collision detect is *really*
necessary? It sounds so time expensive when you could be doing some freaky
special effects or better AI or something instead... I've used gobs of weird
hacks for collision detection in games, and I've always been able to find a
way around pixel-by-pixel. I thought I'd list some of them off:

0. Make your game so intense no one has time to notice that collisions are
pixel exact or not.

1. Simple shapes as hit regions - design the art so it fits well into shapes
that are easy to mathematically check against, like rectangles, circles, and
triangles.

2. Rotated simple shapes as hit regions - sometimes you've got objects that
can rotate - rotating a rectangle and checking it against another rotated
rectangle is still cheaper than pixel-by-pixel.

3. Stick Figures. Say you've got a figure like a character in a 2d fighter.
Make a simple stick figure that mimics the shape and motion of the sprite, ie:

a line for the head, a line for upper arm, lower arm, hand, two lines for the
torso, etc. etc. Then to do hit detect with the other character in the game
all you have to do is treat each line as a fat line and check them against the

fat lines in the other character. This has the advantage of letting you know
that the hand connected with the noggin.

4. Simple hierarchical shapes. Say you've got a top down view of the TOS
U.S.S. Enterprise on the screen. Do your hit detecting on a circle and three
rectangles, one for the two engines and one for the engineering hull, with the

rectangles of course rotated according to the orientation of the ship on the
screen.

5. Polygon shapes. Make a polygon outline that fits around the shape as
tightly as you'd like so that game feels good, then check for intersection
with collidable objects. If you design it right you can have one complicated
polygon collision shape which you test against some trivial shape like a
rectangle, but even still, poly-poly intersection is faster than
pixel-by-pixel, unless your sprites are really tiny, in which case suggestion
number 1. is probably the best IMO." -- Nick Porcino


IMAGES
------

1) Where do my images have to be aligned in video memory?


2) Do my sprites have to be in a special position within an image? I heard
they have to be on even coords or something.


3) Can I have more than one image on a given texture page? Can I arrange
several images next to each other within the texture page?


4) What's the max size of a TIM? Does it depend on the number of colors?

Max size of a TIM is 256 x 256 pixels, no matter how few colors it is. One of

the reasons is because sprites are referenced (u,v) via pixel offsets of
texture pages (or TIMs), and since u and v are both unsigned chars, the
biggest they can both be is 255, meaning sprite (u,v)s can only be from (0,0)
to (255, 255).


5) Where are the best places for CLUTs in video memory?

The typical convention is placement below the display buffers, since the area
is too small to have any decent-sized sprites down there.


6) How do you set up transparency for a sprite / texture?


7) How do you set up translucency for a sprite / texture / model / polygon?


8) What do the different translucency settings mean?

50% back + 50% polygon
100% back + 100% polygon
100% back - 100% polygon
100% back + 25% polygon


9) Do all the translucency settings work right?


10) Why do you have to specify translucency for GetTPage()?

"You can use GetTPage to calculate the tsb section of a tmd primitive
which does require the semi-transpency rate. Just & the result with 31
to get the Texture page number." -- Jim


11) How are texture pages numbered, and what is their ID?


12) Why doesn't LoadImage() work for large rectangles, close to the size of
the video memory (1024 x 512)?



BACKGROUNDS
-----------

1) How does the 16x16 pixel tiling work?

2) How do I make tiled backgrounds with sprites (bigger than 16x16 pixel
tiles)?

This is a nifty trick. The ordering table accepts information in the sprite
struct (GsSPRITE) that you give it as a *new* sprite, so that you don't have
to maintain the same information in the struct within a screen update. So
what you can do is keep changing the info in the sprite struct and sort it
into the OT. So to make a checkered background, for instance, you just need a

black square struct and a white square struct, and repeatedly sort them while

changing their positions.


3) How does the offsetting work -- I mean, how do you get sprites to scroll
around in the background and stuff (2D)?

It usually depends on the game, but here it goes...

First of all, let's draw a difference between a game object and a game sprite.

A game object is something in the game that has a state and presence, but is
not necessarily displayed. A sprite is just a representation of the object ON

THE SCREEN, and always refers to the thing being displayed. So an object can
easily have many sprites, each one representing different states of the
object, or an object's current position on the screen.

Ok, so first you set up a world coordinate system, where all of the objects
that you intend to have in the game are given a position in the world. So all

the changes that you give to your objects are with respect to the world
coordinates, NOT THE SPRITE COORDINATES. The reason for this is that the
sprite coordinates can be calculated from the object's position in the world
with respect to the SCREEN's position in the world. That's right -- you
consider the "game screen" to have a position in the world as well, so that
when you want to "scroll around" the world, you're just moving the screen's
position around in the world, and the sprites that get displayed on your
screen are just a result of them being around the screen when it gets close to

them in the world.

So for instance, if you chose your world to start at (0,0) in the top left
corner, then you could assign objects coordinates like (8,20) or (67,258) or
(600,780) or even (4563,23453), depending on how big you want to make your
world. Of course you're limited by how large your numbers can get, which for
an unsigned long (32-bit) is 0 to 4,294,967,295. So just imagine that you
have a bunch of (rectangular) objects positioned in your world like this
(usually when you're referring to an object's world coord, it is the upper
left corner of its rectangle, at least in this example) and think about a
rectangular, 320x240 screen, moving and scrolling around in the world with
them (again using the upper-left corner pixel as the world coord). Now to
get them to be on the proper position on the screen, you want their sprite
representations to be according to where the object is in reference to the
screen in the world. If the object stays still and the screen moves, for
instance, well then the sprite moves on the screen even though the object
hasn't moved in the world at all. So what you have to do is set up a relation

between the sprite and the screen. It's just:

SpriteX = ObjectX - ScreenX
SpriteY = ObjectY - ScreenY

So if the object position gets bigger with the screen position fixed, then
the sprite position gets bigger, and moves right and down on the screen. If
the screen position gets bigger with the object position fixed, then the
sprite position get smaller, and moves left and up on the screen. Now
remember, this example is all in terms of the origin of the world being to
the upper left, and the origin of the objects and screen at the upper left of

their bounding boxes as well.

When you give the OT a sprite to sort, you're giving it the sprite's SCREEN
position. From experimentation I have found out that this does not mean it
has to be from (0,0) - (SCREENW-1, SCREENH-1), but it can be any number at
all, even negative! The OT compensates and does all the clipping for you, so
that the formula above works fine when using SpriteX and SpriteY as the
position to be be placed on the screen.

If you have trouble visualizing it, just start out with 1 object and the
screen at the origin of the world, and imaging what happens to the sprite
image on the screen when you try to move either one according to the formula:

ORIGIN
+-------+------+--------------------------+
| | | |
|OBJECT | | |
|-------+ | |
| | |
| SCREEN | |
| | |
+--------------+ |
| WORLD |
| |
| |
| |
| |
+-----------------------------------------+



4) Why am I getting a "banding" effect with my background tiles, where a
vertical line in the tile is smeared over a pixel?

The individual tile textures of a background each have to be on an even u
coordinate. If each sprite texture is not positioned on an even number in the
video memory, you will get this effect. This can easily happen if you use
gridlines to separate your tiles for easy editing, for instance.


3D
--

1) What is the 3D coordinate system of the playstation? I've looked everywhere

in the manuals but couldn't find a simple description!

It's actually a right-handed coordinate system, meaning (with your right hand)

+X cross +Y gives you +Z. The +X axis is to the right of the screen, +Y is
down on the screen, and +Z is in towards (behind) the screen.


2) What's the difference between RSD and TMD?

RSD is the file format used to convert from modelers, similar to DXF and other

model formats. It is in ascii, making it easy to edit by hand. The info
making up an RSD is actually four files, .rsd, .ply, .mat, and .grp. It's
easy to mix up talking about RSD (which includes all four files) with just
rsd. A modeler converting to RSD will generate all four of these files.
Also, an RSD refers to only one model, and the grouping information (.grp) in
the model doesn't carry over to TMD.

TMD is the file format the playstation uses, and the data making up this file
actually resides in memory when your Yaroze program is drawing objects on the
screen. A TMD can have more than one model, and each model has its own set of

primitives, which are made up of those model's own vertices and normals. Each

primitive is described in detail as a triangle, quad, flat shaded, gourand
shaded, colored, color gradated, or textured. All the combinations are
described in the Sony online docs.


3) Are the coordinates different in RSD and TMD?


3) How can I see information on my RSD?

To view an RSD, use RSDTool. To get information on the vertex extents and
"center" position, do rsdform -v mymodel.rsd. Follow this with > to output to

a file.


4) How can I see information on my TMD?

To view a TMD, try this:
http://www.netyaroze-europe.com/~sevans ... mdview.ZIP

You can also get vertex information on the TMD when you are converting from
the RSD with rsdlink, just do rsdlink -v mymodel.rsd or rsdlink -info
mymodel.rsd. Follow this with > to output to a file.


5) Can I save multiple models in one RSD file?

Yes and no. An RSD contains only one model per file, so if you wish to put
several models into one RSD with rsdcat, you are really only merging several
models into one big one, and in effect, merging three coordinate systems into
one.


6) Can I save multiple RSD models to one TMD file?

Yes. Unlike RSD files, TMD files can make references to several different
models within the file. To put several RSD models together into one TMD, you
can use rsdlink with several RSD file names as arguments (see top of p.149 in
yellow manual).


7) Is there any reason to put several models within a TMD file instead of only

one?


8) What do the coordinates mean in rsdform (option -v)? What is "center"?

These coordinates refer to the offsets from the model's coordinate system. If

you "translate" the model with rsdform, you are moving all the vertices within

the fixed model coord system, and you can imagine a bounding box of all the
vertices that comprise the primitives of the model moving around in space with

respect to the model's fixed coordinate axis. The "center" is just a
reference to the center of mass of the model, which can usually be specified
within a modeler program. The playstation will rotate models around (0,0,0)
of the coordinate system, *not* the "center", which can be a nonzero offset
from (0,0,0).

When you save an object in a modeler and it is not placed in the middle of the

world, for instance at (8, 10, 12), the "center" in your RSD will appear as
(8, 10, 12). To get the model back to the origin (so that it rotates
correctly) you need to translate back to (-8, -10, -12). However, many times
you will want to use this information, for instance, if you have several
objects and need to know their relative offset position, such as a helicopter
and its blades. You would need to know how high the blades are in the world
originally, so that you can offset them with respect to the helicopter when
you're actually drawing them in your program.

The origin of the model's coord system (0,0,0) is the point that is referred
to when translating the model in your program. So if I give my model's
translation vector (.t) in my program the value of (5, 2, 10), the model's
origin will be at (5, 2, 10), and all the primitives will be drawn around this

point.


9) How do I assign parents to other objects?

When initializing your object's coordinate system, instead of doing
GsInitCoordinate2(WORLD, &MyObjectCoord), do GsInitCoordinate2(&MyParentCoord,

&MyObjectCoord), assuming you already initialized &MyParentCoord with WORLD or

some other coordinate system. Each argument is a pointer to type
GsCOORDINATE2, which includes a matrix that describes the coordinate system
you are using. So then, after the initialization is done, all of the offsets
of your model are with reference to the parent coordinate system. For
example:

GsCOORDINATE2 MyParentCoord;
GsCOORDINATE2 MyObjectCoord;

// the coords of an object with MyParentCoord are in the world
GsInitCoordinate2(WORLD, &MyParentCoord);

// the coords of an object with MyObjectCoord are w.r.t. the parent
GsInitCoordinate2(&MyParentCoord, &MyObjectCoord);

So if you had an GsDOBJ2 handler representing a tank, make its coord2 member
point to MyParentCoord (the tank is the parent), and if you had a GsDOBJ2
handler representing the tank turret, make its coord2 member point to
MyObjectCoord (the tank turret is the child). Now if the turret is at
(0,0,0), it will be at the tank model's origin. You'll probably want to
tranlate the turret to (0, -1000, 0) or so, depending on your model, and
everywhere the tank moves (in the world), the tank turret will follow.


10) How do I rotate an object?

First you have to know that all models rotate about the origin (0,0,0) of your

model's coordinate system (do rsdform -v mymodel.rsd). This means that
however your primitives are placed in your RSD, they will rotate around this
point. So if the "center" of your model (representing the actual center of
your model) is not (0,0,0), translate it there first before you rotate it.

Assuming there is an initialized GsCOORDINATE2 Coord structure (belonging the
object which I am rotating), and I want to rotate the object (RotX, RotY,
RotZ):

MATRIX TempMatrix;
SVECTOR RotVector;

// this makes a vector
RotVector.vx = RotX;
RotVector.vy = RotY;
RotVector.vz = RotZ;

// this turns a vector into a matrix, so that I can multiply
RotMatrix(&RotVector, &TempMatrix);

// multiply original coord matrix by "rotation" matrix
MulMatrix0(&Coord.coord, &TempMatrix, &Coord.coord);

// object should be redrawn now since it changed
Coord.flg = 0;

Note: Rotation this way may distort your model if your model is not very
large.


11) How do you advance an object in the direction it's facing?

Assuming that your model starts out pointing in the +z direction, and you want

to advance U units, and that your object has a GsCOORDINATE2 Coord struct:

SVECTOR StartVector;
SVECTOR CurrentDir;

// assume origin points exactly towards +z direction
StartVector.vx = 0;
StartVector.vy = 0;
StartVector.vz = ONE;

// multiply original orientation (start vector) by current orientation matrix,

to get the current direction vector
ApplyMatrixSV(&Coord.coord, &StartVector, &CurrentDir);

// add a multiple (units) of the current direction to the current translation
Coord.coord.t[0] += (U * CurrentDir.vx) / ONE;
Coord.coord.t[1] += (U * CurrentDir.vy) / ONE;
Coord.coord.t[2] += (U * CurrentDir.vz) / ONE;

// the object should be updated now
Coord.flg = 0;

Note: You could use 1 instead of ONE=4096, and then not divide later on by
ONE, but you'd get considerable error if you don't "pump up" your start vector

to considerable size because of the integer precision.


9) What's a standard size for a model?

Typical sizes are about 500.0 to 2000.0 in each dimension.


10) How small/big can I make my model?

If a model is too small (meaning its vertex coordinates are small numbers,
like 1s or 10s), errors of the playstation fixed-integer rotation and scaling
(matrix computations) will be too large and the model will distort.

If a model is too large


8) I don't see my object! Where is it?

First, see if you're actually sorting it with GsSortObject4() -- of course,
there's some stuff you have to do before you can actually sort it, like
calling GsGetLws(), GsSetLightMatrix(), and GsSetLsMatrix(). You should also
make sure the loading of the model was done right, too.

Second, see if the scale is big enough. Modelers tend to save out RSD models
in the -2.0 to 2.0 range, which is pretty small for a standard playstation
model. Scale it up with rsdform -s 512 512 512 mymodel.rsd, to give it a size

big enough to see at standard viewing distances, which are 500.0 to 1000.0
units away.



7) I want to have an object with several moving parts (a model for each part)
and have each part move independently. What do I have to do to get this to
work?



Since each model must move independently, you should first center each RSD
model by setting its "center" to (0,0,0). For instance, This is so that each
object will rotate properly about its "center".


12) What's the difference between GsVIEW2 and GsRVIEW2?

) Is it true that the colors specified for an object's polygon is 24-bit,
whereas images used for textures on models may only be 4-, 8-, or 16-bit?


) I've tried to draw TMD lines or sprites as documented in the File Format
document, but they don't seem to be working.

Even though they're documented, 3d lines and sprites cannot be used on the
yaroze.


) I've also tried to use double sided polygons with no success.

Again, double-sided polys are not supported on the Yaroze.


) How do TIMs get linked up with objects?

When you do the rsdlink command, your TMD gets info about the textures you are

using for the mapping to the object(s) from the TIM files referenced by your
object. Make sure that if these textures change at all, such as tpage
location or clut location, that you redo rsdlink.


) Do you have to texture map TIMs onto each individual polygon, as in RSDTool,

or is there a way to "wrap" a texture around groups of polygons.

There doesn't seem to be any tools out right now to do this, although the next

version of RSDTool was supposed to incorporate this feature.


) Why are my objects all "flat", even when I rotate them?

You forgot to set the coordinate system of your object, i.e., make your
GsDOBJ2 object handler coordinate pointer (.coord2) point to a validly
initialized GsCOORDINATE2 struct.


) Are there any *simple* modelers out there, that don't triangulate like
crazy?


) How do I convert a 3D coordinate to a 2D coordinate?

--SNIP-------------------------------------------------------------------

void InitTransProj(void);
void TransProj(VECTOR *pos, short *x, short *y);

static GsCOORDINATE2 trans;

//
-------------------------------------------------------------------------
// init trans proj coord
//
-------------------------------------------------------------------------
void InitTransProj()
{
GsInitCoordinate2(WORLD, &trans);
}

//
-------------------------------------------------------------------------
// Trans Proj - convert 3d x,y,z to 2d screen x,y
//
-------------------------------------------------------------------------
void TransProj(VECTOR *pos, short *x, short *y)
{
MATRIX mat;
VECTOR v;

trans.coord.t[0] = pos->vx;
trans.coord.t[1] = pos->vy;
trans.coord.t[2] = pos->vz;
trans.flg = 0;

GsGetLs(&trans, &mat);

ApplyMatrixLV(&mat, pos, &v);

if(mat.t[2]) {
*x = ProjectionDistance * v.vx / mat.t[2];
*y = ProjectionDistance * v.vy / mat.t[2];
} else {
*x = 0;
*y = 0;
}
}

--SNIP-------------------------------------------------------------------

Contributed by Steve Hunt



YAROZE PLATFORM
---------------

) What's this 0x00000000 stuff mean?

This is a hex value, which is 32 bits, meaning 8 hex digits corresponds to 32

binary digits (4 bits per hex digit). The PSX has a 32-bit address space,
meaning all operations with memory are done with 8-digit hex values. Some
other addresses are 4 hex digits = 16 bits, like device memory, but most
things are done with 8-digit hex values.


) What's the difference between uchar and ushort and ulong?



The "u" stands for unsigned, so any values you stick in the variable can't be

negative. This gives you twice the numbers you can get from "signed"
variables char, short, and long. Unsigned variables are ideal for memory
addresses, though, since they are never negative -- uchar gives you 8 bits of

storage, or addresses from 0x00 to 0xff, ushort gives you 16 bits of storage,

or addresses from 0x0000 to 0xffff, and ulong gives you 32 bits of storage,
or addresses from 0x00000000 to 0xffffffff.


) Why do I have to load data at 0x80090000? What about those other addresses
mentioned in the manual?

For the yaroze system, the only valid memory-mapped addresses (meaning if you
stick stuff at these locations, it gets "mapped" to the actual playstation
RAM) are 0x80000000 to 0x801fffff. This is exactly 2 megabytes, or 2,097,152
(2 * 2 ^ 20) bytes, to be exact. The other locations are not used on the
yaroze. The only valid space for us is 0x80090000 to 0x801fff00 (1,507,072
bytes), since the rest is being used for the system. That's why data is
usually started at 0x80090000, and added upwards. Your program may be loaded
anywhere in this space, depending on where you tell your compiler to load it,
but it's usually loaded up towards the top. There has to be enough space
upwards for the program itself (code and heap), plus the amount the stack will

grow. The program's stack usually starts at the top of our usable space,
which is 0x801fff00, and grows down until it collides with the loaded program

(this is bad). That's why it's up to the programmer to figure out how much
his stack will grow, and tell the compiler to place the program low enough in

memory so that the stack doesn't end up running into it.


Typical Setup:

SYSTEM (OS) STACK (0x801FFFFF)
PROGRAM STACK (0x801FFF00)
|
|
*

(hope the stack and heap don't collide!)

*
|
|
PROGRAM HEAP
PROGRAM CODE (stays same size)
DATA N
...
DATA 3
DATA 2
DATA 1 (0x80090000)
OTHER OS GOODIES (0x80000000)

You can set the PROGRAM STACK and PROGRAM CODE in your compiler and the DATA 1

- DATA N in your yaroze batch file.


) What's fixed point?

Fixed point is an alternative to floating point, and is quicker since it
actually uses integer hardware and not any special floating-point hardware.
It is actually a trick done with integers, and tends not to be quite as
accurate as true floating point operations, so you have to watch it when
rotating and scaling models, and make sure they're not getting distorted.

The playstation uses 12-bit fixed point, meaning there's 12 bits of a short
(16-bit) integer allocated to the decimal portion of a number (3 bits are used

for the integer part, and 1 for the sign). These numbers are the values that
will represent the vertices and normals in 3D space within a TMD file. The
details aren't important unless you plan to change the attributes of a model
in real-time, which involves fiddling with the byte values of the TMD in
memory.

See the following web page for more info on fixed point:
http://www.scea.sony.com/net/yaroze/pages/scartier.html


) Can I do floating point?

) How do I get C++ to work?

http://www.netyaroze-europe.com/~c_graham/cplus.html



EFFICIENCY
----------

) How efficient is C++ on the playstation?

) How efficient is using 16x16 pixel tiles (with GsBG) as opposed to using
sprites (with GsSPRITE) as backgrounds?

) How can I make my games quicker, taking into account playstation hardware?

a) Make use of the DCACHE in functions that you call very often; see Scott
Evans' (SCEE) DCACHE article.

b) Declare variables static in functions that you call very often, so fewer
local variables need to be pushed and popped.


) What are some suggestions to make my 2D graphics a little faster?


) What are some suggestions to make my 3D graphics a little faster?

a) First and foremost -- keep polygon count low. With the tools available
this is sometimes difficult, since it seems modelers like to triangulate when
saving out.

b) Make several versions of objects at different "resolutions", and sort
higher polygon objects when those objects are closer to the camera, and lower
polygon objects when they are farther away.


) Why does saving to DXF from modelers make so many more polygons? What can I

do to avoid this?


) Is it more important that I make fewer objects or fewer polygons?


CODEWARRIOR
-----------

) What can I do with Codewarrior that I can't do with Siocons?

a) Automatic makefiles
b) GUI coding (not suggested)
c) GUI debug
d) Use MWDebugIO functions, which allow you to create, open,
and close files on your PC


) What can I do with Siocons that I can't do with Codewarrior?

a) Download memory directly to a PC file (DSAVE[])


) Is there any differences in writing code for Codewarrior versus writing code

for Siocons?


) What's the best setup?

One way to develop for Yaroze is to use Codewarrior to "make" your projects
and the PSComUtil to download batch files, since it's mostly point and click.

I have found the Codewarrior IDE very disturbing, though, so I choose to use
an outside editor such as Microsoft DevStudio, or some shareware code editor.

You can leave the files that you edit in the Codewarrior project, and just
bring Codewarrior into focus and click "make" when you want to build your
project to be downloaded to the yaroze.

Some other people have suggested forgetting Codewarrior altogether, using the
makefile capabilities of MS DevStudio and integrating DJGPP(GCC) with it. See

Steve Dunn's (SCEE) home page.

Also, check out the front end gnu programs that are available (in the
utilities listing of this FAQ).


) How about some simple Codewarrior (MWDebugIO) example code for creating,
opening, reading, and writing files to the PC?


) What kinds of problems are there with Metrowerk's MWDebugIO library?


) Why is PSComUtil failing?

If you get
"Connection Failed. Status -1
Transport Send Data. Status 101812
Transport Poll Rx Status. Status 101812
The PlayStation has generated a Hardware Interrupt exception at instruction
address 0x0."

Probably means that Pscomutil is still resident in memory. Check your task
manager and delete the process. For some reason, even if you exit PSComUtil,
it still stays resident in memory sometimes.



SOUND
-----

) How do I make sounds play? What programs have to be run?

Say I want to use 3 .wav files, a.wav, b.wav, and c.wav. First you do
"aiff2vag a.wav b.wav c.wav" to create .vag's out of the .wav's. Then you
have to type "mkvab -f sounds.def a.vag b.vag c.vag -o sounds.vab" where
sounds.vab is the output .vab and sounds.def is your definition file. What's
that? It's a file you need to provide to make a vab. The vab can contain
programs, and for each program, a tone. You set it up so that there's a .vag
for each tone. You have to set this by hand via the .def file. To see other
people's .def files for their programs, type "mkvab -r person.vab -o
person.def" where person.vab is their vab, and person.def is the output .def
that you want to look at. In the .def file is where you associate programs
and tones. A program can have one or more tones, but the way it is usually
set up is that there's a program for each sound, and each program only
contains one tone, the .vag that you specify. Sometimes people use maybe two
programs and say ten different tones, and maybe 4 tones in the first program
and 6 tones in the second program, where each tone is associated with a vag.
I don't know why, though. Maybe someone can answer this for me. Anyway,
suppose you set up your .def so that program 0 has two tones, a.vag and
b.vag, and program 1 has one tone, c.vag. So to play the sound, you do
"SsUtKeyOn(vabid, prog, tone, note, fine, voll, volr);", where prog is the
the program for the sound you want to play as specified in your .def file,
such as prog 0, and tone is the tone of that prog as specified in your .def
file, such as tone 0 or tone 1. The note is the pitch to play the sound. At 0,

it's normal. Increasing the pitch is like going up the keys of a piano. The
fine parameter is just fine pitch. And voll and volr is the left and right
volumes. But what about vabid? Well, when you call SsVabTransfer(), you get
returned a vab id. This is the vab that is being used for your sound calls.
The vab got loaded into sound memory when you called SsVabTransfer(), where
you have to specify the VH and VB type files that have been loaded into main
memory from siocons. How did they get into main memory in the first place?
Well, all you have to do is split up your vab you made, sounds.vab, with
"vabsplit sounds.vab". Then you got the files sounds.vh and sounds.vb, which
you just load into the psx memory via siocons. Using the syntax of
SsVabTransfer(), you just transfer them into sound memory, and you're ready to

make sound calls.


KNOWN BUGS, ERRORS, OR TYPOS
----------------------------

1) In the green manual, RotMatrix(MATRIX *m, SVECTOR *r) should actually be
RotMatrix(SVECTOR *r, MATRIX *m)



MISCELLANEOUS
-------------

1) What Yaroze tutorials are available?

Ira Rainey's Sprite Tutorial (SCEE)
http://www.netyaroze-europe.com/~shadow ... /Howto.pdf

James Chow's help docs (SCEE)
http://www.netyaroze-europe.com/~jaycee/

Peter Passmore's 3D Tutorial (SCEE)
http://www.netyaroze-europe.com/~middx_ ... torial.zip

Robert Swan's accompaniment to above tutorial (SCEE) - see other downloads too
http://www.netyaroze-europe.com/~middex ... mp_tut.zip

Jamin Frederick's Sprite Tutorial (SCEA)
http://www.scea.sony.com/net/yaroze/pag ... onespr.zip

Nelson Santos' Ping - beginner game with docs
http://www.total.net/~nsantos/downloads/ping.zip


2) What are some useful general-purpose yaroze utilities?

**SCEE member sites:

Memory Viewer - graphically view Yaroze RAM, 0x80000000 to 0x801fffff
http://www.netyaroze-europe.com/~shaugh ... emview.zip

Analog PAD diagnostics - displays analog PAD values
http://www.netyaroze-europe.com/~shaugh ... analog.zip

DOS yaroze tools for people who don't like windows
http://www.netyaroze-europe.com/~yannick/

ARS (Action Replay File Server) - lets you do i/o with yaroze at 20x the
speed; NOTE: you need Datel Action Replay for this
http://www.netyaroze-europe.com/~c_graham/areplay.html

NiceARS - ARS implemented in windows NT; NOTE: you need Datel Action Replay
for this
http://www.netyaroze-europe.com/~steved ... ows_nt.htm

RsdAnim - "...a PC (Win95) hosted keyframe animator for Playstation RSD format

3D models...."
http://www.netyaroze-europe.com/~c_graham/rsdanim.html

Binary Conversion Tool - converts data files to C source binaries
http://www.netyaroze-europe.com/~steved ... n_tool.htm

Sound Effects Player - lets you test sounds on yaroze
http://www.netyaroze-europe.
com/~steved/articles/sfx_player/sound_effects_player.htm

C++ Library - wrappers around standard pslib function calls
http://www.netyaroze-europe.com/~steved ... ibrary.htm

Yaroze Master - makes editing and using makefiles a snap on Win95/NT
http://www.netyaroze-europe.com/~deruiter/ym.zip

Lightwave to RSD converter - convert from LOB to RSD
http://www.netyaroze-europe.com/~Sig1LL ... psx120.zip

Starfield Library - function calls to easily make a 3d starfield
http://www.netyaroze-europe.com/~rcutti ... rfield.ZIP

GCC C++ - Win32 compiler for your C++ code, even if you don't have Codewarrior
http://www.netyaroze-europe.com/~frothy/ftp/gcc281.ZIP

Crossroads - freeware 3D file converter (Win32)
http://www.pnn.com/~rickhowd/xroads1.zip

Convert - freeware DOS audio file converter
http://www.netyaroze-europe.com/~nslave ... nvrt14.zip

PAK - compression utility for data uploads (incomplete?)
http://www.netyaroze-europe.com/~smithers/ftp/pak.zip

Linux Tools
http://www.netyaroze-europe.com/~respond/download.html

Amiga Tools
http://www.netyaroze-europe.com/~CACTUS/

Unix Tools
http://www.netyaroze-europe.com/~byz00002/unix/

Utilities for Atari ST sprites
http://www.netyaroze-europe.com/~sevans/demos.htm

TMD Viewer - includes depth cuing and object/viewpoint manipulation
http://www.netyaroze-europe.com/~sevans ... mdview.ZIP

CRNCHPLY - reduces redundant PLY data
CRNCHPL - same as above, but without DOS4GW.EXE
MEMEDIT - edit the contents of any file on your second memory card
DATAMAN - manages data download offsets
http://www.netyaroze-europe.com/~jruss1/#tools

Memory Card Dump
http://www.netyaroze-europe.com/~badchild/ftp/card.zip

Stereoscopic Vision
http://www.netyaroze-europe.com/~middx_ ... stereo.zip

Dump Address - creates .h and batch files for your Yaroze datafiles
Palette Ripper - extracts Cluts from PCX files. Useful for light and palette
animation
Vertex Extractor - Extracts vertex and normal data from TMD files. Useful for
animated 3D objects
http://www.netyaroze-europe.com/~IBEYON ... ytools.zip

**SCEA member sites:

VRAM and TIM viewer
http://ww1.scea.sony.com/net/yaroze/pag ... /vvram.zip

PSXsock - enables TCP/IP connection of Yaroze (Win95/NT)
http://www.scea.sony.com/net/yaroze/pag ... SXsock.zip

Unix Tools
http://www.scea.sony.com/net/yaroze/pages/chenrich.html

Psx IDE - front end to gcc for Win95/NT
http://yaroze-world.org/assets/images/psxide.zip

WAD Builder - compression utility for Yaroze data/code
http://yaroze-world.org/assets/images/wb.zip

Joystick Routines
Sprite Animation
Decompression
Starfield
(libraries and example code)
http://yaroze-world.org/html/ps_code.html

Card save module - functions to save to memory card
Font module - lets you use pretty, custom fonts
Menu module - lets you easily make a menu system
http://lucien.blight.com/~sauron/Net.Ya ... .My.World/

Address Arranger - automatically arranges your data addresses for downloading
Sprite Assembler - clips a sprite from a TIM and resaves it
TIM Manipulator - fiddle with specific TIM attributes
Screen Grabber - grabs the screen and stores as a file
http://www.scea.sony.com/net/yaroze/pages/scartier.html

PPTMDView - TMD/RSD viewer for Mac
http://www.scea.sony.com/net/yaroze/pag ... 21.sit.hqx

Font Library - fonts and special effects
http://comradery.com/erico/cool/yaroze/ ... ntdemo.zip

GsBG Library - lets you do tiled backgrounds
http://www.scea.sony.com/net/yaroze/pag ... bgdemo.zip


3) Where is there some useful technical info?

**SCEE member sites:

Scott Evans' Technical Notes
http://www.netyaroze-europe.com/~sevans/tech.htm)

Some intro demos and tidbits: dynamic TMDs, lines, sprites, gradients, split
screen (Robert Swan, Downloads section)
http://www.netyaroze-europe.com/~middex2/

Various technical info
http://www.netyaroze-europe.com/~mrfros ... index.html

Using DevStudio with GCC
http://www.netyaroze-europe.com/~steved ... _in_ds.htm

General matrix and MIPS info, graphics links
http://www.netyaroze-europe.com/~javier/index.html

Shiny Toruses
http://www.netyaroze-europe.com/~Sig1LL ... /howto.htm

3D Studio file format
http://www.netyaroze-europe.com/~Sig1LL/3ds/3ds.html

Motion Capture
http://www.netyaroze-europe.com/~Sig1LL/motion.html

TMD file format
http://www.netyaroze-europe.com/~Sig1LL ... dform.html

Exception Handling
http://www.netyaroze-europe.com/~Sig1LL ... /EXCEP.ZIP

Macintosh help
http://www.netyaroze-europe.com/~daryl/

C++ for Yaroze
http://www.netyaroze-europe.com/~c_graham/cplus.html

**SCEA member sites:

NM.EXE
ClearImage()
Multiple CLUTs
Misc Tricks
Fixed Point
http://www.scea.sony.com/net/yaroze/pages/scartier.html

Using the Yaroze with C++
http://www.scea.sony.com/net/yaroze/pag ... well2.html

C++ class examples
http://www.scea.sony.com/net/yaroze/pag ... well4.html

Some programming tips
http://www.scea.sony.com/net/yaroze/pag ... well3.html

Some answered FAQs
http://www.scea.sony.com/net/yaroze/pages/hchen.html

VSync() Diagram
http://www.scea.sony.com/net/yaroze/pages/wlee5.html

Tidbit on speeding up DOS SIOCONS programs
http://www.scea.sony.com/net/yaroze/pag ... erman.html

Macintosh resources
http://www.scea.sony.com/net/yaroze/pages/nporcino.html

Some info on SSUtKeyOn()
http://www.total.net/~nsantos/downloads/sfx.zip

Docs describing api
http://www.total.net/~nsantos/downloads/yardoc.zip


4) Where are some other interesting sites?

Personal profiles of participating Yaroze members
http://www.netyaroze-europe.com/~madmac/

Yaroze Game Reviews
http://www.netyaroze-europe.com/~mrfros ... index.html

Net Yaroze Times
http://www.geocities.com/TimesSquare/Alley/2200/

Club Yaroze
http://www.clubyarouze.com/cyarchive/

Underground Yaroze (no longer updated)
http://www.pacificcoast.net/~titan/


5) Are there any chat sessions going on?

Yaroze Chat in Auditorium on SCEA web page (every Saturday 9:00pm EST)
http://www.scea.sony.com/net/yaroze/aud.html

James Rutherford's chat page (schedule posted)
http://www.netyaroze-europe.com/~mrfros ... index.html

ICQ Chat Group
http://groups.icq.com/group.asp?no=17896


6) What yaroze contests are there? Who can participate?

UK Game Developer ?98 -- SCEE Yaroze only
(http://www.gduk.co.uk/html/first.html)


) Is there any way to read from a CD other than the Yaroze boot disk, and is
it allowed?


) Can I run yaroze programs on a regular playstation? Do I still need to
download?


) What are some cool 2D special effects?


) What are some cool 3D special effects?


) How do I get PAL games from SCEE to work in NTSC?


) What is ARG and Pro Action Replay?


) How much is Pro Action Replay, and where do I get it?

Post Reply

Who is online

Users browsing this forum: No registered users and 0 guests