don't click here

Presenting...

Discussion in 'General Sonic Discussion' started by hxc, Jun 18, 2006.

Thread Status:
Not open for further replies.
  1. Meat Miracle

    Meat Miracle

    Researcher
    1,664
    5
    18
    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?

    Were they drawn with the vdp1 or were they just the tricks used in Burning Rangers where explosions were drawn on a seperate VDP2 field which was all-transparent?
     
  2. Heran Bago

    Heran Bago

    Ah! It's Puyo battle then. Tech Member
    Thanks so much for all the answers to these mysteries Chris! I owe ya.

    Here's another one. Graphical similarities have been pointed out between the Saturn Sonic projects and Sonic's Schoolhouse for the PC (that edutainment game). Is there any connection at all, like could graphics have been re-used?
     
  3. SANiK

    SANiK

    Tech Member
    413
    0
    16
    Made screens of the Saturn 3D model bug Christina was talking about, and how they took advantage of it:

    [​IMG]
     
  4. Eric Wright

    Eric Wright

    Born into this. Oldbie
    THe visual helps a HELL of a lot... maybe now people will stop criticizing me when I say STI kicked fucking ass :P *cough Nik cough*
     
  5. Rarmander

    Rarmander

    Poetaster Member
    1,918
    0
    16
    An Empyreal Child
    Wow that's really cool. A smart way to use a bug.
     
  6. ChristinaCoffin

    ChristinaCoffin

    Tech Member
    18
    0
    0
    I tried to use the quad bug in other gameplay objects in the world as well - like that cannon gizmo in boris's .gif sig, as part of enemies to show you should spindash into their sides instead of jumping on top of them, and terrain hazards like spike pits and such.

    I think there's a magazine shot out there showing a bunch of koosh-ball type objects in a small arena with sonic standing near them, those were rendered using the same bug as well.

    If I had the saturn sdk and hardware reference docs I could probably explain some of the tricks alittle better.
     
  7. hxc

    hxc

    spotteddove Researcher
    1,023
    1
    18
    The Saturn SDK with those models is available, if you would like it. Uploaded it here: http://projectsonic.com/SSSDK.zip

    I think Don Goddard has an original copy of the docs, but is busy right now. Borisz (in IRC) said they might be here: http://www.segaxtreme.net/Developer/Documentation.html
     
  8. SANiK

    SANiK

    Tech Member
    413
    0
    16
    WTF is wrong with you guys? It's been 10 years, and we've finally landed an interview with Christina Coffin, and now there's been like a full day of silence in this topic!

    There's so much to ask from the programmer perspective!

    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.projectsonic.com/Index.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?

    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

    (Borisz, in your avatar the thing that shoots Sonic seems to be transparent so it might count as an 'example')

    AI - ah yes, something that even the game of Pong couldn't live without. I remember reading how you took great joy in playing around with the AI and bringing characters to life, but I wondered how advanced was the AI? Did the AI follow a pattern and eventually always allow the player to hit it (e.g. all Sonic game bosses), or was it more like a fighting game like Sonic Fighters or Street Fighter?

    Logo - And finally, is there a higher res. version of the Sonic Saturn logo by any chance =O
     
  9. Vangar

    Vangar

    Member
    3,656
    62
    28
    I don't think so, he ripped it from the game, not from his art. Unless he has art of it seperately.
     
  10. hxc

    hxc

    spotteddove Researcher
    1,023
    1
    18
    *she.
     
  11. SANiK

    SANiK

    Tech Member
    413
    0
    16
    *poke*

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

    Tweaker

    Banned
    12,387
    2
    0
    Yeah, but Christina hasn't posted, so until then it's pretty much dead. =(
     
  13. ChristinaCoffin

    ChristinaCoffin

    Tech Member
    18
    0
    0
    sorry work has been extremely busy, I'll try to post something later this week regarding the previous questions.
     
  14. ChristinaCoffin

    ChristinaCoffin

    Tech Member
    18
    0
    0
    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.
     
  15. ChristinaCoffin

    ChristinaCoffin

    Tech Member
    18
    0
    0
    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.
     
  16. hxc

    hxc

    spotteddove Researcher
    1,023
    1
    18
    Thanks Christina ;)
     
  17. SANiK

    SANiK

    Tech Member
    413
    0
    16
    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)
     
  18. ChristinaCoffin

    ChristinaCoffin

    Tech Member
    18
    0
    0
    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).
     
  19. Mad Echidna

    Mad Echidna

    Gone Oldbie
    5,219
    0
    0
    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.
     
  20. Ex-Cyber

    Ex-Cyber

    Member
    1
    0
    0
    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.
     
Thread Status:
Not open for further replies.