Is something like the attached image considered substantial?  ;)

Hello, I am the 'chris coffin' that worked on sonic xtreme.
When/If anything can be released by me personally depends on number of factors I cannot discuss at this time.
I can try to answer if possible, any questions regarding my involvement in sonic xtreme or any saturn hardware questions related to sonic xtreme.
I have been talking with hxc for awhile now and I am in contact with some of the other devs for sonic xtreme and releases may be done by proxy or from an individual if possible and appropriate.

Please be patient and respectful, I personally have a very busy schedule as do others (still making games for a living) so there is no timeline for responses or disclosure of 'materials'.

I'll try to answer the questions/specualtion in this thread preceeding my post regarding what hxc has found when/if i can :).
For starters you may want to check out sonic xtreme on wikipedia, as I made some personal annotations regarding the game development history there to clear up some specualtion that my work was based on NiGHTS code for example, which is wasn't. Yuji Naka and I didn't exactly get along through my correspondence with him :P

-Christina Coffin

-------------------------------------------------

Yes that version had lighting in it, sonic was make entirely from gouraud shaded polygons except for the pupil of his eyes which were a 4bit texture. And yes the lighting looks nights-ish, because I always used a contrasting color backlight for each light colored source (done on the dsp and i think i limited it to 3 max) to help sonic from looking flat.

That 'pudgy looking sonic' in that screenshot at the bottom looks like its from one of the early bonus game builds - notice the lack of lighting which makes him look very flat compared to the other shots.

The models in the sdk actually came from my builds of the sonic game because they demonstartated the rendering trick 'bug' where if you collapse opposite points of a saturn quad you get a triangle with one edge thats collapsed in and smoothly concave in screenspace at the pixel level.

To keep the edges around sonics eyes/stomach smooth at any size onscreen this trick was used. For the eyes the white polygons were rendered first and then special concave quads in blue, collapsed to these special triangles were drawn afterwards to 'trim' the excess white away.
The resulting effect allowed the camera to zoom into sonic's face for cutscenes and still look good.
The back of sonics body used quad polygons warped in a similar fashion to keep him from looking too low poly. Some special sorting tricks had to be worked out to keep sonic looking right at all angles because we were warping the quads to be very non planar.
The polygon sonic in those shots was modeled by an artist/designer originally from sega of japan that worked on a saturn arcade game called dynamite deka (renamed die hard arcade in the us)
Sonic only had aout a dozen bones in his skeleton so the transformation overhead and subsequent rendering (due to being gouraud shaded and not textured) was faster than decompressing one of sonic's 8bit palettized sprite frames from memory.

There were a couple other saturn rendering tricks rolled into xtreme before it was cancelled, such as environment mapping, done by using a paletted texture and hacking some mode bits to force gouraud shading and wrap any object in what appeared to be a 1x32 gradient environment map texture, a couple games like the port of wipeout used this.
Another trick implemented was proper, arbitrarily oriented transparent polygons on vdp1 that could be gouraud shaded and didn't have the doubled up transparent pixel artifacts, so we didn't have to resort to using the dithered 'screen mode' which looked awful in saturn titles.

After extreme I worked on R&D and assisted SoA/SoE/SoJ developer support regarding the saturn hardware so these discoveries were passed on and implemented in some late generation  3rd party titles and 1st party works like burning rangers so the time invested in xtreme did not feel like a total loss.

Yes that image underneath the polygon terrain is the vdp2 plane for the metal sonic boss fight stage. Its 'just there' most likely because i just needed something to help align the vdp2 plane with the vdp1 polys and I wasn't concerned about having the right vdp2 tiles loaded.
Its appearance is tinted blue because the other vdp plane thats drawing that vista-pro style rendered mountains(programmer art lol) extends all the way down the screen with a blue gradient and transparency between both layers was enabled. That bottom 3d plane in later builds was aligned and transformed properly to link up with vdp1 polygons in the game with 3d sprites along the horizon to extend the apparent rendering distance of the world. Using some vdp1+2 tricks you could also cut out holes or make apparent dips+valleys in the vdp2 plane to make things more interesting visually.

If you look at a game like NiGHTS, what they did was draw their base heightfield terrain layer out alittle father, fogged it and made it hilly and downward sloping before they stopped drawing it so you wouldn't have such an unsightly horizon in your game. This is what xtreme did as well because it looks good, hence all the parallels and speculation that we had NiGHTS source.

That build is a very old one and its what I call a tester app which only has a fraction of the game's source in it because I would do a lot of tweaking/compile/rerun to refine the look of the game which didn't require everything in a level to be loaded. Surfing around in the sn debugger to mess with things could actually take longer than just a compile+rerun. cd emulators were slow too which is why alot of sega model formats spit out data in .c and .h files so you'd sacrifice ram during development by compiling in your biggest assets for the sake of less load time.
Think of that version as kind of like a little sandbox for sonic to play in, just contains the ability for sonic to move around, collect rings and a few other things. I used some code overlays which made that possible and it saved me alot of time.

I rarely did testing with cd's so if there's any more cd's out there, their contents will most likely be small modules of the game like that one. Burning cd's back then waas a huge pain and really slowed production down. By working mainly with code that had compiled in assets, adding more programmers to the project was eaiser, this gave them a starting to point to familiarize themselves with parts of the source, make modifications and see what their changes would influence more easily so their iteration time was better as well.

Boss AI code was a seperate source file for each boss and custom coded by me for each one, 3 unique bosses (fang, metal sonic, and a sort of evil sonic clone) had some reasonably poilshed unique ai before cancellation, there was a 4th placeholder ai that was pretty dumb, similar to what you'd expect in the older 2d sonics that just required any properly rigged 3d model with a basic set of animations (move, melee attack, ranged attack, take damage, die animations) and collision spheres to work.

I never got around to trying to support the ram cart that some games like KOF 96 used because it was most likely going to be something we couldnt totally take advantage of with our schedule and I was trying to tune gameplay and push for xtreme to require the analog controller that NiGHTS used because the game played so much better with it.

yes its is related - there was plans to include that minigame into extreme since the art style matched pretty closely what was developed for the xtreme boss engine. The technique they used to rendered sonic was very different looking than the polygon sonic approved for xtreme so the plan was to use everything from that minigame except their 'sonic'

The bug model in one of those screenshots is legit if i recall, one of the technology tricks their engine used was a variant of software textured+phong style spheres used in the pc 'demo coder scene' at that time.
It was used to render perfectly smooth spheres with shading at any size onscreen for those pool balls and the eyes+body of that bug creature, normal vdp1 polys were used to model its legs.
I never got their source code, just their art assets and I replicated the sphere effect and gameplay myself in later builds of the extreme engine.

Most likely the hud graphics were hard coded to certain values in their test builds.
I was guilty of this myself by giving sonic 21 lives by default in every code build  :lol: I also had the score automatically incremement among other weirdness that would be removed before making a burn that would be gameplay tested.

yeah ofers engine is probably what he's referring to when he says 'spherical worlds' which would be correct, their bonus game environments would have not rendered correctly in that engine.
In the extreme boss engine their arenas and textures were converted to mdl/sg3 poly models and vdp tiles and rendered without any fuss.

Hmm lets see what else I can share.
Audio wise, I used the audio tracks and sfx from the japanese version of sonic cd (mega cd) as placeholders (because those songs rocked in my opinion), because xtreme's soundtracks were still being composed. Having to use something like the u.s. version of sonic cd music would have killed me  :P

'sonic saturn' that was worked on by peter/adrian was a completely seperate game project and was considered a satellite office of sti by most.
However that sonic head wrapped with the saturn 's' on the 1st page was made by ross harris on a whim for the xtreme project and used as a loading splash screen.
That screen was inferred to mean 'sonic on the sega saturn' - not be the new or tenative title of our game.

Harris also was responsible for modeling the 3d sonic and other objects in 3d studio/soft image that were rendered into 2d sprites and did other pieces of artwork for xtreme.
Back when I was using the sprite sonic in xtreme, harris agreed to my 'experiment' by modifying the original sonic model into amy sonic since it wasnt going to really require any extra animation/skeleton work. It only took a couple days work to model the new shoes,eyes and ribbon and render all the sprite frames out. I wonder if those sprites will ever surface because she came out awfully cute. It was basically a sprite swap in game to play amy in the boss engin= I never got around to modifying the spindash/spinslash/jump/running speed mechanics in the hopes we could make the game play differently if we ever allowed people to play as amy. Having amy in the game was not chris senn's original plans but something I explored myself - I figured if we were going to add more playable characters amy would be the easiest one to prototype for obvious reasons.

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

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.