It didn't fix the cogs as there is only 1 bit correctly placed on the cog and the cog itself is not moving. Edit - (8/5/16 - 6:41pm) : My mistake, it works. Thanks to everyone who helped through this problem. You will be credited
Hey guys, I have a question. How do I go about making a player object greater than 64x64 (probably 96x96) with 24 colors? I am looking at some of the solutions that Sonic Team made like 2 sets of palettes, segmented bosses and multiple objects that merge. I do not think that all of that is necessary but, I don't have much a clue which channel would work best.
By very clever craftmanship. Or using 32X. making sprites 96x96 is actually very easy by simply adding more mapping pieces to it. Larger than 256x256, you will have to consult Sonic 2. As far as multiple palette lines, most mappings editors let you add bitmasks to the tile offset, to specify the next palette lines (or with clever stuff, previous also)
I thought I'd ask this here rather than starting a whole new topic. I'm trying to edit the sprites in Taxman's Sonic CD 2011 port. I've been using Retrun-Sonic to unpack and repack the rsdk file. When I edit the sprites they either don't show up at all on the screen or the palette and transparency are messed up. It bight be because I'm a turd when it comes to editing gif files. Does anyone have any experience with this? The related where I came across retrun-sonic thread can be found here
So, guys, I've been having a REALLY weird problem with the latest version of the Sonic 2 git disassembly. I mean really weird, too. It's making my work a lot more difficult than it needs to be. If I do anything that results in a moderate filesize change, i.e, adding a lot of code or something, I'll often get an error message like this: Code (Text): > > >Code/Obj12(HPZLift).asm(14): error: addressing mode not allowed on 68000 > > > jmp Obj12_Index(pc,d1.w) > > >Code/Obj12(HPZLift).asm(14): error: addressing mode not allowed here > > > jmp Obj12_Index(pc,d1.w) ... The thing is, not only is that completely unrelated to what I was editing, but that's not even erroneous code, the builder is just SAYING it is, but the label Obj12_Index is defined in the very next line. This has never happened in older versions of the disassembly to my memory, but it's happening a LOT now. Any ideas?
Those lines are trying to do pc-relative addressing, but there's too much stuff between the source and the target for it to reach. Either switch to absolute addressing, or move some stuff outside the range. EDIT: Or move the source and target closer to one another. That's what you should do anyway when you're accessing it via register displacement. jmp Obj12_Index(pc,d1.w) means "calculate the (relative) distance from here to Obj12_Index as a word value, add it to the program counter, and also add the word value (displacement) from register d1". If Obj12_Index is too far away, that distance won't fit in a word and the assembler will cough up blood. Unfortunately I don't think there's an absolute addressing mode that also supports displacement.
It is important to note also that "Obj12_Index(pc,d1.w)" addressing mode only allows you to index something up to 128 bytes before, or 127 bytes after, pc*; so if pc is further away from Obj12_Index than this, the code can't be assembled. In contrast, "Obj12_Index(pc)" allows up to -32768 bytes before, or 32767 bytes after, pc. And yes, AS' error message sucks. So another way to fix the issue is: find an unused address register you can use (lets say a1); then for code like this: [68k]move.w Obj12_Index(a1,d1.w),d0 jmp Obj12_Index(pc,d0.w)[/68k] you would use something like this: [68k]lea Obj12_Index(pc),a1 move.w (a1,d1.w),d0 jmp (a1,d0.w)[/68k] This is 8 cycles slower (2 extra read cycles) due to the additional lea instruction. * Technically, it is pc after the instruction word but before the extension word; in most cases, this means you can actually address up to 32766 bytes before, or 32769 bytes after, the instruction.
Wait, so which one is it? Is it a short or a word? I assume your footnote was referring to pc-relative without displacement, but the displacement version is limited to the [-128, +127] range counting from after the current instruction (short, which I was not aware of).
Oops, I mixed them up here; I gave the values for word in the ffootnote while I was talking about short. My bad. The effect of the footnote is: the displacement for these addressing modes is counted from neither the start of the current instruction nor from the start of the next instruction, so if you count from either of them, the range of the addressing mode seems to be extended in one direction and shortened on the other.
A quick Google search indicates that you're probably right, and the range for a short branch is probably -126 to 128, but it just as equally finds publications claiming it's -128 to 126, or my favorite, -126 to 129. Clearly this is a very important subject that's been target of much scrutiny. Though this brings up another question: why the frig is it counting bytes when jumping to an odd address always halts the processor?
-126 to 129 is the correct one, but using 129 leads to address errors (and most assemblers will not let you use this maximum range anyway). I said basically this over in IRC some time ago. In hardware terms, they could shift the offset by 1 for free while doing sign extension to 32-bit, and doing this would have doubled the range of all branches (short and word ones). I think the only reason why they did not do it is the pc-relative addresing modes: there are legitimate uses for reading bytes from odd locations: [68k]move.b MyArray(pc,d0.w),d1 move.b MyArray+1(pc,d0.w),d2[/68k] Add in that they most likely wanted to keep notation consitent between jumps and other instructions, and you can see why counting bytes became a thing. You completely misunderstood what he was saying.
Having more than 15 colors will require you to use different lines for some tiles and overlaying them. I hope you like what I'm going to say because it took me a while doing it :p I took your Big's victory pose as example. First, I convert the colors to the more accuarate genesis ones, but that's just because me being obsesive. Then, I split Big on 2 different sprites, each one with different palette lines. In the first one I placed the purples and browns, and moved yellows and grays to the second one: Then, the most tedious part is optimizing your tile usage. Why? Because theese things will literally eat VRAM so we want to load as few tiles as possible. What you can do is not only avoid the empty tiles, but also create more empty tiles by slicing the sprite into different pieces that won't match just like that, but after proper mapping they will show just like the normal ones: The red and yellow dots serve their purpose to help aligning task. At the right, that's a possible way to load the tiles. As you know, you have to create a sprite by uniting different pieces. They are showed in the colored rectangles. If you think that slicing the sprite is a worthless and tedious task, here am I comparing a sliced sprite tile usage with a non sliced one: 121 total 8x8 tiles for the sliced sprite. 133 total 8x8 tiles for the non sliced one. 12 tiles in such a complicated sprite that uses that many tiles are worth saving in my opinion. The downside is that you end with 33 calls for pieces, while you can get way less without slicing it. That depends on what do you prefer saving, VRAM or cycles. Then, using your prefered mapper, you assembly the sprite using the correct palette line for each piece. Once you done it correctly, clean the sprite and you will get the final result: Note that you will have to do a LOT of work in coding for making this thing work in a genesis, I don't expect it to run on a normal Sonic 1 for example, even with DMA Queue. EDIT #whoknows: if I remember correctly, I linked you a RTF document with mapping info for dummies like me, so it is very well explained.
I will add that at 121 8x8 tiles spread over 33 sprite pieces, you end up using over 1/3rd of all DMA bandwidth available during vblank (121*8*8*4/8 = 3872 bytes out of 9702) and nearly half of all sprite pieces in the entire screen (only 80 sprite pieces in entire screen). Also, in some parts of the final sprite you end up with 10 sprite pieces per scanline (half the maximum), and the overlapping sprite pieces bring you even closer to the limit of 320 sprite pixels per scanline. Meaning that even if you get this sprite to work, it or other sprites are likely to not be fully drawn.
Indeed, that's why I said I don't expect it to work on a normal Sonic 1 for example. There could be at max 4 objects on the screen, so no way of getting a 'simple' Big the Cat in Sonic The Hedgehog. Now if we're talking on a completly different game, then something could come up from there.
Wow I didn't know that you were looking into it as well, rata. I was looking at what I had to deal with by using the standing sprite and found that it took 75 tiles on 10 pieces and that is just with directly setting a sprite on SonMapEd. There's little chance that a sprite set this large will make it in hardware without major cutbacks in visuals "just" Sonic 1. I agree with you and Flamewing on that. I don't think either the original or a 64x64 version will help matters for the Mega Drive games, but if 32X or CD helps, I might have something to pursue. Otherwise, I will start a crash course on making a game engine or just animate a fake game for this Big the Cat set, it's too good of a set to just scrap. :v: I do have other sets of characters that are a ton easier to make into this that are 15 colors or a lot smaller than 80x80, it's just finishing them up, making sense of the funky palettes and coding that will take time with making those a reality.
While learning something like 32x would be cool as hell, I do agree with flamewing after he stated some points, and it's that simply who does have a 32x? 99% of people will play it emulated, and 32x emulation is sort of screwed up. Maybe a PC fan engine would suit better for what you are trying to do. I also agree with you that scrapping a set that awesome should be considered federal crime.
Sorry for not responding to all this sooner - at the time I posted that, I was having really bad internet problems, and I couldn't even tell it got posted properly. The sad part is, that the error it was reporting wasn't even a valid error. Forgive me if posted this already, but this is the literal code: Code (ASM): moveq #0,d0 move.b routine(a0),d0 move.w Obj12_Index(pc,d0.w),d1 jmp Obj12_Index(pc,d1.w) ; =========================================================================== ; off_10A16: Obj12_Index: Incidentally, I DID end up fixing the issue somehow without changing the code, but I don't remember how, I think I added a nop somewhere above and it kind of just... worked.
If it means anything, I swear I've run into strange errors like that before. I just chalked it up to a bug in AS.
