Sonic and Sega Retro Message Board: LZ water ripple in s2 - Sonic and Sega Retro Message Board

Jump to content

Hey there, Guest!  (Log In · Register) Help
Loading News Feed...
 

LZ water ripple in s2 easy to implement, but has it's downsides

#1 User is offline MoDule 

Posted 21 June 2008 - 05:52 PM

  • Posts: 305
  • Joined: 03-October 07
  • Gender:Male
  • Project:Procrastinating from writing bug-fix guides
  • Wiki edits:52
I will now show you how to add the water ripple effect from LZ to theoretically any zone in s2.
Don't get too excited yet, though. If you've played the betas you might remember the effect being there. So why was it taken out of the final? Because things can get really slow, that's why.

First, let me begin by explaining how the ripple effect is achieved. All you really need to know is that horizontal scrolling is handeled by an array of longwords beginning at $FFFFE000. Each entry holds the scroll factor of a single horizontal line of pixels going from top to bottom whereas the high word is for the foreground and the low word for the background. This is explained in more detail by qiuu in the S2:AE thread (thanks, btw). The water ripple basically just manipulates the array so that some lines are shifted slightly to one side or the other. How far each line is shifted is stored in a table. For the foreground it's stored in 'Deform_LZ_Data1' and the background uses the wobble data from the bubble object.

So let's begin, shall we?
First, just so you know, im using Xenowhirl's 2007 disassembly.
Now, we'll be adding to the software scrolling engine, so it would make sense to put our code in there. Since CPZ and ARZ are the only two zones that use water in s2 it would be best to put it somewhere inbetween 'SwScrl_CPZ' and 'SwScrl_ARZ'.

SwScrl_Water:
	; this adds the LZ water ripple effect to any level
	lea	(Deform_LZ_Data1).l,a3
	lea	(Obj0A_WobbleData).l,a2
	move.b	($FFFFF7D8).w,d2
	move.b	d2,d3
	addi.w	#$80,($FFFFF7D8).w ; '€'
	add.w	(Camera_Bg_Y_pos).w,d2
	andi.w	#$FF,d2
	add.w	(Camera_Y_pos).w,d3
	andi.w	#$FF,d3
	lea	(Horiz_Scroll_Buf).w,a1
	move.w	#$DF,d1	; 'ß'
	move.w	(Water_Level_1).w,d4
	move.w	(Camera_Y_pos).w,d5


I'll stop here real quick because I need to tell you that I added an equate to the disassembly to enhance readability. More specifically, it's 'Camera_Bg_Y_pos' which is located at $FFFFEE0C. You'l need to add that equate for it to work. best put it right underneath 'Camera_Y_pos' so it looks something like this:
Camera_RAM =		ramaddr( $FFFFEE00 )
Camera_X_pos =		ramaddr( $FFFFEE00 )
Camera_Y_pos =		ramaddr( $FFFFEE04 )
Camera_Bg_Y_pos =	ramaddr( $FFFFEE0C )


So, what does this first segment do? We load the two tables containing the deformation data into a3 and a2. $FFFFF7D8 stores the 'phase' of the the ripple. Without this there'd still be a ripple, but it wouldn't move. We add $80 to it every frame which means the phase increases every second frame (level coordinates are stored as words and $80 is 1/2 of $100). The phase is copied once to d2 which is for the background and once to d3 which is for the foreground. These two registers will be used later for vertical position of the ripple plus it's phase. Both our tables of ripple data are 256 bytes long, so to avoid flowing into other data we need to use something like x mod 256. Since 256 is a power of 2 we can just and with $FF. We store the Hscroll buffer in a1. If we didn't do that all would be for nothing as we couldn't even make the ripple show without it. We move $DF (223) to d1 which is how many lines there are minus 1 (consider it a do-while statement, where the code is always executed at least once even when the condition isn't true).

Moving on
-	; as long as the camera is above the water
	cmp.w	d4,d5			; is camera below water?
	bge.s	SwScrl_Water_doRipple	; if yes, branch
	addq.w	#4,a1		; increment pointer
	addq.w	#1,d5		; increment camera y pos
	addq.b	#1,d2
	addq.b	#1,d3
	dbf	d1,-
	rts


Here we start checking all 224 lines from to to bottom. As long as the line we're checking isn't under water we just increment the the pointer in a1 (to the Hscroll buffer. This basically means we're not changing the horizontal position of the current line and moving on to the next). d4 and d5 are the current water level and the camera y position, respectively. We increment all of our y position counters so that in the next loop we'll be looking at the line below the current one. If there's no water in sight we've basically done nothing (except waste valuable processor time). Once we reach a line that's below the water surface we branch to the next part of the program.

	; does the LZ water ripple effect once the camera is below the water
SwScrl_Water_doRipple:
	move.b	(a3,d3.w),d4	; FG ripple effect
	ext.w	d4
	add.w	d4,(a1)+

	move.b	(a2,d2.w),d4	; BG ripple effect
	ext.w	d4
	add.w	d4,(a1)+
	addq.b	#1,d2
	addq.b	#1,d3
	dbf	d1,SwScrl_Water_doRipple
	rts

Here we finally make the water ripple happen. Using a3 and a2 as indexes for our tables we retrieve the appropriate values for the current line (remember how we added 1/2 of $100 to the phase earlier? That becomes significant here, because we're just using the high byte of the y position, which only increases every second frame). These values are then added to the current scroll factor of the line we're focusing on. We then increment our counters like before and repeat until we reach the last line.

Deform_LZ_Data1:
	dc.b   1,  1,  2,  2,  3,  3,  3,  3,  2,  2,  1,  1,  0,  0,  0,  0; 0
	dc.b   0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0; 16
	dc.b   0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0; 32
	dc.b   0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0; 48
	dc.b   0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0; 64
	dc.b   0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0; 80
	dc.b   0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0; 96
	dc.b   0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0; 112
	dc.b $FF,$FF,$FE,$FE,$FD,$FD,$FD,$FD,$FE,$FE,$FF,$FF,  0,  0,  0,  0; 128
	dc.b   0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0; 144
	dc.b   1,  1,  2,  2,  3,  3,  3,  3,  2,  2,  1,  1,  0,  0,  0,  0; 160
	dc.b   0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0; 176
	dc.b   0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0; 192
	dc.b   0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0; 208
	dc.b   0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0; 224
	dc.b   0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0; 240

Here's the ripple data so you don't have to look for it in s1.

There, now that you understand how the water ripple effect works you might be wondering how to use it. Simple. All you have to do is locate the code for the zone you want to add the ripple to (they all start with 'SwScrl') and replace all the rts with branches to our code (bra, not bsr, jmp if it's too far away). Done.
At least, I think that's all you have to do. There might be some zones that branch to somewhere outside the main code and don't return.
Note that CPZ only has water in act 2, so you'll need to add a short test for that.

I'd like to warn you again that this will slow down your hack noticably if you have lots of objects on screen. As long as you are playing alone it should be okay in s2, but if you're playing as Sonic and Tails the slowdown will be pretty bad.
I have no idea how s3 manages to do that with collapsing ledges, brakable floors, animated tiles, Sonic and Tails and generally lots of sprites on screen without any slowdown at all.

Btw, does anyone have the AIZ ripple data? I tried to find it but came up empty handed.

If this is satisfactory, I'd like to ask one of the wiki guys to add this to the how-tos section. That is, if there aren't any objections.

Here's some images for demonstrational purposes:
Posted Image CPZ
Posted Image ARZ

Download
This post has been edited by MoDule: 27 August 2008 - 01:32 PM

#2 User is offline Trunks 

Posted 21 June 2008 - 05:55 PM

  • AGAIN TRY
  • Posts: 1292
  • Joined: 20-February 08
  • Gender:Male
  • Location:San Antonio, TX
  • Project:Sure to be Ban'd, The Bancast, Trunks & Soto, iLove
  • Wiki edits:30
Wicked stuff, man. I'm a bit retarded when it comes to ASM, but is there any chance we could see an example in ROM form? I'm excited by this.

#3 User is offline MoDule 

Posted 21 June 2008 - 05:58 PM

  • Posts: 305
  • Joined: 03-October 07
  • Gender:Male
  • Project:Procrastinating from writing bug-fix guides
  • Wiki edits:52
I guess I could compile a rom real quick with just the effect in. I'd just need a place to upload it to.

Edit: yay, level up.
This post has been edited by MoDule: 21 June 2008 - 05:58 PM

#4 User is offline Hitaxas 

Posted 21 June 2008 - 07:03 PM

  • SEGA: Sorry Classic Sonic, we are sending you back to 1994
  • Posts: 1352
  • Joined: 30-September 07
  • Gender:Male
  • Location:Litchfield, CT
  • Project:Sonic: Super Deformed (head director) - Slowly working on it.
  • Wiki edits:196
Module, this is awesome. :thumbsup:

I was going to port this for my hack, but haven't got to it. This will help a lot. <3


Edit: Just a heads up: Not all of the code that Module has posted is labeled correctly, but if you know what you are doing, you can grab the necessary chunks from the S1 asm.
This post has been edited by Hitaxas: 21 June 2008 - 07:40 PM

#5 User is offline Tets 

Posted 22 June 2008 - 01:17 AM

  • one rude dude
  • Posts: 386
  • Joined: 26-December 05
  • Gender:Male
Great timing, I was just thinking the other day about how awesome it would be if I could put Labyrinth Zone's water ripple effects in Sonic 2. I did a quick test of this on my own hack (in which I've already added water to CPZ act 1) and it looks really good, albeit slow like you said. I'd like to have a look at how Sonic 3 does this without any apparent slowdown, but I don't even know where to start.

#6 User is offline qiuu 

Posted 22 June 2008 - 04:15 PM

  • Posts: 132
  • Joined: 05-February 08
  • Gender:Not Telling
  • Project:Blue Ball & Blocks
  • Wiki edits:13
Just added it to ARZ, looks nice.

I think the data of Deform_LZ_Data1 is only included in the rev01 of Sonic 1, of which I haven't got a disassembly, however in an older topic jman2050 has documented that BG deformation changes (also for the other Sonic 1 zones) including ASM code: http://forums.sonicr...?showtopic=7340
bgdeform.txt includes the foreground deformation data, labeled LZ_Wave_Data.

btw, this is my post MoDule was referring to in the beginning of his post, though I guess his explanation is better than mine.

View PostMoDule, on Jun 22 2008, 12:52 AM, said:

[...]Here we start checking all 224 lines from to to bottom. As long as the line we're checking isn't under water we just increment the the pointer in a1 (to the Hscroll buffer. This basically means we're not changing the horizontal position of the current line and moving on to the next). d4 and d5 are the current water level and the camera y position, respectively. We increment all of our y position counters so that in the next loop we'll be looking at the line below the current one. If there's no water in sight we've basically done nothing (except waste valuable processor time). Once we reach a line that's below the water surface we branch to the next part of the program. [...]

I guess that part for the calculation above water level can be optimized as no loop is necessary for this:
Syntax Highlighted Code: ASM
	[color= #00bfff;]sub[/color].[color= #00bfff;]w[/color]	d5,d4
[color= #00bfff;]blt[/color].[color= #00bfff;]s[/color] SwScrl_Water_doRipple
[color= #00bfff;]add[/color].[color= #00bfff;]b[/color] d4,d2
[color= #00bfff;]add[/color].[color= #00bfff;]b[/color] d4,d3
[color= #00bfff;]asl[/color].[color= #00bfff;]w[/color] [color= #ff0000;]#[/color][color= #ff0000;]2[/color],d4
[color= #00bfff;]adda[/color].[color= #00bfff;]w[/color] d4,a1
[color= #00bfff;]cmpi[/color].[color= #00bfff;]w[/color] [color= #ff0000;]#[/color][color= #ff0000;]$[/color][color= #ff0000;][color= #ff0000;]380[/color][/color],d4
[color= #00bfff;]blt[/color].[color= #00bfff;]s[/color] SwScrl_Water_doRipple
[color= #00bfff;]rts[/color]

This should at least improve performance a little if there is no or only little water on the screen.
I guess further performance improvement can be made if the water effect is applied and adapted to each zone's deformation separately.

On a less related note, I noticed that in EHZ, the lowest two layers don't scroll as they are not affected by the deformation code. This can be fixed by appending something like
Syntax Highlighted Code: ASM
	[color= #00bfff;]move[/color].[color= #00bfff;]w[/color]	d4,(a1)+
[color= #00bfff;]move[/color].[color= #00bfff;]w[/color] d3,(a1)+
twice to the EHZ deformation routine.

#7 User is offline MoDule 

Posted 23 June 2008 - 02:06 AM

  • Posts: 305
  • Joined: 03-October 07
  • Gender:Male
  • Project:Procrastinating from writing bug-fix guides
  • Wiki edits:52

View Postqiuu, on Jun 22 2008, 11:15 PM, said:

Just added it to ARZ, looks nice.

I think the data of Deform_LZ_Data1 is only included in the rev01 of Sonic 1(...)

Whoops. I can't believe I forgot about that. I had it right next to me. I'll just have to add it later when I get home.
Edit: It's been added.

View Postqiuu, on Jun 22 2008, 11:15 PM, said:

btw, this is my post MoDule was referring to in the beginning of his post, though I guess his explanation is better than mine.

I felt like mentioning you, because your post is what got me interested in the first place.

View Postqiuu, on Jun 22 2008, 11:15 PM, said:

View PostMoDule, on Jun 22 2008, 12:52 AM, said:

[...]Me go bla[...]

I guess that part for the calculation above water level can be optimized as no loop is necessary for this:
Syntax Highlighted Code: ASM
	[color= #00bfff;]sub[/color].[color= #00bfff;]w[/color]	d5,d4
[color= #00bfff;]blt[/color].[color= #00bfff;]s[/color] SwScrl_Water_doRipple
[color= #00bfff;]add[/color].[color= #00bfff;]b[/color] d4,d2
[color= #00bfff;]add[/color].[color= #00bfff;]b[/color] d4,d3
[color= #00bfff;]asl[/color].[color= #00bfff;]w[/color] [color= #ff0000;]#[/color][color= #ff0000;]2[/color],d4
[color= #00bfff;]adda[/color].[color= #00bfff;]w[/color] d4,a1
[color= #00bfff;]cmpi[/color].[color= #00bfff;]w[/color] [color= #ff0000;]#[/color][color= #ff0000;]$[/color][color= #ff0000;][color= #ff0000;]380[/color][/color],d4
[color= #00bfff;]blt[/color].[color= #00bfff;]s[/color] SwScrl_Water_doRipple
[color= #00bfff;]rts[/color]

This should at least improve performance a little if there is no or only little water on the screen.
I guess further performance improvement can be made if the water effect is applied and adapted to each zone's deformation separately.

I'll definitely try that out when I get home.
And yes, applying the effect directly instead of looping through the array a second time should improve performance considerably.
Edit: I just tried it and there was no noticable speed increase. Too bad, really, it seemed like a good idea and there's got to be something we can do.

View Postqiuu, on Jun 22 2008, 11:15 PM, said:

On a less related note, I noticed that in EHZ, the lowest two layers don't scroll as they are not affected by the deformation code. This can be fixed by appending something like
Syntax Highlighted Code: ASM
	[color= #00bfff;]move[/color].[color= #00bfff;]w[/color]	d4,(a1)+
[color= #00bfff;]move[/color].[color= #00bfff;]w[/color] d3,(a1)+
twice to the EHZ deformation routine.

Actually, I think that's the first thing I did with deformation after your post. Such an easy fix. I wonder how an error like that could make it into the final.
This post has been edited by MoDule: 23 June 2008 - 10:18 AM

#8 User is offline Alriightyman 

Posted 26 August 2008 - 10:56 AM

  • !!!!!!!!!!!!!!!!!
  • Posts: 318
  • Joined: 27-November 07
  • Gender:Male
  • Location:Largo, Fl
  • Project:Hmmmmmmmmmmmmm......
  • Wiki edits:5
Sorry about the bump. But I thought I'd add something to this. This will add that S3K type of ripple effect.
Deform_LZ_Data1:	
		dc.w 0, 0, 1, 1, 0, 0, 0, 0, 1, 0, 0, 0, 0, 1, 0, 0
		dc.w 0, 0, 0, 0, 0, 0, 0, 0, 0, 1, 0, 0, 1, 1, 0, 0
		dc.w 0, 0, 1, 1, 0, 0, 0, 0, 1, 0, 0, 0, 0, 1, 0, 0
		dc.w 0, 0, 0, 0, 0, 0, 0, 0, 0, 1, 0, 0, 1, 1, 0, 0
		dc.w 0, 0, 1, 1, 0, 0, 0, 0, 1, 0, 0, 0, 0, 1, 0, 0
		dc.w 0, 0, 0, 0, 0, 0, 0, 0, 0, 1, 0, 0, 1, 1, 0, 0
		dc.w 0, 0, 1, 1, 0, 0, 0, 0, 1, 0, 0, 0, 0, 1, 0, 0
		dc.w 0, 0, 0, 0, 0, 0, 0, 0, 0, 1, 0, 0, 1, 1, 0, 0
		dc.w 0, 0, 1, 1, 0, 0, 0, 0, 1, 0, 0, 0, 0, 1, 0, 0
		dc.w 0, 0, 0, 0, 0, 0, 0, 0, 0, 1, 0, 0, 1, 1, 0, 0
		dc.w 0, 0, 1, 1, 0, 0, 0, 0, 1, 0, 0, 0, 0, 1, 0, 0
		dc.w 0, 0, 0, 0, 0, 0, 0, 0, 0, 1, 0, 0, 1, 1, 0, 0
		dc.w 0, 0, 1, 1, 0, 0, 0, 0, 1, 0, 0, 0, 0, 1, 0, 0
		dc.w 0, 0, 0, 0, 0, 0, 0, 0, 0, 1, 0, 0, 1, 1, 0, 0
		dc.w 0, 0, 1, 1, 0, 0, 0, 0, 1, 0, 0, 0, 0, 1, 0, 0
		dc.w 0, 0, 0, 0, 0, 0, 0, 0, 0, 1, 0, 0, 1, 1, 0, 0
		dc.w $FFFE, 1, 2, 2, $FFFF, 2, 2, 1, 2, $FFFF, $FFFE
		dc.w $FFFE, $FFFE, 1, $FFFF, $FFFF, $FFFF, 0, $FFFE, 0, 0
		dc.w 0, $FFFE, 0, $FFFE, 2, 0, $FFFE, 2, 2, $FFFF, $FFFE
		dc.w $FFFE, 1, 2, 2, $FFFF, 2, 2, 1, 2, $FFFF, $FFFE
		dc.w $FFFE, $FFFE, 1, $FFFF, $FFFF, $FFFF, 0, $FFFE, 0, 0, 0
		dc.w $FFFE, 0, $FFFE, 2, 0, $FFFE, 2, 2, $FFFF, $FFFE, $FFFE
		dc.w 1, 2, 2, $FFFF, 2, 2, 1, 2, $FFFF, $FFFE, $FFFE
		dc.w $FFFE, 1, $FFFF, $FFFF, $FFFF, 0, $FFFE, 0, 0, 0
		dc.w $FFFE, 0, $FFFE, 2, 0, $FFFE, 2, 2, $FFFF, $FFFE
		dc.w $FFFE, 1, 2, 2, $FFFF, 2, 2, 1, 2, $FFFF, $FFFE
		dc.w $FFFE, $FFFE, 1, $FFFF, $FFFF, $FFFF, 0, $FFFE, 0, 0
		dc.w 0, $FFFE, 0, $FFFE, 2, 0, $FFFE, 2, 2, $FFFF, $FFFE
		dc.w $FFFE, 1, 2, 2, $FFFF, 2, 2, 1, 2, $FFFF, $FFFE
		dc.w $FFFE, $FFFE, 1, $FFFF, $FFFF, $FFFF, 0, $FFFE, 0, 0
		dc.w 0, $FFFE, 0, $FFFE, 2, 0, $FFFE, 2, 2, $FFFF, $FFFE
		dc.w $FFFE, 1, 2, 2, $FFFF, 2, 2, 1, 2, $FFFF, $FFFE
		dc.w $FFFE, $FFFE, 1, $FFFF, $FFFF, $FFFF, 0, $FFFE, 0, 0
		dc.w 0, $FFFE, 0, $FFFE, 2, 0, $FFFE, 2, 2, $FFFF, $FFFE
		dc.w $FFFE, 1, 2, 2, $FFFF, 2, 2, 1, 2, $FFFF, $FFFE
		dc.w $FFFE, $FFFE, 1, $FFFF, $FFFF, $FFFF, 0, $FFFE, 0, 0
		dc.w 0, $FFFE, 0, $FFFE, 2, 0, $FFFE, 2, 2, $FFFF, $FFFE
		dc.w $FFFE, 1, 2, 2, $FFFF, 2, 2, 1, 2, $FFFF, $FFFE
		dc.w $FFFE, $FFFE, 1, $FFFF, $FFFF, $FFFF, 0, $FFFE, 0, 0
		dc.w 0, $FFFE, 0, $FFFE, 2, 0, $FFFE, 2, 2, $FFFF, $FFFE

Also, at least in my hack, it seems to not have as much lag as the other ripple effect does. :words:

#9 User is offline jman2050 

Posted 26 August 2008 - 12:17 PM

  • Teh Sonik Haker
  • Posts: 614
  • Joined: 10-December 05
  • Wiki edits:4

Quote

I have no idea how s3 manages to do that with collapsing ledges, brakable floors, animated tiles, Sonic and Tails and generally lots of sprites on screen without any slowdown at all.


There are several, but one of the big reasons is the method by which it loads objects. I plan to explain that in tutorial form sometime in the near future, as it was applied to Megamix to eliminate most all lag.

#10 User is offline ICEknight 

Posted 26 August 2008 - 12:38 PM

  • Posts: 8111
  • Joined: 11-January 03
  • Gender:Male
  • Location:Spain
  • Wiki edits:18

View PostMoDule, on Jun 21 2008, 05:58 PM, said:

I guess I could compile a rom real quick with just the effect in. I'd just need a place to upload it to.
Please.

Even if it runs slower than it should, I'd really like to see by myself why that Sonic 1 effect was scrapped.

EDIT: Also, it looks like the effect in Sonic 3 (only used in Launch Base?) is somewhat different. Perhaps this one could be ported to Sonic 2... and Sonic 1?
This post has been edited by ICEknight: 26 August 2008 - 12:47 PM

#11 User is offline MathUser 

Posted 26 August 2008 - 12:42 PM

  • 3rd top wiki contributor
  • Posts: 1690
  • Joined: 09-November 05
  • Gender:Male
  • Wiki edits:14,865
I'd like to see it, with slowdown removed, but I wouldnt mind seeing it with slowdown either.

#12 User is offline jman2050 

Posted 26 August 2008 - 12:45 PM

  • Teh Sonik Haker
  • Posts: 614
  • Joined: 10-December 05
  • Wiki edits:4

View PostMathUser, on Aug 26 2008, 01:42 PM, said:

I'd like to see it, with slowdown removed, but I wouldnt mind seeing it with slowdown either.


I'm not sure if "removing" slowdown is such a simple matter...

#13 User is offline Tets 

Posted 26 August 2008 - 12:53 PM

  • one rude dude
  • Posts: 386
  • Joined: 26-December 05
  • Gender:Male

View Postjman2050, on Aug 26 2008, 01:17 PM, said:

I plan to explain that in tutorial form sometime in the near future, as it was applied to Megamix to eliminate most all lag.

I'm looking forward to this.

I think the S3K ripple effect looks better in ARZ, although the LZ effect still works well with CPZ.

#14 User is offline Rika Chou 

Posted 26 August 2008 - 04:03 PM

  • Adopt
  • Posts: 4945
  • Joined: 11-January 03
  • Gender:Not Telling
  • Location:CA US
  • Wiki edits:4

View Postjman2050, on Aug 26 2008, 06:17 PM, said:

Quote

I have no idea how s3 manages to do that with collapsing ledges, brakable floors, animated tiles, Sonic and Tails and generally lots of sprites on screen without any slowdown at all.


There are several, but one of the big reasons is the method by which it loads objects. I plan to explain that in tutorial form sometime in the near future, as it was applied to Megamix to eliminate most all lag.

I'm interested in this. Would probably help my hack out quite a bit.

#15 User is offline MoDule 

Posted 27 August 2008 - 07:29 AM

  • Posts: 305
  • Joined: 03-October 07
  • Gender:Male
  • Project:Procrastinating from writing bug-fix guides
  • Wiki edits:52

View PostAlriightyman, on Aug 26 2008, 05:56 PM, said:

Sorry about the bump. But I thought I'd add something to this. This will add that S3K type of ripple effect.
really big

Also, at least in my hack, it seems to not have as much lag as the other ripple effect does. :(

Ah, thanks. I had the darndest trouble finding it in the rom. I'll need to compare it to the guess I made based on screenshots later.


View Postjman2050, on Aug 26 2008, 07:17 PM, said:

Quote

I have no idea how s3 manages to do that with collapsing ledges, brakable floors, animated tiles, Sonic and Tails and generally lots of sprites on screen without any slowdown at all.


There are several, but one of the big reasons is the method by which it loads objects. I plan to explain that in tutorial form sometime in the near future, as it was applied to Megamix to eliminate most alllag.

Do tell. I was going to ask in the Megamix topic, but your post was already two pages back.


View PostICEknight, on Aug 26 2008, 07:38 PM, said:

View PostMoDule, on Jun 21 2008, 05:58 PM, said:

I guess I could compile a rom real quick with just the effect in. I'd just need a place to upload it to.
Please.

Even if it runs slower than it should, I'd really like to see by myself why that Sonic 1 effect was scrapped.

I'll see to it when I get home.

Edit: Done.
This post has been edited by MoDule: 27 August 2008 - 01:31 PM

  • 3 Pages +
  • 1
  • 2
  • 3
    Locked
    Locked Forum

1 User(s) are reading this topic
0 members, 1 guests, 0 anonymous users