Banner
Views: 1,003,338,714
Time:
12 users online: AmyWiltender, Daizo Dee Von, DashGamer,  Deeke, E-man38,  Fernap, g_helfs, Hamilton64, Jordan, Kaio Henrique, Knucklesfan, Teadums - Guests: 80 - Bots: 192 Users: 54,839 (2,036 active)
Tip: Don't replace the first two Map16 FG pages unless you explicitly know what you're doing, or objects may act strangely.
Not logged in.
VWF Dialogues Patch v1.2
Forum Index - SMW Hacking - Resource & Tool Releases - VWF Dialogues Patch v1.2
Pages: « 1 2 3 4 512 13 » Link
It dosen't matter where you put the code. It's up to you. Everything $EF does is jumping to a subroutine, anyways. Everyone can put the code where he likes to put it. Personally I prefer many files over just one mixed one, though. Therefore I'll not change it. Also you can see customcode.asm as a compilation of subroutines. They ARE reusable. You can use the same routine in any message. Therefore it makes a lot of sense to have them all in one place. Makes it easier to find and edit them.

Also yeah, I meant dw. Sorry about that. :P

--------------------
Feel free to visit my website/blog - it's updated rarely, but it looks pretty cool!
But you couldn't put part of a message in a subroutine, could you? What about a command to check the value of A and do something (display a message, execute code, whatever) depending on it?

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

I'm working on a hack! Check it out here.
Originally posted by "imamelia"
But you couldn't put part of a message in a subroutine, could you?


Why would you want to do that, anyways? Or do you mean jumping to different parts of a message inside a subroutine? That would be possible I guess.

Originally posted by "imamelia"
What about a command to check the value of A and do something (display a message, execute code, whatever) depending on it?


Well the value of A is pretty much predetermined at the time messages are handled, but I guess I could actually use KilloZapit's idea and make a command that affects A and then call a subroutine. In fact, that way I could get rid of a few commandas that just change one address, anyways. Then again... I kind of like having seperate commands for waits and stuff like that. Well I'll see about that.

--------------------
Feel free to visit my website/blog - it's updated rarely, but it looks pretty cool!
Generally I make sure tables appear after RTS/L's, and keep everything in one file unless it's a huge file: Then I incsrc code that will likely be modified.

--------------------
I own a community of TF2 servers!

ASMT - A new revolutionary ASM system, aka 65c816 ASseMbly Thing
SMWCP - SMW Central Presents a Product- tion long name

frog

http://esolangs.org/wiki/MarioLANG
Well the text contatining asm file IS huge. It allows for $FFFF messages in theory. It will be way less when I drop bank crossing support, except if you put a new org $XX8000 each time you've filled a whole bank. There is a 24-bit pointer tabler which points to each message, so that won't be much of a problem. But yeah, to get back to my point: The file with the acutal messages will be huge so it makes sense to put custom code in a seperate asm file especially for reasons mentioned in my last post.

--------------------
Feel free to visit my website/blog - it's updated rarely, but it looks pretty cool!
My main objection to having more then one file is that, if there were no arguments, you would essentially have to re-write code for each message. It makes far more sense to have asm code that is only used once close to where it is used. Reusable code however should probably be together in it's own file.

Also, another way to do it is, instead of using a pointer table, just use direct pointers via labels. That would allow sprites/blocks to directly embed conversation data and just set an address to ram and call a routine to start a conversation, as well as allow asm to jump directly to wherever.

--------------------
Your layout has been removed.
What I'm doing right now is just using a 16-Bit-Address that you write a value from $0000 to $FFFF to to call that message. I think that's more than enough. Noone would ever use $FFFF messages anyways, especially not in a ROM limited to 4 MB (my patch doesn't compress text in any way and neither do I plan to implement that). But if someone really needed to read text from RAM or whatever, then by all means, he could do so. He just had to edit the pointer table. Normally it just says "dl Message0000,Message0001..." there. However, of course you could put a "db $7F4000" or something like that there if you wanted to read text from RAM. Actually this could be quite the good way to display dynamic messages. I already have a command to display the content of RAM Addresses, but with this method you would only use 1/4th of the space (this this command always needs four bytes; 1 for the actually command and 3 for the address).

--------------------
Feel free to visit my website/blog - it's updated rarely, but it looks pretty cool!
I wasn't talking about displaying text from ram, I was talking about loading the pointer from ram, rather then from a table. That way you practically have unlimited messages which can be included anywhere because you don't need to number them and point to them in a master pointer list. Though it makes sense to have a master list for level messages, it's much simpler to set the pointer directly for sprites or blocks that use their own messages so you can include the message in the sprite/block. Displaying from ram would add the extra step of uploading it to ram :P

--------------------
Your layout has been removed.
Which way would work best to keep from having to make a separate sprite for each message? Blocks are different since they don't take up that much space, but making a different sprite for each message would suck.
Well technically, the only difference is how it is referenced, so both could do multiple messages per sprite I admit using a global pointer table is easier though. I am mostly thinking about short messages, but I was just putting a idea out, I don't really think it matters so much. In fact depending on how it is coded if I really wanted to use a direct pointer I could just load it in where the normal code puts the pointer in ram and jump so it skips the pointer loading part.

You know I really should shut up and see how this patch develops rather then bringing up technicalities all the time.

--------------------
Your layout has been removed.
Nah, it's OK. The more feedback and ideas I get the better. After all I also want this to be useful for other people as well.

Anyways I'll include a few example sprites with this patch once it's done. One thing I could do, for example, would be a custom sprite that displays different messages depending on it's X- and Y-Position, kind of like Romi's VWF Sprite. That would allow you to use multiple messages with the same sprite.

I've also started working on this more actively yesterday. The new version is coming along nicely. I'm still thinking about making a SRAM expansion of the game mandatory when using this patch, because to use it without any errors under any circumstances (that means display a whole screen of text in just one frame) you'd need an additional 16 KB of free (S)RAM. The space at $7F0000 (which I got from using a patch) is already used to backup Layer 3 completely.

--------------------
Feel free to visit my website/blog - it's updated rarely, but it looks pretty cool!
I like the idea of using x and y positions. So, how many messages is that per sprite? You could also use the extra bit to go to another page of messages if you run out of messages in the first set of combinations of x/y positions.
Well it's hard to name a number. I'd say the only limit pretty much is ROM space. Otherwise you could put as many messages into a sprite as you'd want. In the end it's the code of the actual sprite that starts the message, not my patch.

--------------------
Feel free to visit my website/blog - it's updated rarely, but it looks pretty cool!
You could also use the extension bytes as soon as GEMS and Lunar Magic 1.72 come out.

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

I'm working on a hack! Check it out here.
Couldn't you reload layer 3 gfx from the rom rather then back it up?

--------------------
Your layout has been removed.
Originally posted by KilloZapit
Couldn't you reload layer 3 gfx from the rom rather then back it up?


Yes, I could, but that, for one thing, would mean I had to know exactly how that data is compressed (and then decompress it, which might take too long during gameplay) and additionally to that it wouldn't be compatible with whatever patch modifies layer 3 data. If I read from VRAM directly, however, there is no chance layer 3 modifications ever being incompatible with this.

--------------------
Feel free to visit my website/blog - it's updated rarely, but it looks pretty cool!
Also I realized the decompression buffer gets overwritten by LM's extended animation tiles.

On a semi-related note, I was reading something a while ago about cart identifier vectors that said carts could have "extended ram" as well as "battery ram". Are these both different types of SRAM, or does "extended ram" refer to some non-sram extended ram? If sonis it the 7Fxxxx range or is it addressed differently?

--------------------
Your layout has been removed.
I think Extended RAM is just the regular RAM and Battery RAM is SRAM. Don't quote me on that, though.

--------------------
Feel free to visit my website/blog - it's updated rarely, but it looks pretty cool!
I wonder: Does SRAM have any big disadvantage compared to RAM? For example: Being slower to access or something like that? If it doesn't I might just make my patch expand SRAM to 64 KB by default and then put both, layer 3 backup and actual VWF stuff into SRAM. That way I wouldn't have to use Kaijyuu's patch. Additionally I would get rid of a glitch that occures if you leave the level while a dialogue is being displayed. Normally I'll try everything possible to prevent this, but it might still be possible under certain circumstances (especially when choosing the "Don't freeze sprites" option). Anyways, if you use the RAM at $7F0000 together with Kaijyuu's patch, it will get overwritten once you get to the overworld. Entering a level will write glitched graphics to layer 3 then. By using untouched SRAM I could prevent this completely.

--------------------
Feel free to visit my website/blog - it's updated rarely, but it looks pretty cool!
Just make sure you test it with the SRAM expand patch (or make a version that is compatible with it). If it doesn't work with that patch, I'll be sad. :(
Pages: « 1 2 3 4 512 13 » Link
Forum Index - SMW Hacking - Resource & Tool Releases - VWF Dialogues Patch v1.2

The purpose of this site is not to distribute copyrighted material, but to honor one of our favourite games.

Copyright © 2005 - 2022 - SMW Central
Legal Information - Privacy Policy - Link To Us


Menu

Follow Us On

  • YouTube
  • Twitch
  • Twitter

Affiliates

  • Super Mario Bros. X Community
  • ROMhacking.net
  • Mario Fan Games Galaxy
  • sm64romhacks