$ hd -n 256 common_rel
00000000 4c 5a 53 53 00 14 e5 b0 00 07 4c 61 00 00 00 00 |LZSS......La....|
00000010 ea ed f0 7d e6 f8 0b ed f0 4c 00 00 ab 15 3c ed |...}.....L....<.|
00000020 f0 27 ed f0 03 ec f2 14 eb bf 70 12 00 60 ed f0 |.'........p..`..|
00000030 10 01 01 fd 01 ea f4 05 fc 00 00 0a 80 4a ed f0 |.............J..|
00000040 04 ed f0 01 12 02 e7 f7 a5 2a 00 fd 9c f3 f8 40 |.........*.....@|
00000050 00 00 0d 0c 00 7f 00 18 4c 00 14 a7 14 dc ff fc |........L.......|
00000060 73 0f e5 f9 94 21 ff f0 93 e1 ff 00 0c 7c 3f 0b |s....!.......|?.|
00000070 78 3d 20 d7 00 00 3d 19 00 38 fd f0 90 09 00 a0 |x= ...=..8......|
00000080 00 9f 0f b1 0f c3 0f d5 0f e7 0f f9 0f 0b 1f 00 |................|
00000090 1d 1f 2f 1f 41 1f 53 1f 65 1f 77 1f 89 1f 9b 1f |../.A.S.e.w.....|
000000a0 00 ad 1f bf 1f d1 1f e3 1f f5 1f 07 2f 19 2f 2b |...........././+|
000000b0 2f 00 3d 2f 4f 2f 61 2f 73 2f 85 2f 97 2f a9 2f |/.=/O/a/s/./././|
000000c0 bb 2f 00 cd 2f df 2f f1 2f 03 3f 15 3f 27 3f 39 |./../././.?.?'?9|
000000d0 3f 4b 3f 00 5d 3f 6f 3f 81 3f 93 3f a5 3f b7 3f |?K?.]?o?.?.?.?.?|
000000e0 c9 3f db 3f 00 ed 3f ff 3f 11 4f 23 4f 35 4f 47 |.?.?..?.?.O#O5OG|
000000f0 4f 59 4f 6b 4f 00 7d 4f 8f 4f a1 4f b3 4f c5 4f |OYOkO.}O.O.O.O.O|


First word is obviously a signature; second is 1,369,520, which is about 2.9 times the file's size, so good bet for uncompressed size; third is 478,305 which the file's size; fourth is likely padding, but potentially an offset into the file (minus header).

What I've seen from similar formats was that the header pointed to two sections, one containing raw data and the other containing offset/length pairs, and was followed by a bitmap telling which to read from next. This doesn't have any such pointer, and the following data seems to have quite a few zero bits, actually resembling machine code somewhat for the first few words. The name "common_rel" suggests an executable, so this makes sense. I haven't tried to disassemble it though, so I might be way off there.

As you look further into the file there are some pretty obvious patterns, which is strange for compressed data. Starting around 0x700 looks like some type of uncompressed graphic. Especially you can see a pattern 1C xx xx repeating often... but, sometimes there are three bytes between the 1Cs instead of two. That looks similar to the ASCII text around 0x440, that has readable words with single bytes inserted:
00000480 05 c5 07 e7 77 69 6e e7 00 d5 0c 76 69 72 ef 74 |....win....vir.t|
00000490 75 61 6c bf 0a 73 69 72 ff 65 6e 5f 61 74 6d 6f |ual..sir.en_atmo|
000004a0 73 fe bf 0a 6c 65 76 65 6c 5f 75 f9 70 aa 03 9a |s...level_u.p...|

And there's an obvious bit pattern in some of those. Check this from 0x48E:
EF ;binary 1110 1111
74 75 61 6C ;ASCII "tual" (from "virtual")
BF 0A ;???
73 69 72 ;ASCII "sir" (from "siren"?)

FF ;binary 1111 1111
65 6E 5F 61 74 6D 6F 73 ;ASCII "en_atmos" (siren_atmos, probably a sound file name)

FE ;binary 1111 1110
BF 0A ;???
6C 65 76 65 6C 5F 79 ;ASCII "level_u"

See the pattern... Counting from right to left (least significant bit first), 0xEF has 4 ones, a zero, and three ones. And immediately after it, we see 4 bytes of ASCII, something unusual (BF 0A), and then three bytes of ASCII. The same pattern follows further on: FF followed by 8 ASCII bytes, FE followed by one unknown (BF 0A again) and 7 ASCII bytes. So, obviously these bytes are bitflags, counting from least significant bit upward, where 1 indicates a raw data byte and 0 indicates something else.

I would expect that "BF 0A" is some type of offset, meaning to copy some bytes from elsewhere into the output. I also notice that these are occurring at the end of each string, and 0A is a newline character, but this doesn't seem to repeat further on, so this is probably coincidental.

I'd guess that BF 0A means to copy 0xA bytes from offset 0x0BF. In other formats I've dealt with, those are relative offsets, so this would mean seek 0xBF bytes back in the output buffer and copy from there. It's a bit odd to see the same offset twice if it's relative, though. Another interpretation is 0x0A bytes from 0xBF. More likely, the actual count is 0xC or 0xD, because it takes two bytes to encode this, so there'd be no reason to ever have a count of less than 2. 0xC seems likely, since it's a multiple of 4, so as to align the strings to word boundaries.

If we assume this applies to the entire file after the header, we run into an interesting situation: the first byte is EA, binary 11101010, which means the first bit decoded would be 0, meaning to copy from previous output... but there's no previous output to copy from, so that doesn't make much sense. The pattern does seem to fit, though:

EA ;binary 1110 1010
EDF0 7D E6F8 0B EDF0 4C 00 00
AB ;binary 1010 1011
15 3C EDF0 27 EDF0 03 ECF2 14
EB ;binary 1110 1011
BF 70 1200 60 EDF0 10 01 01
FD ;binary 1111 1101
01 EAF4 05 FC 00 00 0A 80

following the bits from lowest to highest, we reliably encounter pairs that resemble those we saw earlier, and bytes that don't, exactly where we'd expect. So it's reasonable to say that this is the encoding of the entire file; the question being what exactly ED F0 (and BF 0A and so on) means.

Mostly they seem to be twelve bits having a high value (0xEDF, 0xE6F, 0xBF0) and four arbitrary bits. That corresponds well with length/offset pairs, and matches some of Nintendo's older compression formats. I always thought it didn't seem very efficient when the maximum number of bytes that can be repeated is so small, though.

Still, that doesn't tell where the data is coming from, given these offsets don't make any sense for such a large output buffer. (The offsets might be interpreted as 0xFED, 0xFE6, 0x0BF, but they're still too large.) It's possible they're offsets into some separate dictionary. That would make the repeated offsets between strings make sense, too, especially if it's padding and/or metadata. Being an offset into the file itself is another possibility, but it doesn't look that way here.

So, it might be necessary to find a dictionary table that goes with these files.

--------------------

Originally posted by nensondubois

---

Ok, after about a week, I have determined that roughly 80% of all SGB games have the same DATA_SND transfers. I'm curious about what this actually does now.

---

It's probably boilerplate init code from the SDK, that just plays it safe like Nintendo likes to, and resets everything back to defaults whether it's going to be used or not, and really doesn't need to be mentioned in every goddamn article.

--------------------

I guess only if they're hosted on Youtube it'd be an issue. Modern video container formats allow for multiple tracks.

Oh, and I vote for a rule mandating the use of hacks that disable those goddamn health alarms.

--------------------

I prefer to be shaved, but I'm lazy, so sometimes it builds up until it's enough to annoy me. and for me too one day is enough to have stubble, but my skin seems to be too sensitive, that if I try to shave daily, it gets irritated, so only every second day...

--------------------

Mhm, a lot of games have these strings inserted by dev tools and libraries, that are never shown in the game, and usually noted on TCRF.

--------------------

Ew, body hair.

(finally) posting from my phone.

--------------------

I already have the health bar to alert me to the problem, and not dying as incentive to fix it. I don't need a constant blaring alarm ruining the soundtrack. Especially when I have no way to heal anyway, or still more health than I need for what I'm doing.

Some games will play a warning sound once per hit on low health, or when you enter a room. Mario 64 just had Mario pant (unless you were in water, even just on the surface). That's plenty of warning without being annoying.

It's worse in TAS because players will remain at low health for extended periods before using death as a shortcut. In Pokemon the alarm actually cuts some animations short, so people will leave it running for long times. And when you're watching the video (or making it, even) it serves absolutely no purpose.

--------------------

I'm seeing very wide tables that don't reflow correctly on zoom (maybe because they're tables?), thus being only readable at the farthest zoom unless you like panning back and forth a lot. The post textbox is huge, which also leads to a lot of scrolling (and cursor movement being stupid) since it forces zoom... Mostly Android-being-shit issues but still.

Ikachan gets in the way a bit on these small screens too.

--------------------

Well, that's still no reason to have a constant sound going on.

(reminds me, Link pants in OoT too...)

--------------------

Well, it should still be possible to send a recovery link to those who do specify emails, and if you don't, too bad... but, does it happen often enough to even be worth the effort?

--------------------

Hm, but how would you know it's the actual account holder requesting it? When it's by email, you can check the address on the account, but otherwise I think all you'd have to verify is an IP address. Unless you add some type of secret-question thing. (and if you do, for the love of god, let people write their own questions. )

--------------------

Yeah man, this thread stinks. What is this shit? You may think your comedy is #1, but you clearly just pulled it out of your ass, or at best found it written in a bathroom stall. I suggest you go toot your own horn somewhere else. This is a forum, not a college farthouse.

Sorry for being anal, but I consider it my doody to flush crappy jokes down to the bowels of hell and wipe the smile clean off the asshole who dumped them on us all. This is like the turd time today some stinker has tried to give me the runs-around with their toilet jokes, and I just can't hold it in anymore. You little shits need to get off your thrones and sharten up.

I just hope nobody wasted the paper to print them.

--------------------

Originally posted by Bisqwit

---

Originally posted by Reimu

---

Also, you people might want to try this. No gravity, but always gives you the immediate worst piece.

---

Somehow all of these worst-piece Tetris games revolve around giving disproportionally large numbers of S and Z pieces.

---

That's because they're the worst pieces, existing only to fuck your shit up.

--------------------

Originally posted by Adelheid

---

Originally posted by Xkeeper

---

Unless it's the first one, in which case the green one doesn't exist and one of them gives you 100% more.

---

Ah, but you forget.

And this is critical.

The green potion demonstrably exists.

---

It's an illusion.

--------------------

I read the headline as "Florida restauranteur dooms self to lack of tips, business; annoys unaware customers".

--------------------