[SANiK]

*poke*

Just reminding everybody that this is an ongoing event so that it ain't forgotten about =o

[Tweaker]

Yeah, but Christina hasn't posted, so until then it's pretty much dead. =(

[ChristinaCoffin]

sorry work has been extremely busy, I'll try to post something later this week regarding the previous questions.

[ChristinaCoffin]

SANiK, on Jun 23 2006, 07:58 PM, said:

Transparency - you mentioned transparency before and said that you employed the VDP1 to pull it off. I'm basicly asking the same question as Borisz which was probably missed:
"What I'd like to know is - how in the heck did you make proper transparent, non-meshed polygons on the Saturn?
Can you take pictures of that?"

Transparency is said to be super-slow on the Saturn, and I'm wondering if you devised a new means to achieve it that was faster, or if you used the same old method =O

When you say meshed, im assuming the mode where every other pixel is simply not drawn, like this;

X-X-X-X-
-X-X-X-X
X-X-X-X-
-X-X-X-X
X-X-X-X-
-X-X-X-X
X-X-X-X-
-X-X-X-X


where the x's are the only pixels drawn for a 8x8 pixel sprite/polygon.
Yes this method was ugly and sucked, causing several 3rd party publishers to not even bother developing for the saturn because multilayered transparency doesn't work with this technique or looks horrible.

Now you could enable normal transparency on quads, but due to the rasterization hardware, you'd get double transparency artifacts that would crawl across the polygon as it's vertices moved.
One of the techniques devised to allow transparent untextured 'n-gons' on vdp1 (yes n-gons) with no visible artifacts was to transform a virtual convex polygon and project it to screenspace, then construct the screenspace rasterization gradients. For each scanline conversion of the polygon, these gradients would then be converted into 1 pixel tall sprites (not rotated obviously since we're using sprites to render 'spans') tinted with the appropriate color and drawn with normal transparency, not using the ugly meshed technique.

Some other tricks to speed things up were to chop the vertical resolution of the scan conversion in half, creating slightly chunky edges on the transparent polys, using 2 pixel tall sprites. Pretty sure that trick is visible in burning rangers in a couple spots, just look for some transparent polys with chunky edges.

A few other flavors using gouraud shaded transparent lines were done for transparent gouraud shaded n-gons iirc.

The fine details of the textured transparent quad version escape me at the moment, I do remember one variation where if only one transparent color was needed and the other parts were opaque.
The poly was done as 2 pass render ( 2 quads sorted as one poly against their neighbors, always drawn in the same order), 1st 'pass' done with the transparent base color tint, then the opaque texture overlay with tranparency fully on for the parts where the transparent tint was supposed to show through - such as a textured frame around a plate glass window. The artifacting on the 2nd pass wasn't noticable because the transparency was effectively treated as 1bit so you wouldnt see strange double alpha pixels that are noticable with variable alpha textured quads.

This post has been edited by ChristinaCoffin: 07 July 2006 - 01:19 AM

[ChristinaCoffin]

SANiK, on Jun 23 2006, 07:58 PM, said:

The lighting - how was lighting accomplished at the time? You said that three lights could be used max at the time.
The Red Shoe Diaries (link: http://xtreme.projec....php?dir=rsd%2F )talked about Fang tossing a grenade and how it gave off light as the grenade travelled. Did this use dynamic lighting? Vertex lighting? Gradient tricks? Or did it use a craftily made particle engine?

3 light maximum was used at the time because we had a dsp program that could compute lighting from vertex normals by pushing them through a specially arranged matrix (think of how you apply a vector to a matrix and the math should be self evident).

To make it look nights'ish, the lighting results were returned as values from 0-31 or 0-63 (don't remember the exact range but its one of those two). We had a lookup table for each light that would have rgb values like red->black->green which is what would come out when gouraud shading would interpolate between the two extremes, we just took the fixed point result of the lighting dot product and looked into the lighting table to get the gouraud values. The only remaining math involved was combining the 3 gouraud values together so they behaved like additive light. Some hackery involving shifts, adds and shifting back down was done to keep it quick.

To simulate lighting the vdp2 plane, the 2nd vdp plane was draw in non tiled mode and set to transparent. The 2nd plane's tileset had tiles that looked like a spotlight with a falloff. This floated over the ground vdp plane that sonic and the boss ran around on (see mecha sonic boss fight)
The initial design for mecha sonic and fang bosses were such that only one big projectile was active at any moment. This allowed scale/translation of the untiled 'spotlight' vdp plane underneath the transparent 3d sprite projectile to simulate illuminating the vdp2 plane, something that vdp1 polys cant really approximate unless you're drawing it in meshed mode which looks bad.
Finally the projectile when active was always light source '0' on sonic and the boss with the directional lighting vector just being computed from the center of the projectile to the center of sonic, and the center of each of the boss's parts.

Another lighting trick was to light and bake in the gouraud shading values into the sonic model and the boss model. The draw code just simply ran through the model and drew it, and the lighting code was only called as needed beforehand.
Since those models were not instanced, we could get away with this, I would round robin re-updating the lighting on all the boss parts every frame. The only part I had to update every frame was the boss's head because it was always head tracking sonic and tended to rotate a lot more per frame. This optimization kept the game running fast. Special stuff like death animations or the self illuminated projectile being close to the models would update lighting on certain parts more often.
With hardware being so fast and fancy these days, these hacks are kind of a lost art which makes me alittle sad. If anything it does illustrate how weak the hardware was back then, and how programmers had to fake a lot of stuff.

This post has been edited by ChristinaCoffin: 07 July 2006 - 01:58 AM

[hxc]

Thanks Christina

[SANiK]

Great stuff, keep it up, the homebrew Saturn sceners will love this stuff

"With hardware being so fast and fancy these days, these hacks are kind of a lost art which makes me alittle sad. If anything it does illustrate how weak the hardware was back then, and how programmers had to fake a lot of stuff. "

In 1995 or so, coding a software 3D engine was "all the rage."
Now, one rarely hears about them... except for mobile phones and PDAs =o
(See Delta Force and Outcast for their brilliant use of voxels + polygon hybrids)

And then there were fixed point numbers VS floating point
Times are changing, from cheap 1bit 2D images to fully 3D environments, so I ask myself, what's next? (you don't have to answer that ;P)

[ChristinaCoffin]

SANiK, on Jul 7 2006, 10:24 AM, said:

Great stuff, keep it up, the homebrew Saturn sceners will love this stuff

"With hardware being so fast and fancy these days, these hacks are kind of a lost art which makes me alittle sad. If anything it does illustrate how weak the hardware was back then, and how programmers had to fake a lot of stuff. "

In 1995 or so, coding a software 3D engine was "all the rage."
Now, one rarely hears about them... except for mobile phones and PDAs =o
(See Delta Force and Outcast for their brilliant use of voxels + polygon hybrids)

And then there were fixed point numbers VS floating point
Times are changing, from cheap 1bit 2D images to fully 3D environments, so I ask myself, what's next? (you don't have to answer that ;P)

Yeah I almost got into pda/handheld programming because the hardware is really difficult to program or 'weak' :blink:
Thankfully sony made something called the Playstation2 and gave it stuff called 'vu0 and vu1' to satiate my desire for programming 'pain in the ass' hardwre LOL

There's no shortage of xbox/360 programmers compared to ps2/ps3 so from a job security standpoint, working with a difficult console can be a good thing

since there's some interest in saturn tricks not necessarily related to sonic, I remember another rather simpler one:
Since saturn didnt have uv mapping per vertex, we would do some simple texel level animation on textures vertically by doubling the height of the source texture (texture applied to the poly would be set as 32x32 but the memory used would be 32x64) and we'd slide the starting address of the texture source down one row per frame by adding a counter to it and using a mask on the address. Combined with clut animation, you'd get some better looking texture animation. Waterfalls and rivers in sonic used that kind of trick. I also stored all the rings and 3d sprites in a similar fashion but obviously stepped the starting address by the appropriate value equal to the height of each texture 'frame'

The lack of uv mapping per vertex also made clipping look really awful, because most people would just snap clipped poly against the near plane, causing a smashed up look of polys close to the viewer. Now if you use the above trick to vertically clip away texels pushed into the texture mapping of the quad, you can roughly clip it in one dimension at least or do vertical subdivison poly clipping like a lot of PS1 games. So for games and environments that aren't so free roaming, you can minimize the near clipping artifacts quite nicely (like racing games such as wipeout).

This post has been edited by ChristinaCoffin: 09 July 2006 - 12:40 AM

[Mad Echidna]

Christina, I'm so glad that you've decided to join us! This is a really cool development. I don't know much about programming, so I'll have to stick to the usual fanboy stuff I just wanted to tell you that the epic story about how you nearly worked yourself to death is one of my favorite stories to tell, it's the prime example I use when discussing corperate politics with my co-workers.

[Ex-Cyber]

ChristinaCoffin said:

One of the techniques devised to allow transparent untextured 'n-gons' on vdp1 (yes n-gons) with no visible artifacts was to transform a virtual convex polygon and project it to screenspace, then construct the screenspace rasterization gradients. For each scanline conversion of the polygon, these gradients would then be converted into 1 pixel tall sprites (not rotated obviously since we're using sprites to render 'spans') tinted with the appropriate color and drawn with normal transparency, not using the ugly meshed technique.

That's a neat hack. Do you know if anyone ever layered a software renderer on top of a VDP1-based renderer to achieve unusual effects or just more polys? I somehow got it into my head that it might be interesting to adapt Fabrice Bellard's TinyGL to Saturn (whether in code or concept), and it seems it would be a waste to only allow accelerated or unaccelerated operation... why not both at once? I'm sure it would raise all sorts of fascinating Z-sort and/or occlusion issues, but it wouldn't be a hack if there weren't issues, would it? :lol:

As for the curved quad hack, can you summarize what the actual deal is with regard to how/why it works? I've heard several descriptions of it and none of them square with my understanding of VDP1. Frequently I see it described as "non-coplanar" quads, but this makes no sense to me (isn't VDP1 purely 2D, or is this referring to modeling technique?). I had assumed it was a matter of it not being able to generate correct scanlines for concave quads and basically skewing that portion of the quad; I never wrote a software renderer, but my limited understanding is that it's simple to scale from width A to width B along one dimension of the polygon and to reflect that scaling along a line of symmetry if necessary, but that anything more complex than that quickly makes the algorithm hairy. However, my reading on this was quite triangle-centric, which leaves out concavity entirely. Any chance you can enlighten me?

Either way, thanks for all you've posted so far; it's been quite informative.

[Quickman]

Ex-Cyber, on Jul 12 2006, 04:10 PM, said:

As for the curved quad hack, can you summarize what the actual deal is with regard to how/why it works? I've heard several descriptions of it and none of them square with my understanding of VDP1. Frequently I see it described as "non-coplanar" quads, but this makes no sense to me (isn't VDP1 purely 2D, or is this referring to modeling technique?). I had assumed it was a matter of it not being able to generate correct scanlines for concave quads and basically skewing that portion of the quad; I never wrote a software renderer, but my limited understanding is that it's simple to scale from width A to width B along one dimension of the polygon and to reflect that scaling along a line of symmetry if necessary, but that anything more complex than that quickly makes the algorithm hairy. However, my reading on this was quite triangle-centric, which leaves out concavity entirely. Any chance you can enlighten me?

I'm not Christina, but I'll have a go.

The VDP1 is, as you say, primarily a sprite engine (hence the reliance on quads - a three-sided sprite doesn't happen) and is a logical extension of the previous 2D graphics chips like the VDP in the Megadrive. It has a concept of "deformed sprites" which is effectively a quad (the SDK we all know and love to hate translates the coordinates into settings for the VDP1 to handle in drawing the quad). However, when the sprite itself has to cover a bend (a concave quad) it breaks down - it's not clever enough to resolve it as two triangles or any other workaround because it can't do texture mapping, so it tries its best (at this point my knowledge runs thin) and the result is this curved effect which is used.

I'm probably extremely wrong in that. =P

[SANiK]

Quickman's extremely right in that. =P

Quick "tutorial" that I drew up that covers it:

This post has been edited by SANiK: 14 July 2006 - 05:59 PM