News: 11 March 2016 - Forum Rules
Current Moderators - DarkSol, KingMike, MathOnNapkins, Azkadellia, Danke

Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.


Topics - FinS

Pages: [1]
1
Script Help and Language Discussion / ID help
« on: September 15, 2018, 11:22:52 pm »


This is what I have so far. I put an asterisk next to the ones I think are wrong but would appreciate being corrected on others too.

古の昔,
力こ*そがすべてであり
鋼の教え*匕*をみを司る魔が*支*砲する
ゼテギネア*匕呼ばれる*晴代があった。

2
ROM Hacking Discussion / Practicality of BRL?
« on: March 15, 2014, 09:50:13 am »
I was just comparing the SNES instructions "Jump" and "Branch Long" and it occurred to me there is no particular advantage for branching long. It takes 1 additional cycle and has a smaller range than the jump instruction while using the same number of bytes.

Anyone have any thoughts or examples of what purpose it might serve? Maybe it's got something to do with ease of programming.

3
Programming / New Compression Scheme
« on: September 07, 2011, 08:43:07 pm »
I have an idea for an improvement to LZSS. It would operate by pointers instead of bit flags but it could still use the bit flags if there are 2 or more compressed packets in the following 8 entries or if there are 127 uncompressed bytes followed by 1 or more compressed packets in the next 8 entries. It could save as much as 5% in wasted data with little or no loss.

Basically you start with the pointer which would be from 1 to 128 and this would tell you how many uncompressed bytes to write. If the pointer is 0x00 then the next 128 bytes would be uncompressed. The first bit of this pointer would be a flag telling whether it points to an 8 bit flag code which would be like the one used for LZSS. If the first bit is not set then it just points to a 2 byte control code which operates the same as a normal LZSS  control code. If the pointer and bit flags and control codes have completed all operations then follow with another pointer.

4
ROM Hacking Discussion / SNES color math (sprite palette 0-3)
« on: August 14, 2011, 07:15:03 pm »
I've read in a few documents that sprite palettes 0 through 3 cannot participate in color math.  I need to figure out a way to do it anyway and I have found an example in a game where it seems to happen.  I wonder if anyone can look at this and give me an idea of how it might work.



I tested this in Vsnes.  In this screenshot the mage is being hit with an inferno attack, the mage is using sprite palette 3 and the paladin in front of him is using sprite palette 1, both at priority 2. They both look like they are participating in color math with the inferno which is in BG2 using palette 3 priority 1.  The code sent to the color math register $2130 is #2202, so $2130 would receive bits "0000 0010" and $2131 would receive "0010 0010" which according to documentation translates to 'add subscreen', 'enable color math with BG2 and backdrop', 'add colors'. This also makes it seem as though there is a color math operation involving sprite palettes 1 and 3.

I forgot to mention that this is in mode 1.... could be important.

correction: "0010 0010" sent to $2131 would translate to 'enable color math with BG2 and backdrop'

August 14, 2011, 09:07:38 pm - (Auto Merged - Double Posts are not allowed before 7 days.)
Does backdrop mean everything that would normally appear on the screen, including sprites utilizing lower palettes, which would explain why it is possible to do color math on them?

5
Newcomer's Board / need extra snes sprite palette
« on: March 13, 2011, 10:06:10 pm »
The game I am working on was built to be able to place 9 sprites on screen but it only ever places at most 8 sprites. Since sprite cgram only has 256 bytes and each sprite uses 32 bytes I suspect there was no room for palette data for the 9th sprite.  I would like to find out if there is a way to place 9 sprites on screen with unique palettes.  Has anyone ever run into a similar problem? and did you figure out a solution?

6
Newcomer's Board / ID this raw snes data?
« on: March 01, 2011, 07:14:34 pm »
There are some sections of data in Ogre Battle that I haven't been able to figure out.  I have set breakpoints on parts of it and wrote zeros to some of it without noticing any changes.  I know it's not a whole lot to go on but it looks like something an experienced hacker might recognize. Here is a small sample of some of the data.  It's all very similar to this and ranges from a length of 50 bytes to 2 or more kb in different parts of the rom.  All I really need to know is if it might serve a purpose or if it is just garbage data.

Code: [Select]
AA AA A2 AB AA EA AA AA A8 AA AA AE BA AA AA A2
AA A2 8A AB 22 A8 AA E2 AA AA AA A2 2A AA AA A8
8A AA A8 82 20 AA AA BA AA AA AA AA A8 AA A2 EA
AA 8A AA AE AA AA A2 AA 1A A2 AA AA CA AA 2A AA
A8 A8 AA AA AA 2A 8A AA AA AA AA AA 8A AE 2A AA
AA 2A AA 8A 2B AA AA AA AA AA AA AB AA AA 2A 82
A8 A8 AA A8 AA A0 AA A8 AA AA AA 2E AA AA AA AA
AE BA AA A8 AA AA AA AB 2A AA AA 0A AA A8 8A AA
AA A2 AA 2A AA AA AA 8A AA AA AA BA AA AA AA AA
8A AA 8A A8 AE 8A A8 AA 2A AA AA 32 AA 28 AA AA
A8 8A 88 A3 AA AA 8A 8A AA E2 AA AA AA AA AA 0A
AA AA AA AA AA 2A AA AA AA A8 AA AA AB A8 AA AA
AE A8 A8 AA AA A2 8A A8 AB 2A AA AA 8A A2 BA 2A
AA AA A2 AA AA AA AA A2 AA AA AA AA AA AA A0 AA
AA AA AA AA 8A AA 0A 0A AA A8 28 AE 2A AA 8A A0
AA AA AA AA A8 AA AA A2 AA 8A A2 AA AA AA AA 2A
AA CA AA A8 AA AA BA 8A AA BA AA A2 AA 8A AA AA
20 AA 22 AA AA 2A AB 8A A2 AA BA A2 AA 4A 8A AA
AA AA AA A8 AA AA A2 AA 2A AA BA AA A8 0A AA 88
80 AA A2 AA AA A2 AA AA 0A AA 2A A2 AA AA 0A A8
E2 AA 8A EA 8A 8E 8A AA 9A AA AB A9 AA AA AA A2
AA AA 2A 28 2A A2 A2 AA AA AA AA A8 8A BA EA A8
AA AA 2A A8 88 A8 2A AA AA

Pages: [1]