 |
| Register | Login | |||||
 |
Main
| Memberlist
| Active users
| Calendar
| Chat
| Online users Ranks | FAQ | ACS | Stats | Color Chart | Search | Photo album |
|
| | ||
|
| Register | Login | |||||
|
Main
| Memberlist
| Active users
| Calendar
| Chat
| Online users Ranks | FAQ | ACS | Stats | Color Chart | Search | Photo album |
|
| | ||
| 0 users currently in SMW Hacking. |
| Acmlm's Board - I3 Archive - SMW Hacking - Add 255 sprites? |
New poll |  |  |
| Pages: 1 2 | Add to favorites | Next newer thread | Next older thread |
| User | Post | ||
Glyphodon                  Since: 11-18-05 Last post: 6346 days Last view: 6327 days |
| ||
Originally posted by Bio.exe Good job, Bio. Those should come in handy. Isn't the location of the sprite in the tables stored in the X or Y register or something? If so, all we'd need is an LDA absolute indexed with X/Y and we'd be good to go. Originally posted by Smallhacker Again, totally missing the point. Blocks can't act differently until they're touched. Sprites, which can read just about any byte in RAM or ROM to change their appearence, behavior, etc. straight from the start, trump your 21 bits. Originally posted by Smallhacker Let this be a lesson to you all. Nobody beats Glyph Phoenix in a battle of theoretical game mechanics. Viva la Extra Info! ...and they don't need to be unused. Extra Info + used sprites can work too. |
|||
Smallhacker Super Koopa I AM A Group Of Officially Frustrated Younglings, G.O.O.F.Y. MEMBER |
| ||
Originally posted by Glyph Phoenix Appearently, you misunderstood my idea. The hacked level loading routine would translate the sprite blocks into real sprites before the level fades in and any other sprites have had a chance to execute anything. They're not blocks. They're sprites stored as blocks. As for the "what to turn the 'sprite blocks' into" question: Let's set it to 25. The level data is stored in Z order (from back to front). If we place a "sprite block" in the level and put a normal block on top of it, the "sprite block" would be loaded first of the two, right? Therefore, the loading code would load the "sprite block", translate it into a sprite and turn the block into thin air. Then, it would load the block placed on top of it, overwriting the thin air. The only problem I see with this method is that the "sprite block" can't be seen in LM unless you move the block on top of it. (edited by Smallhacker on 06-11-06 06:13 AM) |
|||
|
Glyphodon Since: 11-18-05 Last post: 6346 days Last view: 6327 days |
| ||
| I didn't realize you were applying the 21 bits to your block-sprite idea. Having a sprite use LM's block data would indeed give you extra bits to work with, but blocks themselves are quite static--that's all I meant.
I still wouldn't go for the idea unless there were no more viable solutions, though. Hacking level loading routines, like I said, can't be much fun. |
|||
|
Smallhacker Super Koopa I AM A Group Of Officially Frustrated Younglings, G.O.O.F.Y. MEMBER |
| ||
Originally posted by Glyph Phoenix Actually, the 21 bits haven't got anything to do with the idea. I just wanted to prove you wrong by showing that blocks are more dynamic than sprites.  |
|||
Sukasa Birdo Not quite as active as before. Xkeeper supporter Xk > ||bass I IP Banned myself! Twice!   Since: 11-17-05 From: Somewhere over there Last post: 6306 days Last view: 6305 days |
| ||
| AND, if the routine doesn't place anything for the sprite blocks, you could have those on top of everything else, without having any problems. Shows up on top of everything else in LM, doesn't show up in SMW. | |||
SnifflySquirrel Shyguy  Since: 03-03-06 From: Vermont Last post: 6406 days Last view: 6306 days |
| ||
| Sukasa makes a very valid point. It's up to an individual object's rendering code to write any block data that defines it. If that code decides to interpret the object data differently, without writing to the level layout, then it won't matter what it overlaps, because it will still be there. A few things in SMW already work this way, like screen exits (which are Extended Object 0) and some of LM's enhancements.
That being said, I would opt for the "unused sprite index + extra data + level-specific sprite table" method, myself. It sounds like it would be far less difficult to implement. Furthermore, it wouldn't involve sacrificing Map16 pages. |
|||
|
Smallhacker Super Koopa I AM A Group Of Officially Frustrated Younglings, G.O.O.F.Y. MEMBER |
| ||
Originally posted by SnifflySquirrel Well. My idea would only use one Map16 block per sprite. Instead, it would use a table that contains Map16 numbers and the custom sprite ID to turn the block into. Using entire pages was somebody else's idea. |
|||
HyperHacker Star Mario Finally being paid to code in VB! If only I still enjoyed that. <_< Wii #7182 6487 4198 1828 Since: 11-18-05 From: Canada, w00t! My computer's specs, if anyone gives a damn. STOP TRUNCATING THIS >8^( Last post: 6306 days Last view: 6306 days |
| ||
Heh, I thought of what Sukasa mentioned, but it being 5 AM or so, I thought it wouldn't work.  Really, it does sound like a good idea. |
|||
Mozeki  160  Since: 03-17-06 From: NY Last post: 6487 days Last view: 6487 days |
| ||
Originally posted by Smallhacker This seems like this could work if some planning was put out for it. BTW if this was to be done I really hope it doesn't use Decimals like blocktool  (edited by Soulblader88 on 06-11-06 11:29 PM) |
|||
|
Alastor Fearless Moderator Hero  Since: 11-17-05 From: An apartment by DigiPen, Redmond, Washington Last post: 6305 days Last view: 6305 days |
| ||
| gih... guh...
Okay, that's on the list. |
|||
|
mikeyk Shyguy Since: 02-22-06 Last post: 6469 days Last view: 6314 days |
| ||
| i'm not promising that i'll make a program, but i am seriously considering it. here's what i had in mind.
my plan is to add support for ~255 custom sprites by using the second extra bit. i know i could use the first extra bit as well and support ~765 sprites, but i wanted to leave this one free to use in sprite code. i think 255 custom sprites should be plenty. i would hijack the code that calls sprite routines. my code would first check if the second extra bit was set. if not, i would return and let the game deal with that sprite like normal. (i would also return if the sprite uses the second extra bit itself). at this point i would know that we're dealing with a custom sprite and i would convert it. the game does many checks with the sprite number, so i would try and avoid this. i would store the sprite number to a ram location (for fun, lets just say $9962,x) and set the original sprite number ($9E,x) to 12 indicating a custom sprite. from then on the custom code could use $9962,x to index a big table. the table would be of fixed length and have 9 bytes per sprite. 6 bytes for sprite properties (basically: tweaker code - asm information) and 3 for the code location. I would set the sprite properties, jump to the code, and be done with the custom routine. there is a little problem using extra bits. they are actually stored in bits 2 and 3 (if the least significant bit is numbered 0) of 14D4,x by the level loading routine (see SNES $02A965). it’s only the sprite code for the goal tape that puts the bits in 187B,x and ANDs them out of 14D4,x. $14D4,x is usually only used for the high byte of the sprite position, and this leads to some interesting consequences. The first is that goal tapes don't work very well on vertical levels. place a regular one on screen 05 and you'll notice it won't show up. this is because 14D4,x = 05 is interpreted as a secret exit (bit 2) on screen 01 (bit 0). using $14D4,x to hold the extra bits also explains all other sprites don't appear if they use them. the extra bits just mess up the high byte of their y position, and they are placed way off sceen. when i planned to use an extra bit i was going to handle them as the goal tape did, but this would make them breakdown on vertical levels. perhaps i could fix this with a hack to the level loading routine. so that's my plan. i'd appreciate some feedback. |
|||
|
HyperHacker Star Mario Finally being paid to code in VB! If only I still enjoyed that. <_< Wii #7182 6487 4198 1828 Since: 11-18-05 From: Canada, w00t! My computer's specs, if anyone gives a damn. STOP TRUNCATING THIS >8^( Last post: 6306 days Last view: 6306 days |
| ||
| It sounds like it might be easier to just change the ASM pointer of some unused sprite, say #12 as you mentioned, to grab the real code location from some other table. Just as object #0 can actually be one of several objects from a second list; you'd be doing the same with sprites. You could perhaps use the sprite # itself (0 for the first instance of #12, 1 for the second, etc) as the table index, or the sprite position (leaving the sprite's code to set up the actual position in-game).
I still think Smallhacker's idea is best, though. Put a specific block and use the size or one of the block # bytes as the sprite #, and hack it to spawn a sprite at that position instead of drawing a block. |
|||
|
mikeyk Shyguy Since: 02-22-06 Last post: 6469 days Last view: 6314 days |
| ||
| i'm not sure how the block loading routine works. is the whole level loaded once at the begining or does the game just load the parts that are about to come onscreen? either way
dealing with blocks that spawn sprites seems to complicate things greatly. once the sprite was spawned, what would become of the block? i would think that it would need to stay in place. if the sprite wasn't killed and we went back to the original screen, we'd expect it to be respawned. but after the sprite has been killed, then it shouldn't be. there seems to be unnecessary bookkeeping. there's also a couple more issues that i can think of, but it's quite possible i'm thinking about this whole thing wrong on the other hand, i am familiar with how sprites are initialized and loaded into ram when they're about to come onscreen. i know for a fact that it would be very easy to write the snes code to split on the extra bit. that part would be short and sweet. so very easily 00 could indicate a green koopa if the extra bit was clear, and a custom sprite if it were set. i could create the system in my previous post easily in a day. the only semi-difficult or time-consuming thing would be making a program to automatically insert the code. the whole process of finding free space, inserting the .bin, modifying the reloc offsets, erasing the stuff that was inserted in the previous use of the program, etc. i'm without a computer for the next 2-3 days, so i'll catch you guys later. maybe i can get something started when i come back. |
| Pages: 1 2 | Add to favorites | Next newer thread | Next older thread |
| Acmlm's Board - I3 Archive - SMW Hacking - Add 255 sprites? |
| |
