@lunarstudio I tried to port some sprites from origins, and as result- one is good, but another- shit, made from random tiles.... It's also happens in Flex2, so.. maybe it's problems with S3K game format? In game- it also random tiles(
I'm noticing that it's going back to the start of the tile bank. How many tiles do you have? DPLCs can only support so many tile offsets.
Um.. I didn't expand it much.. just for a couple of sprites... I don't remember how many of them are in the original, it seems.. FF? Or DC.. Even so, Sonic has much more frames without mapping separation... is there really no way to get around the frame limit?
The DPLC format can only support up to $1000 tiles. The format of a player DPLC entry is as follows in binary: llll tttt tttt tttt l = Number of tiles to load (minus 1) t = Tile offset, which only has 12 bits, meaning the the range is 0-$FFF. This is why you're seeing the starting tiles in those corrupted frames, because it has wrapped back around to 0. The other DPLC format doesn't seem to be any better for your situation. It appears they just swapped the location of l and t for more optimal performance in bit shifting. You're either gonna have to set up a new DPLC format, split up Knuckles' data into 2 sets, or find ways to optimize the tile data to use less tiles.
It should be noted that Sonic and Tails already have had their DPLC lists split up between art common to Sonic 3 and Sonic & Knuckles and art solely in S&K. Not that Knuckles's frames are properly optimized, though.
When sonic is facing left or the collision data is flipped, do things need to be corrected as we'll? In the sonic game, quadrant 1 2 3 and 4 in the game are quadrants 4 3 2 1 in normal math grid correct? ( though there aren't quadrants in the game ) .. But if you face left x sign switches. If the solidly data flips it will change . so wouldn't sonics angle change depending on his facing direction as the initial ray of.the angle would move if he is facing left because the quadrant order would change? Sorry this is a confusing question . I think I am.confusing and mixing concepts.
The way collision works is that there are 2 sensors on the bottom of Sonic's feet, and it simply picks the sensor that finds the highest column. These sensors do rotate according to which "quadrant" Sonic is in, downwards in floor mode (angles E1-20), towards the right in right wall mode (angles A1-E0), towards the top in ceiling mode (angles 60-A0), and towards the left in left wall mode (angles 21-5F). The direction Sonic faces does not affect the sensors in any ways, nor does it affect the angle. The negative ground speed when moving left will automatically take care of sending Sonic in the right trajectory when it gets multiplied by the sine and cosine of the angle (i.e., say you go down-right when facing right, meaning that both the X and Y speed signs are positive, negating the ground speed when moving left will cause the signs of the X and Y speeds to be negative as well, and make Sonic go up-left). The flip flags in the blocks do flip the angle, though.
Why do some characters in Sonic Adventure go faster when walking up slopes? This is most notable with Big. I've always wondered what makes this kind of thing happen.
I'd be astonished if I were right, but I latched onto the notion that the larger characters appear to move faster up slopes due to their meatier frames/animation needing to catch up.
Lapper Solid Tiles article states how sloped ceilings are possible if the height arrays start at only one end . that the tiles can be flipped horizontally and vertically. And the collision system takes this to play when reading the height data from the tiles. My question is it at the chunk level that lapper is referring to everything dynamically at run time being flipped thus flipping all the block (sub units and thus solidity data )? Also can you flip Individual blocks in the chunk independent dynamically?
Chunks do indeed have flip flags for each block, and the game does automatically flip the angle and heights/widths accordingly.
So want to make sure I understand this correctly - That the sine table values are slight off . Hex times 1.40625 gives angle in degree. If hex angle is 0x5 or 7.03125 in degrees , the sin of 7.03125 is really 0.1224106751992 but in the sinewave table it is 0.12109375 in float ( 0x001F 8.8 fixed point ) . I am assuming the reason for this loss of precision is : 1. 8.8 fixed points fractal part can have a maximum of 8 places. And 2. The 8.8 fixed points fractal parts value has to be a summation of 2^-1 , 2^-2 ... 2^-8 and the fractal part smallest value and the amount it increments by is 2^-8 .. Ie 1/128 = 2/256. So this is the reason the fractal is can only represent fractions that are between and including 1/256 and 255/256 by 1/256 increments ?? Just as the integer part smallest number 2^0 = 1 is the increment ? Is this correct?
What's up with the crushers in Marble Garden? Why do I get killed when trying to sprint past them, even when they're completely open?
