Normally, the VDP works with 8x8 tiles. When double resolution is enabled, it works with 8x16 tiles instead. The pattern indices (the low 11 bits of a tile in a plane) are affected by this: instead of multiplying the index by $20 to find the tile's address, you multiply by $40 instead. In Sonic 2, when the block mappings are loaded into RAM, it shifts the pattern indices right by 1 bit to account for this; Adjust2PArtPointer and Adjust2PArtPointer2 do a similar job for the art_tile property of objects. Also, the sprite mappings all have the precomputed pattern indices to use in double resolution mode as well as the pattern indices to use in normal resolution mode. When rendering the blocks in double resolution mode, only the top row is effectively written, since a row isn't 8 pixels high but 16 pixels high. If you load a level that's designed for double resolution mode, you'll see that the pattern indices in the bottom row of every block is the pattern index of the tile above it + 1. This is necessary to be able to use the same tiles and block mappings in both normal resolution and double resolution modes. If this rule is not followed, you get garbled graphics.
I will add that SonMapED doesn't correctly shift the pattern index for 2P mode, incorrectly leaving the top byte unchanged.
So basically - I need to make sure my art is using 8x16 tiles, then make sure I have my block format updated to take only two tiles instead of one. Also - since this is double resolution, would I need twice as much space for the name tables and the HScroll data, or is this all shared somehow? I can imagine that sharing HScroll data might be a pain, but meh. Also- I guess this somehow affects sprite mappings, too? Or will they just continue working with regular 8x8 tiles, which I'm guessing they will? I guess I should just get off my arse and code something that shows a few letters in the top half of the screen and something else in the bottom or summat.
So in my boredom I was playing with the ReadySonic project files and trying to make a new custom layout. The problem started when I put a looping in GHZ1 using SonED2 v11.05.19. The problem is the following: All the foreground and background chunks disappeared leaving only the objects and leading Sonic to death if I start the level. My doubts are the following: - Why did that happened? - And if it's there a way to solve this problem. Or must I start it all over again? Sorry if this was posted before and sorry again if this is a really easy problem. :P Thank you in advance... EDIT: Nevermind, the problem is MUCH worse than that. I must use the classic SonED2 and start it all over again. Again thank you.
Hm... My sonic 2 mod is suffering from a huge slowdown when losing rings; I was thinking, maybe I could lower the ammount of rings shown. I don't know, at most, how many rings can be displayed at the same time (about 20 or something?), but how can I lower the max ammount of rings displayed when losing rings?
For Sonic 1 the routine is "Obj37_CountRings" and the instruction is "moveq #32,d0", for Sonic 2 the routine is "loc_120A2" and the instruction is "moveq #$20,d0" (Same amount, just hex obviously), for Sonic 3 (I had trouble with this due to lack of knowledge of where the damn objects actually art), the only place I could find in such a small space of time was "sub_89DAC" for the FBZ prison ring loss (6 rings at "ChildObjDat_89EF0" "dc.w 5".
Does the badnik roller's art work differently than regular badniks? I have changed art and mappings but one of the frames seems to be garbled http://dl.dropbox.com/u/40547891/pjelcSanshrw.wmv
You're probably encountering a variant of the good old Roller bug which is present even in plain Sonic 1. Basically it loads the Caterkiller art in one of the frames. Most recent post about it: http://forums.sonicretro.org/index.php?showtopic=10693&view=findpost&p=194630 Another random post about it: http://forums.sonicretro.org/index.php?showtopic=11681&view=findpost&p=216316
I have recently started to make progress with my hack. I am attempting to import some custom level chunks into a sonic 2 disassembly using SonLVL. Upon importing it is displaying the incorrect palette. When I created the tile I ensured that all colours I used were from palette line 3 (Which I assume is the level chunk palette because of the variety of browns and greens) however when I import it appears with the shades of blue. I can only assume it is using palette line 1 for my custom chunk. What puzzles me more is that in the Tile editor view (of the tile / block / chunk editor) the palette is correct and in the block view it is stating that tile I am using is the correct palette, but it is still displaying shades of blue. Can anyone aid me on this venture? Edit: Just built and tested it and it seems that when played the entire graphics for my chunk are garbled. :S Edit 2: Should have noted I am using the SVN Version of SonLVL and the Sonic 2 Disassembly.
If you want to be absolutely sure what palette line it uses, export the level's palette to PNG, apply it to your image(s), and save as 8bpp (256 color). If the image is 8bpp, SonLVL uses the indexes to choose the palette instead of trying to match the colors. If it's 4bpp or 1bpp it defaults to palette 0. Otherwise it tries to match the colors in the image to the closest color in the palette, and whichever palette has the most matches is chosen. No idea why it's corrupted ingame though, unless you accidentally added too many tiles, and they're being overwritten with other graphics.
I'm still incredibly baffled by this. I used print screened hive pal and that is the palette I have been working from. I have just exported the correct palette line (palette line 2 ((in my explanation I forgot that the first palette line was 0 as opposed to 1) and all the values line up. Saved it again and I'm getting the same thing. I'm not sure about adding too many tiles, I literally selected one chunk, deleted it and then imported my own chunk in. That might have caused a tile overflow causing the overwrite. Interestingly, when I set the collisions to solid it appears to completely ignore them. Edit: On second look, it might actually be the tiles causing the corruption because after importing my chunk, I go into the tile editor and scroll to the bottom and the tiles that would be included in my custom chunk are not fully there. The palette issue still remains though. I am using Photoshop so it is more than likely an issue that I am causing with how I am saving or editing the pieces.
Yeah. I only did a single chunk as a test and made it exactly 128x128. Do you need to delete all existing chunks to successfully import custom chunks or can you do it on a chunk by chunk basis? Edit: I just double checked and it is doing the same thing with both a .png and .gif version of the same image. Edit 2: Ok. The corruption is fixed ... Somehow (it might have been the .gif version that helped). Palette issue still happens and the collisions are still getting ignored.
For the palette, did you try exporting the whole level's palette, and using it for the chunk image? And did you set the collision for both layers of the chunk to "All Solid", and assign a collision to the blocks? (use View -> Collision -> Path 1 to help)
I have just set the collisions to all solid, I'm not sure how to assign a colission to the blocks, I did it earlier but I can't seem to do it now. I'm gonna take a little break now and experiment and chill. Thanks for all of the help MainMemory and I will let you know how I get on. --- Edit: I have attempted to import some slightly different art but it seems the palettes are almost correct. It is persistant in selected random parts of tiles (that are consistent in colour) and just filling them with a random other colour. I'm going to keep trying though. --- Edit 2: I just tried re-importing one of the chunks that was exported using SonLVL and the palettes are still incorrect. (It keeps using blue instead of some of the browns). I still don't know what is causing this. I'm going to try re-downloading and trying again. Other than that, It's a very cool program. Edit 3: Still hitting same palette problem, I'm sure it's something on my end because lots of other members have used the program fine. I'm not sure exactly what to do. How does everyone else import custom level art?
I wanted to ask... why does Sonic 1, 2 and 3 all have completely different sets of collision blocks? AND, would it work to put all 3 sets into 1 library for a program to read from?? I'm asking, as I am working on a fangame... not a hack. But the fangame is meant to emulate the physics and the engine... So I think this question should be here.
Evolution, progress and improvement... ...is why the collision array has changed through the series, not to mention that there are certain gimmicks that required specific blocks which don't exist in later games, Sonic 1 for example has collision blocks for SBZ's tunnels, these I don't believe exist in Sonic 2 or 3+, and because they aren't needed, they would be replaced with something a little more useful based on the gimmick they needed them for. A collaboration of all three for a fan game could prove to be useful, but as far as I'm concerned you should strongly consider making a completely new set of your own, so you can generate your own specific gimmicks, play style, and differ the playability a little in your fan game, making it more original and much more fun and unexpected.
