| Posts by Sonikku |
|
|
|
|
|
|
|
|
Originally posted by asutoroZmarioThere are about 14 kinds of "custom sprite" which appeared by the animation.
If you make a pointer, you can just create the same custom sprite with a different RAM table (such as $1510,x as it is only used in the falling platforms) each time instead of different sprites. I constantly do it with my sprites and it saves a lot of sprite list slots.
|
|
|
|
|
I've looked at Carol's sprites. Most times he uses the Extra Bit as a method of combining 2 sprites (except as far as I know, makes no effort to combine multiple projectiles). With things like projectiles it appears he uses multiple sprites rather than a single sprite under different states like I've been utilizing as of recent.
|
| Last edited on 2012-02-25 08:19:12 PM by Sonikku. |
|
|
|
Most everyone in the world can use Blocktool Super Delux if they install the .NET framework, which is required by quite a few tools for hacking SMW. Transitioning into a new tool wouldn't stop anything, especially not the Automatic Mario levels. Most Automatic Mario levels use what SMW originally included with the game, and the few blocks they do use are incredibly simple blocks that we have plenty of already.
Besides this, most Automatic Mario levels were designed back when Jonwil's tool was pretty much the only one around - there are plenty of alternatives that are actually much better and safer to use such as Blocktool Super Delux and the patch yoshicookiezeus mentioned.
|
| Last edited on 2012-02-28 09:52:29 PM by Sonikku. |
|
|
|
@arotenbe - The only way I could tell that is still SMW is the fact that you used sound #$01 of $1DF9, otherwise I was completely fooled. This is the first time in some time that something has caught me completely off-guard in terms of changing the game to such an extent.
Out of curiosity, how did you manage to code in the ability to 'hang' on ledges like that? Was it clever usage of custom blocks or..?
|
|
|
|
Originally posted by MaxodeX
Er... what? This is not speedy gonzalez or whatever the fuck you try to say.
He was talking about this hack of the Speedy Gonzalez SNES game.
On topic; while it's not a new idea (it's been thought of and even attempted a couple times before now), it could theoretically work out great if executed properly.
As it is, though, I don't think the SMW engine is very good for a Sonic-themed game. Sonic games are generally about speed and relying on gravity to assist in reaching newer places. Mario games are.. not quite the same. I really don't like the idea of 3 emeralds per level; emeralds in sonic games are collected via special stages and there are only 7; generally one should be collected per-zone which is 2 to 3 levels (with the last one having a boss). I'd say maybe collecting emerald shards to complete a full emerald when say.. 6 to 9 are collected, since as seen in previous Sonic games, the Master Emerald can be easily shattered so that assumes the normal ones can too.
Along with this, I really don't care for the graphics for the player at all; you are using Genesis-style level graphics, while using Game Gear-like player graphics. You'll have to do a lot to the SMW engine in order to make a convincing SNES Sonic game.
|
|
|
|
|
Still a WIP. I have the major part done; making the sprite actually move properly, not loop when it goes too far down, and making it interact with the blocks. All I need to do now is write some OAM to make the handle and the door, as well as the sprites it drops. For the time being though, it's semi-functional.
|
|
|
|
As it is, there are currently no attacks, although the graphics routine for the Dryad itself is pretty much 100% complete. All frames and such have been completed - the body, arms, and facial expression use different routines solely to remain simple.
The graphics routine itself is really the most complex part I have with bosses, so I should be able to finish the boss by the end of the week given I have enough free time to work on it.
Any idea of how we should need to damage the boss? I was thinking the purple berries could grow along the brambles, and you throw an apple at it to bounce it off and hit the boss.
|
| Last edited on 2012-03-21 01:36:15 AM by Sonikku. |
|
|
|
I can't think of a way to utilize really.. any other of Mario's abilities for a boss like this. The actual idea, to give more of a grasp of what I was thinking, is trying to find a way to hit the head/body of the boss, and not the base of it. The only way to attack the boss without getting hurt is bouncing it off the berries which will deflect it into the boss if you aim properly.
Although, if you have any other ideas before I get on to working on the actual boss then feel free to say it.
|
|
|
|
Test of a thing
Technically this is a nearly direct port of SMB3's Boom Boom. Nearly all opcodes and everything are identical to the SNES's, so it was fairly simple and self explanatory. It's incredibly buggy and stuff, but if I make it halfway usable, I can maybe obsolete many of the existing SMB3 sprites with 100% accurate versions.
|
|
|
|
@dahnamics - I am fairly certain he meant getting + writing a decimal value from a RAM address to the status bar.
To write to the status bar, like the lives counter in decimal is simple;
CodeLDA !RAM
JSL $00974C
TXY
BNE NotZero
LDX #$FC ; 'blank' tile number, for decimal digits less than 10
NotZero:
STX $0F16 ; Tens digit location RAM.
STA $0F17 ; Ones digit location RAM (add 1 to tens digit RAM).
Use this to identify where you want to place it on the status bar. I used the default location the lives counter is generally placed, but its easy to relocate. The counter goes up to 99 without glitching, in the case it does it 'overloads' and starts writing A0, A1, etc., code the gimmick to disallow possible overloading.
|
| Last edited on 2012-04-11 01:21:14 PM by Sonikku. |
|
|
|
This thingy
What it pretty much is, is a combination of 4 blocks (since unlike normal 32x32 blocks, this had to be activated on the top corners too by sprites/cape). It acts pretty much exactly as the original giant brick block did with the exception of a bounce block when you're small.
I made SUBL_SET_MAP16, aka the JSL that people use to spawn their own tiles into a single place in the ROM that I can JSL to whenever, to save space and such. In addition to that, I also edited the original brick piece (replacing the unused Yoshi smoke as it served no use) to be a 16x16 brick piece, allowing both 8x8 and 16x16 sized versions. I also made a JSL like the existing shatter routine to generate these brick pieces. Overall, it was a test to see how difficult it would be to make decent 32x32 bricks.
|
|
|
|
|
They did, I guess. I just have no idea how I would arrange to have 32x32 bounce blocks without either editing which OAM slots bounce blocks normally use (maybe rearranging them to use every 4th slot instead of 4 consecutive ones so I can have 4 32x32 ones?) or making them another type of sprite.
|
|
|
|
|
I doubt it, but shells may activate more than 1 within that period.
|
|
|
|
Yeah I've made sprites with the Magikoopa aim routine before - Alcaro has the right address to change. Values 01-7F will aim at the player, while 80-FF will aim away from them.
The faster speed the projectile has, however, means there is an added possibility of it going through floors or walls in rare cases.
|
|
|
|
It depends on your definition of how it would "100% work", so it's hard to answer as you were very vague in your question. Yoshi is an unnecessarily complicated sprite so it'd be a lot of time and work as you mentioned.
If you mean multiple Yoshis on screen - that is possible but not easily as it uses DMA and stuff to upload tiles dynamically. If you mean making Yoshi have more YI-like abilities - still possible. Again, you were vague so it's hard to answer.
|
|
|
|
I guess it's about due for another update. Long story short, the ROM exploded to where I couldn't continue it without certain crashing later on. Thankfully, I actually used a universal patch so finding a solution to some of it, removing parts which pretty much prevented it from breaking anymore. However, 90% of the code was inefficient and overall poorly coded, so I redid it all. The last few months I've been busy with college and also other ASM projects for SMWCP2 and such so I haven't done much serious hacking. The last few weeks, however, I've been on and off working on alternate ASMy things, which you can see the result of here;
(It's a video, by the way)
Everything regarding the status bar and such is still in very early prototype stages since I haven't gotten around to re-implementing my coin counter and such. The level itself is to test stuff, mainly, so more likely than not this isn't how you'll see it in the final product.
|
|
|
|
I had an idea that I think would be neat to implement, and really useful for certain people.
Saving individual/all (level/global) Exanimation slots to a file. I mean, it would save a lot of time for graphics makers and (for people too lazy to DMA stuff themselves) certain ASMers, since Exanimation is annoying to set up if it's a huge animation and reading the instructions for which animation to go where and etc. is still fairly tedious.
|
|
| Posted on 2012-04-28 06:02:56 PM in sweet |
Link |
|
Originally posted by AdamSonikku is system.
you didn't hear it from me...
N..no I'm not!
|
|
|
|
| (restricted) |
|
|
|
|
|
|
