Author
|
Topic: Screenshots (Read 67862 times)
|
byuu
Guest
|
 |
« Reply #225 on: January 18, 2008, 07:44:32 pm » |
|
All ten dynamic names are tightly packed into RAM, loaded from the save RAM file. It's a really bad idea to try expanding or moving it, as you may end up corrupting some other important area in the game. Or if you stick it in the wrong spot, the game might even overwrite your names.
You could expand SRAM and store the names there, but that's generally not a good idea, either. Especially if you want it to work on copiers with tiny SRAM, or the same type of PCB it was printed on initially.
It's also not a good idea to try storing some data from one name inside of another (eg give Byuu + Yoyo eight character names, use the extra storage to allow 11-bit names for Fahrenheit + dragons), as all kinds of issues may come up with saving and loading names.
Another idea would be to encode in base-53, rather than base-64. Which is even more complex to encode with, and as I don't feel like computing the storage amount that would need right now, it might not even store more than ten characters (though it will most likely store at least 11 that way.)
That's also a whole hell of a lot less portable and reliable for languages which have more than just A-Z+a-z (pretty much all of them.)
In fact, even the 6-bit encoding doesn't play out so well for non-Latin-alphabet derived languages.
|
|
|
|
|
Chester
Guest
|
|
« Reply #226 on: January 19, 2008, 08:36:47 am » |
|
It's all true, I have been thinking about that but I can't find out a solution. The main problem is the lack of space in SRAM, as already said. In fact, even the 6-bit encoding doesn't play out so well for non-Latin-alphabet derived languages. In fact, I had to remove the numbers from the name selecting screen. |
|
|
|
|
byuu
Guest
|
|
« Reply #227 on: January 19, 2008, 08:30:45 pm » |
|
In fact, I had to remove the numbers from the name selecting screen. Honestly, I think your 6-bit encoding was a really good move. It was also extremely innovative, since nobody else has ever publicly mentioned an idea like that before. We certainly need more people who think outside the box like that in our scene :) Besides, it's kind of silly to accept characters like 0, 4, 7, (, ), #, %, etc on a name entry screen. Sure, people like using their "leet" internet handles in games, but oh well. Personally, I think it's more professional to only have actual letters and a space character on name entry screens. And in this case, that handicap gives you the ability to enter ten-letter names for Salamander, Ice Dragon and Fahrenheit. Would you rather have Salmandr, IceDragn and Farnheit in exchange for someone being able to name Byuu "_^MaG4^_" ? I bet Alessandro wouldn't ;) |
|
|
|
|
Gemini
Guest
|
|
« Reply #228 on: January 19, 2008, 09:20:02 pm » |
|
Honestly, I think your 6-bit encoding was a really good move. It was also extremely innovative, since nobody else has ever publicly mentioned an idea like that before. Not really:  It's like one or two years old.  I even remember you answering to that image and mentioning the idea of 6-bit names for BL in this same topic.  Besides, it's kind of silly to accept characters like 0, 4, 7, (, ), #, %, etc on a name entry screen. Sure, people like using their "leet" internet handles in games, but oh well.
Personally, I think it's more professional to only have actual letters and a space character on name entry screens. And in this case, that handicap gives you the ability to enter ten-letter names for Salamander, Ice Dragon and Fahrenheit. Totally agree on the matter. Unless you are going to use some particular names (i.e. robot names [RY66]), numbers and symbols are totally useless. And screw l33t names. |
|
|
|
|
byuu
Guest
|
|
« Reply #229 on: January 19, 2008, 10:40:18 pm » |
|
It's like one or two years old. I even remember you answering to that image and mentioning the idea of 6-bit names for BL in this same topic. ... oops. Me and my lousy memory :/ That looks really good, by the way. FF6 would look a lot nicer with an 8x8 VWF. That was one thing I wished Chris would have done for FF6. I know he was throwing the idea around and all, but, well, yeah ... |
|
|
|
|
Chester
Guest
|
|
« Reply #230 on: January 20, 2008, 03:49:03 am » |
|
The FF6 PSX screenshot is old but still beautiful *_* Honestly, I think your 6-bit encoding was a really good move. It was also extremely innovative, since nobody else has ever publicly mentioned an idea like that before. We certainly need more people who think outside the box like that in our scene  Thanks Another idea would be to encode in base-53, rather than base-64. How can you do that? |
|
|
|
« Last Edit: January 20, 2008, 04:30:05 am by Chester »
|
|
|
|
|
|
byuu
Guest
|
|
« Reply #232 on: January 22, 2008, 10:02:58 am » |
|
Another idea would be to encode in base-53, rather than base-64. How can you do that? Think of it like extended multiplication for encoding, and division for decoding. An 8-byte string is really just a 64-bit number. Well, an example works better than words: #include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <stdint.h>
uint64_t encode(const char *name) {
uint64_t result = 0;
for(int n = strlen(name) - 1; n >= 0; n--) {
result *= 53;
if(name[n] == ' ');
else if(name[n] >= 'A' && name[n] <= 'Z') result += (name[n] - 'A' + 1);
else if(name[n] >= 'a' && name[n] <= 'z') result += (name[n] - 'a' + 27);
else throw;
}
return result;
}
void decode(char *result, uint64_t name) {
while(name) {
int x = name % 53;
name /= 53;
if(x == 0) *result++ = ' '"";
else if(x < 27) *result++ = x - 1 + 'A'"";
else if(x < 53) *result++ = x - 27 + 'a'"";
else throw;
}
*result++ = 0;
}
int main() {
uint64_t name = encode("Thunderhawk");
printf("encode = %0.8x%0.8x\\n", (uint32_t)(name >> 32), (uint32_t)(name));
char t[16];
decode(t, name);
printf("decode = %s\\n", t);
return 0;
} encode = 5c1194473d06e3d9 decode = Thunderhawk You can think of the 8-byte string as a 64-bit number. You can tell the length limit by using all of the highest possible character ('z' in this case), and run until the highest bit (0x8000000000000000) is set. You know you can't add even one more number then without potentially overflowing your value. In our case, base-53 yields an 11-character name as an upper limit. encode = 80a23b117c8feb6c decode = zzzzzzzzzzz Looks like a perfect solution for "Thunderhawk" :) And we can use the SNES multiply and divide+modulus registers to do the above math for us. No, it won't be fast, but then, how fast should name encoding / decoding be, anyway :) The only problem then would be that 11x 'W' in pixels would be 66 (65 if you don't care about the space at the end), which would overflow a tile of eight characters. Damned if you do, damned if you don't, right? You could then always make the max name length dynamic. Don't allow more characters than will fit in either 6-tiles for names, or 8-tiles for dragons, or 11-characters total. |
|
|
|
|
Chester
Guest
|
|
« Reply #233 on: January 22, 2008, 11:26:02 am » |
|
The only problem then would be that 11x 'W' in pixels would be 66 (65 if you don't care about the space at the end), which would overflow a tile of eight characters. Damned if you do, damned if you don't, right? You could then always make the max name length dynamic. Don't allow more characters than will fit in either 6-tiles for names, or 8-tiles for dragons, or 11-characters total. I think we can use two fonts, the normal one and a smaller one, and display that or the other depending on the width of the string. And we can use the SNES multiply and divide+modulus registers to do the above math for us. No, it won't be fast, but then, how fast should name encoding / decoding be, anyway The only problem would be handling a 64-bit integer with a 16-bit accumulator, but it can be done. |
|
|
|
« Last Edit: January 22, 2008, 03:32:53 pm by Chester »
|
|
|
|
Kajitani-Eizan
Guest
|
|
« Reply #234 on: January 22, 2008, 12:10:38 pm » |
|
while you're at it, you might as well do base 56, right?
|
|
|
|
|
Lupus Erectus
Guest
|
|
« Reply #235 on: January 22, 2008, 01:45:06 pm » |
|
This is starting to look way better than expected  (All the unit palettes are loaded in VRAM, but only the soldier icon has been modified to use it) |
|
|
|
|
byuu
Guest
|
|
« Reply #236 on: January 22, 2008, 02:10:55 pm » |
|
I think we can use two fonts, the normal one and a smaller one, and display that or the other depending on the width of the string. I tried that with Dai Kaijuu Monogatari. I only had four tiles for names, but eight letter names. So the worst case fallback was a 3x7 font. It looked really bad. For this case, your 'W's would all have to be 3 pixels wide (plus one for space) to be consistent. I actually had three fonts to choose from in Daikai, but it still looked awful and inconsistent. I'd personally prefer a variable character limit, myself. The only problem would be handling a 64-bit integer with a 16-bit accumulator, but it can be done Very true. You would have to simulate a 64-bit integer by way of the carry and add/sub operations. Most likely, you'd have to use a mul/div software implementation using only add/sub/and/or/xor. Definitely not going to be easy, but it depends how far you want to go for perfection, I guess :) while you're at it, you might as well do base 56, right? You can use any base, so long as (max(1, base-1))^11 <= unsigned int64(-1), yes. Might as well use the highest possible base to provide support for as many languages as possible. Map the unneeded characters to spaces. They won't be on the name entry screen anyway. |
|
|
|
« Last Edit: January 22, 2008, 02:16:09 pm by byuu »
|
|
|
|
Chester
Guest
|
|
« Reply #237 on: January 22, 2008, 03:18:12 pm » |
|
I tried that with Dai Kaijuu Monogatari. I only had four tiles for names, but eight letter names. So the worst case fallback was a 3x7 font. It looked really bad. For this case, your 'W's would all have to be 3 pixels wide (plus one for space) to be consistent. I actually had three fonts to choose from in Daikai, but it still looked awful and inconsistent. I'd personally prefer a variable character limit, myself. But in our case, I guess we can use a bigger "W" (at least 4 pixels). Gemini passed me a quite good small font, which doesn't look so awful to me. However, keep in mind that it should be used only for very longs names. Very true. You would have to simulate a 64-bit integer by way of the carry and add/sub operations. Most likely, you'd have to use a mul/div software implementation using only add/sub/and/or/xor. I was thinking over that. In fact you can't use the multiplication registers as you said at first. Definitely not going to be easy, but it depends how far you want to go for perfection, I guess :) I'll try and let you know. |
|
|
|
« Last Edit: January 22, 2008, 05:30:11 pm by Chester »
|
|
|
|
DaMarsMan
Guest
|
|
« Reply #238 on: January 22, 2008, 04:54:36 pm » |
|
Who...who are you Chester. You seem pretty knowledgeable for someone just getting into romhacking.
|
|
|
|
|
Nightcrawler
Guest
|
|
« Reply #239 on: January 22, 2008, 06:06:01 pm » |
|
Very true. You would have to simulate a 64-bit integer by way of the carry and add/sub operations. Most likely, you'd have to use a mul/div software implementation using only add/sub/and/or/xor. I was thinking over that. In fact you can't use the multiplication registers as you said at first. Let me know if you have trouble with this. I add advanced multiplication and division routines to small processors all the time. I typically work with 8-bit micro-controllers at work and have to code assembly provisions to deal in 32-bit math. Though any size is trivial when you get the mechanics down. You're just looping, checking for end of operations, carrying/borrowing, adding/subtracting, and storing in memory. 64-bit operations may turn out to be slow on the SNES. Especially if you were say dividing a 64-bit number by a smaller 8-bit number or something. I have been able to create noticeable delay on ~4Mhz chips with operations like that. |
|
|
|
|
|
RHDN Forum Archive
