Ah ha excellent thank you. I should've thought of that but didn't know there was a specific page for ring loss on the wiki. Well now I know how to tackle these things then that I'm working on.
A quick question. Have I got the execution times right? If not, what is it? Code (ASM): tst.w (Camera_Min_Y_pos).w ; Does this level y-wrap? 4(1/0) + 8(2/0) = 12(3/0) bpl.s + ; If not, branch and skip looping 10(2/0)[taken] OR 8(1/0) [not-taken] andi.w #$7FF,y_pos(a0) ; perform wrapping of Sonic's y position 12(2/1) + 4(1/0) = 16(3/1) + If this is right, that am I right to say that it would be faster just to 'andi' the y_pos all the time rather than asking if it needs doing or not? The "y_pos" in question is Sonic.
In Sonic 2, they're all $800 or less ( I should have mentioned I was talking about Sonic 2), everything works so far without the checks...
Code (ASM): tst.w ($FFFF8000).w ; 12 bpl.s Location ; 10 (08 non-branch) andi.w #$07FF,$0C(a0) ; 20 That alone will cost you 22 cycles when branching, and 40 cycles when not branching, thereas: Code (ASM): andi.w #$07FF,$0C(a0) ; 20 This will cost 20 cycles constantly.
andi.w is 20 cycles? I thought it was 16 "12(2/1) + 4(1/0) = 16(3/1)" ? Either way, just "andi"ing it constantly is still faster than doing the checks. By 2 cycles :v:
In SonMapEd, I seem to have completely forgotten what object mappings to use for the HUD number. It's not 21 since that's SCORE TIME RINGS and loads the number tiles in that part, with the number and lives parts with garbled mess tiles. So, which mappings file do I use?
This is very difficult to explain so please forgive me if you have trouble understanding. First things first, the hud mappings (21) is setup prepared for VRAM, all of the individual sprite pieces are indirectly pointing to a "specific" VRAM address, you'll be able to see the "SCOR", "TIME", and "RINGS" when you load up the hud art, but you will not be able to see the actual numbers or the lives icon, it's not that you have the wrong map list file, it's simply to do with the lives art being a seperate file/item that gets decompressed to a different location in VRAM, but is displayed using the same mappings. The same goes with the letter "E" the colon ":" and the numbers for the hud, except these are uncompressed, what I mean by this of course is that one of every possible number is stored all in one file "artunc/HUD.bin", the file will contain the art like so "0123456789:E" in that order, what happens is that these numbers are loaded in real time to VRAM when the score, time or rings are updated, so if you collect a ring and have 1 ring, the system will advance to the place in the art file where the number "1" art is, and it will load that art into VRAM, the reason for doing it this way is to save up on sprite usage. If you are looking to edit the hud, then it isn't impossible, but it will be a challenge, SonMapEd simply isn't designed to work with multiple VRAM specific addresses/data. So, you'll need to edit the lives and number art/positions seperately to the mappings (21), so plan carefully. Of course, you aren't restricted to SonMapEd for editing sprite graphics, you could look into other tools for editing the art, I also recommend learning how to edit the actual sprites manually if necessary, not for practical use, but for knowledge, gaining knowledge from this is what you'll need to make the necessary edits you want with little hassle.
The HUD mappings for 1P mode are in mappings\sprite\hud_a.bin. hud_b.bin and hud_c.bin are for 2P Vs. I think.
Thanks for the insight as to how it all works, it made sense as I noticed VRAM stuff when looking through sonic1.asm in that area. While the art itself I already have edited and eveything, numbers, life icon and such (including making a small Adventure 1-like life icon, haha) I was more thing messing with the positioning itself, for experimental purposes. While I know even if the tiles aren't loaded in SonMapEd you can move the mappings around, I wanted to experiment by trying to add an extra digit to say the time counter (to have two 0s for minutes instead of one 0). Figured that was probably impossible in SonMapEd, partially because of the whole it being updated on the fly thing, and also because copying and moving garbled tiles probably wouldn't have accomplished much, haha. Forgot to mention I meant Sonic 1, sorry, haha. Though that is some useful information for the future so thanks EDIT: One thing I tried is changing the "hud_1" (I think minutes used that by default...not looking at it right now) in the minutes part to "hud_10" (again I think that's what seconds uses, so yeah). Of course without adding mappings for the extra digit it probably won't help much, haha. As usual I'm working with the Hivebrain disassembly, if that helps.
It's not enough to change the starting digit, you also have to change the loop counter in d6, which is the number of digits minus one. Of course if you're aiming to make the minute counter behave identically to the seconds counter, you might as well either comment out everything between Hud_Mins and Hud_Secs so they refer to the same code, or delete Hud_Mins entirely and change the branches to go to Hud_Secs. You also have to make sure there's VRAM space for that extra digit and have mappings include that extra digit.
When looking in the HUD Mapping (again this is the Hivebrain disassembly), this is the first part: Code (ASM): byte_1C5BC: dc.b $A dc.b $80, $D, $80, 0, 0 dc.b $80, $D, $80, $18, $20 dc.b $80, $D, $80, $20, $40 dc.b $90, $D, $80, $10, 0 dc.b $90, $D, $80, $28, $28 dc.b $A0, $D, $80, 8, 0 dc.b $A0, 1, $80, 0, $20 dc.b $A0, 9, $80, $30, $30 dc.b $40, 5, $81, $A, 0 dc.b $40, $D, $81, $E, $10 dc.b 0 And from comparing with ReadySonic, this line seen to be one for the time "n:nn": Code (ASM): dc.b $90, $D, $80, $28, $28 Now I might be completely wrong here as this might just be to do with positionings, but what would I need to add to put an extra digit before the "n:" part? So it'd become "nn:nn". Which messing about myself I got weird results like everything but the score flashing when I didn't have rings and the score being the only thing there upon getting a ring, upon other such things.
You need to change the very first byte from $A to $B, then add a new line. The 1st byte indicates how many mapping pieces there are to that whole sprite. If you want to add a digit before the n:nn, then you can create a new mapping piece and place it in front. To do that, you need to create a new line and edit the positioning and the art_tile of this new piece and it's positioning, etc. And not forgetting to change the $A to $B to indicate of this new line (otherwise it will never appear). To make things easier for yourself, copy the code you currently have from "byte_1C5BC:" and paste it in a new clean ASM file. Then, use SonMapED, and then use the new created ASM file you made as mappings. From there, using SonMapED, add a new piece, place it whereever you want. Then save it as the ASM file again. Then, open the saved file and replace your old code with your new one. See if that has worked. What are you planning to put in front of this n:nn, is it just a plain 0? Or are you making it count up so you can have more than 10 minutes?
You will need to add another sprite to this list for your extra digit, to do so, change the first "dc.b" value "A" to "B" (this is the number of sprites in the list to process, we're putting in 1 extra sprite, so this should be increased by 1), next, put in (preferrably on the bottom line (above the "dc.b 0" that's on its own (it shouldn't really be there, there should be an even there instead (I like brackets)))), a new sprite: Code (ASM): dc.b $90,$01,$VV,$VV,$20 Where 90 is the Y relative position, 01 is the shape (two tiles vertically), and 20 is the X relative position (which I've set as 20 which is one cell/tile (8 pixels) to the left of the 1 minute digit, that's where you want it after all). VVVV is your VRAM pattern index address, I've left this one as VVVV simply because it's up to you to decide where in VRAM you want to put this extra digit's art, that's entirely down to your preferrence, you may want to consider making a VRAM dump of the level and taking a look for any free spaces to put the new digit (it will be two cells/tiles worth), you will then need to alter the hud routine known as "HudUpdate", to write the 10 minute digit's art to that VRAM location, and then change VVVV to point to that VRAM location. Please note, this is just one way of doing it and might be considered the easiest, the other method which would help keep things optimised and organised will require a rewriting; the hud routine, the VRAM locations of the digit art, and the sprites. EDIT: It seems RHS's post got in before mine.
More detailed and well explained yours was. Although, I was at work at the time and that was all from the top of my head =P
Speaking of mappings, does anyone know if it would be possible to convert my Sprite Mappings Macros to work with asm68k? Solved thanks to Andlabs giving me an asm68k manual.
Thanks guys for all the help here, it's really appreciated For the VRAM I sort of have an idea. Since in my hack "SCOR" doesn't show up at all, I could use the VRAM from that, right? Same could be said for "RING" aside from 4 tiles but yeah.
Got a quick one-off about the Shadow & Highlight modes in the Mega Drive's VDP. Can anyone tell me about what exactly they are and how they are important? I'm currently looking in SEGA Retro, starting at the SEG Mega Drive's page, and looking from there and not seeing too much. I've started to place a Shadow/Highlight preview in Triad's palette editor and was just curious about what exactly these are for...
