Basic Questions and Answers Thread

you would be advised to put one before Art_Ashuro too, to see if it fixes the issues you are having

 

Hi, (i use hivebrain 2005), it is possible to decompressing art from map256 and copy/paste it to map256_u?
The reason is that i have many new compressed chunks in my MZ files (under map256), i don't wan't to lose them, because i want to load the chunks from rom and for this, i have to load the uncompressed chunks files from map256_u...

I know that the files are Kosinski compressed art, i just decompressed them with the Sega Data Compression tool, and put them into my map256_u but it still don't work like i wanted to.

 

Pretty sure you can just use SonMapEd; open the compressed tile artwork, and then export it as uncompressed, and to the new location.

As for the chunk layouts, I don't think the game is built to use uncompressed copies of such data. If you're looking to have alternating tiles, the swapping data should also be compressed, even for scenery sprites (such as animated flowers and tops of waterfalls).

Honestly not too sure what else to try for decompressing the mapping layouts, though. That plane editor might help, though?

 

He's looking to load uncompressed chunks from ROM. He would need to modify the code to be able to load uncompressed chunks, since Sonic 1 only handles compressed chunks that get decompressed into RAM.

 

i've already done it with the Retro guide, i just want to decompressing the art files from map256, and then put it into map256_u, because if i juste done the tutorial like it, i will get the old original MZ files and not those i created. (i don't know if you understand xD).

I will try with SonMapEd.

 

You can just change the SonED2/SonLVL project files to load the uncompressed files. For compressing files, I recommend the FW-KENSC Shell Extension.

 

@MainMemory Hi! Yes i know it (chunkcmp=uncompressed), and change map256/mz.bin to map256_u/mz.bin.
But that's not what i searching.

Thank you i will try it!
EDIT: How does it works? I've installed it but...

 

You right click on the file(s) you want to compress or decompress, and go into the FW-KENSC submenu to select which action you want to do. It produces files in the same folder with an extension based on the compression (.kos, .nem, .unc, etc).

 

Ohhhh riiiight!
Thank you very much!

 

Whats the mappings for the title screen emblem? Just curious cause I was going to edit it.

 

Title screen haven't mappings (in fact yes, but you can't load them with sonmaped)..
The big Sonic object on the title emblem is obj0E.asm if i remember.
The title foreground can be edited with PlanED or SonMapED if you want to edit them by hand...

 

Huh. I thought they would provide mappings... Proves me wrong. Thanks for the help.

 

There are 2 kinds of mappings: sprite mappings and plane mappings. Sprite mappings are used for sprites (basically, used by objects in Sonic) and plane mappings are used for the foreground and background (and window) planes. The title screen emblem uses plane mappings. You can edit sprite mappings in something like SonMapEd or Flex, and plane mappings in something like (Captain) PlaneEd.

For Hivebrain, the mappings are mapeni/titlescr.bin. For Git, it's tilemaps/Title Screen.bin. This is Enigma compressed.

For the art, it's artnem/titlefor.bin in Hivebran. For Git, it's artnem/Title Screen Foreground.bin. This is Nemesis compressed.

 

Title screen emblem has mappings, but these are plane mappings, not sprite mappings.
Sprite mappings editors include SonMapEd and Flex, for instance. Plane mappings editors that I know include PlaneEd and Captain PlaneEd (personally, I've never used plane mappings editors though, it easier to use image importing programs that will generate both tiles and mappings for you, rather than edit them manually).

Just to avoid confusions, every consistent element/object/picture you see on screen has to have mappings in terms of Mega-Drive hardware, as image consists of individual 8x8 tiles, that have to map into a whole image in one way or another. Ordering tiles that are drawn on foreground or background planes is usually referred to as plane mappings, whereas arranging sprite pieces into proper objects' sprites is handled by sprite mappings ("sprite pieces" term isn't really correct when applied to the hardware, but I'm not going to get too technical here...)

Speaking of the mappings for title screen emblem, they can be found in \mapeni\titlescr.bin in Hivebrain's 2005 disassembly. The data is Enigma compressed as hinted by the folder's name, mapeni. You can configure PlaneEd to decompress and view them, but you also need to load tiles to display a proper image.

EDIT: Ninja'd by Novedicus

 

Okay, that clears up the confusion, thanks a lot for the info guys.

 

I definitely cannot fix this issue. (i'm using hivebrain 2005)

My code to make Sonic and Ashuro run on the walls is (a code based on the Labyrinth Zone wind tunnels code) almost perfect:

Spoiler: First

Code:

; ---------------------------------------------------------------------------
; Subroutine to make the player run on walls
; ---------------------------------------------------------------------------
; ||||||||||||||| S U B    R O U T    I N E |||||||||||||||||||||||||||||||||||||||
Sonic_WallRun:                ; XREF: Wall Run
        tst.w    ($FFFFFE08).w    ; is debug mode    being used?
        bne.w    locret_wallrun_end    ; if yes, branch
        tst.b     ($FFFFFFD0).w ;if layour flag set?
        beq.s     @SetSonicLayout
        lea (WallRun_Data2).l,a2
        bra.s     loc_1
    @SetSonicLayout:
        lea    (WallRun_Data1).l,a2
        
loc_1:
        moveq    #0,d0            ; clear register
        move.w    ($FFFFFE10).w,d0        ; get zone number
        lsl.b    #6,d0            ; multiply by $40 (64) (32 words)
        lsr.w    #3,d0            ; divide by 8 (8) (4 words) results in 32/8=4 words
        adda.w    d0,a2            ; add d0 to script address
        lea    ($FFFFD000).w,a1

WallRun_Loop:

And:

Spoiler: Wall Run Datas

Code:

; ================== dc.w $left, $up, $right, $down ==================
WallRun_Data1:    ; Wall Run Data for Sonic
        dc.w $0000, $0000, $0000, $0000 ;GHZ1
        dc.w $0000, $0000, $0000, $0000    ;GHZ2
        dc.w $0000, $0000, $0000, $0000 ;GHZ3
        dc.w $0000, $0000, $0000, $0000 ;GHZ4
        
        dc.w $0000, $0000, $0000, $0000 ;LZ1
        dc.w $0000, $0000, $0000, $0000 ;LZ2
        dc.w $0000, $0000, $0000, $0000 ;LZ3
        dc.w $0000, $0000, $0000, $0000 ;LZ4
        
        dc.w $1520, $0140, $1850, $01E0 ;MZ1
        dc.w $2AC0, $0040, $3320, $00F0 ;MZ2
        dc.w $0000, $0000, $0000, $0000 ;MZ3
        dc.w $0000, $0000, $0000, $0000 ;MZ4
        
        dc.w $0000, $0000, $0000, $0000 ;SLZ1
        dc.w $0000, $0000, $0000, $0000 ;SLZ2
        dc.w $0000, $0000, $0000, $0000 ;SLZ3
        dc.w $0000, $0000, $0000, $0000 ;SLZ4
        
        dc.w $0000, $0000, $0000, $0000 ;SYZ1
        dc.w $0000, $0000, $0000, $0000 ;SYZ2
        dc.w $0000, $0000, $0000, $0000 ;SYZ3
        dc.w $0000, $0000, $0000, $0000 ;SYZ4
        
        dc.w $0000, $0000, $0000, $0000 ;SBZ1
        dc.w $0000, $0000, $0000, $0000 ;SBZ2
        dc.w $0000, $0000, $0000, $0000 ;SBZ3
        dc.w $0000, $0000, $0000, $0000 ;SBZ4
        
        dc.w $0000, $0000, $0000, $0000 ;End
        dc.w $0000, $0000, $0000, $0000 ;End
        dc.w $0000, $0000, $0000, $0000 ;End
        dc.w $0000, $0000, $0000, $0000 ;End
        
        dc.w $0000, $0000, $0000, $0000 ;FIZ1
        dc.w $0000, $0000, $0000, $0000 ;FIZ2
        dc.w $0000, $0000, $0000, $0000 ;FIZ3
        dc.w $0000, $0000, $0000, $0000 ;FIZ4
        
        dc.w $0000, $0000, $0000, $0000 ;WZ1
        dc.w $0000, $0000, $0000, $0000 ;WZ2
        dc.w $0000, $0000, $0000, $0000 ;WZ3
        dc.w $0000, $0000, $0000, $0000 ;WZ4
        even
; ---------------------------------------------------------------------------------------------------
WallRun_Data2:     ; Wall Run Data for Ashuro
        dc.w $3370, $0260, $3C50, $02D0  ;GHZ1
        dc.w $0000, $0000, $0000, $0000    ;GHZ2
        dc.w $0000, $0000, $0000, $0000 ;GHZ3
        dc.w $0000, $0000, $0000, $0000 ;GHZ4
        
        dc.w $0000, $0000, $0000, $0000 ;LZ1
        dc.w $0000, $0000, $0000, $0000 ;LZ2
        dc.w $0000, $0000, $0000, $0000 ;LZ3
        dc.w $0000, $0000, $0000, $0000 ;LZ4
        
        dc.w $0000, $0000, $0000, $0000 ;MZ1
        dc.w $0000, $0000, $0000, $0000 ;MZ2
        dc.w $0000, $0000, $0000, $0000 ;MZ3
        dc.w $0000, $0000, $0000, $0000 ;MZ4
        
        dc.w $0000, $0000, $0000, $0000 ;SLZ1
        dc.w $0000, $0000, $0000, $0000 ;SLZ2
        dc.w $0000, $0000, $0000, $0000 ;SLZ3
        dc.w $0000, $0000, $0000, $0000 ;SLZ4
        
        dc.w $0000, $0000, $0000, $0000 ;SYZ1
        dc.w $0000, $0000, $0000, $0000 ;SYZ2
        dc.w $0000, $0000, $0000, $0000 ;SYZ3
        dc.w $0000, $0000, $0000, $0000 ;SYZ4
        
        dc.w $0000, $0000, $0000, $0000 ;SBZ1
        dc.w $0000, $0000, $0000, $0000 ;SBZ2
        dc.w $0000, $0000, $0000, $0000 ;SBZ3
        dc.w $0000, $0000, $0000, $0000 ;SBZ4
        
        dc.w $0000, $0000, $0000, $0000 ;End
        dc.w $0000, $0000, $0000, $0000 ;End
        dc.w $0000, $0000, $0000, $0000 ;End
        dc.w $0000, $0000, $0000, $0000 ;End
        
        dc.w $0000, $0000, $0000, $0000 ;FIZ1
        dc.w $0000, $0000, $0000, $0000 ;FIZ2
        dc.w $0000, $0000, $0000, $0000 ;FIZ3
        dc.w $0000, $0000, $0000, $0000 ;FIZ4
        
        dc.w $0000, $0000, $0000, $0000 ;WZ1
        dc.w $0000, $0000, $0000, $0000 ;WZ2
        dc.w $0000, $0000, $0000, $0000 ;WZ3
        dc.w $0000, $0000, $0000, $0000 ;WZ4
        even

And then a call under DynScrResizeLoad:

Spoiler: The call to make the wall run work

Code:

; ---------------------------------------------------------------------------
; Dynamic screen resize    loading    subroutine
; ---------------------------------------------------------------------------
; ||||||||||||||| S U B    R O U T    I N E |||||||||||||||||||||||||||||||||||||||
DynScrResizeLoad:            ; XREF: DeformBgLayer
        moveq    #0,d0
        move.b    ($FFFFFE10).w,d0
        add.w    d0,d0
        move.w    Resize_Index(pc,d0.w),d0
        jsr        Resize_Index(pc,d0.w)
        bsr.w     Sonic_WallRun
        moveq    #2,d1
        move.w    ($FFFFF726).w,d0
        sub.w    ($FFFFF72E).w,d0
        beq.s    locret_6DAA
        bcc.s    loc_6DAC
        neg.w    d1
        move.w    ($FFFFF704).w,d0
        cmp.w    ($FFFFF726).w,d0
        bls.s    loc_6DA0
        move.w    d0,($FFFFF72E).w
        andi.w    #-2,($FFFFF72E).w

loc_6DA0:
        add.w    d1,($FFFFF72E).w
        move.b    #1,($FFFFF75C).w

locret_6DAA:
        rts

But the issue is:

If i put this data for MZ1: $1520, $0140, $1850, $01E0
Then every acts of MZ will enable the wall run code into this data ($1520, $0140, $1850, $01E0), also, i have a data in MZ2, and this data work in MZ1, MZ2, MZ3 ect...

BUT the issue don't finish here, every datas works with every acts and every zones, this data ($1520, $0140, $1850, $01E0), works in GHZ1, GHZ2, GHZ3, MZ1, MZ2, MZ3, SLZ1, SLZ2 ect... and not only MZ1 (sorry if i'm misunderstood).

I really need help, please! ._.

 

$FFFFFE10 is the Zone
$FFFFFE11 is the Act.

If my speculation is correct, that is.
You are reading a word, but the act is a second word after it.
I'm not sure if it's "right," but you could try reading a long-word to see if it'll capture them both. If not, then it shouldn't be too hard to also test the word for the Act shortly after testing the Zone. (Although, I think that Zone and Act are only bytes, but..)

(EDIT: There's also Sonic 2's water table method, but they also rely a separate code to check if Chemical Plant is in act 1, so I don't think it'd be as effective.)
--------------------
Also, I was looking to do model swapping and/or imports with SA2.
I understand that in SADXMDL, you can import and export to OBJ.
SATools' SAMDL seems to only export, leaving importing to be a wonder to me.
I've tried using the copy/paste on the next tab over, which definitely moves the polygons, but I'm not quite understanding why it's then saving as ".sa2mdl"

My guess is that this is per-poly, as the split model folders are, but then I'd need to compile the new .prs file for use on hardware. As such, I ask for a few pointers on how to get "buildMDL.bat" to work, as it keeps crashing after ran, and doesn't leave a log of any sort. I've tried opening the folder as the "file," and I've tried opening the generated .ini in the model's split folder, but they both make this happen. (And if it matters: I'm copying the individual files that I'm modifying to the SA2PC folder, rather than moving it to the SA2 directory. So, if it's a file missing, then which one?)

 

No, the level and act are both bytes, reading a word gets both of them.
-------
SA Tools cannot currently edit SA2 models at all, unfortunately. There's a lot of work that needs to be done before that can happen. Copy/paste might work, I'm not sure. Using buildMDL.exe is not strictly necessary, as SA2 Mod Loader can load models from a split folder if you put it in your mod's gd_PC folder. If you are going to use buildMDL though, you need to specify the /be switch in order for it to work with SA2B on GameCube or SA2 on PC, and then you specify the MDL file name that you want to create, and it reads the files from the folder of the same name.

It's really weird to see someone asking for help with SA2 here.

 

Thank you for your answers, but in fact, i think the issue comes from here:

Spoiler: ISSUE

Code:

...
lea (WallRun_Data2).l,a2
        bra.s     loc_1
    @SetSonicLayout:
        lea    (WallRun_Data1).l,a2
        
loc_1:
        moveq    #0,d0            ; clear register
        move.w    ($FFFFFE10).w,d0        ; get zone number
        lsl.b    #6,d0            ; multiply by $40 (64) (32 words)
        lsr.w    #3,d0            ; divide by 8 (8) (4 words) results in 32/8=4 words
        adda.w    d0,a2            ; add d0 to script address
        lea    ($FFFFD000).w,a1

WallRun_Loop:
        move.w    8(a1),d0
        cmp.w    (a2),d0
        bcs.w    loc_2
        cmp.w    4(a2),d0
        bcc.w    loc_2
        move.w    $C(a1),d2
        cmp.w    2(a2),d2
        bcs.w    loc_2
        cmp.w    6(a2),d2
        bcc.w    loc_2
...

I'm pretty sure about it, i don't touched at this part of the code, and i'm pretty sure the parts with d0 and (a2) are the source (or not) ???? (this code is imported from the LZWindTunnels routine).

 

This question isn't to do with a hack I'm making but it's something I've always wondered with the classic Sonic games:

It's to do with scattered rings when they bounce, I understand why they fall through objects (like the bridges in GHZ) since they're only programmed to bounce off of floor collision but why is it that sometimes they'll fall through the floor?