Banner
Views: 865,030,257
Time:
16 users online:  BeeKaaaay,  DeppySlide, Gammed Z, Golden Yoshi, Infinity,  KevinM, KitikuSa, Mario is the best, myuuuga, Narcologer, PokerFace, qantuum, RAFAEL_M_C_, RollingRigatonis, Samuel Zuccati,  Telinc1 - Guests: 116 - Bots: 56 Users: 47,900 (2,077 active)
Latest: PoiMoiPoi
Tip: Linear levels aren't necessarily a bad thing. After all, most official Mario levels are fairly linear.Not logged in.
Overworld sprites planning thread
Forum Index - Important - Announcements - Overworld sprites planning thread
Pages: « 1 » Thread Closed
So the with the recent addition of custom overworld sprite support, in addition to the recent sprite remoderation, the ASM team set to the task of standardizing a format for the overworld sprites, all of which were removed during said remoderation.

This zip file includes two bps files showing them in action. For the normal user, there's no difference on either one of them. If you're a coder and are curious, feel free to disassemble or breakpoint them or whatever.

This one includes the base asm for overworld sprites. You can suggest any improvements to the main base patch if you want. As you can tell, there's two versions on this zip file: one based on Lui37's system used in VLDC9, and the second one based on Katrina's design proposal (specifically her second one), which you can read here.

Now then, there's a bit of stuff to clear up first.

First, and this one might concern the general public: this system will disable the original overworld sprites completely. They I guess can be enabled with a bit of ease, but most of them have weird-ass restrictions and will most likely not play nice with custom ones. So the question is, do I re-enable the original OW sprites, or do I leave them disabled? In case of the latter, consider the behavior for most of those sprites is simple enough to recode them in the new format, which also enables us to disable/fix stuff like hardcoding ghosts into certain slots.

The second one will be deciding on the system to be used to code sprites. We have two systems with two main differences.
Lui's system:
- Starts with A in 16-bit mode and XY in 8-bit mode.
- X contains the sprite index.
- Has tables which work similar to the original SMW sprite ones, except with 2 bytes per sprite.
Katrina's system:
- Starts with AXY in 16-bit mode.
- The sprite tables work (and I quote because hell if I know anything about real programming) "something more like the actual C sense of 'struct'." So one sprite has a 2 byte value for sprite number, followed by position, etc.
- Thus, X contains 14C8, plus their index, plus the total table size, making table reads LDA $00,x instead of LDA $14C8,x

Katrina's system is slightly faster due to the table reads being in direct page rather than full addresses. Other than that, I can't really tell any advantage of one over the other.

Third would be deciding on shared subroutines to use. Right now, I included:
- ow_get_draw_info
- ow_is_offscreen
- ow_update_x/y/z_pos
- ow_spawn_sprite
- ow_sub_horz_pos

All based on the ones included in VLDC9. Some (specifically that OAM loop in get_draw_info) might need cleanup.
There's some that I didn't add yet that might be useful, such as a routine to get the Layer 1 tile a sprite is touching; or others which aren't programmed yet, such as interaction. Other than that, not sure what else could be added.

Finally the unknown that'll remain unsolved, for now, is the tool to use. I don't follow dys' development so this could all already be in and finished and I wouldn't even know, but other than that, we would need one tool to insert the sprites. We can try and convince 6646 to add support for them on GIEPY, but last I heard he was opposed due to how varied they were from other sprite types or some stuff like that. Or someone else could code a tool which actually works. Or something else idk.
Quote
So the with the recent addition of custom overworld sprite support

honest question because I haven’t been paying attention: what got overworld sprite support. PIXI? something else? idk


I haven’t actually properly checked Lui’s thing (I meant to but I’ve been forgetting and I need to go to bed so I know I’ll forget again if I don’t post now), but does Lui’s patch let any sprite state information survive if you’re on the overworld, go to a level, and then return to the overworld? This is important for a few existing custom sprites (e.g. the custom airship absolutely needs to stay in place if you go to an island and play a level there or you’ll be soft-locked). I know for sure that Daiyousei’s current patch doesn’t deal with this at all.

I don’t think it needs to be all of the sprites’ state. Four bytes is enough to store a position, with a few bits for extra stuff. It might also be worth thinking about some way to give them a way to put a few bytes into SRAM, but that’d be hard to do in a way that doesn’t break other patches that use SRAM, and it’d be pretty silly for a sprite tool to break those.

It’s been a hot minute since I worked on Daiyousei, and I have overworld sprites implemented but it’s seriously not release-ready, and now I have a few other things I’m doing that I’m also way behind on, so I’m really hesitant to say people should start depending on me for stuff right now. It’s fairly easy to implement on the tool side (it’s pretty similar to cluster sprites in that it’s basically a couple tables completely separated from the usual standard/shooter/generator tables, so if GIEPY has anything like that, it shouldn’t be too tough, but I haven’t seen the code), but it needs an unusually large amount of code on the ASM side.
I think that overworld sprites are not very neccessary, usually they are very simple, you can do the same with an Uber asm of overworld, we have a section for Uberasm codes, people can upload uberasms simulating overworld sprites there.
------------------------------------------------------

Youtube
Twitter
SMWControlLibX GitHub
My Discord Server
Pages: « 1 » Thread Closed
Forum Index - Important - Announcements - Overworld sprites planning thread

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

Copyright © 2005 - 2020 - 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