Basic Questions and Answers Thread

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

  1. MASTERestlib

    MASTERestlib Well-Known Member Member

    Joined:
    Apr 1, 2010
    Messages:
    167
    Location:
    In my room, drawing mah art.
    If there are any tools out there to handle SFX, then I'm unaware of them. Though if you are desperate, that should give you a head start at least.



    thanks, i imagined that there'd be atleast something like this: http://shiru.untergrund.net/pic/ayfxedit.png
     
  2. MaDSkull

    MaDSkull Lycanthrope Member

    Joined:
    Apr 3, 2013
    Messages:
    25
    Location:
    Baku
    How can I import sound effects from other sega games ? 
     
  3. CollinAB

    CollinAB Active Member Exiled

    Joined:
    Nov 24, 2014
    Messages:
    30
    Location:
    76 6th ave
    I'm Porting the Sonic 2 clone driver V2 (2.2.5) & I got 25 warnings:

    > > >s2.asm(283): warning: address is not properly aligned

    > > > cmpi.l #'init',(Checksum_fourcc).w ; has checksum routine already run?

    > > >s2.asm(283): warning: address is not properly aligned

    > > > cmpi.l #'init',(Checksum_fourcc).w ; has checksum routine already run?

    > > >s2.asm(313): warning: address is not properly aligned

    > > > move.l #'init',(Checksum_fourcc).w ; set flag so checksum won't be run again

    > > >s2.asm(3871): warning: address is not properly aligned

    > > > move.w #0,(Demo_mode_flag).w

    > > >s2.asm(4049): warning: address is not properly aligned

    > > > move.w (Demo_number).w,d0

    > > >s2.asm(4054): warning: address is not properly aligned

    > > > addq.w #1,(Demo_number).w

    > > >s2.asm(4055): warning: address is not properly aligned

    > > > cmpi.w #(DemoLevels_End-DemoLevels)/2,(Demo_number).w

    > > >s2.asm(4055): warning: address is not properly aligned

    > > > cmpi.w #(DemoLevels_End-DemoLevels)/2,(Demo_number).w

    > > >s2.asm(4057): warning: address is not properly aligned

    > > > move.w #0,(Demo_number).w

    > > >s2.asm(4059): warning: address is not properly aligned

    > > > move.w #1,(Demo_mode_flag).w

    > > >s2.asm(4206): warning: address is not properly aligned

    > > > tst.w (Demo_mode_flag).w ; test the old flag for the credits demos (now unused)

    > > >s2.asm(4213): warning: address is not properly aligned

    > > > tst.w (Demo_mode_flag).w

    > > >s2.asm(4361): warning: address is not properly aligned

    > > > tst.w (Demo_mode_flag).w

    > > >s2.asm(4475): warning: address is not properly aligned

    > > > tst.w (Demo_mode_flag).w

    > > >s2.asm(4478): warning: address is not properly aligned

    > > > move.w (Ending_demo_number).w,d0

    > > >s2.asm(4490): warning: address is not properly aligned

    > > > tst.w (Demo_mode_flag).w

    > > >s2.asm(4493): warning: address is not properly aligned

    > > > cmpi.w #4,(Ending_demo_number).w

    > > >s2.asm(4493): warning: address is not properly aligned

    > > > cmpi.w #4,(Ending_demo_number).w

    > > >s2.asm(5093): warning: address is not properly aligned

    > > > tst.w (Demo_mode_flag).w ; is demo mode on?

    > > >s2.asm(5154): warning: address is not properly aligned

    > > > tst.w (Demo_mode_flag).w

    > > >s2.asm(32913): warning: address is not properly aligned

    > > > tst.w (Debug_mode_flag).w ; is debug cheat enabled?

    > > >s2.asm(34722): warning: address is not properly aligned

    > > > tst.w (Debug_mode_flag).w

    > > >s2.asm(34792): warning: address is not properly aligned

    > > > tst.w (Debug_mode_flag).w

    > > >s2.asm(83407): warning: address is not properly aligned

    > > > move.w (Ending_demo_number).w,d0

    > > >s2.asm(86250): warning: address is not properly aligned

    > > > tst.w (Debug_mode_flag).w ; is debug mode on?

    > > >s2.asm(283): warning: address is not properly aligned

    > > > cmpi.l #'init',(Checksum_fourcc).w ; has checksum routine already run?

    > > >s2.asm(283): warning: address is not properly aligned

    > > > cmpi.l #'init',(Checksum_fourcc).w ; has checksum routine already run?

    > > >s2.asm(313): warning: address is not properly aligned

    > > > move.l #'init',(Checksum_fourcc).w ; set flag so checksum won't be run again

    > > >s2.asm(3871): warning: address is not properly aligned

    > > > move.w #0,(Demo_mode_flag).w

    > > >s2.asm(4049): warning: address is not properly aligned

    > > > move.w (Demo_number).w,d0

    > > >s2.asm(4054): warning: address is not properly aligned

    > > > addq.w #1,(Demo_number).w

    > > >s2.asm(4055): warning: address is not properly aligned

    > > > cmpi.w #(DemoLevels_End-DemoLevels)/2,(Demo_number).w

    > > >s2.asm(4055): warning: address is not properly aligned

    > > > cmpi.w #(DemoLevels_End-DemoLevels)/2,(Demo_number).w

    > > >s2.asm(4057): warning: address is not properly aligned

    > > > move.w #0,(Demo_number).w

    > > >s2.asm(4059): warning: address is not properly aligned

    > > > move.w #1,(Demo_mode_flag).w

    > > >s2.asm(4206): warning: address is not properly aligned

    > > > tst.w (Demo_mode_flag).w ; test the old flag for the credits demos (now unused)

    > > >s2.asm(4213): warning: address is not properly aligned

    > > > tst.w (Demo_mode_flag).w

    > > >s2.asm(4361): warning: address is not properly aligned

    > > > tst.w (Demo_mode_flag).w

    > > >s2.asm(4475): warning: address is not properly aligned

    > > > tst.w (Demo_mode_flag).w

    > > >s2.asm(4478): warning: address is not properly aligned

    > > > move.w (Ending_demo_number).w,d0

    > > >s2.asm(4490): warning: address is not properly aligned

    > > > tst.w (Demo_mode_flag).w

    > > >s2.asm(4493): warning: address is not properly aligned

    > > > cmpi.w #4,(Ending_demo_number).w

    > > >s2.asm(4493): warning: address is not properly aligned

    > > > cmpi.w #4,(Ending_demo_number).w

    > > >s2.asm(5093): warning: address is not properly aligned

    > > > tst.w (Demo_mode_flag).w ; is demo mode on?

    > > >s2.asm(5154): warning: address is not properly aligned

    > > > tst.w (Demo_mode_flag).w

    > > >s2.asm(32913): warning: address is not properly aligned

    > > > tst.w (Debug_mode_flag).w ; is debug cheat enabled?

    > > >s2.asm(34722): warning: address is not properly aligned

    > > > tst.w (Debug_mode_flag).w

    > > >s2.asm(34792): warning: address is not properly aligned

    > > > tst.w (Debug_mode_flag).w

    > > >s2.asm(83407): warning: address is not properly aligned

    > > > move.w (Ending_demo_number).w,d0

    > > >s2.asm(86250): warning: address is not properly aligned

    > > > tst.w (Debug_mode_flag).w ; is debug mode on?

     

    HOW DO I GET RID OF THEM????????????????????????
     
  4. Lil-G

    Lil-G Friendly Local Noob Root Admin

    Joined:
    Oct 21, 2014
    Messages:
    13
    Location:
    olathe, KS
    try throwing a even before the first error or putting one after the first error

    i have very limited knowledge in ASM but this usually fixes it

    wait before you do that are all of those equates in the same area

    if they are can you post that part of the equates in a spoiler
     
    Last edited by a moderator: Jan 3, 2015
  5. warr1or2

    warr1or2 I AM CLG Member

    Joined:
    Apr 7, 2008
    Messages:
    416
    Location:
    Town Creek, AL
    I had this issue many times in my sonic 1 hacks. In each line add an even below it, or in some disassemblies, align 2 (i think)
     
  6. MarkeyJester

    MarkeyJester ♡ ! Member

    Joined:
    Jun 27, 2009
    Messages:
    2,867
    cmpi.l #'init',(Checksum_fourcc).w"address is not properly aligned" will mean that the instruction was assembled on an odd address, when it should be an even address. The cause of this is likely due to data before that instruction that ends it's last byte on an even offset. You will need to place an "even" directive after the data that exists before that instruction.
    Not before the instruction itself.

    Not after the instruction.

    But after the data that exists before the instruction.

    An example:

    Code:
    Data:		dc.w	$0000
    		dc.l	$00000000
    		dc.b	$00,$00,$00,$00
    		dc.b	$00,$00
    		dc.b	$00
    		even			; <- Place even here
    
    Lable:
    		cmpi.l	#'init',(Checksum_fourcc).w
     
  7. Psi

    Psi Well-Known Member Member

    Joined:
    Dec 20, 2014
    Messages:
    102
    I think this is a bug with a certain SVN version of the disassembly? Try loading the default palette. It's either that or you can't edit the clear colour in palette line 2...or something like that. It's been too long :V



    I tried editing back the clear color and it works properly now. Thanx. :D

    On the topic of title cards however, is it possible to enable the other palette lines in Sonic 1 without screwing up the transition (eg. if I wanted part of the title card to use the second line's yellows).
     
    Last edited by a moderator: Jan 5, 2015
  8. Lil-G

    Lil-G Friendly Local Noob Root Admin

    Joined:
    Oct 21, 2014
    Messages:
    13
    Location:
    olathe, KS
    okay, now i have a question. this is from my question thread here
     

    since i have posted that i have have tried adding rests and (blank) notes to the beginning of the patterns to see if it was like xm4smps in some way but that hasn't worked, any ideas?
     
  9. sham1

    sham1 Newcomer Member

    Joined:
    Jul 8, 2014
    Messages:
    23
    Location:
    Somewhere in Northen Europe
    I happen to have a question about objects, especially about the once on certain radius. I am trying to implement homing attack by using Markey's "guide"-thingy on this thread like 59 pages ago. I found all the necessary commands so I could give them as argument for CalcAngle. I even found the areas on Object Status Tables. But one thing I just can't seem to understand how I am supposed to get the coordinates of badniks. So to end this question, how can I access the X and Y coordinates of the nearby objects, effectively accessing their OST.
     
  10. MainMemory

    MainMemory Well-Known Member Member

    Joined:
    Mar 29, 2011
    Messages:
    922
    You have to set up a loop through the whole area of RAM that "dynamic" objects are loaded in (slots that aren't reserved for Sonic or a shield or things like that). For each object you have to check its collision flags and/or ID to see if it can be attacked, then check its distance against a maximum value. If it's closer than the maximum, store the object's address or coordinates and make its distance the new maximum. Continue until you've reached the end of the list, and you'll have the closest object. You can look at how RunObjects (or whatever it is in your disasm) sets up its loop and copy that (replacing a0 with a1 and d7 with d6). From there you can access each object's coordinates through a1 just like you would for Sonic through a0.
     
  11. N30member

    N30member non-pro user btw Member

    Joined:
    Feb 15, 2014
    Messages:
    216
    Location:
    Kazakhstan
    What would happen if I uncompress all the art files in Sonic 1? Also, can you tell me about +'s and -'s of Kosinski compression and about the mysterious Comper compression, please?
     
    Last edited by a moderator: Jan 6, 2015
  12. warr1or2

    warr1or2 I AM CLG Member

    Joined:
    Apr 7, 2008
    Messages:
    416
    Location:
    Town Creek, AL
    are you talking about + and - in subroutines? If so...


    see it like this

    -
    cmpi.b #1,(insert_address_here).w
    beq + ;if so, branch to next routine
    add.b #1,(insert_different_address_here).w
    +
    sub.b #1,(insert_different_address_here).w
    bra - ; recheck the code

    + goes ahead one routine and can be used many times compared to labels, - goes backward. However let's say one routine  has +s and -s, the next one does as well as previous one. the + and - is next/previous one label, ++/-- is the same but twice, get it yet?

    (good thing i converted obj02's code from s2 to s1 or i'd never figure this out...)
     
  13. Lil-G

    Lil-G Friendly Local Noob Root Admin

    Joined:
    Oct 21, 2014
    Messages:
    13
    Location:
    olathe, KS
    i think he meant the pros and cons
     
  14. Clownacy

    Clownacy Retired Staff lolololo Member

    Joined:
    Aug 15, 2014
    Messages:
    1,016
    Uncompressing everything would make your ROM significantly larger, that goes without saying. But, if you use this uncompressed, ready-to-access-and-use data correctly, you can cut down on load times, but that's about it. It's not like uncompressed blocks or chunks, where making them uncompressed saves RAM; uncompressed art doesn't do anything to VRAM consumption, unless of course you employ dynamic loading or DPLCs (a very nice goal to persue with the invincibility stars and shields). But don't forget, you'll have to program in uncompressed art loading in several areas that are designed to use a Nemesis decompressor.

    Kosinski? Seems to be used as your general-purpose compression. Nemesis is specifically designed for art, and Saxman is something I've only ever seen used for sound drivers. Despite that, I've seen both compressed in Kosinski before. It's not uncommon. Compared to Nemesis, with art, Nemesis provides a better compression ratio, but the decompression speed is around 10x more than Kosinski, or at least that's what I've heard. Saxman VS Kosinski, I'm not too sure of. All I know is, I swapped S2's sound driver's compression from Saxman to Kosinski, and the resulting compressed code was smaller. So I guess Kosinski's compression ratio is a plus, at least with Z80 code. To use it, load the address of the start of the Kosinski-compressed data into a0, load the address of where you want the decompressed data to be written to to a1, and jump to KosDec.

    Quoted from here, "Kosinski is a variant of LZSS compression algorithm, used in various Sega Genesis games. Being much faster than Nemesis algorithm in decompression, this format also provides a fairly better compression ratio on data with frequently repeated sequences of bytes."

    Also quoted from here, "Comper is a new compression format, developed by me while I was working on a small proof-of-concept a while ago. My goal was to provide the best compression ratio possible along with faster decompression speeds that no other algorithms offered before. This way, large amounts of data can be loaded "on the fly" within one frame, giving no slowdown. Therefore, the compressed data can be operated as easily as uncompressed."

    It's a user-made compression with a focus on speed. I replaced all Kosinski-compressed elements in an old hack of mine with Comper-compressed ones, and the speed boost is amazing. Of course, for the most part, Comper's compression ratio isn't as good as Kosinski's. You can use it the same way you would use KosDec.
     
  15. MarkeyJester

    MarkeyJester ♡ ! Member

    Joined:
    Jun 27, 2009
    Messages:
    2,867
    An additional note about LZ variants, is that they rely on retracing back and copying lines of uncompressed data forwards, LZSS specific variants have two main downsides. The first is compression speed (not decompression speed), for the best results the compressor is required to back trace every possible line and length, this however, is usually handled outside of the game via a tool. The game itself generally only handles decompression, so this downside is really reliant on your computer programming resources.

    The second is that the device that's handling the decompression (in this case the 68k) needs to have read access to the output region, so it can perform the back tracing.

    • For data that is to be decompressed to memory spaces that the 68k can access directly (such as main RAM/Z80 RAM) this is suitable.
    • For VDP memory (be it VRAM, or less likely CRAM and VSRAM), the 68k does not have direct access to the memory space and relies on the VDP collecting and sending data to and from its memory. This can be slow. Most games that use an LZSS variant, decompress the data in sections to a small buffer in RAM, and then flush the data directly to VDP memory via DMA or even manual if necessary. But this means the back tracing is limited to what's currently available in the buffer. Thus, compression size is deprecated by this nature.
    If you're looking for advice on which one you should choose, then it depends on what sort of game/hack you're making. If you are not making anything out of the ordinary or making anything special that is dependant on speed or size, then I wouldn't worry about changing anything. Leave the system as it is. If however you are curious about compression, or you are doing something that desperately requires speed or size, then take note of Clownacy's post, and go for it.

    You would have a load of uncompressed art files from Sonic 1.

    Sorry, I couldn't resist! dX
     
  16. ProjectFM

    ProjectFM Optimistic and self-dependent Member

    Joined:
    Oct 4, 2014
    Messages:
    912
    Location:
    Orono, Maine
    I have a problem when porting Sonic 3K's Sonic sprites to Sonic 1 Hivebrain. The problem is that when Sonic is at an angle and doing his walking animation, one of his frames is of him at a different angle (For example, if he is at a 45 degree angle, his eighth frame will be him when he's walking on a flat surface). I've been having a problem with this and I know the animation file is the problem. Could someone help?
     
  17. Devon

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

    Joined:
    Aug 26, 2013
    Messages:
    1,372
    Location:
    your mom
    You'll have to port the Sonic 2/Sonic 3K version of SonicAnimate (maybe it was Sonic_Animate), because the S1 version of it is coded for 6 frames of the walking animation, while the S2/S3K version of it is coded for 8 frames of the walking animation. which the S2 and S3K sprites have.

    If you want to have a better time porting, port the S2 code.
     
    Last edited by a moderator: Jan 11, 2015
  18. nineko

    nineko I am the Holy Cat Member

    Joined:
    Mar 24, 2008
    Messages:
    1,902
    Location:
    italy
    There's no need to "port" code from other games, you just need to understand how the code works. Markey's post here and the 3633 just below that give a hint at how that code works (for walking and running animations), and that's only the first result I found in 3 seconds while searching, the 6-to-8 frames thing pops up every now and then and I'm sure there are many other posts detailing how to deal with it, this is the classic candidate of "search first, ask later". Seriously, people, when you have a problem with something, the first thing you should ask yourselves is "am I the first one who is trying to do this?", and most of the times the answer is "no", especially for common ideas such as porting Sonic 3 sprites into Sonic 1, so it's likely that other people had your same problems in the past and asked the same questions, you're not the first one to experience those problems and you can peek at how it was solved for other people. Of course there's going to be the unexpected issue sometimes, but original ideas are getting rarer and rarer these days, I don't think there are many unanswered questions as of now.
     
    Last edited by a moderator: Jan 12, 2015
  19. Devon

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

    Joined:
    Aug 26, 2013
    Messages:
    1,372
    Location:
    your mom
    I apologize for double posting but I have a little question:


    Is there any tips anyone can give about optimizing code to make it smallet and/or faster?
     
  20. Lil-G

    Lil-G Friendly Local Noob Root Admin

    Joined:
    Oct 21, 2014
    Messages:
    13
    Location:
    olathe, KS
    remove all your "nop"'s that'll speed things up (joking obviously)

    one thing that will help a lot is to add this to your macros


    Code:
    jeq macro label
    beq.s branch

    rts

    branch:

    jmp label

    endm

    jne macro label

    bne.s branch

    rts

    branch:

    jmp label

    endm

    jge macro label

    bge.s branch

    rts

    branch:

    jmp label

    endm

    jgt macro label

    bgt.s branch

    rts

    branch:

    jmp label

    endm

    jle macro label

    ble.s branch

    rts

    branch:

    jmp label

    endm

    jlt macro label

    blt.s branch

    rts

    branch:

    jmp label

    endm

    jpl macro label

    bpl.s branch

    rts

    branch:

    jmp label

    endm

    jhi macro label

    bhi.s branch

    rts

    branch:

    jmp label

    endm

    jcs macro label

    bcs.s branch

    rts

    branch:

    jmp label

    endm

    jcc macro label

    bcc.s branch

    rts

    branch:

    jmp label

    endm

    jmi macro label

    bmi.s branch

    rts

    branch:

    jmp label

    endm

    (if you can't already tell) this will add conditional jumps so you don't have "jmpto_something" everywhere you need a conditional branch but the jump distance is to long. i actually had this idea in early december and its worked so far.
    (sorry if this post looks weird, i had to type it in BBCode mode because the normal editor wasn't working right for some reason)

    (woo, post number 20)