Author
|
Topic: Anyone Interested in Doing "SMB Special" for NES? (Read 16 times)
|
doppelganger
Guest
|
 |
« Reply #165 on: March 18, 2008, 04:10:30 am » |
|
I had no idea that SMB Special even existed until recently...and it's nice to see that my work has gotten several balls rolling. :-)
|
|
|
|
|
rbudrick
Guest
|
|
« Reply #166 on: March 18, 2008, 08:38:26 am » |
|
I just wanted to comment on the dungeons' "looping" effect. I can say from experience that SMBS definitely does do this in some dungeons. Definitely on 4-4, and possible at least one that preceded it. Since I was the one who played up to the 4-4 glitch, I remember being a bit frustrated by the "looping." Just wanted to make sure you didn't forget to implement this.
EDIT: I just remembered...I think SMBS does this on some levels that are NOT dungeons, as SMB2J does.
One would have to physically play through the game to see what I mean....I can't remember what stages.
-Rob
|
|
|
|
« Last Edit: March 18, 2008, 01:06:45 pm by rbudrick »
|
|
|
|
frantik
Guest
|
|
« Reply #167 on: March 18, 2008, 02:23:32 pm » |
|
4-4 is a pipe maze.. if you go in the wrong pipe you end up at the beginning of the level. but thats not the castle loop thing which occurs in SMB.. are you sure you're thinking of the same thing?
i've been watching the videos on you tube and have no seen anything like that so it would be great to see an example
|
|
|
|
|
rbudrick
Guest
|
|
« Reply #168 on: March 18, 2008, 02:55:20 pm » |
|
Oh, so you mean looping without the pipes? Hmmm, can't say I recall this...I've only played half the levels, so I don't know about worlds 5-8, but I can't specifically recall it looping without pipes. However, It would still be a good idea to play them to be sure. Perhaps the guy in the videos knew which way to go so it didn't display this effect? Probably not, but I figured it's best to keep the bases covered.
-Rob
|
|
|
|
|
deespence2929
Guest
|
|
« Reply #169 on: March 18, 2008, 04:18:35 pm » |
|
Yeah, the most reliable way to test everything is to actually play the game, if only people could hack up hacks or something to make it easier to play thru. Infinite time, starman, maybe higher jumps.
|
|
|
|
|
Karatorian
Guest
|
|
« Reply #170 on: March 19, 2008, 01:39:51 am » |
|
In regards to the looping, I don't think it's used. On a related note, I've been working on implimenting the changes frantik has made to the ROM into doppleganger's source code and I've discovered that the pipe patch he used stomps all over the looping code. I've integrated the following changes so far: - Demo mode changes.
- End of game message related changes.
- Background color changes.
- Water pallet changes.
- Scenery changes.
- Terrain rendering bits.
- Bridge height adjustment.
- Level changes.
- Any changes in CHR-ROM.
There are still a handful of changes that I haven't implimented. I belive they're all related to the pipe hacking patch or frantik's prirana plant changes. I'd say I'm about a third to halfway done integrating the hacks into the ASM source. The changes to the demo mode, scenery, levels, and CHR-ROM where all implimented by binary copy from the ROM produced by the latest patch. All the other changes have been implimented by changing the source code. Once I've finished integrating the existing hacks, I'll start working on getting both sets of levels into one ROM. However, I will be out of town for the remainder of the week, so I proably won't get that done until next weekend, at the earliest. In regards to the mysteriously appearing platform in that one level (I can't remember which one), I know what causes it. The game can only handle three elevators/platforms at once, if there are more than three active, the later ones are ignored. So the appearing platform isn't really a bug or a feature, it's a misfeature. Whether the engine limitation was intentionally abused by the level designer, I can't say, but I rather doubt it. (I discovered this a while back, but I didn't put two and two together until recently.) |
|
|
|
|
frantik
Guest
|
|
« Reply #171 on: March 19, 2008, 02:18:33 am » |
|
In regards to the mysteriously appearing platform in that one level (I can't remember which one), I know what causes it. The game can only handle three elevators/platforms at once, if there are more than three active, the later ones are ignored. So the appearing platform isn't really a bug or a feature, it's a misfeature. Whether the engine limitation was intentionally abused by the level designer, I can't say, but I rather doubt it. (I discovered this a while back, but I didn't put two and two together until recently.)
I suspected something of this nature was the case actually. similar things happen in the SMB engine as well. Regarding the changes to the pipe code yes they are related to the piranna plant hack. let me see if i can't give you the source for that stuff to save you the time of integrating it yourself edit: here you go.. double check it for errors but I think it's correct. You can obviously clear out the residual and nop stuff ; $98e5-$9949 ( 0x18f5 - 0x1959 ) vertical pipe object handler
VerticalPipe:
jsr GetPipeHeight
lda $00 ;check to see if value was nullified earlier
beq WarpPipe ;(if d3, the usage control bit of second byte, was set)
iny
iny
iny
iny ;add four if usage control bit was not set
WarpPipe: tya ;save value in stack
pha
lda AreaNumber
ora WorldNumber ;if at world 1-1, do not add piranha plant ever
------------- changes start here
bpl DrawPipe ; unconditional branch since A is always positive here
ldy AreaObjectLength,x ; residual
beq DrawPipe ; residual
PlacePlant:
sta Enemy_X_Position,x ; get enemy horizontal coordinate
adc #$08 ; add eight to put the piranha plant in the center
sta Enemy_X_Position,x ;store as enemy's horizontal coordinate
lda CurrentPageLoc ; residual
adc #$00 ; residual
nop
nop
lda #$01
sta Enemy_Y_HighPos,x
sta Enemy_Flag,x ;activate enemy flag
lda Enemy_Y_Position,x
adc #$08
sta Enemy_Y_Position,x
nop
nop
nop
nop
nop
nop
lda #PiranhaPlant ;write piranha plant's value into buffer
sta Enemy_ID,x
jmp InitPiranhaPlant
------------- changes end here
DrawPipe: pla ;get value saved earlier and use as Y
tay
ldx $07
...
; $c282-$c291 ( $4292-$42a1 )
;jump engine table for newly loaded enemy objects
.dw InitNormalEnemy ;for objects $00-$0f
.dw InitNormalEnemy
.dw InitNormalEnemy
.dw InitRedKoopa
.dw NoInitCode
.dw InitHammerBro
.dw InitGoomba
.dw InitBloober
.dw InitBulletBill
.dw NoInitCode
.dw InitCheepCheep
.dw InitCheepCheep
.dw InitPodoboo
.dw PlacePlant ; changed
.dw InitJumpGPTroopa
.dw InitRedPTroopa |
|
|
|
« Last Edit: March 19, 2008, 02:51:58 am by frantik »
|
|
|
|
Karatorian
Guest
|
|
« Reply #172 on: March 19, 2008, 03:18:25 am » |
|
Hey, thanks. That's one less thing I have to reverse engineer. Edit: I gotta go work on a stay-away job, so chances are I won't be able to do anymore work on the ASM until the weekend. If anyone wants to take a look at it, I've still got the following changes to investigate. 0x0000C06B 0x0005 RLE loop command world number data
0x0000C070 0x00BF STD loop command world number data
0x0000C930 0x0002 STD enemy movement subs
0x0000D3CF 0x0004 STD piranha plant movement routine
0x0000D3EC 0x0003 STD piranha plant movement routine
0x0000D799 0x0008 STD defeated enemy code used when enemies hit by ...
0x0000D8AB 0x0006 STD player to enemy collision handler
0x0000E853 0x0001 STD enemy graphics table offsets based on enemy ID number
0x0000E86E 0x0001 STD enemy attribute data
0x0000E8C5 0x0001 STD enemy graphics handler
0x0000EA17 0x0001 STD enemy graphics handler
0x0000EAB7 0x0009 STD enemy graphics handler
The effected bits of code are labled by doppleganger as follows: 0x0000C06B LoopCmdWorldNumber
0x0000C076 LoopCmdPageNumber
0x0000C081 LoopCmdYPosition
0x0000C08C ExecGameLoopback
0x0000C0CC ProcLoopCommand
0x0000C0D8 FindLoop
0x0000C102 IncMLoop
0x0000C115 WrongChk
0x0000C11C DoLpBack
0x0000C122 InitMLp
0x0000C12A InitLCmd
0x0000C905 EnemyMovementSubs
0x0000D3CF ChkPlayerNearPipe
0x0000D3E0 SetupToMovePPlant
0x0000D795 ShellOrBlockDefeat
0x0000D895 HandlePECollisions
0x0000E840 EnemyGfxTableOffsets
0x0000E85B EnemyAttributeData
0x0000E8BE CheckForBulletBillCV
0x0000E9FA CheckToAnimateEnemy
0x0000EAB6 ContES
Keep up the good work. |
|
|
|
« Last Edit: March 19, 2008, 03:49:22 am by Karatorian »
|
|
|
|
frantik
Guest
|
|
« Reply #173 on: March 19, 2008, 04:45:22 am » |
|
I suspect most if not all of those changes are related to the Red piranha plants  .. i will look into it |
|
|
|
|
rbudrick
Guest
|
|
« Reply #174 on: March 19, 2008, 08:21:03 am » |
|
In regards to the mysteriously appearing platform in that one level (I can't remember which one), I know what causes it. The game can only handle three elevators/platforms at once, if there are more than three active, the later ones are ignored. So the appearing platform isn't really a bug or a feature, it's a misfeature. Whether the engine limitation was intentionally abused by the level designer, I can't say, but I rather doubt it. (I discovered this a while back, but I didn't put two and two together until recently.) I guess I'm wondering what makes an elevator an "active" elevator. The fact is, the first two elevators are 2 or 3 screens before the one that magically appears. How are those still active? There's several levels where many elevator platforms appear, iirc. How did those levels deal with it? I find it tough to believe that the team of programmers who made this game accidentally missed this detail in their play testing for this level. Anybody figure out how the bee works? -Rob |
|
|
|
|
frantik
Guest
|
|
« Reply #175 on: March 19, 2008, 12:20:17 pm » |
|
I find it tough to believe that the team of programmers who made this game accidentally missed this detail in their play testing for this level. i would agree that play testers should have noticed this. Maybe it was left in as an abuse of the engine, or maybe it was an unnoticed bug. I honestly don't feel that it was intentional simply because that would make 4-3 one of the most difficult levels in the game, with a less obvious solution than even 8-4. regardless of the intent of the bug, it does appear. however as i said before, implementing that bug into the NES engine is an extreme low priority. I actually would rather not include it in the game since most people will not know it's a intentional bug and assume is is an error made by one of the people porting the game. You spent untold amount of lives figuring out the solution; most people will just delete the rom lol You're of course welcome to write the code yourself and patch it in though  |
|
|
|
« Last Edit: March 19, 2008, 12:31:00 pm by frantik »
|
|
|
|
Karatorian
Guest
|
|
« Reply #176 on: March 20, 2008, 05:58:52 pm » |
|
I really have no idea how the game determins what's an active elevator. All I know is that when testing, when I put in four elevators on one screen, only three of them show up.
What's a Red Piranha Plant? Do we actually need them. I don't recall any red pirana plants in SMBS. However, part of that code proably also has to do with upside down Piranha Plants.
Anyway, I got back earlier than expected, so I'll try and see what I can get done on the ASM tonight. Hopefully I'll get a working test of the expanded ROM with worlds one through five released soon.
|
|
|
|
|
rbudrick
Guest
|
|
« Reply #177 on: March 20, 2008, 07:24:20 pm » |
|
I find it tough to believe that the team of programmers who made this game accidentally missed this detail in their play testing for this level. i would agree that play testers should have noticed this. Maybe it was left in as an abuse of the engine, or maybe it was an unnoticed bug. I honestly don't feel that it was intentional simply because that would make 4-3 one of the most difficult levels in the game, with a less obvious solution than even 8-4. regardless of the intent of the bug, it does appear. however as i said before, implementing that bug into the NES engine is an extreme low priority. I actually would rather not include it in the game since most people will not know it's a intentional bug and assume is is an error made by one of the people porting the game. You spent untold amount of lives figuring out the solution; most people will just delete the rom lol You're of course welcome to write the code yourself and patch it in though I totally understand what you are saying, but I am also torn because Nintendo was so scrutinous of their second and third party developers...especially their second party developers. That this would escape NOJ, even on an obscure system makes me doubtful still. On the other hand, it WAS an obscure system, but was it known at the time that history would treat it as such? Man, we've gotta find that X1 version. -Rob |
|
|
|
|
Karatorian
Guest
|
|
« Reply #178 on: March 20, 2008, 11:28:59 pm » |
|
I've managed to incoporate all of the existing changes into the ASM source code. The block of code overwriting the looping code is a quick and dirty dissassembly of the patched ROM's contents in that area, but all the other changes have been integrated more or less cleanly. In any event, when compiled, I can generate a ROM identical to the latest world 1-4 patch released by frantik. One change to the code seems kinda off to me. The following function had the "lda #$03" changed to "lda #$00". I'm not entirely sure what that does, but it doesn't seem that it'd be relevant to any of the changes that I'm aware of. CheckForBulletBillCV:
cmp #BulletBill_CannonVar ;otherwise check for bullet bill object
bne CheckForJumpspring ;if not found, branch again
dec $02 ;decrement saved vertical position
lda #$03
ldy EnemyFrameTimer,x ;get timer for enemy object
beq SBBAt ;if expired, do not set priority bit
ora #%00100000 ;otherwise do so
SBBAt: sta $04 ;set new sprite attributes
ldy #$00 ;nullify saved enemy state both in Y and in
sty $ed ;memory location here
lda #$08 ;set specific value to unconditionally branch once
Could anyone shed some insight into this. Anyway, now that I've got all of that out of the way, I'm going to start working on the expanded ROM with worlds 1-5. Once that's taken care off, I'll probably start looking into cleaning up the existing ASM hacks and implimenting new ones. |
|
|
|
|
frantik
Guest
|
|
« Reply #179 on: March 21, 2008, 04:46:08 am » |
|
What's a Red Piranha Plant? Do we actually need them. I don't recall any red pirana plants in SMBS. However, part of that code proably also has to do with upside down Piranha Plants. the red plants are the upside down ones we can make then green though if you don't like red hehehe and i have no idea where that bullet bill code change came from... i'd guess the plant/pipe patch. edit: here's the upside down pipe code (in the looping area) cleaned up.. some really inefficient use of space too :'( ; $c070
RenderUpsideDownPipe1:
ldy #$01 ;check for length loaded, if not, load
jsr ChkLrgObjFixedLength ; pipe length of 2 (horizontal)
jsr GetLrgObjAttrib ; returns vert length in Y
dey
dey
sty $05 ; save length - 2 in $05
ldy AreaObjectLength,X ; check pipe column
sty $06
ldx $05 ; load length
inx ; increase by 1
lda VerticalPipeData+2,Y ; read pipe metatile data
cmp #$00 ; if vertical length is too short just draw pipe end
beq DrawEnd1 ; (this might be residual/doesnt appear to work right)
ldx #$01 ; set upper render height
ldy $05 ; load length
jsr RenderUnderPart ; render pipe body
clc
DrawEnd1: ldy $06 ; check which column of pipe
lda VerticalPipeData,Y ; load pipe end
sta MetatileBuffer,X ; render pipe end
rts ; return
nop
nop
nop
nop
; $C0A0
RenderUpsideDownPipe2:
ldy #$01 ;check for length loaded, if not, load
jsr ChkLrgObjFixedLength ; pipe length of 2 (horizontal)
jsr GetLrgObjAttrib ; returns vert length in Y
dey
dey
sty $05 ; save length - 2 in $05
ldy AreaObjectLength,X ; check pipe column
sty $06
ldx $05 ; load length
inx ; increase by 1
lda VerticalPipeData+2,Y ; read pipe metatile data
cmp #$00 ; if vertical length is too short just draw pipe end
beq DrawEnd2
ldx #$05 ; set upper render height
ldy $05 ; load length
jsr RenderUnderPart ; render pipe body
clc
DrawEnd2: ldy $06 ; check which column of pipe
lda VerticalPipeData,Y ; load pipe end
sta MetatileBuffer,X ; render pipe end
rts ; return edit2: actually, use this code for the 2nd pipe.. I changed it so it has a set lower point and a variable high point (unlike the other which has a set high point and variable lower point ) RenderUpsideDownPipe2:
ldy #$01 ;check for length loaded, if not, load
jsr ChkLrgObjFixedLength ; pipe length of 2 (horizontal)
jsr GetLrgObjAttrib ; returns vert length in Y
dey
dey
sty $05 ; save length - 2 in $05
ldy AreaObjectLength,X ; check pipe column
sty $06
ldx $05 ; residual
inx ; residual
lda #$08 ; get height location from length
clc ; make sure carry is cleared or else
sbc $05 ; wont render correctly
tax
lda VerticalPipeData+2,Y ; read pipe metatile data
ldx #$05 ; set upper render height
ldy $05 ; load length
jsr RenderUnderPart ; render pipe body
clc
ldy $06 ; check which column of pipe
lda VerticalPipeData,Y ; load pipe end
sta MetatileBuffer,X ; render pipe end
rts ; return and the suspected residual code can be nooped in the first one, alone with the fiddling with X before it ------ edit 3: here's a version of code for both upside down pipes which doesn't waste any space  i didn't test it but it should be fine InitUpsideDownPipe:
ldy #$01 ;check for length loaded, if not, load
jsr ChkLrgObjFixedLength ; pipe length of 2 (horizontal)
jsr GetLrgObjAttrib ; returns vert length in Y
dey
dey
sty $05 ; save length - 2 in $05
ldy AreaObjectLength,X ; check pipe column (horz length)
sty $06
rts
RenderUpsideDownPipe1:
jsr InitUpsideDownPipe
lda VerticalPipeData+2,Y ; read pipe metatile data
ldx #$01 ; set upper render height
ldy $05 ; load length
jmp DrawUpsideDownPipe ; render pipe
RenderUpsideDownPipe2:
jsr InitUpsideDownPipe
lda #$08 ; set lower height location
clc ; clear carry to render correctly
sbc $05 ; substract vert length to find upper location
tax
lda VerticalPipeData+2,Y ; read pipe metatile data
ldy $05 ; load length
DrawUpsideDownPipe:
jsr RenderUnderPart ; render pipe body
clc
ldy $06 ; check which column of pipe
lda VerticalPipeData,Y ; load pipe end
sta MetatileBuffer,X ; render pipe end
rts ; return
|
|
|
|
« Last Edit: March 22, 2008, 06:49:51 pm by frantik »
|
|
|
|
|
RHDN Forum Archive
