Basic Questions & Answers thread

So I have been romhacking Sonic 1 to implement a new character, and yellow numbers appear on the jump sprites. Anyone got a fix?

 

In Sonic 1, the way the player's sprite graphics are loaded is that it takes the current sprite frame, loads it into an area of main memory, which is then loaded into video memory. That area of main memory has a fixed size, so that means if you have too many tiles in a frame, then it will only load what it can fit in there.

The yellow numbers are the points graphics that display when you destroy a badnik. They are placed right after Sonic's graphics area in video memory. Due to the extra tiles not being loaded over into that area, the areas of the sprite that should have those extra unloaded tiles appear as those numbers.

There are 2 fixes that come to mind. You can either expand the size of the sprite graphics area in main memory, or you can use the DMA queue, which basically allows you to easily load graphics straight from ROM into video memory without having to store the graphics in main memory first or having to deal with a limited space for loading the player graphics in. I personally recommend the second option. There's even a Sonic 1 implementation in part 3 of the spindash porting guide in the wiki, so it shouldn't be difficult to implement.

Now, because with this you are allowing the extra tiles to load in video memory, they will overwrite the points graphics, so they will have to be relocated to another spot in video memory.

 

Open "newObj17.bin" with a hex editor, and share what the values are inside of it,

I have a... ...feeeling.

 

Usually the wild sprites are a sign the sprite rendering routine is given a rouge list of random crap.

Given the mappings you've shared are fine, then it has to be something within the object's routine itself. It could be the map frame ID is wrong, or perhaps some wrong subroutine calls, there is no way of telling from the above information.

 

That's why then. The spike log changes the frame ID rotating around from 00 to 07 in a loop. You only have one frame (map frame 00), you need another 7 (01 to 07).

 

Did you add the pole graphics to the PLC list?

 

Alright, so how would I expand the sprite graphics in the main memory? It sounds a lot easier than the second fix and I'm a lazy piece of crap.

 

Just gonna steal this from an SSRG MarkeyJester made...

Ultimately, though, adding a DMA queue will be better for you in the long run as it saves spaces in memory and is more flexible.

You will still need to move the points graphics. Regardless of how you approach it, they will still get overwritten by the additional tiles being loaded for the player's sprite.

@Aerosol It may help to show more of the object code or the mappings data again, because it still looks like there's still some kind of mappings error or sprite frame error.

 

Is anyone experienced with adding DPLCs to objects.

I've tried adding DPLC to a projectile of mine to save tile space, but the issue is that now the object doesn't delete when the routine commands it to:

Code (Text):

1.  
2.     lea    (Ani_Laser).l,a1
3.     jsr    AnimateSprite
4.     bsr.w    LoadProjDynPLC
5.     jsr    (TouchResponse).l ;Touch_KillEnemy, Touch_Monitor
6.     jmp    DisplaySprite  
7.  
8. Obj_Blob_Destroy:
9.     clr.b    ($FFFFFFA4).w    ; clear flag  
10.     jmp DeleteObject
11.  
12.  
13. ; loc_1D1AC:
14. LoadProjDynPLC:
15.     moveq    #0,d0
16.     move.b    mapping_frame(a0),d0                ; load frame number
17. ; loc_1D1B2:
18. LoadProjDynPLC_Part2:
19.     cmp.b    objoff_30(a0),d0
20.     beq.w    return_ProjDPLC
21.     move.b    d0,objoff_30(a0)
22.     lea    (MapRUnc_Proj).l,a2
23.     add.w    d0,d0
24.     adda.w    (a2,d0.w),a2
25.     move.w    (a2)+,d5
26.     subq.w    #1,d5
27.     bmi.s    return_ProjDPLC
28.     move.w    #$9280,d4                        ; ****** Here
29. ; loc_1D1D2:
30. PPLC_ReadEntry:
31.     moveq    #0,d1
32.     move.w    (a2)+,d1
33.     move.w    d1,d3
34.     lsr.w    #8,d3
35.     andi.w    #$F0,d3
36.     addi.w    #$10,d3
37.     andi.w    #$FFF,d1
38.     lsl.l    #5,d1
39.     addi.l    #ArtUnc_Proj,d1
40.     move.w    d4,d2
41.     add.w    d3,d4
42.     add.w    d3,d4
43.     jsr    (QueueDMATransfer).l
44.     dbf    d5,PPLC_ReadEntry                        ; repeat for number of entries
45.  
46. return_ProjDPLC:
47.     rts
48.  
49. ; ===========================================================================
50. Ani_Laser:
51.     dc.w laser0-Ani_Laser
52. laser0:    dc.b 1,1,2,3,$FF
53.     even
54.  
55. Map_Obj4D:    include "ProjMap_Unc.asm"
56.  even
57. MapRUnc_Proj:    include "ProjPLC_Unc.asm"
58.  even
59.  

Any idea what I'm doing wrong here?

 

Ah right sorry:

Code (Text):

1.  
2. Obj4D:
3.     moveq    #0,d0
4.     move.b    $24(a0),d0
5.     move.w    Obj_Blob_Index(pc,d0),d0
6.     jmp    Obj_Blob_Index(pc,d0)
7.  
8. Obj_Blob_Index:
9.     dc.w    Obj_Blob_Init-Obj_Blob_Index
10.     dc.w    Obj_Blob_Move-Obj_Blob_Index
11.     dc.w    Obj_Blob_Destroy-Obj_Blob_Index
12.  
13. Obj_Blob_Init:
14.     move.l    #Map_Obj4D,mappings(a0) ; ($C)
15.     move.w    #$2,priority(a0)
16.     move.b    #$8,width_pixels(a0)
17.     move.w  #$9280/$20,art_tile(a0)
18.     move.b    #$4,render_flags(a0)
19.     move.b    #$4,y_radius(a0) ; $A
20.     lea    (MainCharacter).w,a1
21.         cmpi.b  #$25,anim(a1)    ; is NICOLE attack being performed?
22.         beq.w   MinThrow           ; if not, branch
23.         cmpi.b  #$30,anim(a1)    ; is NICOLE attack being performed?
24.         beq.w   MaxThrow           ; if not, branch
25. MinThrow:
26.     move.w     #$2C0,x_vel(a0)                ; speed of laser
27.     move.w     #-$430,y_vel(a0)                ; speed of laser
28.     move.b    #$38,$30(a0)                 ; distance laser will travel
29.     bra.w    Obj4D_Cont
30. MaxThrow:
31.     move.w     #$740,x_vel(a0)                ; speed of laser
32.     move.w     #-$490,y_vel(a0)                ; speed of laser
33.     move.b    #$38,$30(a0)                 ; distance laser will travel
34.  
35. Obj4D_Cont:
36.     btst    #0,($FFFFB001).w
37.     beq.s +
38.     neg.w    x_vel(a0)
39.     add.w    #$40,x_pos(a0)
40.     bra.w    ++
41. +
42.     sub.w    #$40,x_pos(a0)
43. +
44.     move.w #$9280,d2
45.     addq.b    #2,$24(a0) ;
46.  
47.  
48. Obj_Blob_Move:
49.     cmp.b    #0,$30(a0)
50.     bne.w    ContCounter
51.     bra.w    Obj_Blob_Destroy
52.  
53. ContCounter:
54.     sub.b     #$1,$30(a0)
55.     bsr.w    ObjectMoveAndFall
56.     move.b    $40,$20(a0)    ; lol
57.  
58.     clr.w d0
59.     move.b $1A(a0),d0
60.     asl.w #$1,d0     ; *2 for correct offset  
61.     lea (ArtUnc_Proj).l,a1
62.     adda.w (a1,d0.w),a1
63.     move.w #$9280,d2
64.  
65.     lea    (Ani_Laser).l,a1
66.     jsr    AnimateSprite
67.     bsr.w    LoadProjDynPLC
68.     jsr    (TouchResponse).l ;Touch_KillEnemy, Touch_Monitor
69.     jmp    DisplaySprite  
70.    
71. Obj_Blob_Destroy:
72.     clr.b    ($FFFFFFA4).w    ; clear flag    
73.     jmp DeleteObject
74.  
75.  
76. ; loc_1D1AC:
77. LoadProjDynPLC:
78.     moveq    #0,d0
79.     move.b    mapping_frame(a0),d0                ; load frame number
80. ; loc_1D1B2:
81. LoadProjDynPLC_Part2:
82.     cmp.b    objoff_30(a0),d0
83.     beq.w    return_ProjDPLC
84.     move.b    d0,objoff_30(a0)
85.     lea    (MapRUnc_Proj).l,a2
86.     add.w    d0,d0
87.     adda.w    (a2,d0.w),a2
88.     move.w    (a2)+,d5
89.     subq.w    #1,d5
90.     bmi.s    return_ProjDPLC
91.     move.w    #$9280,d4                        ; ****** Here
92. ; loc_1D1D2:
93. PPLC_ReadEntry:
94.     moveq    #0,d1
95.     move.w    (a2)+,d1
96.     move.w    d1,d3
97.     lsr.w    #8,d3
98.     andi.w    #$F0,d3
99.     addi.w    #$10,d3
100.     andi.w    #$FFF,d1
101.     lsl.l    #5,d1
102.     addi.l    #ArtUnc_Proj,d1
103.     move.w    d4,d2
104.     add.w    d3,d4
105.     add.w    d3,d4
106.     jsr    (QueueDMATransfer).l
107.     dbf    d5,PPLC_ReadEntry                        ; repeat for number of entries
108.  
109. return_ProjDPLC:
110.     rts
111.  
112. ; ===========================================================================
113. Ani_Laser:
114.     dc.w laser0-Ani_Laser
115. laser0:    dc.b 1,1,2,3,$FF
116.     even
117.  
118. Map_Obj4D:    include "ProjMap_Unc.asm"
119.  even
120. MapRUnc_Proj:    include "ProjPLC_Unc.asm"
121.  even

 

Right here you're decrementing $30(a0) and bailing out when it gets down to zero. However...

Right here you're using $30(a0) to store the last queued PLC frame. If frame zero never gets queued, then we'll continue taking the branch to ContCounter forever.

Just move either of these to a different byte and you should be good.

 

One thing that comes to mind is having the shield and invincibility stars art be uncompressed, have both objects share the same VRAM space, like in S3K, since neither of them show up simultaneously, so it just makes sense to only have the current powerup graphics loaded at one time. Bonus points if you have them use DPLCs so only the currently shown art is loaded into VRAM at once.

I don't think it'll save a whole lot of space, but it certainly helps, although I think this would only work out in 1P mode, since it is possible for Sonic to have a shield and Tails to have invincibility and vice versa in 2P mode. Maybe someone who has more experience working with Sonic 2 can chime in.

You can also pull a Sonic CD and split off the level into sections, and only load the graphics for certain objects that are used in each section.

 

Ah that seems to have done it. Thanx. :d