<- 1  -   of 75 ->
^^
vv
List results:
Search options:
Use \ before commas in usernames
no comic sans?
ooh that's cool! Is that tool going to support multiple glyph layers (as found in the MP2+ FONT formats)?
yep, those are supported but I haven't tested them yet. I only just got it working.

character spacing isn't quite right, there's no kerning yet and it doesn't do outlines yet either, but I think those things are all fixable.

bonus Comic Sans for biospark:


attachment:
why. biospark this is your fault.
haha.

good work on the wiki. it didn't leave much unanswered.
WHYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYY
A Washing Machine
God damn it biospark
I know the Comic Sans is there as a joke but in general, if the fonts insert at that size the UI becomes way too cluttered. Is there a way to make it smaller or is that on your to-do list for the program?
yeah, it's an option (or will be). that was just literally the first size I tried.
Alright just wondering. Still a very cool idea for a tool!
XD that's freaking hilarious

It actually does a decent job with the oversized glyph layout
Edit history:
jackoalan: 2016-03-03 02:39:42 am
More particle stuff!
http://www.metroid2002.com/retromodding/wiki/PART_%28File_Format%29

That's almost 100% complete, though LIT_ and RSOP needs to be figured out.. and any properties added after MP1.

EDIT: Oh KSSM also needs to be documented.. I'll probably add a separate section for that data layout
How complete is the documentation on the animation stuff?
It should be complete or close to it
MP1/2 ANIM docs are pretty darn close to complete, aside from some header fields.

MP3 still has some unknown operational aspects, like the per-frame signal bit in the bitstream and the extra bits in the bone key header channel (where the W sign bit is extracted from), As well as a bunch of header fields. I suspect they play a role in triggering CHAR events while associating them with bones.
Edit history:
Antidote: 2016-03-10 03:05:35 am
Sooo, I got curious about a few of the fonts in the series so I decided to look them up:
The digit font in MP1 is quite a bit like Crubster:
http://myfonts.us/td-QpLCCt
The japanese font in MP2 and 3 is called DF So Gei - W5
Which is FIVE HUNDRED DOLLARS (USD):
http://www.fonts.com/font/dynacomware/df-so-gei-japanese/w-5

And the stylized font used in MP2 and 3 which looks like the image attached, is VoxBox:
http://www.dafont.com/voxbox.font

Those are the only ones I've been able to successfully track down.

mp1 jp credits font is just arial
Yep, which makes it annoying because we can't distribute it.
Edit history:
Antidote: 2016-03-11 01:23:48 am
Oh, a bit more info on FONT:
What we thought was the index to the GLYPH's kerning information isn't so, it's actually just where the font STARTS checking, which is why it can be the larger than the actual number of entries.

CKernPair is the wchar, wchar, int set and it SEEMS that the engine is checking if either of those characters are nearby, if so it moves the glyph and bails, otherwise it continues checking.
Quote from Antidote:
Oh, a bit more info on FONT:
What we thought was the index to the GLYPH's kerning information isn't so, it's actually just where the font STARTS checking, which is why it can be the larger than the actual number of entries.


Soo... it's the index to the glyph's kerning info? :P
Yes, but it's currently marked in a manner that suggests it's for the glyph in question, not to iterate from that point.
In other words, it's misleading.
I kinda figured that was obvious though. There's no count of how many kerning pairs each glyph has, so the only way to read them is to iterate from that point.
Edit history:
Antidote: 2016-03-11 06:24:39 pm
Antidote: 2016-03-11 06:23:56 pm
While I'd tend to agree, that's not strictly true, so explicitly stating that it's the start would remove any ambiguity.

Edit:
So I went through and actually RE'd, with jacks help, the function responsible for getting the kerning info, and this is what it looks like:
Code:
    static s32 KernLookup(const std::vector<CKernPair>& kernTable, s32 kernStart, s32 chr)
    {
        auto iter = kernTable.cbegin() + kernStart;
        for (; iter != kernTable.cend() && iter->GetFirst() == kernTable[kernStart].GetFirst() ; ++iter)
        {
            if (iter->GetSecond() == chr)
                return iter->GetHowMuch();
        }

        return 0;
    }


Parax actually got pretty close way before this though.
technically, that was me.
ah, so you were, lol.