1572 replies to this topic

[Mike B Berry]

It seems I have stumbled into yet another issue. As stated on my update to the hack; I have imported both rain and ash objects to load in GHZ, MZ, SLZ, and SBZ: What happens is the stage loads garbed stars. This issue either might be caused because of the RAM address is wrong. Or, the screen can't handle everything. Please help if you can.

; ---------------------------------------------------------------------------

; Object 02 - Rain

; ---------------------------------------------------------------------------



obj02:								  ; XREF: Obj_Index

				moveq   #0,d0

				move.b  $24(a0),d0

				move.w  obj02_Index(pc,d0.w),d1

				jmp	 obj02_Index(pc,d1.w)

; ===========================================================================

obj02_Index:	dc.w obj02_Main-obj02_Index

				dc.w obj02_First-obj02_Index

; ===========================================================================



obj02_Main:							 ; XREF: Rain code

				addq.b  #2,$24(a0)			  ;go to next routine

				move.l  #Map_obj02,4(a0)		;Maps

				move.w  #$56E,2(a0)			 ;VRAM position

				move.b  #0,1(a0)

				move.b  #1,$18(a0)

obj02_Display:

				jmp	 DisplaySprite

				rts



obj02_First:

				jsr	 Obj02_Display

				move.w  #-$700,$10(a0)  ; make the object have a speed which moves it up quickly

				addq.w  #4,$A(a0)

				jmp	 SpeedToPos	  ; update the object's position (move the object)

				rts

Obj02Next_Func:

				addq.b  #2,$24(a0)

				rts

Obj02_Delete:

				jmp	 DeleteObject

; ===========================================================================

; ---------------------------------------------------------------------------

; Sprite mappings

; ---------------------------------------------------------------------------

Map_obj02:

		include "_mapsrain.asm"

	include "_mapsrain2.asm"

The screen shot: (The Ash code will be a carbon copy of Obj02, but with different ram addresses. Obj10 will be the space it uses)

Edited by Mike B Berry, 05 August 2012 - 12:43 AM.

[MarkeyJester]

I'm afraid I don't have enough information to pin point exactly what's wrong, you haven't stated whether the ash has its own art or not, and if so, if it has been loaded to VRAM or not, and if so, where abouts.

move.w    #$56E,2(a0)            ;VRAM position

Here, in VRAM at 56E x 20 = VRAM address ADC0, that is where the invincible stars art is loaded, I'm assuming you want the invincible art in your levels, so you should not be trying to load your art to there (if you are), and you shouldn't be setting your object to read from there (if you don't want it to display stars instead of your art).

Tell us more about the art, and where you might have loaded it to in VRAM (if you have), we need more information.

[Mike B Berry]

I'm afraid I don't have enough information to pin point exactly what's wrong, you haven't stated whether the ash has its own art or not, and if so, if it has been loaded to VRAM or not, and if so, where abouts.

move.w #$56E,2(a0) ;VRAM position

Here, in VRAM at 56E x 20 = VRAM address ADC0, that is where the invincible stars art is loaded, I'm assuming you want the invincible art in your levels, so you should not be trying to load your art to there (if you are), and you shouldn't be setting your object to read from there (if you don't want it to display stars instead of your art).

Tell us more about the art, and where you might have loaded it to in VRAM (if you have), we need more information.

I'm using the rain art for a place holder in MZ, That part is cleared up now. The guide I followed on retro hack wasn't the greatest demonstration I've stumbled across. The RAM location I have used was this:

lea	 ($FFFFD5C0).w,a1	 ;Ram location for the object.

			 move.b #$02,0(a1)			 ;Load object 02

Now I put the move.b code in with it because I load the art with the resizing codes. I still feel like I'm missing something though. I have my mappings and the art that is supposed to load as well.

Edited by Mike B Berry, 05 August 2012 - 02:34 AM.

[MarkeyJester]

[Mike B Berry]

I know that expression... It'd be best just to take my question down. I'll noodle about by myself until I figure this out...

Edited by Mike B Berry, 05 August 2012 - 03:37 AM.

[SpirituInsanum]

The problem is more that you obviously don't know what you're doing. Even in such a simplistic object there's a number of mistakes and errors, and to be perfectly honest I firmly believe it would be a waste of time to detail them.

That's really an awfully programmed object.

Besides, if I may throw my two cents in the bottomless and ineffective well of wishes, you shouldn't follow guides that will only put in your hack the same broken stuff as so many other hacks probably already have if someone made a guide for them.

Try the basic asm tutorials, you'll learn more and faster than by following such guides. And maybe, when you won't depend on those guides any longer, you'll have the necessary knowledge to consider adding your own original ideas into your hack.

[Mike B Berry]

Even though your accusation is 100% that I have no prior knowledge, I have the art loading correctly now.

[redhotsonic]

lea     ($FFFFD5C0).w,a1     ;Ram location for the object.

             move.b #$02,0(a1)             ;Load object 02

You should never make an object have it's own RAM address unless you know it's definitely always going to be free.


If you look how other objects are loaded, they use "SingleObjLoad". Or in Sonic 1,"FindFreeObj". What this does is it finds the next free and available RAM in the OBJECT_RAM. That way, you're not over-writing any objects. So, try this.

        jsr    FindFreeObj    ; Find next free available RAM
        bne.s    alabel        ; If Object_RAM is full, branch away and skip making object
        move.b    #2,0(a1)    ; load Obj02

alabel:

Edited by redhotsonic, 05 August 2012 - 11:45 AM.

[MarkeyJester]

Well actually redhot, given the context and use of the object, it looks to be a feature that hangs around in a level semi-perminantly displaying, like the water surface, or the HUD, so I feel that he's right to use that place. I also feel that it's not the object that's the problem, the object is fine enough, it isn't up to scraps as it could be, but it should still work (which is does looking at the screenshot), the problem is the art and its VRAM space, this is the information we need in order to help, but until he gives us information regarding the actual art itself, and where in VRAM he's attempting to load it, noone can help.

[redhotsonic]

Well actually redhot, given the context and use of the object, it looks to be a feature that hangs around in a level semi-perminantly displaying, like the water surface, or the HUD, so I feel that he's right to use that place.

Ah yes, if he is making it rain instantly, that's a sure thing. If making it rain later on, then the "FindFreeObj" would be a better option.

[Sonic master]

Ah yes, if he is making it rain instantly, that's a sure thing. If making it rain later on, then the "FindFreeObj" would be a better option.

If the function returns the first free sprite (and all the ones after it are also free) then why not directly edit the VRAM sprite table it would be much easier than messing around with mapping and all that it would also reducing processing time because the mapping does not have to be decoded. This can be done since your sprite is 4x4 tiles or smaller.
Here is a good VDP doc that I would recommend
http://cgfm2.emuviews.com/txt/genvdp.txt
It has the sprites table format used by the VDP and many more useful stuff that should be read.
Also you need to add the tiles that are loaded to the Pattern Load Cues.
When adding the object to the PLC see to it that there is a free vram address and remember which address you picked and use the vram address you picked and divide it by 32 (each tile is 32 bytes uncompressed).
Also it sucks that the window plane hides plane a the window would have been perfect for rain and other overlays.

[StephenUK]

I shit you not, this is exactly what I did before I even noticed this post.

[SpirituInsanum]

I'm trying to fix Sonic's balancing problem with the conveyor belts in Scrap Brain 2. It seems like my fix is working, but there one detail that could cause a problem, therefore this question:

Is there any object that could modify Sonic's speed while Sonic is standing? (I do mean the speed, the one stored in $FFD010)

I know most objects modify the coordinates directly, and so far I couldn't find any that would modify the speed, but I don't want to overlook something.

[Kensou]

I'm trying to fix Sonic's balancing problem with the conveyor belts in Scrap Brain 2. It seems like my fix is working, but there one detail that could cause a problem, therefore this question:

Is there any object that could modify Sonic's speed while Sonic is standing? (I do mean the speed, the one stored in $FFD010)

I know most objects modify the coordinates directly, and so far I couldn't find any that would modify the speed, but I don't want to overlook something.

I remember that bug. In what situations that bug exactly happens?

[SpirituInsanum]

This one:
 S1_conveyor.png   7.1K   10 downloads

The fix I have requires to avoid the balancing animations if Sonic's speed isn't null, otherwise, before Sonic falls, every balancing animation is used for a few frames each and that's ugly.

[MarkeyJester]

No objects alter Sonic's X speed if he is on the ground, the problem here is that Sonic's X and Y speeds are technically uneffective when he is not in the air (or well, that's a bit of an understatement), the angle in which Sonic is on the floor, is taken and used to collect the sine wave X and Y positions, these positions are multiplied by the ground speed (the one held at 14-5 of Sonic's SST space), the X and Y positions that were multiplied, are then saved into the X and Y speeds (the ones held at 10-1 and 12-3), this however, is done in the Sonic object's routines itself, and these speeds are converted and added to his X and Y positions almost directly after, before any other objects, or any other routines during the main loop are able to manipulate those speeds, so altering them anywhere else will have no effect, hence useless trying.

Additionally, you cannot alter Sonic's ground speed without his animation of walking/running coming into action, it wouldn't look like he's "standing" on the conveyor belt and being moved by it. The advice I can only give that works the way you would like it, is to preserve a memory space for an X speed, and then add that X speed to Sonic's X speed before it is "converted and added" to Sonic's X position, it will require clearing that space when not in use, and obviously making sure nothing else alters it.

A tough fix, really tough, sorry if this is not the information you were looking for.

[SpirituInsanum]

It's a perfect answer, now I know what to fix (although it's probably specific to my hack), thanks.

The bug itself was fixed when I asked the question, I was worrying about possible problems the fix would cause if the speed was modified anywhere else. Actually I'm precisely using that property of the speed value as a kind of flag.

I'll write the fix here, if anyone wants to try and find possible problems:

In obj68_main, add 12 to both widths (in decimal).
Then in Obj68_MoveSonic, replace addi.w #$30,d1 with addi.w #$23,d1, and after add.w d0,8(a1), add

asl.w #4,d0 ; < you can use less than 4 here, as it will influence sonic's speed if he jumps. For full inertia, use 8

add.w d0,$10(a1)

and after Sonic_Balance: , add

tst.w $10(a0)

bne.w Sonic_LookUp

I absolutely don't know how the fix will behave in the original game, or in other hacks.

In my hack I've had to fix a problem with the camera while charging the peelout or spindash on a conveyor belt, but for now that's it.

[Mike B Berry]

My next plan is to add foreground objects into GHZ; much like those girders in SLZ... I'm designing large totem polls. I already have the art and mapings finished, and a cheap copy of object5C's code (It's just there because I get a few errors without the routines being called.) But now it is time for the coding, yet I already know that this code line for obj10 will be entirly different than the code provided on the girder object (5C). What would be my best option? Heres some concept of how the level would look with it: