So then...what sucks about Mysterious Song?

[Tom]

Will there be a Super EX + alpha ' version?

 I thought you're supposed to write out the "+" as a word; super EX 'plus alpha.

[nodtveidt]

One thing I have observed from this project is that it has really pushed the limits of HuC's capabilities, and has shown that HuC's code generation is less than optimal. Yeah, it's certainly possible to do a big game with HuC, and this project proves it. But it also proves that stuff like this is better suited to assembly. Memory consumption is a constant battle as you have to find new ways to optimize for smaller code generation.

As of right now, Beta 3 of the game, the last major beta version before the Release Candidates, is being prepared for release right now. The release will come within the next hour or so.

[Arkhan]

yeah, the function call overhead alone that HuC generates is enough to make you wanna go ASM-fu on it

[nodtveidt]

Sure does. As it is, I've gotta rewrite a major portion of the text displayer to cut back on memory consumption. It's WAY too greedy. Of course, that means writing new utilities...but I'm used to that already.

Beta 3 was released a little while ago, so we're now on the home stretch.

[Arkhan]

so we're now on the home stretch.

careful , youre going to jinx it.
>_<

[nodtveidt]

Can't jinx it any more than I already have.

[nodtveidt]

I've implemented the new text display function, and even though all the code hasn't been converted yet, it's already down 8KB in size. That's a huge reduction in code size, and it can only continue to go down further.

EDIT: Now down 16KB!

[Necromancer]

Wanna know what really sucks about Mysterious Song?
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
That it hasn't been released yet. 

[nodtveidt]

Hehe. Well, we're working on that now. The code for the trouble town has been reduced by 24KB by switching all of the English dialogue over to the new routine. I will next do the same thing for the Spanish script, which is likely to drop it another 24KB in size. By going around and using this technique on all of the areas of the game with heavy text, the overall size of the game will be greatly reduced, making load times smaller and reducing the possibility of read errors on old hardware.

[ParanoiaDragon]

Which also means more room for niceties(is that a word), like clouds n' stuff I'd assume.........but only if we can still release the game on time!

[nodtveidt]

The world map doesn't have heavy text in it so utilizing it there might be fruitless and might even have the opposite effect...

[ParanoiaDragon]

doh

[lord_cack]

Well, I have been away  hehe

I don't really want to dredge up things that (as of Page 5 in this thread) have been handled. But, I only took a small offense to what was said, thats mainly because I worked hard on ALOT of the tiles in this game.

I began work on this game in 2005 after it was made apparent the game was gonna need a complete graphical overhaul. The castle tiles were the first set I did. What I like about this set? I like the texture of the floor and the walls look pretty good. As for a 10th grader being able to do better.... I had done exactly Zero tile work, graphic design, pixel art, ANY computer art before those tiles. This isn't a group  of professional game designers here you are talking about, we aren't ex-gamedesigners, and for the most part we aren't technical wizards (as far as I know....  ) this isn't a group of people who can even communicate there ideas in an instant, I have never met the fine people I work with never heard there voices. We are a group of people (scattered around planet) who love games, who have a great deal of passion about our particular parts in these projects, we are people who LOVE this system. We want to make games, create something outside of ourselves, and allow other people who love this system to continue to play it for years to come....

Im glad to hear everyones positive feedback. Thanks for caring enough to be honest. I hope you all enjoy the final product, I know I will.

I look forward to everyone seeing our upcoming titles 

[esteban]

Well, I have been away  hehe

Hey. Good to hear from you.

Hope all is well.

[TheOldMan]

ThOldRover:
"the BRAM functions require a single, contiguous region of memory. MSR uses a lot of different arrays and variables. Therefore, it is necessary to put all the variables and arrays into one large array when saving..."

Since HuC almost requires everything to be global (for speed), the copy then write isn't really necessary; just list everything you want to save in order, get the address of the first thing and the number of bytes needed, and write from there. Same thing for loading.

HuC assigns variable addresses in the order they are declared, so if two things follow each other in the code, they follow each other in memory. Makes block writes like that a lot easier (but watch out if you cross a page boundary.)
Personally, I use HuC to get a working (though slow) prototype running, and then use the overscan trick to see what needs optimizing. Then I go assemblerize the parts that take a huge amount of time. Since I have a working version of the C code to go from, I can swap the assembler stuff in and out to make sure it's working right. And, if I need to, I can refer to how HuC generated the assembler, just to make sure.
It's a bit more work than writing it all in assembler, but I tend to think in C. And for the most part I only have to optimize a few routines to get the speed I want.