+  RHDN Forum Archive
|-+  Romhacking
| |-+  ROM Hacking Discussion
| | |-+  Romancing SaGa VWF source code
Pages: [1]
Author Topic: Romancing SaGa VWF source code  (Read 2 times)
DarknessSavior
Guest
« on: July 14, 2009, 05:21:22 pm »
I didn't notice this, until I went to the front page. I actually emailed F.H. back when I started the project, to see if I could get this routine from him. Apparently, it was released to the public!

However, it's not written in a normal ASM code manner (at least, not ones I've seen. And I've seen code written by RedComet and gemini that made more sense!). Can someone help explain to me what all the random notes mean that he's written in there?

Example:

Code:
; I need to keep this here with so many rep/seps, due to this hookup.
sta WRMPYA
lda Rs1e.VWF.Win.xTiles,x ;
asl a
sta WRMPYB

rep #$20 ; [3 cycs]
lda Rs1e.VWF.Win.TilNumBase,x ; [5 cycs]
adc RDMPYL ; [3 decode cycs]
sta Rs1e.VWF.currTil
sep #$20 ; Accum back to 8-bit.
rts

All of his little abbreviations and crap.

If I could get this working in-game, I basically would be able to get a translator and get the project done (as he had worked in a VWF for just about everything. Menus, dialog, the map screen!).

~DS
Tauwasser
Guest
« Reply #1 on: July 14, 2009, 07:32:38 pm »
Jeez...can't you look into the source yourself?

WRMPYA...Write Multiplication Register A (multiplier)
WRMPYB...Write Multiplication Register B (multiplicand)
RDMPYL...Read Multiplication Lower Byte.
Rs1e.VWF.Win.xTiles...number of tiles per message box horizontally
Rs1e.VWF.Win.TilNumBase...Tile number base
Rs1e.VWF.currTil...current Tile to write to (on next write)

Something goes in (in A), will be multiplied by 2*(number of tiles in a line) which is then the offset from the Tile number base to the current tile to write.
The common register names seem to be from MAME's SNES header file and can be looked up in Anomie's doc.
As the preamble states it manages different windows, that's what's in X, the window index.

I hope it is clear to you why he is counting cycles everywhere...
Also, this is pretty much what I just said:
; --- Generate Tile Offset.
; --- (XLen*YBuffCounter)+TNumBase

Two lines above your segment...
Also, to understand it better:
; --- Check for Window+Buffer wraparound.
; Tiles should be wrapped for full win length and y+1 size.


cYa,

Tauwasser
Kagemusha
Guest
« Reply #2 on: July 14, 2009, 09:51:21 pm »
Quote
If I could get this working in-game, I basically would be able to get a translator and get the project done (as he had worked in a VWF for just about everything. Menus, dialog, the map screen!).

Nah, you'd most likely need fix the severe crashes that would result from this code. That's just an assumption, but what else could he have been doing to cause those crashes. How's that saying go? The last 10% accounts for 90% of  the work that needs to be done.
Tauwasser
Guest
« Reply #3 on: July 14, 2009, 09:59:47 pm »
As far as the source code goes, at least the author knew exactly how the system was working. It sounds like a pretty good deal to have all the menu data available in ram and slice up vram for different menus. However, he also mentions crashes that even were in the production version or another game that used an analogous algorithm... I'm pretty sure if the original works and you can understand it, that you can rework this so it works more time efficiently. I don't see why all the multiplications are used for bit processing for instance. I always thought multiplication was dead-slow on SNES...
However, I see the comfort of not having to deal with XRR and TRR etc all the time, so X can stay the whole routine x and be used to get the indexed data for a specific menu out of ram etc...
You'll probably have to try to improve upon that code to rework it to be either more time efficient or error resistant (whatever makes it crash in the first place, remember NO BG3 FREE ghost).

cYa,

Tauwasser
Pages: [1]  


Powered by SMF 1.1.4 | SMF © 2006-2007, Simple Machines LLC