45 replies to this topic

[theloon]

Here's a scrolling engine for The Sensational Santuci Sisters (S3).  I intend to pay homage to The Great Giana Sisters.  Right now it's just one level about 256 screens wide.  Every game gets a different map layout!.  pfhscoll.asm is needed to compile the program.

Barb and Deb must search the Dream World for clues to their Grandmothers Secret Spaghetti Sauce!

Left and right to move.  Fire to jump.  Press down to crouch.  Falling into holes in the ground will kill you.  Star blocks are 100 points.  Red Helmet Demons and Badbees kill you on contact!

Advanced technique:  You can sometimes reach higher by catching the edge of a brick and jumping again when moving forward.

Attached Thumbnails

• 

Attached Files

•  pfhscroll.asm   5.67K   35 downloads
•  sss36.bas.bin   4K   116 downloads
•  sss36.bas   12.03K   48 downloads

Edited by theloon, Thu Dec 20, 2012 3:32 PM.

[theloon]

Tried to figure out how to expand SeaGtGruffs second horizontal scrolling demo from 64 bit playfield maps without success.  For now I'll continue working on my own solution as seen above.

Edited by theloon, Fri Aug 24, 2012 2:33 PM.

[SeaGtGruff]

theloon, on Fri Aug 24, 2012 6:20 AM, said:

Tried to figure out how to expand SeaGtGruffs second horizontal scrolling demo from 64 bit playfield maps without success.  For now I'll continue working on my own solution as seen above.

That demo was coded kind of stinky, since I had problems getting certain statements to work and had to program around the problems. I should work up a better demo, one that doesn't bother with trying to scroll different rows at different speeds or in different directions. Also, I might be able to make a different version of the function that's intended to scroll the entire screen within a large map.

[Mr SQL]

Very cool Loon! Is this the bit project you were working on?

[theloon]

@SeaGtGruff:  I had a mind block with your second demo.  I just couldn't see how to expand the scrolling info from 64-bits wide to the full DATA statement limit of 256 bytes.  I went ahead and tried my own solution but it isn't as elegant as yours.  In particular one can SEE and easily edit the level data in your second example.  I'm hoping you find time for a little more in the scrolling department.  It really is a brilliant library!

@Mr. SQL:  I'm supposed to be working on a Rogue-like game called "Destiny" using BatariBASIC.  Or continuing my stuggle to make a four-way scrolling engine for the Sega Genesis.  My success in converting Batari's early Rally-X clone to the new compiler lead me to take interest in four-way scrolling on the 2600 again.  You and bogax left amazing help for me trying to use arrays as binary arrays.  My silence in that department is merely lack of mental agility.  In order to ask further questions I need to understand what's already been said better

Strangely, I whipped up this example in a couple of hours.  I reduced the playfield to 8 visible rows and used each element of a DATA statement as a column of blocks.  I also resticted movement to the horizontal plane so I wouldn't have to access the array in a complicated way.

Edited by theloon, Sat Aug 25, 2012 3:16 PM.

[Mr SQL]

theloon, on Sat Aug 25, 2012 3:12 PM, said:

@Mr. SQL:  I'm supposed to be working on a Rogue-like game called "Destiny" using BatariBASIC.  Or continuing my stuggle to make a four-way scrolling engine for the Sega Genesis.  My success in converting Batari's early Rally-X clone to the new compiler lead me to take interest in four-way scrolling on the 2600 again.  You and bogax left amazing help for me trying to use arrays as binary arrays.  My silence in that department is merely lack of mental agility.  In order to ask further questions I need to understand what's already been said better

Strangely, I whipped up this example in a couple of hours.  I reduced the playfield to 8 visible rows and used each element of a DATA statement as a column of blocks.  I also resticted movement to the horizontal plane so I wouldn't have to access the array in a complicated way.

Nice effect and it's fast, interesting approach!  Rogue on the Sega Genesis would be fantastic, I enjoyed that game on the CoCo, think it was one of the few OS-9 games I actually liked

What do you use for Genesis dev, that Tiny BASIC compiler or C?

[theloon]

I should be using SGDK but my BASIC background (and lazy programming) keeps me using BasiEgaXorz.  QuickBASIC is dear to my heart and BEX does a good job simulating it.

Batari intended bB to be a gateway for assembly.  BasiEgaXorz simply needs asm to be a complete product.  Unfortunatly asm isn't in my blood - not even on an easy peasy 68k.

Rogue-likes have been done for the Genesis - see Fatal Labyrinth.  I was thinking of turning Adventure into a 2600 Rogue-like.  On the Genesis I'm exploring either a platform game or RPG done in character graphics like the MZ-700 or Aquarius.

Edited by theloon, Sat Aug 25, 2012 8:21 PM.

[Mr SQL]

loon,
that's awesome you are doing this project on both platforms. Big difference in resources!

I've been meaning to check out BEX; I remember seeing another Basic compiler for the Genesis too but not sure what it is called.

Why does BEX need asm, is it missing functionality? bB feels like a cross between Tiny BASIC and asm (things wrap around and fall through, etc); from our discussions on your bit project I don't think you'd have any trouble switching to asm

[theloon]

Coming from you I'll seriously reconsider my aversion to assembly.  Groovybee also suspects C isn't beyond my grasp.  Maybe the leap isn't too far away after all!
I got a little spoiled by 4GLs like FoxPro and PowerBuilder.  I think that's part of my problem

BEX has basic tone generation commands but nothing built in for complex music synthesis or digital sound.  The z80 requires proper initalisation which cannot be done with built in commands.  Tile drawing commands are not optimized and don't have proper bounds checking - kind of the worst of both worlds:  usually you expect fast and unchecked or slow and safe.  My last scrolling engine had a horrible bug in collision because somehow the tile drawing command was overwriting my collision map.

If you think in QuickBASIC terms/limitations BasiEgaXorz is quite good.  If you think in using it as a scaffold to put your assembly routines in it's still okay wtih a few quirks.  If you're a BASIC fan and want to harness all that Sega Powa! then you might be disappointed.

I was thinking about posting a bB to BasiEgaXorz tutorial series someday.  Wasn't sure if bB programmers would be interested.

Edited by theloon, Sat Aug 25, 2012 11:02 PM.

[theloon]

New version that scrolls both left and right on first post.  Trouble is you can get duplicate columns of pixels by jittering the controls rapidly left and right.  Also, this demo is using single playfield pixels so level data is reduced to 8 screens long.

I'm going to see if SeaGtGruffs scrolling library is any faster in later revisions.  Also, I may have to go Super Mario style (no leftward scrolling) to make the levels procedural to save storage space.

[Random Terrain]

Is this the same thing Sprybug is doing or did he discover another method?

[theloon]

Random Terrain, on Wed Dec 12, 2012 8:59 AM, said:

Is this the same thing Sprybug is doing or did he discover another method?

I haven't double checked the sources Sprybug has posted.  I suspect we are both reinventing the wheel in different ways.  My method stores levels in 8 pixel vertical strips - one 8 bit value per column.  With one normal DATA statement you can have 8 screen wide levels or 16 if you double up the pixels for each block.

UPDATE:  SeaGtGruffs scrolling library seems a bit faster.  Good stuff!

[theloon]

Meh.  There can be 16 different screen types per level.  Levels can be 256 screens wide.  Trouble is, the rand function just doesn't seem to be random enough (but it still needs a static seed to stay the same level each time).  If you scroll right you can see not all the screen types are being used.  What am I doing wrong?  Code and binary are at top if y'all care to have a look-see.

[Random Terrain]

Are you using  dim rand16 = z?

[theloon]

Random Terrain, on Wed Dec 12, 2012 3:45 PM, said:

Are you using  dim rand16 = z?

Doesn't seem to do much when I add that.  If you run the binary attached to the first post you'll see what I mean about the lousy distribution.

[Random Terrain]

theloon, on Wed Dec 12, 2012 4:29 PM, said:

Doesn't seem to do much when I add that.  If you run the binary attached to the first post you'll see what I mean about the lousy distribution.

I just looked at your code. It wouldn't help at all since you are using  rand = 253. You're always going to get that 253 pattern.

[theloon]

The latest change "fixes" the sub-par distribution I was getting.  The main gist was instead of relying on the worldx{5} to trigger a new screen I had to use up a separate variable called "change".  Both methods were SUPPOSED to change the screen layout every 64 pixels of eastward movement.  I still don't quite understand why the randomness was lame with one method over the other.

Also, tweaked the Santuci Sister sprite.  You can now hit reset to change the random seed for a different level.

At this point the only "data" needed to produce a new level is reseeding the rand function.  Which means I could go up to 256 platforming levels without wasting much space.  In reality this means I have to "design" levels like in Pitfall.  Basically testing every random seed value between 0-255 for good levels.

[theloon]

Okay.  With this build I start to incorporate item/enemy placement.  Right now the dummy object is the Giana Sister equivalent of a coin block.  The retarded thing is, I can't multiply by 10!!!  20?  Sure!  11?  Yep!  10 causes the compiler to BARF.  The best I can do is:

player1y = ((((rand&7)+1)*20)/2)-30

Which seems overly complicated.  All I want is to place the coin block somewhere on the screen high enough for Barb (Santuci sister #1) to always hit.  The coin block seems to be 10 pixels and or display coordinates big.

[GroovyBee]

theloon, on Fri Dec 14, 2012 7:10 AM, said:

10 causes the compiler to BARF

What errors/warnings do you see?

[theloon]

GroovyBee, on Fri Dec 14, 2012 7:21 AM, said:

What errors/warnings do you see?

With:  player1y = ((((rand&7)+1)*10)/2)-30

[12/14/2012 8:30:41 AM] saving C:\BatariBASIC\Projects\pfhscroll\mygtscroll12.bas succeeded.

Compile started at 12/14/2012 8:30:42 AM
Compiling C:\BatariBASIC\Projects\pfhscroll\mygtscroll12.bas
DASM V2.20.07, Macro Assembler (C)1988-2003
	 bytes of ROM space left
	 1733 bytes of ROM space left
	 1733 bytes of ROM space left
	 1733 bytes of ROM space left
--- Unresolved Symbol List
pfcenter				 0000 ????		 (R )
kernelmacrodef		 0000 ????		 (R )
Areg					 0000 ????		 (R )
pfhalfwidth			 0000 ????		 (R )

Fatal assembly error: Source is not resolvable.
Errors were encountered during assembly.
2600 Basic compilation completed.
Compilation completed at 12/14/2012 8:30:43 AM
view output file:///C:/BatariBASIC/Projects/pfhscroll/bin
Post compilation files deleted

[GroovyBee]

Any chance of looking at the assembly language produced that is causing the problem? A search on Areg looks to be a likely candidate.

[theloon]

GroovyBee, on Fri Dec 14, 2012 7:41 AM, said:

Any chance of looking at the assembly language produced that is causing the problem? A search on Areg looks to be a likely candidate.

I'm not quite sure how to do that.  The latest source plus SeaGtGruffs scrolling library is posted at top..

UPDATE:  Is it this file?

Attached Files

•  mygtscroll12.bas.asm   45.42K   33 downloads

[GroovyBee]

What files are in the pfhscroll directory after the compilation?

[theloon]

GroovyBee, on Fri Dec 14, 2012 7:47 AM, said:

What files are in the pfhscroll directory after the compilation?

I put the yaddayadda.asm file in my last post.  I searched on Areg and it looked like it had something to do with the rand function.  I changed my sub-routine to use a variable instead of rand and got a compiler error still.   Changed from "player1y = ((((rand&7)+1)*10)/2)-30" to "player1y = ((((change&7)+1)*10)/2)-30"

[GroovyBee]

Seems to look reasonable

.L086 ; player1y = ( ( ( ( rand & 7 ) + 1 ) * 10 ) / 2 ) - 30

; complex statement detected
jsr randomize
AND #7
CLC
ADC #1
asl
asl
clc
adc Areg
asl
lsr
SEC
SBC #30
STA player1y

I can't find Areg defined in that assembly language file and randomize doesn't write to Areg either (as far as I can see at a quick glance).