Language…
10 users online: AJ1Ayrton, Daizo Dee Von, GRIMMKIN, Hidincuzimsmokin, Klug, Oskise,  Ringo, Rykon-V73,  Telinc1, Tsquare07 - Guests: 249 - Bots: 398
Users: 64,795 (2,375 active)
Latest user: mathew

Terra Stripe 1.0 released!

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:

Image and video hosting by TinyPic

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

frog

http://esolangs.org/wiki/MarioLANG
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:

Image1.01.1
Water3976148
Beta Cage880500
Windows18601860
Cave832832
Fog13961036
Fish216200
Smasher692628
Title screen960884
Overworld border1140458


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:

Image1.01.1
Water3976148
Beta Cage880500
Windows18601860
Cave832832
Fog13961036
Fish216200
Smasher692628
Title screen960884
Overworld border1140458


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):
ImageTS 1.0TS 1.1Nintendo
Water3976148149
Beta Cage880500525
Windows186018601857
Cave832832833 (unsure)
Fog139610361081
Fish216200201
Smasher692628693
Title screen960884905
Overworld border1140458Couldn'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:

ImageTS 1.0TS 1.1Nintendo
Water3977149149
Beta Cage881501525
Windows186118611857
Cave833833833
Fog139710371081
Fish217201201
Smasher693629693
Title screen961885905
Overworld border1141459307


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.

I hate being limited to only 15 tilesets:/