Thanks a lot rstewart, I'll experiment swapping the backgrounds between levels.
This is how my mushroom platform is going:
I have to recheck everything, because I think some triangles are missing. For the textures, I just swapped the whole texture bank for now.
I'm now building the collision for this. Before turning this into a specific collision behavior, I'm writing the collision data in the level collision pointed by the 0x2E command. This way, I can see the collision in TT64, because it can't read (yet?) collision from behaviors. However, I have a question concerning level collision.
Flatworld collision is very simple:
00 40 00 04 <------ Loads 4 collision data vertices [followed by 4 vertices X,Y,Z]
00 00 00 02 <----- Loads 2 "0000" collision triangles
00 00 00 01 00 02 <----- triangles
00 00 00 03 00 01
[Now here comes my mushroom collision, one 00 40 00 0F command followed by vertices and chunk of triangles. After this comes the "end commands" 00 41 00 42].
Now when I open TT64 my collision triangles are all messed up, because in the second chunk of triangles, he used also some of the previous loaded vertices.
This is a picture of what I get:
See how not just the new vertexes but also the previously loaded are used? (the ones that make the big "death at the bottom" giant plane)
If I point my collision data to start at the second 00 40 vertices/triangle chunk, I get correct collision data (incomplete at the moment):
So, there must be a command that resets the vertex cache and goes between the 00 40 load vertex chunks, is that right?
Edit: Nope. I was looking at the collision data from Castle Grounds, and it seems that there is just one HUGE list of vertices and collision triangles. Now I see why 0xBF use just one byte for each triangle vertex pointer while collision triangles use two.
---
Edit 3: Ah, my mushroom now looks better  . The stem always looked a bit akward (look at the colors in the first screenshot. It is also a bit transparent). If you look at the Geo Layout (check earlier post), you'll see that the polygons are divided in two "drawing layers" (as VL-Tone calls in the Hacking doc). Since the geometry is composed of jumps and I'm importing this from another level, the second drawing layer (in fact, number 5) which draws the stem of the mushroom must have different properties than the first one, setted somewhere earlier in the data or maybe some global properties set in terrain geo layout. I unified the polygons in just one drawing layer. It looked better (more solid), but the colors were a bit messed up.
Then I erased this "FC12 1824 FF33 FFFF" command on the beggining of the second layer data and things turned out even better. I may have been a bit lucky, but it worked, and now it looks way better.
Enough of the mushroom saga, I hope you appreciate my effort for this, as the pratical results will surely be interesting!
---
Last edit for this post: I finished the collision for this. Converting any 3D model into the collision data format should not be too difficult (just time-consuming) and could be possibly done automatically. If there is interest, I can post more detailed
information.
Download big mushroom collision data.
One absolutely great thing is that the "0000" collision triangle is somewhat flexible. If there is inclination, it will act like a hill, and if there is too much of it, you won't be able to climb it or it will turn itself into a slide. I first realized this when I made the first "height terrain" level, but it amazed me how well my mushroom collision worked.
-- New video !!
<object width="425" height="350"> <embed src="http://www.youtube.com/v/6lBRXHZrc_g" type="application/x-shockwave-flash" width="425" height="350"> </embed> </object>
|
!!
. If I set drawing/disappear distance to maximum for all 0x24 objects, the level gets very slow.
