Sonic and Sega Retro Message Board: Basic Questions & Answers thread - Sonic and Sega Retro Message Board

Jump to content

Hey there, Guest!  (Log In · Register) Help
  • 418 Pages +
  • ◄ First
  • 416
  • 417
  • 418
    Locked
    Locked Forum

Basic Questions & Answers thread NEWBIES: Start here!

#6256 User is offline Random Gaming 

Posted 08 June 2019 - 11:43 AM

  • Posts: 15
  • Joined: 02-May 19
  • Gender:Male
  • Location:Greece
Hey, I've another question. How do I restore Sonic 2 Hidden Palace's art, collision and layout in the final? There doesn't seem to be any koskinski art in the improved S2SWB Disassembly by Super Egg and the layout data there doesn't seem compatible... I tried messing around with the code for a bit and I think I got something artwise but I'm just very confused.

#6257 User is offline Ralakimus 

Posted 08 June 2019 - 11:46 AM

  • Posts: 318
  • Joined: 16-April 13
  • Gender:Male
MainMemory's LevelConverter tool can be used in SuperEgg's version of the disassembly to convert the data to be compatible with Sonic 2 final.

The Simon Wai prototype (mostly) still uses the same compression algorithms for the level data as in Sonic 1. It also uses the same level layout format as in Sonic 1 (where it stores the level size in the header, and then the game formats that data into RAM, whereas in Sonic 2, it has a fixed level size for the actual data, so that it doesn't need to be reformatted).

The global collision widths, heights, and angles are identical to the ones in the final. However, the Simon Wai prototype leaves the collision block IDs for the chunk blocks uncompressed like in Sonic 1. For Sonic 2 final, they need to be compressed with Kosinski.
This post has been edited by Ralakimus: 08 June 2019 - 12:00 PM

#6258 User is offline JustMe 

Posted 08 June 2019 - 11:46 AM

  • Just laziness...
  • Posts: 6
  • Joined: 03-June 19
  • Gender:Male
  • Location:Planet Earth
Random, i think you should port this and subroutines that loads this and do it for hidden palace only, i think it should work. Or do that ralakimus said (level converter really supports s2b? I think i should pay my attention at another try)
This post has been edited by JustMe: 08 June 2019 - 11:48 AM

#6259 User is offline Ralakimus 

Posted 08 June 2019 - 12:02 PM

  • Posts: 318
  • Joined: 16-April 13
  • Gender:Male
Well, Sonic 2 prototype wise, it only really supports the Nick Arcade build, but the formats and compression algorithms used are pretty much the same as in the Simon Wai build, so you can just use that. (Although most chunks are uncompressed in the Nick Arcade build, so you'd still need to define the chunk compression in the INI file if you want to use it for the Simon Wai build)
This post has been edited by Ralakimus: 08 June 2019 - 12:07 PM

#6260 User is offline MainMemory 

Posted 08 June 2019 - 12:16 PM

  • Every day's the same old thing... Same place, different day...
  • Posts: 4264
  • Joined: 14-August 09
  • Gender:Not Telling
  • Project:SonLVL
  • Wiki edits:1,339
LevelConverter is built on SonLVL's API and supports everything SonLVL does, at least for source files; the output formats are a bit more restricted.

#6261 User is offline Super Egg 

Posted 08 June 2019 - 02:59 PM

  • Master of MS Paint.
  • Posts: 307
  • Joined: 01-July 10
  • Gender:Male
  • Location:Tomball, TEXAS
  • Project:Sonic 2 beta 3 hoax
  • Wiki edits:46
Hey there, it's THE SuperEgg here. Ok kiddos, let's talk a bit about Sonic 2 proto compressions.

S2NA and S2B use the same layout compression and format, which is no compression, and a layout format the same as Sonic 1's. The background and foregrounds are separate files.

As far as S2B is concerned, the level art files are compressed as such:

Tiles - Nemesis
Blocks - uncompressed
Chunks - Kosinski

I don't remember S2NA off the top of my head, as I haven't touched S2NA in about 2 years, but I assume it's the same.

Collisions in S2B is uncompressed.

SonLVL does support S2B by extension, but I never released a public LVl file, as I've abandoned the disasm to make a custom engine with it, so I haven't bothered to advance anywhere with it. I suppose I could release a disasm will the the LVL files for it later if there is a big enough call for it.

Last note to make, the "improved" disasm doesn't change file type compression for the sake of "byte perfection." It's "improved" because I either reorganized the file names, locations, split more data from the disasm, ect.

#6262 User is offline AsuharaMoon 

Posted 09 June 2019 - 08:59 PM

  • Posts: 18
  • Joined: 02-November 15
  • Gender:Male
  • Location:Buenos Aires, Argentina
  • Project:Sonic Rocket
How do I port Knuckles' top boundary block (while gliding and climbing) to Sonic 1 correctly? Just asking cuz' I give it several unsuccessful tries as far my knowledge can (being the main reason why I deactivated it in my Rouge in S1 hack).

While its functionality works quite fine, it suddenly activates itself on random places:

Posted Image

And it also rarely happened with Tails' S3 flight codes (needs beta-testing since I recently modified it), so I would be grateful if someone could check them.

Here's the codes:
Spoiler


#6263 User is offline JustMe 

Posted 09 June 2019 - 11:33 PM

  • Just laziness...
  • Posts: 6
  • Joined: 03-June 19
  • Gender:Male
  • Location:Planet Earth
AsuharaMoon, check S1 ram editing page and you'll notice your Camera_Min_Y_pos isn't correct:

Quote

$F73C-$F73D Number of pixels scrolled by the camera vertically since the previous frame (multiplied by $100)
So it should be:

Quote

$F72C-$F72D Level's upper boundary

This post has been edited by JustMe: 09 June 2019 - 11:54 PM

#6264 User is offline AsuharaMoon 

Posted 10 June 2019 - 12:06 AM

  • Posts: 18
  • Joined: 02-November 15
  • Gender:Male
  • Location:Buenos Aires, Argentina
  • Project:Sonic Rocket
Huh, how did I overlook that one? I was just checking the same list!

Thanks!
This post has been edited by AsuharaMoon: 10 June 2019 - 12:07 AM

#6265 User is offline JustMe 

Posted 10 June 2019 - 12:08 AM

  • Just laziness...
  • Posts: 6
  • Joined: 03-June 19
  • Gender:Male
  • Location:Planet Earth
No problem :)

#6266 User is offline JustMe 

Posted 11 June 2019 - 06:30 AM

  • Just laziness...
  • Posts: 6
  • Joined: 03-June 19
  • Gender:Male
  • Location:Planet Earth
EDIT: Now I can solve my problem
This post has been edited by JustMe: 23 June 2019 - 07:16 AM

#6267 User is offline Zycor 

Posted 16 June 2019 - 02:59 AM

  • Unlike Sonic, I don't chuckle.
  • Posts: 168
  • Joined: 13-June 04
  • Gender:Male
  • Project:Work. Amazing isn't it?
I'm watching a lets play of Sonic 2 8-bit and I also tried playing it myself, has anyone looked into why sometimes you can go over 10 lives and sometimes you can't? Someone commented saying it depended on whether you picked up your 100th ring through a 10 ring TV or from a normal ring, I'm curious about this behavior. I didn't see anything mentioned on the Wiki. I've encountered some strange bugs playing Sonic 2 8 Bit and this one is curious because in Sonic 1 8-bit your life counter would go over 9 no problem and reflected it on the results screen, but in levels it would just show 9.

#6268 User is offline MarkeyJester 

Posted 16 June 2019 - 06:43 AM

  • It's Saturday TV Toons!! (90's Style)
  • Posts: 1891
  • Joined: 22-July 08
  • Gender:Male
  • Location:Japan
  • Wiki edits:16
I thought I'd have a look into this, so I disassembled the SEGA Master System version of Sonic 2.

Now, for the record, I'm not 100% familiar with the Master System games, I've played them mind, but not enough to be familiar. But judging by the code I'm seeing, it looks to me like there is no cap for the lives counter at all, only for the display to remain at 9 if it's beyond 9. The lives counter itself may go beyond 9. Observe:

ROM:25C3 IncreaseRings:                          ; CODE XREF: ROM:026Cj
ROM:25C3                                         ; sub_7378+8Cj
ROM:25C3                 ld      a, (RingsCounter) ; load rings counter
ROM:25C6                 add     a, 1            ; increase by 1
ROM:25C8                 daa                     ; adjust for decimal addition (this should wrap to 0 once it surpasses 99 decimal)
ROM:25C9                 ld      (RingsCounter), a ; update rings counter
ROM:25CC                 or      a               ; check the number of rings now
ROM:25CD                 jr      nz, DisplayRings ; if it has NOT wrapped back to 0, branch (no lives updating)
ROM:25CF                 ld      hl, 0D298h      ; Load lives counter address
ROM:25D2                 inc     (hl)            ; Increase lives counter
ROM:25D3                 call    DisplayLives    ; Cap it for display only and update
ROM:25D6                 ld      a, 0A6h ; 'ª'
ROM:25D8                 ld      (byte_DD04), a
ROM:25D8 ; END OF FUNCTION CHUNK FOR sub_7378
ROM:25DB
ROM:25DB ; =============== S U B R O U T I N E =======================================
ROM:25DB
ROM:25DB
ROM:25DB DisplayRings:                           ; CODE XREF: j_DisplayRingsj
ROM:25DB                                         ; sub_30+96Ap ...
ROM:25DB                 ld      a, (DemoFlag)   ; is the demo running?  (I "think" this is demo, the hud doesn't display during demo)
ROM:25DE                 or      a
ROM:25DF                 ret     nz              ; if demo is on, branch
ROM:25E0                 ld      a, (byte_D295)
ROM:25E3                 cp      6
ROM:25E5                 jr      nz, loc_25ED
ROM:25E7                 ld      a, (byte_D296)
ROM:25EA                 cp      2
ROM:25EC                 ret     z
ROM:25ED
ROM:25ED loc_25ED:                               ; CODE XREF: DisplayRings+Aj
ROM:25ED                 ld      a, (RingsCounter)
ROM:25F0                 rrca                    ; Get upper digit but multiplied by 2
ROM:25F1                 rrca
ROM:25F2                 rrca
ROM:25F3                 and     1Eh             ; get only upper digit
ROM:25F5                 add     a, 10h
ROM:25F7                 ld      (RingDigitUpper), a ; Upper digit of rings counter
ROM:25FA                 ld      a, (RingsCounter)
ROM:25FD                 rlca                    ; get lower digit by multiplied by 2
ROM:25FE                 and     1Eh             ; get only lower digit
ROM:2600                 add     a, 10h
ROM:2602                 ld      (RingDigitLower), a ; Lower digit of rings counter
ROM:2605                 ret


And the lives counter updating:

ROM:25AC DisplayLives:                           ; CODE XREF: j_DisplayLivesj
ROM:25AC                                         ; sub_30+901p ...
ROM:25AC                 ld      a, (DemoFlag)
ROM:25AF                 or      a
ROM:25B0                 ret     nz
ROM:25B1                 ld      a, (LivesCounter) ; load lives counter
ROM:25B4                 cp      9               ; has it reached 9 or above?
ROM:25B6                 jr      c, loc_25BA     ; if not, branch
ROM:25B8                 ld      a, 9            ; keep it at 9
ROM:25BA
ROM:25BA loc_25BA:                               ; CODE XREF: DisplayLives+Aj
ROM:25BA                 rlca                    ; multiply by 2
ROM:25BB                 and     1Eh             ; get only the digit
ROM:25BD                 add     a, 10h
ROM:25BF                 ld      (LivesDigitLower), a             ; update lives display counter
ROM:25C2                 ret


Note, this is just for ring collection it appears, but the claim is there is no cap for collecting a 10 ring monitor, but that would mean that a single ring collection in the routine above would have the cap, which it does not. I'll keep looking though, but either I've misunderstood your post, or I've yet to discover the capping within the routines of the game.

--- --- --- --- --- --- --- --- --- --- --- --- --- --- ---

EDIT: OK, I think I understand what you're talking about now.

I've found the routine for collecting 10 rings from a monitor:

ROM:4817 Monitor_Rings:                          ; CODE XREF: sub_2FA8+1854j
ROM:4817                 res     0, (hl)
ROM:4819                 ld      a, (RingsCounter)
ROM:481C                 add     a, 10h          ; Add 10 to rings
ROM:481E                 daa                     ; Adjust for decimal
ROM:481F                 ld      (RingsCounter), a
ROM:4822                 ld      a, 0B3h ; '¦'
ROM:4824                 ld      (byte_DD04), a
ROM:4827                 jp      DisplayRings


This increases the ring counter by 10, and that's it. If the result ends up surpassing 100 rings or not doesn't matter, there is no change to the lives counter. It could quite easily be added in though.
This post has been edited by MarkeyJester: 16 June 2019 - 06:54 AM

#6269 User is offline Ravenfreak 

Posted 16 June 2019 - 10:10 AM

  • Sucks at sprite art
  • Posts: 2753
  • Joined: 24-November 08
  • Gender:Male
  • Location:O'Fallon Mo
  • Project:Sonic 1 Game Gear Disassembly
  • Wiki edits:112
I've ported over the code from Sonic Chaos that removes the lives counter cap. I think I wrote a guide and put it on the wiki too. I'm not really sure why the programmed the lives counter to be capped.

#6270 User is offline Zycor 

Posted 16 June 2019 - 11:42 AM

  • Unlike Sonic, I don't chuckle.
  • Posts: 168
  • Joined: 13-June 04
  • Gender:Male
  • Project:Work. Amazing isn't it?
Thanks for the reply MarkeyJester!

I wrote the post when it was pretty late, so that may have lead to some clarity issues.

  • 418 Pages +
  • ◄ First
  • 416
  • 417
  • 418
    Locked
    Locked Forum

2 User(s) are reading this topic
0 members, 2 guests, 0 anonymous users