Streets of Rage Amos demo

[DamienD]

Originally Posted by Brick Nash

Just to say, I noticed that there was a couple of bugs in the demo from watching Superman's much appreciated playthrough. The flashing enemy is a mystery as it's fine on my PC, but the other bug was that the enemies will get trapped in their "punch" state until hit again (something that I was working on but never finished). If the player scrolls the screen past them while this happens the enemies won't re-spawn as the remaining enemy will be off screen still punching away. I've fixed this by using alain's new source, so they will break out of punching if the player is outside the attack range.

Could somebody please compile Brick Nash's latest version with this "trapped in their punch state until hit again"?

I'll create a new .ADF afterwards.

Originally Posted by d4rk3lf

I will join Flat Earth Society, if no one continue developing this.

Paperwork is now is the post

[Dan]

Hi, here is it.

[DamienD]

Perfect, thanks Dan

I'll create a new .ADF once home from work today.

[DamienD]

Originally Posted by Dan

Hi, here is it.

Heya Dan,

Hmmm, something is up with this new compiled file.

Firstly, comparison of file sizes between the old and new:

OLD = 175624

NEW = 127780

I'm using your same files / folders as located here, but with the new game EXE: http://eab.abime.net/showpost.php?p=...9&postcount=90

...but just before the games starts it crashes with:

[Dan]

I took the Sourcecode from Brick Nash, and compiled it few times, but every time when i wanted to start the compiled file, it ended up in a Guru.

The guru happens because of some bank, which is saved with the sourcecode. (This is AmosPro bug)

So i loaded up the sourcecode, and removed almost all saved banks (part from one) from it, then compiled it.
This may explain the different filesize.

Anyway, i saved the sourcecode as ascii file, loaded it up in windows, and removed all of the unneeded files. (i hope i haven't missed anything, the intro and the game are starting)
The result is uploaded in the leveldata.zip

[DamienD]

Originally Posted by Dan

I took the Sourcecode from Brick Nash, and compiled it few times, but every time when i wanted to start the compiled file, it ended up in a Guru.

The guru happens because of some bank, which is saved with the sourcecode. (This is AmosPro bug)

So i loaded up the sourcecode, and removed almost all saved banks (part from one) from it, then compiled it.
This may explain the different filesize.

Anyway, i saved the sourcecode as ascii file, loaded it up in windows, and removed all of the unneeded files.
The result is uploaded in the leveldata.zip

Ok, so use this "leveldata.zip" plus your new game EXE hey?

[Dan]

Yes.

[DamienD]

Thanks Dan; all working now

I think I know why the size difference in the old vs new game EXE.

I now needed to include the "amos.library"; previously it must have been compiled within.

New file in The Zone!

[Dan]

Originally Posted by DamienD

I think I know why the size difference in the old vs new game EXE.

I now needed to include the "amos.library"; previously it must have been compiled within.

Hmm that's strange, the compiler shell is set up to include the amos.library ...

This was compiled with amos for windows version converted to kick/wb1.3 ...

Anyway, i'm glad that it is working now.


Edit: Ok i think i know what happened. I haven't started the Amos for windows (kick1.3) from it's configuration, but started my Amiga HD config, which had the Amos4Win hd assigned.
Then i started Amos4win from there.
And this loaded the config which does not add the Amos.library.

[Dan]

Hi,

Today i thoght to test the Amos tome map, provided with the sourcecode.

Practically, to program this correctly is different than in the theory.

I'v used the available code from the tome4 examples, the MapHandle.amos, and replaced the icons and the map data with the sora's level 1.

So far, so good.

Then, i thought, lets see how this will work with some bobs.
I made a 4 bob image bank, and then the troubles started.

The main question was, how to place the bobs, so that the flickering stops.

after few hours of trying, this is the best result which i have achieved with it.

Attached is an ADF with 2 executable files.

The MapHandle displays a scrollable level. Use the Joypad to scroll left and right.
Use up and down on the Joypad to adjust the speed of the scrolling.

The MapHandleBobTest has 3 figures (each made of 4 bobs) moving around.
Use the Joypad just like in the 1st demo.

Maybe someone more experienced with Amos programming knows how to achieve better results.

Both sourcecodes are included. They only need the tome4 extension (so far i know).



Edit: Looks like a better result can be achieved, updated adf will be uploaded soon in the next post.

[Samurai_Crow]

Tome is a bad choice for realtime scrolling. It has a good editor but the extension needs a total rewrite.

[Dan]

Today i have made few more testings with the Tome extension.
I studied the source code of other tome example demos a bit more.

I wondered how did they managed to make the scrolling flawless ?

And so i changed the previous (now deleted) sourcecode to match that of the sample game (well, the placement and the right bob commands).

And now it works very well. See it in the attached file.

The question now is, will it work that well in the SORA demo ?

[Retro1234]

Originally Posted by Dan

I took the Sourcecode from Brick Nash, and compiled it few times, but every time when i wanted to start the compiled file, it ended up in a Guru.

The guru happens because of some bank, which is saved with the sourcecode. (This is AmosPro bug)

So i loaded up the sourcecode, and removed almost all saved banks (part from one) from it, then compiled it.
This may explain the different filesize.

Anyway, i saved the sourcecode as ascii file, loaded it up in windows, and removed all of the unneeded files. (i hope i haven't missed anything, the intro and the game are starting)
The result is uploaded in the leveldata.zip

this bug means it will only compile and work on 68020+

a quick way around is go into direct mode and type Erase all then save this must be done before any apk files are loaded or created etc(if you run the program then press Ctrl-C straight away erase all - save)

a better way of scrolling is just create your map in Tome if you want, MrAmos did a better map editor then just use Peek or Deek to read the map and Screen Offset to hardware scroll instead of those tome Software scrolling commands.

also replace the main hero with a sprite instead of a bob - unfortunately this may need to be split into 2 but with give a great speed increase I.e sprites have virtually no impact on speed unlike Bobs - so you basically get one character on screen for free.

[Samurai_Crow]

But sprites are NOT free! They overlap bobs that are supposed to be in front of them meaning ALL the characters have to be sprites or ALL have to be bobs! You can't mix and match in this kind of game.

[Retro1234]

I meant speed wise, he doesn't have a priority system?

but I just thought of another thing sprites will scroll with the screen when hardware scrolling so you would have to move them manually alot but it won't matter because there so fast etc.

but yeah I forgot someone pointed out the sprite priority thing earlier there are ways round it but are a bit long and limiting but yeah sprites are Fast! bobs are slow!

[Samurai_Crow]

@Retro1234
The speed limit of the CPU is going to limit the frame rate more than the blitter. As long as you scroll smoothely it won't be as noticable if bobs render at 25 FPS.

[Dan]

Hi,
Last week i have started to program a simple map displayer code for the tome maps.

Today i took a bit of time to write a scrolling routine.

I thought, if i try to program this in Amos, it would take ages to debug and to do it right.

So here it is, attached are 2 programs for the PC.

The ScrollingTheroy.exe demonstrates how the scrolling is builded up. It uses simple squares with numbers to do this.

The SoraLVL-Theory.exe uses the map data and the 'icons' to build up the level.

There are 2 demonstrations here. One is simple map scrolling, by displaying the 20x13 map data on screen.
The other is made with the ScrollingTheory code. The space key makes it scroll until the level end.

Start the SoraLVL-Theory with debug parameter to see how the tiles are drawn.

Soon ill try to code this in Amos Pro. Unless someone else likes to do it.

Here is the BlitzBasic (PC) code of it:

If CommandLine$()="debug"
	debug=1
Else
	Debug=0
EndIf
If debug=1 Then
	Screen (672,208,1)
Else
	Screen (320,208,2)
EndIf
Local imgScreen0
Local tiles=LoadImage("L116x16_Tiles.png")
Dim imgTile(240)
Grab=CreateImage(16,16)
;20*12
SetBuffer ImageBuffer(tiles)
z=0
For y=0 To 11
	For x=0 To 19
		GrabImage grab,x*16,y*16
		imgTile(z)=CopyImage(grab)
		z=z+1
	Next
Next
FreeImage Grab

SetBuffer BackBuffer()

oFile=ReadFile ("L1_16x16_TOP.map")
a=  ReadByte(oFile)
a1= ReadByte(oFile)
w= hex2dec(Right$(Hex$(a),2) +  Right$(Hex$(a1),2))-1
a=  ReadByte(oFile)
a1= ReadByte(oFile)
h= hex2dec(Right$(Hex$(a),2) +  Right$(Hex$(a1),2))-1
Print h
Print w

Dim Map(w,h)

For y=0 To h
	For x=0 To w
		Map(x,y)=ReadByte(oFile)
	Next
Next
CloseFile oFile
st=0
mapw=320/16
SetBuffer BackBuffer()

;AppTitle "Map drawing 20x12 - Arrow Left and Right to move, esc for next test"
;Repeat
;	Cls
;	For y=0 To 12
;		For x=0 To mapw
;			DrawBlock imgTile(Map(x+st,y)),x*16,(y*16)
;		Next
;	Next
;	If KeyDown(205) Then st=st+1 
;	If KeyDown(203) Then st=st-1
;	
;	If st<0 Then st=0
;	If st=>(w-mapw) Then st=w-mapw
;	Flip
;	Delay (25)
;Until KeyDown(1)
;While KeyDown(1)
;Flip()
;Delay 1
;Wend
;FlushKeys()
;Delay 500

Global wMap=21
imgScreen0=CreateImage((42)*16,208)

;Pre-render the first part of the screen
SetBuffer ImageBuffer(imgScreen0)

For y=0 To 12
	For x=0 To wMap
		DrawBlock imgTile(Map(x,y)),x*16,(y*16)
	Next
Next

;Variable assignment
st=0
Local drawt=0
Local LeadPos=21
Local LeadPosY=0
Local LeadNR=21
Local TrailPos=-1
Local oldtbpos

Repeat
	AppTitle ("(In)finite Scroll " +pos + " / "+bpos+" / "+LeadNR+"  Hold space to advance, esc to end")
	SetBuffer ImageBuffer(imgScreen0)				;Simulating a Screen using an image
	bpos=pos/16
	
	If KeyDown(57) Then 
	pos=pos+1
	If LeadNR=192 And pos>288 Then pos=288
	EndIf
	
	If bpos>21 Then bpos=0 : drawt=0 : LeadPos=21 : TrailPos=-1 : pos=0
	
	If LeadNR<192 Then
		If bpos+21=LeadPos And drawt=0 And oldtbpos<>LeadPos Then drawt=1 :  LeadPosY=0 : oldtbpos=LeadPos 
		If drawt=1 And LeadPosY<13 Then 
			If LeadPos<=41 Then DrawBlock imgTile(Map(LeadNR,LeadPosY)),LeadPos*16,(LeadPosY*16)
			If TrailPos=>0 And TrailPos<21 And bpos>0 				;Trailing squares are enabled to draw
				DrawBlock imgTile(Map(LeadNR,LeadPosY)),TrailPos*16,(LeadPosY*16)
			EndIf
			LeadPosY=LeadPosY+1
			If LeadPosY=13 Then drawt=0 : LeadPos=LeadPos+1 : LeadNR=LeadNR+1 : TrailPos=TrailPos+1
		EndIf
	EndIf	
	
	SetBuffer BackBuffer()
	Cls
	If debug=0 Then
		DrawBlock imgScreen0,0-(pos),0
	Else
		DrawBlock imgScreen0,0,0
	EndIf
	Delay 1
	Flip(1)
    
Until KeyDown(1)



Function Screen(x,y,zoom#=1)
	If x<64 Then x=64
	If y<64 Then y=64
    bits=32
	Graphics x*zoom,y*zoom,bits,2
	Graphics x,y,bits,3
End Function

Function hex2dec%(hex_number$)
; Converts the supplied hex number into a decimal number
; If hex_number isn't a valid hex number, then returns -1
; written by Matt Burns (Blu_Matt / matt at blis co uk)
	Local the_hex$=Upper(Trim(hex_number$))		; the hex number
	Local base_power%=0							; the current base power
	Local base%=16								; the base to convert from
	Local the_dec%=0							; the decimal representation
	Local chars%=0
	Local hex_length%=Len(the_hex$)				; current length of the hex
	If Left(the_hex$,1)="$" Then 				; removes any leading "$"
		the_hex$=Right(the_hex$,hex_length%-1)
	EndIf
	hex_length%=Len(the_hex$)					; current length of the hex
	Local chars_left%=hex_length%				; current number of chars left
	Local hex_left$=the_hex$					; current hex left
	Repeat
		current_hex$=Right(hex_left$,1) 		; gets the current hex char
		If ((Asc(current_hex$)>=Asc("0")) And (Asc(current_hex$)<=Asc("9"))) Then
			hex_dec%=current_hex$				; digit 0-9
		ElseIf ((Asc(current_hex$)>=Asc("A")) And (Asc(current_hex$)<=Asc("F"))) Then
			hex_dec%=Asc(current_hex$)-55		; char A-F
		Else
			Return -1 							; found an illegal character, aborting...
		EndIf
		the_dec%=the_dec%+((base%^base_power%)*hex_dec%)	; add the local hex digit to the total
		base_power%=base_power%+1				; increase the base power
		chars_left%=chars_left%-1				; reduce the number of chars left
		hex_left$=Left(hex_left$,chars_left%)	; sets the remainder
	Until chars_left%=0
	Return the_dec%								; return the result
End Function
 
;~C#Blitz3D

[Retro1234]

basically all the Map editors from that era normally used the same or similar layout Tame and Tume used for commercial games.

You can even Cut the Map of a Commercial game into black file and then edit it with Tome or one of the other map editors etc.

Tome was just the Amos version of any map editor the extra Amos commands that came with Tome weren't very good and you can scroll faster without them.

this link is the basics of how to do endless scrolling

http://eab.abime.net/showthread.php?t=81634

simply when you scroll past the end of the screen I.e X 1024 the screen wraps back around to the beginning and you start pasting tiles at location 0,0+1 again
but you have to move down Y 1 pixel.

idrougge also wrote another of a scrolling technique this of-course can work horizontally http://eab.abime.net/showthread.php?t=80646

good luck

at a quick guess looking at your code and iirc the oFile=ReadFile would be Bload and the to read the data is command Deek you don't need to load it into a Dim variable because it's already in memory with Bload .

[Dan]

Hi,
today i took the MapTest from one of the previous posts, and removed all of the tome commands from it, and added the Scroll test code from my last post.

The attached file is the result.

Press space to move the level. The sourcecode is attached too.
The bobs are now repositioned to stay on the screen, there are 12 of them (4 per char)

[Dan]

Yes, today i thought, i'v done the previous test, lets try it with the full (demo) game.

This is a quick hack, with the new scroller code.

You can scroll a bit, and see the how it would look like, but ultimately the main character will disappear from the screen.

Included are 3 tests, all are the same just the Autoback setting is different.
Therefore to start the games either start them with their icon or from the CLI, type:
Autoback0, Autoback1 or Autoback2

each has its own advantage/disadvantages/bugs.

All 3 games will end in a Guru if you press the ctrl c button, this must be due to some Amos4win extension (i guess).