wow that's incredible... I've always wanted to play this game after getting addicted to the original SNES one.

Are you just translating it to Italian or will there be an English version too?

Ask in the coding subforum or get a few (GB)Z80 manuals for recoding some other routines.

Its a flexible 8-bit CPU.(sadly this is just a partially compatible Microcontroller)

Universal VWF? One routine to end them all...er rule them all.

http://transcorp.parodius.com/forum/YaBB.pl?num=1228747326

Tenshi No Uta was similar in nature, and why I started the universal routine to begin with. A different text engine was used for every different kind of text. Multiple text engines were used on the same screen! A single menu screen could use say 3 or 4 different text engines. A typical battle could see say 5 or 6 depending on what you do. After I implemented 2 or 3 VWFs and discovered how many more there were, I had enough! No sense rewriting the same basic code over and over. That's software design 101. It indicates a problem in your design!

What's even more interesting is Tenshi No Uta's lineage is Wolf Team, who did Tales of Phantasia and Star Ocean. Several of those guys went to Tri-Ace if I'm not mistaken. I imagine there's probably a loose connection of people between the two.

As far as practicality and speed on the SNES, mileage will vary. There are several text engine scenarios on the SNES (sprite text, straight tilemap text, dynamic draw text etc.) It's definitely fine for dialog where you typically print a character per frame. It's probably OK for anything where the screen is already drawn dynamically. It's generally OK for basic menu screens too if they are fairly static, or don't fill the entire screen with walls of text.

Where you run into issues is when the original font is fully stored in VRAM and text routine was a straight tilemap to that font. The entire screen is typically rendered in a single frame, refreshed each frame in that situation. That's where you really suffer, especially if the screen is completely filled with text such as a scrolling full screen item list. It can be difficult to VWF that situation properly, even when you do a specialized routine (not even possible in some cases if you don't have enough VRAM). Add in the overhead of the universal routine and I've found it very difficult to get acceptable speeds. The more flexible I make my routine, the more overhead it incurs. So, some balance must be struck. It will certainly not be ideal for all cases. It's just not possible.

I am experimenting with several ideas to do a better global job on all situations. Rather than a true universal routine, I can be more modular where you plug in the correct function calls from a library designed to work together for the situation you need. It's not as user friendly (all you do now is define a handful of starting variables and a few things like what values to drop out of the text rendering loop with), but more practical. Another idea is perhaps there should be three VWFs to rule them all, one for each major type (sprite, straight tilemap, dynamic). Then it could be optimized for each target reducing overhead greatly.

So, there's definitely plenty left to do. In the end, it may not be something very useful to others. As an end user, there's a balance between how much time you'd need to learn my system to use effectively versus time saved from not doing it yourself. You already need to be an intermediate hacker to figure out where this routine needs to go and configure it properly. If the learning curve continues upward and requires more of the user, and may deliver slow results, one might be more inclined to do it themselves. We'll see where this experiment goes. It will definitely be useful to me if nothing else.

You know, the only logical reason I can think of why you would code a game like that would be a bunch of people were thrown in separate isolated rooms unable to communicate and told to code their small task. It's like the guy who needed to code the 'Gold XXX' display on the menu had absolutely no knowledge of any other text engine, routines, or even fonts. He made new everything from scratch just for that. Several others did the same.

That's a bit of an exaggeration, but that's really what it seems like must have occurred. Parallel tasking, little collaboration. There's just far too much duplicated efforts for any other reasonable explanation.

I have already used a macro and defined some pretty generic routines, the problem is that this code is executed lots of times and I want it the fastest possible so I've had to define much of it as a macro to avoid the overhead of doing a lot of calls (and a lot of bank switching in some cases which add a lot of overhead imho).

To make things faster i've only jumped from the original routine to mine routine, i'll define some "bounds" (i think using the .org directive should block WLADX from overwriting) and overwrite the original routines as much as possible to get some more space. If there's enough space i'll try to do a little refactorization of the code and move things around to have even more space in the first bank (though that's where most of the code have to be to avoid doing more bank switching than necessary)

UGAAAAAAAAAAAA!!! (*cries*)