S3: The Sensational Santuci Sisters [CANCELLED]

[+Gemintronic]

Thanks for the help GroovyBee. Apparently bB doesn't like the number 10 for complicated arithmetic statements. I separated out the multiply by ten and it stopped bugging out.

 

tempvar = ((rand&7)+1)

player1y = tempvar*10

 

You suggestion to look at the assembly gave me the hint that it just wasn't parsed correctly.

 

In other news I just figured out how to avoid artifacting when rapidly scrolling left and right. Now I can safely make a Metroid clone. Basically, you cannot immediately scroll in the opposite direction when sitting on the same x/y coordinate. Sprybug gives the player some leeway to move a little on the screen instead of being fixed in the middle. I *think* this is how he avoids this issue.

[+GroovyBee]

I'd better explain that code . The routine randomize is called and leaves a value in the accumulator. After bitwise ANDing with 7, clearing carry and adding one the value in the accumulator is shifted left twice which multiplies it by 4. The contents of Areg are then added (so this should be the value in the accumulator before the x 4). So the accumulator is now 5 times the value "returned" from the randomize call. The accumulator is then shifted left once which gives and effective multiply of 10. Then a shift right gets you a divide by 2 before setting carry and subtracting 30. In pseudo code it would be :-

 

a=(rand&7)+1
val=(((a*4)+a)*2)/2)-30

[+GroovyBee]

Thanks for the help GroovyBee.

 

No worries,

 

Apparently bB doesn't like the number 10 for complicated arithmetic statements. I separated out the multiply by ten and it stopped bugging out.

 

Personally I'd report it as a bug in the bB bugs thread.

[+Random Terrain]

Do you think you might need to use this?

 

www.randomterrain.com/atari-2600-memories-batari-basic-commands.html#multiplication

   include div_mul.asm

[+GroovyBee]

Calling a generic multiply routine for a value of 10 will be much slower than the simple shift and add method bB generated. Even though bB didn't generate valid code in this instance theloon has a workaround to go forward with.

[+Gemintronic]

Do you think you might need to use this?

 

www.randomterrain.com/atari-2600-memories-batari-basic-commands.html#multiplication

 include div_mul.asm

 

I double checked the source I posted at the beginning of this topic. It does indeed have the div_mul.asm at top. Removing that asm library generates the same error. Like GroovyBee said, I guess I've got a workaround for now. Thanks for the sanity check though! It's always good to double check the basics when things get too complicated.

 

Now I have to decide if I want to refactor my code now that I have an idea to make scrolling westwards work without artifacts.

[bogax]

re GroovyBee's comment about faster than calling a generic multiply,

if you use *4*4 or *2*8 instead of *16 bB will use shifts instead of caling

the multiply routine.

 

There's other optimizations you could make also. (but they might mess

with the clarity of your code)

[+Gemintronic]

re GroovyBee's comment about faster than calling a generic multiply,

if you use *4*4 or *2*8 instead of *16 bB will use shifts instead of caling

the multiply routine.

 

There's other optimizations you could make also. (but they might mess

with the clarity of your code)

 

Clarity of my code? Is that like the translucency of mud?

 

I'm not sure how I could get a random number that would place the object in multiples of 10 with those operations.

 

This seems to be the best useable method so far:

 

tempvar = ((rand&7)+1)

player1y = (tempvar*10)-30

 

It sometimes goes off screen to make object placement a little more spaced out. It also remains two blocks above the usual ground level so Barb (the player) can almost always hit the block.

 

In other news I tried my idea to stop artifacts when scrolling left to no good result. So, I guess this remains a traditional Maryo type scroller after all

[bogax]

I'm not sure how I could get a random number that would place the object in multiples of 10 with those operations.

 

This seems to be the best useable method so far:

 

tempvar = ((rand&7)+1)

player1y = (tempvar*10)-30

 

I didn't mean that particular bit I meant elsewhere where there's a mutiply by 16

specifically, this line in the print_screenright routine:

 

if change = 32 then worldx = rand*16 : change = 0 else change = change + 1

Edited December 14, 2012 by bogax

[+Gemintronic]

Build #25 has passable collision detection. I tried merging the scrolling code into my earlier effort into 4 way scrolling without success. Instead, merging the collision detection code into the newer engine worked "better". Still, I'm having issues keeping Barb (player 1) out of solid blocks.

 

I. hate. collision. detection.

[+Gemintronic]

The current build now has its first enemy! Enter the Red Helmet Demon!!

 

I try a little harder to simulate an event driven system as far as coding goes. Each object now has creation, step and collision events - or at least related sections within sub-routines.

[+Gemintronic]

Okay fellas. Build #31 has a few changes.

 

1. New enemy type! The Badbees can shoot forward one to three at a time!

2. Barb (player 1) Starts out from her house.

3. Forward scrolling movement has been slowed down at bit.

 

Please chime in if you guys have comments about the gameplay so far =)

[+Random Terrain]

I'm going to see if my collision prevention/detection crap will work with this. Don't know how long it will take me, though.

[+Random Terrain]

How are you doing your collision detection with the playfield? I'm having a hard time finding it.

[+Gemintronic]

I'm going to see if my collision prevention/detection crap will work with this. Don't know how long it will take me, though.

 

I'll definitely have to check out your example, again. I'd like Barb and Deb to shoot some sort of projectile weapon.

 

The basic jist of my current collision detection code is to check one or two playfield pixels ahead in the direction the player is moving.

gravity
rem calculate the player x/y coodinate into the equivelent playfield pixel coordinates
tempvar = (player0x/4)-4
tempvar2 = (player0y/10)
rem Check for a playfield pixel at said coordinates and skip falling down if needed
if pfread(tempvar, tempvar2) then goto skip_gravity
rem Check the next horizontal playfield pixel for collision and skip falling if needed
tempvar = (player0x/4)-3
if pfread(tempvar, tempvar2) then goto skip_gravity
rem Pull the player down and make onground = 1 to confirm player is standing
player0y = player0y + 1
onground = 1
return
skip_gravity
rem Make onground = 0 to confirm player is mid-air
onground = 0
return

 

It's not perfect in that sometimes you can inject yourself into the middle of a brick. This happens usually when you rush forward into a pit and catch the edge of the ground just after the pit. Also, the bouncing and extra hang-time when you bump into a brick above.

 

Are these the things that made you want to explore retrofitting in your collision detection routines?

 

Also, build #33 makes it possible to crouch by pressing down!

[+Random Terrain]

Are these the things that made you want to explore retrofitting in your collision detection routines?

 

Yeah, I keep getting inside of blocks instead of being on top. If you feel like doing a test to see if you can adapt my collision prevention/detection code, that would be nice because I'm working on a new little section for the bB page right now.

[+Gemintronic]

Yeah, I keep getting inside of blocks instead of being on top. If you feel like doing a test to see if you can adapt my collision prevention/detection code, that would be nice because I'm working on a new little section for the bB page right now.

 

Okay, build #34 should be a bit better. Barb (player 1) now has a "walking gait" as a side effect of the adjusted collision code.

 

UPDATE: Build #35 removes the mid-air floaty de-bounce when you hit a brick from above. Although more aesthetically pleasing the player has less of an advantage when jumping to avoid a passing monster.

[+Random Terrain]

That's better. Still need to fix the head bumping part so it will look more like this guy when he bangs his head:

 

www.atariage.com/forums/topic/179473-fake-gravity-platformer-test/

[+Gemintronic]

That's better. Still need to fix the head bumping part so it will look more like this guy when he bangs his head:

 

www.atariage.com/forums/topic/179473-fake-gravity-platformer-test/

 

Didn't have time to add more animation. I did adjust the head bumping jitter though. I also made the jumping arc a little more smooth. Also, the "walking gait" caused some unintentional unresponsiveness to triggering a jump that needed to be corrected. See build #35a. Thanks again R.T.!

[KevinMos3]

This is really shaping up. Once you get the running/jumping worked out, I think it will be a ton of fun. This is one I'll definitely be watching closely and looking forward to.

[Impaler_26]

I just played this game a bit and i think it could become a really nice platformer. The scrolling is already quite good IMO but the player should really fall slower after jumping. Looking forward to see how this one turns out.

[+Gemintronic]

I'm having a hard time compiling this game with recent versions of bB.

 

This is the message log:

Compile started at 9/9/2013 3:42:42 PM
Compiling C:\BatariBASIC\Projects\S3\sss36.bas
2600 Basic compilation failed!
LINE --> complex condition detected
Post compilation files deleted

Has anyone else experienced this?

 

I've tried rearranging where I put include div_mul.asm to no avail.

[bogax]

just an additional observation
(at this point I don't remember
if it's nonsequitor)

you're talking about doing this:

tempvar = ((rand&7)+1)
player1y = (tempvar*10)-30

so if rand returns, say, 1

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

is that really what you want?

[+Random Terrain]

The bB page says:

 

http://www.randomterrain.com/atari-2600-memories-batari-basic-commands.html#inline

 

Using inline will insert the asm code exactly where the statement is, so doing so at the wrong place (such as at the beginning of your program) will probably cause your game to crash.

 

 

Are you putting it where it should go in your program?

[+Random Terrain]

Think I found the problem. You have this in your code:

__

if player0x = 77 gosub print_screenright else player0x = player0x + 1

__

 

It should be this:

__

if player0x = 77 then gosub print_screenright else player0x = player0x + 1