Another feature that I'd like to see is the ability to select multiple tiles, and then change them all at once; something similar to the "Modify selected 8x8 tiles..." dialog in LM's OW editor would be great.
Can someone explain to me why this happens whenever layer 3 is loaded to the level:
Only for a split second this happens, then it just goes back to normal.
Use Ersanio's leveASM + Init. Just place the code you put in levelcode.asm into the corresponding level in levelinitcode.asm, and it should be fixed.
Seeing as my server keeps messing up, I've uploaded Terra Stripe to the file bin. The link in the original post has been updated.
Quick question, Can this tool be used with Roy's Layer 3 EXGFX patch? Cause I'm running out GFX space, and I have nowhere else to fit my GFX
Yes, it can. However, it'll still look like the base gfx when you assemble it in terra stripe. (will look fine in game though)
Originally posted by Monster
Yes, it can. However, it'll still look like the base gfx when you assemble it in terra stripe. (will look fine in game though)
Hmmm, You just gave me a brilliant idea!! But I don't know it'll work though:/
Here's the idea:
You replace the Default Graphics in file GFX2B with the Graphics that You want, for instance...clouds.
Then You assemble the clouds in TerraStipe, then save.
Okay, then You take the clouds and copy/delete them from the GFX2B file and paste them In the Layer3 Exgfx file, (Here's the trick), But You have to put the cloud graphics in same spot space You had them in the GFX2B file.
Then whatever level You decide to have clouds in, You make the Layer3 ExGFX file use that level.
In theory it should work. I don't see why it wouldn't. (Goes to try it)
EDIT: It worked!! Nice
I don't see why it wouldn't work. Not the most fun workaround, but.
Originally posted by Monster
I don't see why it wouldn't work. Not the most fun workaround, but.
Agreed, not the most fun way of doing it, But it's at least a simple and uncomplicated method of getting it done. Until Smallhacker releases a version of TerraStripe with EXGFX support, the above method I mentioned above will have to be done.
I've had ExGFX support planned for a while. The idea was to add it to version 1.0, but due to some complications, it would have delayed the release of version 1.0 significantly and I felt that it was about time that I released it.
I'm currently prioritizing a proper compression routine, but ExGFX support is also pretty high on my list.
Hey this is interesting.... so with this could I actually make use of the garbage layer 3 that gives you a cage? Also are there any special properties to that cage other than it being there?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
Hey this is interesting.... so with this could I actually make use of the garbage layer 3 that gives you a cage? Also are there any special properties to that cage other than it being there?
Well, there's an unused sprite (number 88) that makes the cage solid, traps Mario inside and creates (glitched) animated wings at the top of the blue parts of the cage. It's normally assumed that this was meant to be used in an auto-scroll level to make it seem like something was flying away carrying the cage containing Mario.
Also, just an update on my progress. I finally implemented a compression function. It's not perfect, but it should reduce the filesizes somewhat in most cases. Here's a table comparing the image sizes when saved in version 1.0 and 1.1:
Image
1.0
1.1
Water
3976
148
Beta Cage
880
500
Windows
1860
1860
Cave
832
832
Fog
1396
1036
Fish
216
200
Smasher
692
628
Title screen
960
884
Overworld border
1140
458
Now that the compression is done, I can focus on other parts of the program.
Originally posted by Smallhaunter
Originally posted by Run & escape r
Hey this is interesting.... so with this could I actually make use of the garbage layer 3 that gives you a cage? Also are there any special properties to that cage other than it being there?
Well, there's an unused sprite (number 88) that makes the cage solid, traps Mario inside and creates (glitched) animated wings at the top of the blue parts of the cage. It's normally assumed that this was meant to be used in an auto-scroll level to make it seem like something was flying away carrying the cage containing Mario.
Also, just an update on my progress. I finally implemented a compression function. It's not perfect, but it should reduce the filesizes somewhat in most cases. Here's a table comparing the image sizes when saved in version 1.0 and 1.1:
Image
1.0
1.1
Water
3976
148
Beta Cage
880
500
Windows
1860
1860
Cave
832
832
Fog
1396
1036
Fish
216
200
Smasher
692
628
Title screen
960
884
Overworld border
1140
458
Now that the compression is done, I can focus on other parts of the program.
You are awesome
Originally posted by Smallhaunter
comparison of TS 1.0 and 1.1
I decided to add the original sizes too (assuming that you didn't change them, I also bolded the smallest ones):
Image
TS 1.0
TS 1.1
Nintendo
Water
3976
148
149
Beta Cage
880
500
525
Windows
1860
1860
1857
Cave
832
832
833 (unsure)
Fog
1396
1036
1081
Fish
216
200
201
Smasher
692
628
693
Title screen
960
884
905
Overworld border
1140
458
Couldn't find in all.log
TS wins in most cases, but you might want to look into those windows.
Or it might just be me sucking at counting.
There's some things in that table I found to be weird, though.
Sometimes they beat the original with ONE BYTE (water, fish, cave, smasher in 1.0). I can't think of ANY situation that allows the image sizes to be an even number of bytes. Maybe you forget to count the ending FFs?<blm> zsnes users are the flatearthers of emulation
Hrm? In my experience, it's always even. The thing's size is controlled by the DMA upload routine. Those ending FFs are probably junk.
You obviously don't know how the stripe image format works. Nuke the FFs and the VRAM will propably get filled with garbage.<blm> zsnes users are the flatearthers of emulation
Hrm, yes, that is moonspeak to me currently. Perhaps I was incorrect to assume that since I was able to DMA the output of terra stripe using the same method as how I update the status bar, everything was the same.
I guess this compressed format uses a different method?
Oh crap, you're right. I forgot to include the ending FF. Here's the corrected table:
Image
TS 1.0
TS 1.1
Nintendo
Water
3977
149
149
Beta Cage
881
501
525
Windows
1861
1861
1857
Cave
833
833
833
Fog
1397
1037
1081
Fish
217
201
201
Smasher
693
629
693
Title screen
961
885
905
Overworld border
1141
459
307
I just thought of a way to improve the algorithm a bit, which should reduce the size of the overworld border. I'll also look into the windows.
Wow, is the current format entirely raw tilemaps? That is... disconcerting. I may hold off on using this anymore until version 1.1 is released.
Either way, looks like you are making good progress on your compression algorithm. Keep up the good work!
Is there any way I can use the unreferenced images that get saved to the rom by TS? I wanna use those for my levels. I hate having to use the Tileset Specific images in LM. Considering there's not that many of them to begin with, only 0-E.