Basic Questions and Answers Thread

Discussion in 'Discussion & Q&A' started by Malevolence, Jul 7, 2009.

  1. LackofTrack

    LackofTrack Well-Known Member Member

    Joined:
    May 30, 2018
    Messages:
    51
  2. breakthetargets

    breakthetargets Well-Known Member Member

    Joined:
    Aug 6, 2009
    Messages:
    180
    Would like to mention that Yamaha FM is *technically* Phase Modulation and not Frequency Modulation (that gif shows Phase Modulation in action) but it's "basically the same"

    Here's a really good article on it: https://moinsound.wordpress.com/201...or-phase-modulation-synthesizer-technologies/

    Also, I recommend not doing math for more complex waveforms, you can do math to get other simple waveforms like a square or a saw, but the more complicated it gets... the worse it is to do mathematically. Typically, I make my own FM patches just by listening and messing around with the values. I know what each value does to the outcome after a while of messing around, so I recommend just spending time messing around with creating an FM patch, or even editing a pre-existing FM patch from a game.
     
  3. MarkeyJester

    MarkeyJester ♡ ! Member

    Joined:
    Jun 27, 2009
    Messages:
    2,867
    Yeah I... wasn't really going to get into the whole Frequency vs Phase debate, I personally find it to be pathetic terminology at the best of times.

    Furthermore, I agree regarding the "doing the math" situation (however, I mentioned no-where about doing the math, it just happened that the animated GIF had the equations d=), the purpose was to give a general insight as to what was happening from a visual point of view. I would like to build on your recommendation, many musicians when using synthesisers usually try a trial and error approach as opposed to working out the specifics, I personally think it's less of a recommendation and more of a professional direction, the dials should be used in this manner, the only real exception I could throw in is where more modern keyboards have instrument patches which are specifically calculated to emulate a specific real-life instrument with clear accuracy.
     
  4. GreaterGam

    GreaterGam Newcomer Trialist

    Joined:
    Jun 30, 2019
    Messages:
    6
    Location:
    A Place
    For now, I'll read up one the links you showed me. When I start coding, I'll use Stealths engine for editing Sonic 1 visually, then later on I'll start working on the confusing text.

    I really didn't expect you to give this long, extremely detailed explanation to a beginner like me. I'm excited to see what I can rack up in my ROM hack. Thanks MarkyJester.

    Edit - Oh God the hex editor makes zero sense.
     
    Last edited: Jul 11, 2019
    Trickster and Crimson Neo like this.
  5. Trickster

    Trickster Well-Known Member Member

    Joined:
    Aug 22, 2018
    Messages:
    110
    Location:
    Brazil Bad Future
    upload_2019-7-13_13-32-54.png
    upload_2019-7-13_13-33-1.png

    Which one is better?
    Also, the octopus need to look black. :v
     
  6. Devon

    Devon Down you're going... down you're going... Member

    Joined:
    Aug 26, 2013
    Messages:
    1,372
    Location:
    your mom
    B for Sonic, A for the octopus badnik.
     
  7. Pacca

    Pacca Having an online identity crisis since 2019 Member

    Joined:
    Jul 5, 2014
    Messages:
    1,175
    Location:
    Limbo
    I'm extremely close to finally making a 1 to 1 remake of Green Hill in Sonic 2s' engine, but I seem to have straight up run out of vram. Those darned Newtrons use a shocking amount of tiles, and given both Sonic 2s' default VRAM set aside for tails and what not, and the VRAM used for super sonic/ stars and shield (I've optimized VRAM for the latter, but have used it all for more universal objects that need to render in all levels), I only seem to have about $20 tiles left, added up from two separate parts of VRAM that surround the universal section. Even if I did break up the artwork to fit around that limitation, I doubt it'd fit...

    Does anyone have any tips for saving/micromanaging VRAM? I've been going about it intuitively thus far, but I seem to have hit a brick wall on this one.
     
    Last edited: Jul 14, 2019
    Trickster likes this.
  8. MarkeyJester

    MarkeyJester ♡ ! Member

    Joined:
    Jun 27, 2009
    Messages:
    2,867
    Green Hill Zone has a few unused tiles in the level's art itself, some unused totem poles, unused inside walls (i.e. SMS Sonic 1), of course, we are talking about 12 or so tiles, no idea if that would be enough.

    You could also optimise the badniks art themselves, for example the motobug, there are two frames for the arms, each frame for the arms consist of four tiles horizontally, however the fourth tile in both of them are the exact same tile. The reason was to cost only 1 sprite to display all four of these tiles at once, at the expense of another sprite, you could save a tile when rendering the second arm by displaying only the three tiles of the other frame, and using another sprite to display 1 tile from the previous (which is identical). That's just one example though, other badniks do have similar frames here or there, even the newtron has the same head about three times with different mouth gestures, by sacrificing the number of sprites you can save on tiles.

    Another method involves misdirection, you would be amazed at what you could remove without anyone ever noticing. When trying to create Project Sonic 1:Two-Eight I hit into the issue where Sonic 1's 256x256 chunks would not fit into 128x128 chunks, pure and simply some of the levels were too big, sacrifices to the patterns of some of the chunks were made, and no-one noticed them because they were minor. To further this, sometime ago, I made an experimental ROM to test this theory, you play GHZ, you go around and around and around, and each time you go around, something changes. Of all the people who have ever played it, an extremely few number have ever noticed one of the changes, let alone all 13.

    I believe if you were to use a combination of misdirection or rearrangement of the level chunks designs, you could remove some tiles without anyone ever noticing.

    An additional thing you could do to help find free spaces you never knew you had, is to flood the entire VRAM space with F's from VRAM 0000 to FFFF before the level starts. You can then view the contents of VRAM, and any tiles that are solid using the last colour in the palette are highly likely to be unused free space. Blank transparent tiles have a habbit of being used in combination with sprites, so this helps to rule it out.
     
    Last edited: Jul 14, 2019
  9. MainMemory

    MainMemory Well-Known Member Member

    Joined:
    Mar 29, 2011
    Messages:
    922
    One slight problem with that is that Sonic 2 likes to load some art once at startup and never reload it, I believe it's the PLC with the ring art in it. You'll want to manually reload that after clearing VRAM.
     
    Trickster likes this.
  10. MarkeyJester

    MarkeyJester ♡ ! Member

    Joined:
    Jun 27, 2009
    Messages:
    2,867
    6 years ahead of ya~

    This'll go after the "move #$2700,sr" in the "Level:" routine.

    Code:
    		lea	($C00004).l,a6				; load VDP address port to a6
    		move.l	#$8F019780,(a6)				; set increment mode & DMA source
    		move.l	#$94FF93DF,(a6)				; set DMA size
    		move.l	#$40200080,(a6)				; set DMA destination
    		move.w	#$FFFF,-$04(a6)				; fill location with F's
    
    Level_WipeVRAMWait:
    		move.w	(a6),ccr				; load VDP flag to "v" flag
    		bvs.s	Level_WipeVRAMWait			; if still busy with DMA, loop
    		move.w	#$8F02,(a6)				; set increment mode to normal
    		moveq	#$00,d0					; set to reload the HUD/Ring patterns
    		bsr.w	LoadPLC2				; ''
     
    Last edited: Feb 28, 2020
    Trickster and ProjectFM like this.
  11. Pacca

    Pacca Having an online identity crisis since 2019 Member

    Joined:
    Jul 5, 2014
    Messages:
    1,175
    Location:
    Limbo
    I've ran into some trouble while trying to get Scrap Brain Zones spinning sticky circles working in Sonic 2 (the ones that appear at the start of SBZ Act 2). The problem is that it has a tendency to buck the player off the circle in a seemingly random fashion, which gets worse as you build up speed. Obviously, this defeats the point of the object and makes it way less reliable and fun.

    I've dissected the object itself, and as far as I can tell, it works exactly as it's supposed to; the part of it that renders functions perfectly, and it properly sets the players "sticky" flag (object ram $38, referred to in the S2 git disasm as "stick_to_convex"). It even pushes the player around it's surface properly, forcing them to have a minimum inertia and capping their acceleration at a certain point. I even went to the length of taking a quick look at S3Ks' Carnival Night Zone object, in hopes of finding some major fix; as far as I can see, it's a straight port from Sonic 1 with some minor additions to support tails.

    So I tried simply testing the sticky flag itself, taking the object out of the equation. And although the pushing behavior caused by the object obviously went away, it otherwise suffered the exact same issue, bucking the player for seemingly no reason while walking around it. I even tested it in a "vanilla" rom with only Scrap Brains layouts and collision ported in, and the flag still didn't quite work right around those circles.

    I even went to work comparing how the flag is referenced in the player objects routines between Sonic 1 and 2. They seem to be untouched; the code looks identical between the two surrounding how the flag is read and cleared between games. Unless I missed a reference to it somewhere (as it's unlabeled in the Sonic 1 disassembly, I can't say for certain I caught every reference to it)...

    My best guess is that it has something to do with a change in the collision engine between games, but even then I have my doubts; after messing with the object and the sticky flag in Sonic 1, I noticed several little collision quirks inherited by Sonic 2, like Sonic having some trouble walking around to the top from the side of the circle when moving slowly; he seems to get stuck for no good reason, and does so in exactly the same way in both games. The only noticeable difference in behavior is that Sonic 2 just ejects the player from the circle when moving around it seemingly at random.

    All my obvious avenues for tackling an issue like this seem to have run into dead ends. The more I learn, the more I wonder why there's even a problem at all! Does anyone have any ideas as to what could be happening?
     
    Painto likes this.
  12. MarkeyJester

    MarkeyJester ♡ ! Member

    Joined:
    Jun 27, 2009
    Messages:
    2,867
    The angles of the collision come to mind. We don't know what collision you used, the angles they represent, so on... If you show us that, it might shed light on the anomaly.

    Might also be worth sharing the object code you've ported, just in-case you've made a mistake and not noticed?
     
    Pacca likes this.
  13. Pacca

    Pacca Having an online identity crisis since 2019 Member

    Joined:
    Jul 5, 2014
    Messages:
    1,175
    Location:
    Limbo
    Ah yes, sorry about that. Here you go:
    Object code
    S2 SBZ level data
    I commented the object by hand; as per usual, I didn't quite get everything, but was able to grasp generally what it was doing. The level data was converted by an older version of MainMemorys' level convertor.

    EDIT: Oh! Quick warning about the object layouts, if you do decide to use them; I created an alternate Object ID list for Sonic 1 levels, that object layout file won't work properly in vanilla S2 without restructuring it's object list to fit Sonic 1s'.
     
    Last edited: Jul 23, 2019
  14. MarkeyJester

    MarkeyJester ♡ ! Member

    Joined:
    Jun 27, 2009
    Messages:
    2,867
    Goto "Sonic_Angle:", you'll see this:
    Code:
    Sonic_Angle:
    	move.b	($FFFFF76A).w,d2
    	cmp.w	d0,d1
    	ble.s	+
    	move.b	($FFFFF768).w,d2
    	move.w	d0,d1
    +
    	btst	#0,d2
    	bne.s	loc_1E380
    	move.b	d2,d0			; <-
    	sub.b	angle(a0),d0		; <-
    	bpl.s	+			; <-
    	neg.b	d0			; <-
    +					; <-
    	cmpi.b	#$20,d0			; <-
    	bcc.s	loc_1E380		; <-
    	move.b	d2,angle(a0)
    	rts
    ; ===========================================================================
    
    loc_1E380:
    	move.b	angle(a0),d2
    	addi.b	#$20,d2
    	andi.b	#$C0,d2
    	move.b	d2,angle(a0)
    	rts
    If the lowest bit is clear (of which to my knowledge is usually only set for the floor collision) the arrow'd lines check to see Sonic's distance from the angle, if the distance is more than 20 (i.e. 45 degrees) it'll perform the same action as an FF floor collision would (basically snapping you to the nearest 90 degrees (that's what the code at loc_1E380 does), but because the curve is so tightly packed, it's possible for Sonic to read the angle of a block which happens to be more than 20 (45) degrees away, thus Sonic snaps to his nearest angle and then reacts with the curve as if it's a wall/ledge.

    The arrow'd lines do not exist in Sonic 1, it simply just saves the angle directly to Sonic regardless of it's distance away. I'd imagine this mechanism was put in place to potentially prevent Sonic from jamming right into the floor if the angle is bizzarely opposite enough, but I haven't tested (and I likely won't). If you are concerned about it's nature, you could put in a specific flag which when enabled skips the very lines marked, where said flag is set by the object itself when Sonic collides. Point being, removing these lines reverts the collision to function just like Sonic 1 and thus, back to normal.
     
    Pacca likes this.
  15. Pacca

    Pacca Having an online identity crisis since 2019 Member

    Joined:
    Jul 5, 2014
    Messages:
    1,175
    Location:
    Limbo
    Thank you so much! Works like a charm. It's actually pretty convenient that I'd need to set a flag too; the CD styled camera needs to be suppressed during that section as well.

    EDIT: Although now that I think of it, the object already sets an otherwise unused flag anyways X3
     
    MarkeyJester likes this.
  16. MarkeyJester

    MarkeyJester ♡ ! Member

    Joined:
    Jun 27, 2009
    Messages:
    2,867
    You could simply skip the code based on "stick_to_convex" of Sonic, I had a search of the source of Sonic 2 and found that it wasn't set anywhere at all.

    In fact, in Sonic 1 the flag is only set for those circular objects you're porting.
     
    Painto and Pacca like this.
  17. Bobbie

    Bobbie Newcomer Trialist

    Joined:
    Jul 20, 2019
    Messages:
    17
    Is it possible that anyone can rip transparent files of the tiny character sprites from Mania? I've tried looking online but have had no luck. I also only have Mania on the Switch so I can't do it myself (or else I wouldn't have been asking this).

    EDIT: Just the idles! Not every single sprite, unless they're all coupled into one image.
     
    Last edited: Jul 26, 2019
  18. MainMemory

    MainMemory Well-Known Member Member

    Joined:
    Mar 29, 2011
    Messages:
    922
    ProjectFM, Bobbie and Painto like this.
  19. Bobbie

    Bobbie Newcomer Trialist

    Joined:
    Jul 20, 2019
    Messages:
    17
    Need help!
    I downloaded ROMs of Sonic Jam & Sonic R to put on my PSP, but they are .mdf/mds files (which the PSP doesn't recognize.) Is there any way or any software that I can use to convert them to .bin or .iso files?
    I use Yasabuse 0.9.10 for the PSP as an emulator. Thanks for reading.
    EDIT: Nevermind... I just found out that the PSP can't run Saturn games (at least not very well). Sorry.
     
    Last edited: Jul 28, 2019
  20. JayKuriN

    JayKuriN wowie Member

    Joined:
    Jul 27, 2019
    Messages:
    20
    Location:
    hell
    Where is the parallax data at in Sonic 2’s Disassembly? And are there any good alternatives to Selbi’s parallax editor? I heard it screws up verticals.