Banner
Views: 859,558,072
Time:
22 users online:  Anorakun,  autisticsceptile1993, BrownBuddy, Cheolpeoduck, chickaDEE Magazine, codfish1002,  E-man38, Ezek.The Square Remixer, FYRE150, HammerBrother, J.C.Russell_96, JupiHornet, K3fka, MarioriaM, Mattrizzle, MecchaSugoiTntn, musicalman, quietmason, SammmUuU, SiameseTwins, SimFan96, Slash Chen - Guests: 94 - Bots: 68 Users: 47,507 (2,208 active)
Latest: Abstract
Tip: Press F2 on the level editor to see sub-screen boundaries. This will help you avoid glitching Dragon Coins by putting them on the sub-screen boundaries.Not logged in.
Posts by MathOnNapkins
MathOnNapkins' Profile - Posts by MathOnNapkins
Pages: « 1 2 3 4 »
*walks into thread*

...uh.... oh my isn't this awkward?
Originally posted by B.B.Link
Originally posted by MathOnNapkins
*walks into thread*

...uh.... oh my isn't this awkward?


Wow. How did your ears burn all the way from Board||?


It was linked to at ||Board. I can tell you right now I'd never come here 99.99% of the time. So I bid you adieu, good luck moderating the unwashed SMW hacking masses.
Circle in and out is done with HDMA to the window registers. At least, that's *easy* way of doing it. The other method I can think of is just dumb and would take too long.
Thoughts / Comments?

Open source? Maybe?
A cursory check seems to indicate the Earthbound has a standard N-SPC engine, similar to if not the same as SMAS's. So you'd want to install a SMAS engine patch, then import the track data and music samples from the Earthbound file. With a proper tool this wouldn't be very difficult, but I'm not sure if one exists at the moment. I only have a tool for parsing Link to the Past N-SPC files directly from a ROM.
http://www.romhacking.net/docs/%5B196%5Dregs.txt

In a nutshell, HDMA allows you to alter many different hardware values (palettes, background position, much more) as the screen is being drawn. Somewhat tricky but can also produce some very neat effects.
I've done this on accident in A Link To the Past before, so yeah it is possible I just have no idea how.

http://www.romhacking.net/docs/%5B196%5Dregs.txt

Look under the windows section for some ideas.
xkas is easy to use and comes with a reasonably good document on its commands >_>. If you need example source here's one of mine (plenty more where that came from)

http://math.arc-nova.org/Drewpatch_version4.asm

http://rafb.net/p/JpDMq557.html

I was bored and decided to perform some optimizations on smwedit's code. Assuming this is called up to 16 times per frame (more?) you need to make this as fast as possible. I'm sure there's other ways to make this faster but SMW is not the game I hack so oh well.

The biggest optimization you'll notice is the loop-unrolling. Loops can be very costly the longer they have to run in order to complete. My "loop" mechanism takes 3 cycles on failure whereas his takes 6. Also the lots of NOPs every call is a big no-no, I can't emphasize that enough. Why complain about having a slow CPU when you're wasting time with it? That's 2 cycles a NOP, which adds up!
fair enough, all I did was test to make sure it compiled, not that it was logically sound ;).

you should still see a speed improvement, especially in the worst case scenario.
iirc, it's negative if falling and positive if rising.
...


it would go more something like this:

Code
; (assuming you were using xkas as an assembler)

!playerCoins = $7E0DBF

SEP #$20 ; ensures that the accumulator is 8-bits
; otherwise you'd have to use an AND #$00FF to zero out the high byte
; that would get read out in the LDA below

LDA !playerCoins ; A = the number of coins the player has

BEQ dontShootFireball ; branches to a label below b/c if we don't have coins

SEC
SBC #$01
STA !playerCoins

JSL shootFireBall

dontShootFireball:

RTL

; end of routine



I think you're a little unclear on how this all works.

the semicolon is a comment marker:

Code
; this whole line is a comment
this line is not an will be treated as code! and it will not compile b/c it isn't valid assembly language.

; both of these lines are commented out
; LDA $7E0000 this will do absolutely nothing b/c of the semicolon!

!x = $7E3000 ; this does something b/c the comment market comes after I've actually done something on this line.



Also, you need to realize that most of the time code on the SNES is not running in RAM. In fact, very few games seem to do that at all (FFVI does).

This means that generally speaking you "jump" or "branch" to ROM locations and you "access" RAM locations. One means to "go somewhere else" and the other means to "obtain information".

The point of the ! symbol is to label an address, such as $7E1234. But the addresses you jump to, rather than "access" are automatically calculated for you by the assembler (xkas). So doing something like:

!dontShootFireball = dontShootFireball

is redundant. You already have a label for that address, why make another?
"!playerCoins = $0DBF ; Unnecessary 7E"

In many situations, you would be right. However, once you start doing a bit more advanced ASM work you might want to change the data bank register. (for example, to set $7F as the data bank and read memory locally from it)

Code
PHB

LDA #$7F
PHA
PLB ; sets the data bank to $7F

LDA $0DBF ; this reads from $7F0DBF, not $7E0DBF!


luckily, SMW is a LoROM game and almost any access from $0 to $1FFF in any bank you're likely to be working in will resolve to $7E, but only for that range. $2000-$FFFF in banks like $00-$3F will resolve to either hardware registers or an open bus effect (meaning it's just stale data sitting on the system.) This means that $7E:2000-$7E:FFFF are NOT the same as $00:2000-$00:FFFF!
wowguy:

depends on what you want to do. In some cases tables are more efficient and make for more compact (and faster!) code. I mainly hack Zelda ALTTP, and I can't tell you how many times I see code like this:

Code
LDA !variable

CMP #$10

BEQ .somePlace

CMP #$42

BEQ .someOtherPlace

CMP #$0F

BCC .yetAnotherPlace

; list goes on and on



Now let's say you have four items, each of which have their own MP costs. The ids of the items are 0 through 3. It doesn't make much sense to use a CMP instruction for all 4 cases. You just use a table:

Code
; start of routine is here

SEP #$30 ; A, X, and Y registers are all 8-bit

LDA !itemIndex
AND #$03 ; ensures that the item index is in the range 0 to 3
TAX

LDA !playerMP

CMP .mpValues, X ; check to see if we have enough to use the equipped item

BCC .noCanDo ; (BCC is conventionally a "less than" test)

SEC
SBC .mpValues, X
STA !playerMP

TXA
ASL A
TAX ; X = X * 2

JSR (.itemActionTable, X) ; <-- this is pretty nice! You can call a specific subroutine using a table as well.

.noCanDo

RTS


.mpValues

db 0, $20, $20, $80

.itemActionTable

dw BoomerangFunction, IceRodFunction, FireRodFunction, SuperAllScreenAttackFunction

; each of the functions above would have to be defined in your code like so:

BoomerangFunction:

; Do boomerangy stuff >_> <_<

RTS



The point is that tables, in many cases, are much more efficient than a series of CMP instructions.


<_<

"open source"?

I assume you actually like coded stuff in ASM. Otherwise that terms really makes almost no sense.
I would answer your question but I don't know specifically what you're talking about. You mean like how the memory map for the SNES works? Are you asking about an xkas feature (allows you to write code as though it were running from RAM, etc). Please be a bit more specific.
Eh.... sorry can't help with that bud.
This thread makes me want to cry. Do yourselves a favor and just add this link: http://www.romhacking.net/community/548/

Anomie might not cover absolutely everything under the sun when it comes to SNES hacking, but his guides are the most authoritative you'll find on nearly every aspect of SNES emulation and programming. They may not be the easiest to read, but they are accurate, up to date, and full of information other guides leave out.

edit: The register document is the one that most people are going to get any use out of. The memory map document, as well as the s-dsp and spc-700 docs might be useful for even more advanced programmers.
Depends on how fast you want it to be. The easiest way is to use the hardware divide registers:

Code
SEP #$10 ; X, Y = 8 bit
REP #$20 ; A = 16 bit

LDA !variable
STA $4204

LDX #$03
STX $4206 ; make sure the data bank is $00-$3F, or at the very least, not $7F or $70!

NOP #8 ; you have to wait 16 cpu cycles for the hardware divide to complete. If you can find something useful to do in the meantime, more power to you.

LDA $4216 ; this is the remainder of the division operation (remainder == modulus)
BEQ .divisibleBy3

; cry about it ;_;
RTS

.divisibleBy3

; yay

RTS



In the event that you are only working with the modulus of an 8-bit number it is definitely faster to just use a table, commonly called a LUT (Look Up Table)

Code
SEP #$30 ; A, Y, X = 8-bit

LDX !variable
LDA .mod3Table, X ; voila, you already have the answer, and it took way less cycles.

; celebrate

RTS



.mod3Table

db 0, 1, 2, 0, 1, 2 ;... etc. you would have to construct this table either manually or with the help of a programming / scripting language for all values between 0x00 and 0xFF inclusive
; I sometimes use Python for constructing lookup tables b/c it means I won't have to do tons of manual entry or ugly macro creation



Any other way besides these two is going to be way too slow and not really worth it. I'd say if you're working with 16-bit data, use the first one, and if only 8-bit data, use the second. The disadvantage of the second method is that you'll have to supply a different table for every modulus number you want to do. Meaning, if you wanted to do x mod 5 instead of x mod 3, you'll need a new table.

Pages: « 1 2 3 4 »
MathOnNapkins' Profile - Posts by MathOnNapkins

The purpose of this site is not to distribute copyrighted material, but to honor one of our favourite games.

Copyright © 2005 - 2020 - SMW Central
Legal Information - Privacy Policy - Link To Us


Menu

Follow Us On

  • YouTube
  • Twitch
  • Twitter

Affiliates

  • Super Mario Bros. X Community
  • ROMhacking.net
  • Mario Fan Games Galaxy