Banner
Views: 790,416,018
Time:
5 users online:  KKevinM, niko, Pink Gold Peach,  poopsey, underway - Guests: 36 - Bots: 158 Users: 41,262 (1,500 active)
Latest: Teisen
Tip: If you use custom music, make sure your ROM has been expanded to at least 1MB.Not logged in.
Lunar Magic suggestions and discussion (LM v3.10)
Forum Index - SMW Hacking - Resource & Tool Releases - Lunar Magic suggestions and discussion (LM v3.10)
Pages: « 1 218 19 20 21 »
Originally posted by FuSoYa
Something similar has already been in LM since 2.53. It's on alt-middle click. You don't even need to have viewing screen exits turned on, you can just click anywhere within the screen that the exit applies to.

Whaaat! I had no clue! It's mentioned in the Main Window Mouse Behavior section of the help file too... I think it's weird that it's on middle click and that it works even with screen exits view turned off, but I'm still happy to learn that the shortcut exists
If you make an horizontal level with horizontal setting 1C and level mode 02, this is what happens. Is this intentional or a bug? Either way it shouldn't be allowed to be selected if that's what happens.

Or on second thought, maybe it's the fact layer 2 halves the amount of screens usable. Maybe you should make the descriptions in horizontal settings take that into account when you have a layer 2/tide level.

--------------------
Baby please, would you end your night with me?
Originally posted by Shiny Ninetales
Yeah, I know, 2:1 would be too much, but isn't possible to do a 1,5:1 or 1,25:1? Actually, the setting used in Yoshi's Island makes layer 3 images to move at a 119,92% speed (basically 1,2:1) which is still better than 1:1 for those kind of layer 3 images. I understand it might sound very specific, considering what smw hacks are and how you can use it, so I understand if you don't want to deal with it anyway (also, I'm pretty sure you can do it with custom asm or something).


Yeah, could maybe add a 1.2:1 layer 3 scroll rate for those looking for a YI-like setup. Assuming enough people would use it, as there's only a couple unused settings left in the current list.

Originally posted by Erik
If you make an horizontal level with horizontal setting 1C and level mode 02, this is what happens. Is this intentional or a bug? Either way it shouldn't be allowed to be selected if that's what happens.

Or on second thought, maybe it's the fact layer 2 halves the amount of screens usable. Maybe you should make the descriptions in horizontal settings take that into account when you have a layer 2/tide level.


Yes, it's intentional and is because cutting 1 screen in half gives you 0 full screens. The "Max Screens" value under the "SNES Registers" setting will show you how many screens you'll actually end up with when taking layer 2 and tides into account (which you'll notice shows 0 screens for the settings you describe).
Have you ever done anything with LZ4 compression (no, not LC_LZ4; they're different things)? I would assume that no SNES games use it or something similar (considering it was released in 2011). I wrote an implementation of the algorithm, but I haven't had an opportunity to test it.

Another compression algorithm that might be worth looking into is the one that Donkey Kong Country 2 uses. p4plus2 could give you some info on that.
Originally posted by FuSoYa
It's possible, but 12 extra bytes is already quite a bit for individual sprite settings. The bigger you make them, the more you're going to bloat up your sprite level data.


Just wanted to butt-in on that. Currently pixi supports the same amount of sprite data as SA1. So both SA1 and fastROM solutions have the same amount of sprite data to use, which is up to 65536 bytes (16 bit indexing, not accounting for headers and LM3 command configs).

Sure thing you can end up bloating your sprite data / ROM if you abuse the n extra bytes feature, but I think this problem should be up to whoever is making the hack to embrace.

That said, I'm not super sure if I would expand it too if I was in your shoes. For me, currently the most cumbersome item in the issue list of allowing n extra bytes on sprites is the extra byte editing box. It doesn't feel very good (mostly size issues). If it was further expanded it would look pretty bad.
I think you could make like an auto-expanding box or let users expand the box on their own, kinda like the reply box in smwcentral, maybe adding a scrolling bar? I don't know really, just throwing out stuff.
Originally posted by imamelia
Have you ever done anything with LZ4 compression (no, not LC_LZ4; they're different things)? I would assume that no SNES games use it or something similar (considering it was released in 2011). I wrote an implementation of the algorithm, but I haven't had an opportunity to test it.


No, I haven't. The unlimited length encoding is interesting, but based on the format description I'd expect it to be comparable or maybe slightly worse than LC_LZ3 depending on the input. LC_LZ3 allows for single byte offsets while this one forces 2, LC_LZ3 has 5 bits for size before extending while this one has 4, LC_LZ3 can reverse LZ fetched bytes while this one can't... but this one lets you combine uncompressed lengths with LZ lengths in one byte while LC_LZ3 doesn't. You'd probably have to run sample data and compare between them to be sure though.

Originally posted by Tattletale
Just wanted to butt-in on that. Currently pixi supports the same amount of sprite data as SA1. So both SA1 and fastROM solutions have the same amount of sprite data to use, which is up to 65536 bytes (16 bit indexing, not accounting for headers and LM3 command configs).


Er, not really sure why you mentioned FastROM there. LoROM has 32KB banks whether you're using FastROM or not. The only ROM maps supported by the public build of LM that have 64KB banks would be SA-1 and SuperFX.

Originally posted by Tattletale
Sure thing you can end up bloating your sprite data / ROM if you abuse the n extra bytes feature, but I think this problem should be up to whoever is making the hack to embrace.

That said, I'm not super sure if I would expand it too if I was in your shoes. For me, currently the most cumbersome item in the issue list of allowing n extra bytes on sprites is the extra byte editing box. It doesn't feel very good (mostly size issues). If it was further expanded it would look pretty bad.
I think you could make like an auto-expanding box or let users expand the box on their own, kinda like the reply box in smwcentral, maybe adding a scrolling bar? I don't know really, just throwing out stuff.


I'd probably just go with a simple multi-line text edit box with scrollbar if it had to be expanded further. Which I may yet end up doing, if someone comes up with a practical use for it.
Originally posted by FuSoYa
Er, not really sure why you mentioned FastROM there. LoROM has 32KB banks whether you're using FastROM or not. The only ROM maps supported by the public build of LM that have 64KB banks would be SA-1 and SuperFX.

Oh, I did not mean to touch this subject. I mentioned the new system for fastROM because we used to have a sprite count warning on Lunar Magic and the old sprite data pointer used to be indexed by 8 bits. It's now safe to disable that warning + the sprite data is being handled the same it is handled by SA-1, with a 16 bits pointer.

I thought when you replied to Anoni you were worried about the old implementation bloating up/exploding too quickly.
FuSoYa, do you have an idea of about how much v-blank time is decreased with LM features? I hear that scrolling takes up most of it, vertical scrolling more so. I'm trying to get an idea of how much stuff I can do within NMI so knowing that would help a bit.
Originally posted by Tattletale
Oh, I did not mean to touch this subject. I mentioned the new system for fastROM because we used to have a sprite count warning on Lunar Magic and the old sprite data pointer used to be indexed by 8 bits. It's now safe to disable that warning + the sprite data is being handled the same it is handled by SA-1, with a 16 bits pointer.

I thought when you replied to Anoni you were worried about the old implementation bloating up/exploding too quickly.


Nah, just about it bloating up in general.

About Pixi now supporting 255 sprites for non-SA-1 ROMs though... I wonder if I shouldn't just set aside a bit somewhere in the ROM that other tools could change to let LM know that the limit has gone up to 255. It's probably a better alternative to turning LM's warning off entirely, since there still is a count limit.

Originally posted by mario90
FuSoYa, do you have an idea of about how much v-blank time is decreased with LM features? I hear that scrolling takes up most of it, vertical scrolling more so. I'm trying to get an idea of how much stuff I can do within NMI so knowing that would help a bit.


That depends. ExAnimation will vary based on how much data you're trying to transfer in one frame for that level (there's more detail in the help file on that topic, but basically the first 8 slots all run in different frames, and every group of 8 slots after that are split up the same way among those first 8 frames).

But if you're just talking about scrolling... back when smkdan tested his patch, he said the worst case would result in 8 scanlines of spare vblank capacity. But that worst case would be if you're in a layer 2 level and trigger the need for both a horizontal and vertical tilemap update for both layers within the same frame. It can be better for other level types. For example a horizontal level with a BG on layer 2 wouldn't require any horizontal updates for that layer at all. You might want to run a trace and check the vcounter yourself on multiple frames to see what you have left to work with.

That's the price we pay for having 2 extra GFX slots (and the ability to have resizable levels in LM3). Though there is the option to do without by turning off the VRAM patch before starting a new hack, if one really wants...
Originally posted by FuSoYa
That depends. ExAnimation will vary based on how much data you're trying to transfer in one frame for that level (there's more detail in the help file on that topic, but basically the first 8 slots all run in different frames, and every group of 8 slots after that are split up the same way among those first 8 frames).

But if you're just talking about scrolling... back when smkdan tested his patch, he said the worst case would result in 8 scanlines of spare vblank capacity. But that worst case would be if you're in a layer 2 level and trigger the need for both a horizontal and vertical tilemap update for both layers within the same frame. It can be better for other level types. For example a horizontal level with a BG on layer 2 wouldn't require any horizontal updates for that layer at all. You might want to run a trace and check the vcounter yourself on multiple frames to see what you have left to work with.

That's the price we pay for having 2 extra GFX slots (and the ability to have resizable levels in LM3). Though there is the option to do without by turning off the VRAM patch before starting a new hack, if one really wants...


I already know about the Exanimation bit but I was specifically talking about what features are automatically added with LM that give less V-blank, and the info you gave does help. What prompted me to ask this specifically was the fact that I noticed ever so slightly some flickering at the top of the screen with 3 dynamic sprites on screen and nothing else running. (No Exanimation, or other VRAM uploads or HDMA or anything and on an earlier version of LM that wasn't happening) It was a normal Horizontal level but the flickering only happening when the camera scrolled upwards, so I figured maybe it had something to do with the added level sizes. It's a shame SA-1 can't handle VRAM and NMI stuff on its side. I'll just trace it like you suggested and continuing to see if I can optimize things even more.
The current issue for me regarding spare v-blank time is when there's stripe image updates. Currently smkdan's patch hijacks the stripe image routine and attempts doing a VRAM remap at real time to all tilemap updates so it automatically changes VRAM address $XXXX (from standard SMW model, 512x512 size) to VRAM address $YYYY (from smkdan's model, 512x256), which can involve vertical adjust (offset), run as it is or discard stripe update if it's out of range.

With that, any 16x16 block update inside the rendered layer 1 or layer 2 has an overhead of up to 300 cycles (150 cycles per line), that's nine 8x8 4bpp tiles or one 32x16 tile. However since SMW already wastes up to 300 cycles on stripe image uploader, that's in total 600 cycles on the worst case. This is more than one 32x32 tile.

I understand smkdan's decision because changing the stripe image format would create incompatibilities with many resources, but technically speaking it's a not good method to use.

As far about scrolling, I believe it's already optimized enough. 8 spare scanlines is around 0x52C bytes, which is still a considerable amount if you disregard that ~0x258 bytes can end up "eaten" in any moment by the stripe image routine when you touch any question block.

Originally posted by mario90
It's a shame SA-1 can't handle VRAM and NMI stuff on its side. I'll just trace it like you suggested and continuing to see if I can optimize things even more.


Sadly it indeed can't, but it can be used for prebuffering the v-blank writes for minimizing setup time. That's what I'm currently working for the next SA-1 Pack version. Initial research says that it's possible to reduce to 16 cycles (compared to 600) for 16x16 tilemap updates by creating a VRAM address/VRAN word table (4 regs write once to $2116-$2119) and let SA-1 build it before v-blank starts. Hope it works, because combined with the IRQ-as-NMI system it will allow to an absurd amount of animations and dynamic sprites on screen with reliable stability.

--------------------
GitHub - Twitter - YouTube - Blog - SnesLab Discord
Originally posted by FuSoYa
About Pixi now supporting 255 sprites for non-SA-1 ROMs though... I wonder if I shouldn't just set aside a bit somewhere in the ROM that other tools could change to let LM know that the limit has gone up to 255. It's probably a better alternative to turning LM's warning off entirely, since there still is a count limit.


That would feel pretty good actually. People probably wouldn't notice it, but the fact that they won't notice it is a good thing in a way.
Alright, then lets go with the byte at 0x801E0 PC. Since it's 0xFF in the default ROM, clear the lowest bit to notify the next version of LM that the sprite limit has gone up to 255. The rest of the bits will be set aside for potential future notifications.
Pages: « 1 218 19 20 21 »
Forum Index - SMW Hacking - Resource & Tool Releases - Lunar Magic suggestions and discussion (LM v3.10)

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

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


Total queries: 7

Menu

Follow Us On

  • YouTube
  • Twitch
  • Twitter

Affiliates

  • SMBX Community
  • ROMhacking.net
  • MFGG