Because... 8F80 & 07FF = 0780 x 20 = F000 "VRam location" It's declare them to be at $F000, not 8F80 =P
Where did you get that 07FF number from? The wiki just describes a bitmask in the mappings, with 11 bits for the address, which multiplied by $20 should give the VRAM address. I'm thinking I've been reading something incorrectly that is giving me much trouble.
11 bits = 0000011111111111 = 07FF If you take the last 11 bits of 8F80, you get 0780, in exactly the same way.
It seems people are starting to get interested in S3K hacking. Well Now that these posts were brought to my attention I'd like to say that My disassembly is more complete than that of Andlabs' and that I've been doing work on my hack from it. It's more or less 65% complete in terms of labels. Enumerations are 40%. I am still working on my disassembly but I wont' release it till it's more tangible for others to be able to work with and understand better. It took me awhile to learn how most things have worked in S3K but I've got S3K down to around 3026kb. It's still in the works and I will release it when everything is complete to make everything easier on everybody. So expect it sometime in the next several months as I do have other things to work on such as a Super Mario RPG hack and other things.
Alright, thanks for the lessons folks, I finally get what Thorn was saying in detail. I'm not seeing a $2434 anywhere in this sprite mapping file though. Or a $?780. Just for clarification, I'm using the current split dissasembly, and looking at file "mappings/sprite/obj36.bin". First few bytes of said file of said file: Code (Text): 00 10 00 22 00 44 00 76 00 b8 00 ca 00 ec 01 1e 00 02 f0 07 00 00 00 00 ff f0 f0 EDIT I R DUM LOL The mappings just maintain an index of the tiles from the VRAM offset. The VRAM offset is declared in the object's init subroutine. Code (Text): ; loc_15926: Obj36_Init: addq.b #2,routine(a0) move.l #Obj36_MapUnc_15B68,mappings(a0) move.w #$2434,art_tile(a0) Am I correct on this? AGAIN EDIT - Aha! s2.asm, I have vanquished thee! Line 25972 - Code (Text): move.w #$242C,art_tile(a0) The art needs to be at $8580. I tried it and it's frickin' working. I just need to sort out the art file and the mappings now. Thanks for the help folks! FINAL EDIT: Art sorted. Horizontal spikes working, and well. Thanks again, kids!
I wonder where 2P mappings are kept. I can't find something special for Emerald Hill/Casino Night/Mystic Cave.
Grr, I still can't get GHZ to load correctly after building my ROM. I even re-did all the steps in the guide 3 times over, and still the same choppiness. Does anyone know if I'm doing anything wrong? Here's the picture http://s915.photobucket.com/albums/ac358/V...if&newest=1
Hey folks, I'm having some issues. Something is corrupted in my rings data. When I use my custom layout, the 128x128 chunks mess up visually. The game runs as if the correct chunks were loaded (I can still run around, go through loops that I can't see, etc), but all I can see is the same 4x4 set of 128x128 chunks that are near the character starting location of the level. The problem goes away if I revert to the original ring data for the zone. My ring data is also smaller (mine is 448 bytes, original is 552). Any ideas as to what might be causing the issue? Ring data edited with SonED2, on a split dissasembly of s2rev01, if that helps.
^ The data size may not be the issue. Notice that in SonED2, you can create rows and columns of rings from length 1 to 8. While the file saves this row/column data, every ring is considered individually in-game, so you can get a data overflow despite having less sets of rings if there's more rings per set. You could eliminate rings, or consider <a href="http://info.sonicretro.org/SCHG How-to:Port Sonic 3k's rings manager to Sonic 2" target="_blank" style="background: url(http://info.sonicretro.org/images/5/50/Reticon.png) right no-repeat; padding-right: 20px; border-bottom: 1px dotted #3366BB; color: #3366BB; cursor:pointer; text-decoration:none;" class="wiki">SCHG How-to:Port Sonic 3k's rings manager to Sonic 2</a>.
Very cool, I'm working on that new ring manager now. Muy gracias, Thorn! EDIT: Blah, the files provided with this are a bit out of date. Most of the branches are pointing to loc_XXXXX as opposed to the newer labels. Most of the labels still have their loc commented above them, but not all, so that's causing a few issues. I, as best as I can tell, have fixed them, but I'm still having some issues. It hangs on the title card, but music continues playing and I hear a lot of rings being gathered at odd intervals, followed by a subsequent gaining of en extra life.
Question regarding 8x16, that's actually a Mega Drive thing, not a Sonic engine thing right? It's used for the interlaced modes right? (Or at least #2) IIRC it just uses two VRAM cells together to make the 8x16... so it's gotta have stuff loaded in there that when interlaced together will look like one clean tile)
I'd like to add an extra monitor type to Sonic 1 that gives Sonic extra time when he destroys it (like the Blue UFOs in the Sonic CD special stage). I've added the extra monitor type, but I'm not sure how best to subtract 20 seconds from the Time. I'm so used to coding in high-level languages with modulo commands and everything, but I'm lost when it comes to ASM.
This should do it: Code (ASM): sub.l #$1400,($FFFFFE22).w ; substract 20 ($14) seconds from the time move.b #1,($FFFFFE1E).w ; update time counter In $FFFFFE22 you have the time as a longword in this format: $MMSSMS. MM are the minutes, SS are the seconds, MS the milli seconds (not displayed but used for counting the seconds). However, you will need to do multiple checks too: 1: If your time is below 20 seconds (for example 0:09) you want to reset it to 0:00 instead of substracting 20 seconds from it or else the time counter will glitch up. 2: If you destroy the monitor so you get back to the last minute (for example you are at 1:17 and destroy the monitor) you will additionally need to put down the minute counter a bit (if you understood what I told you above, that shouldn't be a problem for ya).
This is my last trial post, so I have to use this wisely. Anyway, I have this question, and I'll make it clear as possible. How do most of you make your level art graphics for Sonic Games? I mean, this is a complicated question for me, but I want to learn how to make my own original level art, so it won't look like some common recolor or something so bland. Take Project Sonic Retro for example. It had such a beautiful grass level. a mass amount of talent and knowledge, that I alone don't have enough of. I want to be able to make something as unique as that, or at least have help making something unique as that. I've been trying to make my own Sonic game since the beginning of click products and such, and you think, by now, I'd be better at it. I am, but not when it comes to the pixel art. I've been trying to get someone to help me on that sense, so I think I may as well try asking again here. All I ask is please... Don't Spam me.
The idea behind making a level for sonic games is dependant on what sonic game you're editing, as each one has it's own special engine, and there's VDP (Video Display Processor) rules to follow. The VDP has 4 palette lines holding a total of 16 colours per each line, excluding the first colour which acts as a transparent colour use. There are individual blocks of art which we call "Tiles" (Or has also been known as "Cells"), each "Tile"/"Cell" is made up of 32 pixels in an 8x8 pixel square, example: Each of these "Tiles" can use 1 of the 16 colours using 1 of the 4 palette lines, these "Tiles" are grouped together in "Blocks" of 4, like so: This is known as a "Block", each block holds 4 tiles making a total of 16x16 pixels in size, each tile within this block can be either flipped, mirrored, set to use any of the 4 palette lines, and set in hi or low plane (In front or behind). These blocks are grouped together in a large square called a "Chunk", these chunks make a total size of 256x256 pixels for Sonic the hedgehog (16-bit megadrive/genesis), however 128x128 pixels for Sonic the hedgehog 2, 3, & Knuckles (16-bit megadrive/genesis), like so (Sonic The Hedgehog): Each of these "Chunks" can hold "Blocks" which can be flipped or mirrored, and set a certain solidity. These "Chunks" are held in a large section of space known as a layout. To edit these "Tiles", "Blocks" and "Chunks", they must be firstly decompressed, each one is compressed in a certain format depending on the game, once decompressed, they can be edited via a hex editor, then recompressed and saved back into the rom. Now most people don't like using hex editors, and for such an important thing for games as level editing, I don't blame them. There are however, tools which can be used for editing the levels, if you are editing the rom itself via hex hacking, then tools such as: ESE by Esrael and SonED by Stealth ..can be used for doing this in a more confortable way, though if you are editing the first sonic game, then there is a bit of manual work to do, as SonED tends to edit the savestate data rather than the rom itself, so you'd need to extract the data from the savestate, save it, and insert it into the rom, and maybe change a few vital pointers. If you are editing a Disassembly then you might want to take a look at SonED 2 by Stealth, this is used for editing levels for disassemblies which does not require savestate editing, hex modifying or pointer changing of any kind, and is the most recommended tool to date. Check those links out for more information, other links may include: http://info.sonicretro.org/SCHG_How-to:Import_Art_to_SonED2 http://info.sonicretro.org/SCHG:SonED2_Manual Good luck.
If you need help with art, I'll be happy to give you a hand. Just msg me over msn and we'll get spriting. Also don't worry, when I first started, I felt like making my own art would be as complicated as doing advanced mathematics. But once you learn some of the basics it becomes as easy as riding a bike. So like I said im happy to help you and or any one who needs it.
I can't believe my last post failed slightly. But unfortunately, regarding the earlier post, That's not exactly what I meant by making level art. I don't know the first thing about hacking Sonic ROMS. The above is very useful advice, I won't lie. What I mean was, actually making the art. Making levels like in these images pixel by pixel so well. I want to be able to make THIS. Sorry for bringing something old back up, but there is no greater example.
Open MS-Paint or similar program. Use basic art skills. ?????? Profit. There's nothing more than that to it. You just need to know how to draw in some form and you're done.
Oy. I'll try not to make this confusing. I wish I had the skill. I thought I did before, but there were a good few that didn't think so. I just don't know how to make anything better. By sonjohenji at 2010-03-14 This is my oldest bit of proof. But I know a lot of you will say that it's no more than a knockoff. It can't be anything better. It would just be better if I got someone else to help me make this better or even make other zones.
