Basic Questions & Answers thread

Isn't DMA68kToVRAM just a macro? If so, my understanding is that the macro does not exist in that disassembly.

 

I do know that "QueueDMATransfer" is called "DMA_68kToVRAM" in Esrael's Sonic 2 Nick Arcade disassembly. I've not seen a macro called that specifically.

 

OK, it seems what I was thinking of was "dma68kToVDP" from the Sonic 2 GitHub disassembly, which is pretty much identical to the macro pointed to in the previous post.

 

Simply put, all of Sonic's mappings reach the mappings limit ($FC mappings), not to mention Super Sonic's separate mappings is interleaved with it and reuses certain entries to save space. Unless you find a way to extend the mapping limit even further (which itself would require significant engine rewrites), you have to deleted unused sprites and split both Sonic's and Super Sonic's mappings entirely.

 

...doesn't tell you what disasm it uses (part 2 also doesn't do it but part 1 states it's the 2005 one so i assume it is the 2005 one, judging from the rest of the code) and then wants you to 'go to DMA_68kToVRAM'

i'm just gonna paste that somewhere though, wish me luck cuz the last time i tried (it was with the modern hivebrain disasm and the github porting guide by clownacy it resulted in screen vomit whenever you'd jump)
edit: it worked, and the new ported queue is working now :>

 

Actually, part 2 of guide is talking about porting it:

 

oh
that's what i get for skipping straight to part 3 lol

 

No thanks

Simply put, it's impossible, yes? XD
Ok, thanks for information)

 

You don't need to use part 2. Just paste the functions under ShowVdpGraphics and ignore the parts that replace "DMA_68KToVRAM" and "Process_DMA".

The reason I say that part 2's process of porting the DMA queue should be ignored is because it's only a partial implementation and cuts into object RAM, all with the sole purpose of getting the spindash dust graphics to appear, and that alone. Part 3 properly converts Sonic's DPLC routine to use the DMA queue, and you can use it for other things in the future. Though, if you're just doing it to make part 3 make more sense, then that's fine.

 

another question: how do the demo BINs work?
provided to you by my very bad handwriting only made worse by my mouse

based on the graph the first/second/whatever frame (assuming every byte is a frame) it presses down, B and A

 

You've got the bits backwards. Bits go from right to left, not left to right. Each frame is also 2 bytes, first one being the button data itself, and the second one being the duration that those buttons are held.

 

The Sonic Physics Guide by Lapper says when sonic's in the air, if sonic exceeds the top/bottom border, the camera will move up to him, up to 16 pixels that he exceeds the borders:

"Vertical Border

In the Air
Top border: 64
Bottom border: 128

If you exceed the border, the camera will move by how much you've exceeded, up to
16. So if the Player moves faster than this, the camera will lag behind "

However if sonic is exactly at the bottom border ( not exceeding it ), wont the camera move as well. In .notRolling,
if d0 is 0x80 (128) then 0x80 + 0x20 - 0x60 - 0x40 = 0x0 which at bcc.s .doScroll_fast evaluates to true. As bcc is
synonomous with branch on higher or same.

Code:

ScrollVerti:
moveq #0,d1
move.w y_pos(a0),d0
sub.w (a1),d0 ; subtract camera Y pos
cmpi.w #-$100,(Camera_Min_Y_pos).w ; does the level wrap vertically?
bne.s .noWrap ; if not, branch
andi.w #$7FF,d0

.noWrap:
btst #2,status(a0) ; is the player rolling?
beq.s .notRolling ; if not, branch
subq.w #5,d0 ; subtract difference between standing and rolling heights

.notRolling:
btst #1,status(a0) ; is the player in the air?
beq.s .checkBoundaryCrossed_onGround ; if not, branch
;.checkBoundaryCrossed_inAir:
; If Sonic's in the air, he has $20 pixels above and below him to move without disturbing the camera.
; The camera movement is also only capped at $10 pixels.

addi.w #$20,d0
sub.w d3,d0
bcs.s .doScroll_fast ; If Sonic is above the boundary, scroll to catch up to him
subi.w #$40,d0
bcc.s .doScroll_fast ; If Sonic is below the boundary, scroll to catch up to him
tst.b (Camera_Max_Y_Pos_Changing).w ; is the max Y pos changing?

 

Does anyone else have false positives from your antivirus by SonLVL? I was editing a level and my antivirus software began freaking out, said it's from SonLVL.

 

according by another thread it's a false positive (i guess av's hate sonlvl? try to drop it in virustotal and see where that gets you)

edit:
VirusTotal says 27/68 av's flag it, so it's probably not a big deal but be careful

 

It's a definite false positive. IIRC several years ago, one of the compression DLLs that it had at the time caused some issues with AVs (it wasn't malware, but something in it tipped them off) and it's been stuck in some databases ever since. The source code is up on GitHub just in case you're ever suspicious about it.

Yes.

 

So the exact conditions for updating the camera when sonic is jumping / rolling is: if the adjusted (minus 5 pixel) y position of sonic is above ( less than) the top bound or greater than or equal to the bottom bound the camera will scroll to catch up by the difference he exceeded previous conditions up to 16 pixels? Should this be be mentioned to Lapper for his physics guide to make precise?

 

I was the last person to touch that specific page, so I can edit it in when I get the chance.

 

Does (and if yes- HOW) I can edit Enigma format mappings?

 

PlaneEd has the ability to edit mappings compressed in Enigma, but you have to have a project file first. no problem, right? it's easy to make that