Wall/Object Collision and Multiple Screen Help

[Arcade]

I think I'm more confused now

 

Does using xprevious and yprevious allow for collision along walls/playfield objects? Also, will this help allow a character to move to another playfield without using code to have 100% playfield collision?

[+Gemintronic]

I think I'm more confused now

 

Does using xprevious and yprevious allow for collision along walls/playfield objects? Also, will this help allow a character to move to another playfield without using code to have 100% playfield collision?

 

For reference here is the example again:

http://atariage.com/forums/topic/211997-wallobject-collision-and-multiple-screen-help/#entry2749964

 

It's something I carried over from Game Maker on the PC. They have built in variables for the previous x/y coordinates of objects. In this case I simulate that by using up two variables and name them xprevious and yprevious. At the start of our main loop I put the players x and y coordinate into xprevious/yprevious. Immediately after the drawscreen command I check for collisions and put the player back to his last collision-free coordinates.

 

That example does not have any code to transition from one screen to another. That would be a different example.

 

Note that Random Terrain doesn't like this example because the player doesn't "slide" off walls. You collide with the playfield and stay there until you back out.

[+Gemintronic]

Here is an uncommented "example" of changing rooms using ON GOTO statements.

 

Basically, when the player reaches the bounry of the screen you set which direction he should pass (left, right, up down) and then go to the change_room routine.

check_boundaries

 if player0x = 0 then player0x = 152 : direction = _left : goto change_room
if player0x = 153 then player0x = 1 : direction = _right : goto change_room
if player0y = 17 then player0y = 87 : direction = _up : goto change_room
if player0y = 88 then player0y = 18 : direction = _down : goto change_room

The change_room routine checks to see what room you are currently in and jumps to that specific section of code.

change_room
on current_room goto room0 room1 room2 room3 room4 room5 room6 room7 room8

Each rooms code now has a section that decides which room to change to based on the direction you exited the current room.

room0

on direction goto draw_room0 draw_room2 draw_room1 draw_room6 draw_room3

Finally, we set the current room and draw it.

draw_room0
current_room = 0
pfcolors:
$0E
$0C
$0A
$08
$0E
$08
$0C
$0A
$0E
$0A
$08
end
playfield:
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
X..............X................
X............XXX................
X...........X..X................
X..............X................
X..............X................
X..............X................
X..............X................
X..............X................
X...........XXXXXX..............
X...............................
end
goto after_check_boundaries

roomchange.bas

[bogax]

Look up tables are easy and fun

 

look up your room:

 

check_boundaries
if player0x = 0 then player0x = 152 : direction = _left : goto change_room
if player0x = 153 then player0x = 1 : direction = _right : goto change_room
if player0y = 17 then player0y = 87 : direction = _up : goto change_room
if player0y = 88 then player0y = 18 : direction = _down : goto change_room

after_check_boundaries
if counter{4} then REFP0 = 8
drawscreen
goto main

change_room
current_room = current_room * 4 + direction - 1
current_room = room_data[current_room]
on current_room gosub drw_rm0 drw_rm1 drw_rm2 drw_rm3 drw_rm4 drw_rm5 drw_rm6 drw_rm7 drw_rm8
goto after_check_boundaries


rem rows are rooms columns are directions

data room_data
2, 1, 6, 3
0, 2, 7, 4
1, 0, 8, 5
5, 4, 0, 6
3, 5, 1, 7
4, 3, 2, 8
8, 7, 3, 0
6, 8, 4, 1
7, 6, 5, 2
end

 

compute room:

 

check_boundaries
if player0x = 0 then player0x = 152 : room_col = sub[room_col] : goto change_room
if player0x = 153 then player0x = 1 : room_col = add[room_col] : goto change_room
if player0y = 17 then player0y = 87 : room_row = sub[room_row] : goto change_room
if player0y = 88 then player0y = 18 : room_row = add[room_row] : goto change_room

after_check_boundaries
if counter{4} then REFP0 = 8
drawscreen
goto main

change_room
current_room = room_row * 2 + room_row + room_col
on current_room gosub drw_rm0 drw_rm1 drw_rm2 drw_rm3 drw_rm4 drw_rm5 drw_rm6 drw_rm7 drw_rm8
goto after_check_boundaries

data sub
2, 0, 1
end

data add
1, 2, 0
end

 

lookup_room.bas

 

compute_room.bas

 

edit: the returns should have been

return thisbank (now fixed)

 

another edit:

 

another option

 

check_boundaries
if player0x = 0 then player0x = 152 : current_room = subc[current_room] : goto change_room
if player0x = 153 then player0x = 1 : current_room = addc[current_room] : goto change_room
if player0y = 17 then player0y = 87 : current_room = subr[current_room] : goto change_room
if player0y = 88 then player0y = 18 : current_room = addr[current_room] : goto change_room

after_check_boundaries
if counter{4} then REFP0 = 8
drawscreen
goto main

data subc
2, 0, 1
5, 3, 4
8, 6, 7
end

data addc
1, 2, 0
4, 5, 3
7, 8, 6
end

data subr
6, 7, 8
0, 1, 2
3, 4, 5
end

data addr
3, 4, 5
6, 7, 8
0, 1, 2
end

change_room
on current_room gosub drw_rm0 drw_rm1 drw_rm2 drw_rm3 drw_rm4 drw_rm5 drw_rm6 drw_rm7 drw_rm8
goto after_check_boundaries

 

 

direct_lookup.bas

Edited May 12, 2013 by bogax

[Arcade]

Ah thank you both so much! I'll def have to try those out!

[SeaGtGruff]

Ah thank you both so much! I'll def have to try those out!

You can also look at a demo I posted a while back called "move_around_rooms.bas"-- you should be able to find it in this forum by searching for that program name. It's sort of like bogax's "lookup_room.bas" except each direction has its own data matrix so you can have up to 256 rooms if you want.

[+Random Terrain]

You can also look at a demo I posted a while back called "move_around_rooms.bas"-- you should be able to find it in this forum by searching for that program name. It's sort of like bogax's "lookup_room.bas" except each direction has its own data matrix so you can have up to 256 rooms if you want.

 

Here's the link:

 

atariage.com/forums/topic/95820-adventure-type-game/#entry1162741

 

So far, the room code posted by you and bogax is way over my head. Are any of your examples similar to how it was done in Adventure? I know that Adventure was programmed using assembly language, but there must be a BASIC equivalent that we could come up with that we could put on the batari Basic page. A no_blank_lines Adventure-style batari Basic program with room data that can be easily adjusted by new users that also has items that can be picked up and dropped and bad guys doing bad guy things.

[+Gemintronic]

Here's the link:

 

atariage.com/forums/topic/95820-adventure-type-game/#entry1162741

 

So far, the room code posted by you and bogax is way over my head. Are any of your examples similar to how it was done in Adventure? I know that Adventure was programmed using assembly language, but there must be a BASIC equivalent that we could come up with that we could put on the batari Basic page. A no_blank_lines Adventure-style batari Basic program with room data that can be easily adjusted by new users that also has items that can be picked up and dropped and bad guys doing bad guy things.

 

I *think* whats going on is that subc/addc is for moving between rooms horizontally whilst subr/addr is vertically. I guess the DATA arrays could be named moveleftfrom, moverightfrom, moveupfrom, movedownfrom.

[Arcade]

Thanks a lot! I will have to look more in to that in the future when I'm done working on my current project!

[bogax]

I *think* whats going on is that subc/addc is for moving between rooms horizontally whilst subr/addr is vertically. I guess the DATA arrays could be named moveleftfrom, moverightfrom, moveupfrom, movedownfrom.

 

I guess this merits some comment.

 

Contrary to SeaGtGruff's comment,

I think the third bit "direct_lookup"

is closer to his.

 

I debated whether to do it that way

to begin with but I was trying to

shoehorn a table into your code with

minimum changes. eg you don't use

direction for anything there, other

than choosing the room, but you might

want to.

 

After thinking about it a bit I decided

it was silly to advocate lookup tables

and not demonstrate building the calculations

into the table. so I added the direct_lookup

bit.

 

I debated whether to call the tables by

the directions but opted for add and sub(tract)

to emphasize that that was built into the table.

 

I arranged the tables 3 x 3 because that's how

you had the rooms arranged and I was trying to

make the correspondence easy to see.

 

But the tables make it easy to do arbitraty

connections between rooms.

 

Going right from a to b need not

mean that going left from b will take you

to a

 

The rooms don't have to be in a two

dimensional grid they could be three or four

or what ever dimensions.

 

Or nothing like a grid.

Edited May 13, 2013 by bogax

[bogax]

Here's the link:

 

atariage.com/forums/topic/95820-adventure-type-game/#entry1162741

 

So far, the room code posted by you and bogax is way over my head.

 

 

The loons code has directions 1-4

he does an on goto based on the room

you're currently in which takes you

to an on goto for that room that

selects a new room based on the

direction you're going.

 

The one I called lookup_room is simlar

except I took out the on gotos and put

the target rooms in a table.

There's a row for each room and the

four columns are the four directions.

Since the rows/rooms are every fourth

direction the current room is multiplied

by four to get the row and then the direction

is added to get the column for the index

into the table. Then on gosub to select

the drawing code for that room.

 

The one I called compute_room assumes the

rooms are in a 3 x 3 grid.

if you want to go right you add one to the

column address of the room and if you want to

go down you add one to the row address.

Simliar for left or up except you subtract.

row / column numbers have to wrap so that

eg 0 is after 2, that's built into the table.

So you just look up the result of adding or

subtracting in the appropriate table.

Similar to forming the table address for

lookup_room, since there's 3 columns of rooms

the row number is multiplied by 3 and the

column number is added to get the room

number then on gosub is used to go to the

room drawing code for that room.

 

The direct_lookup code has a table for each

direction and an entry in each table for each

room. You just look up the new room for

a particular dirction based on the room you're

in now. Then on gosub to draw that room.

 

SeaGtGruff's move_around_rooms is similar

except he goes to a subroutine for each

direction that does the table look up for

that direction then uses the room to

look up a room shape (and a room color)

then uses a bunch of if statements instead

of on goto (and why in the world.. ;P )

to select the correct room shape drawing

code for the room. (so different rooms

can have same shapes with different colors)

[SeaGtGruff]

SeaGtGruff's move_around_rooms is similar

except he goes to a subroutine for each

direction that does the table look up for

that direction then uses the room to

look up a room shape (and a room color)

then uses a bunch of if statements instead

of on goto (and why in the world.. ;P )

to select the correct room shape drawing

code for the room. (so different rooms

can have same shapes with different colors)

Well, it was written about 6.5 years ago, so I don't really remember why in the world I did it that way. I'm not sure when on-goto was added to batari Basic, but I don't think the no_blank_lines option was available yet, otherwise I'm pretty sure I would have used it in that example. On Random Terrain's page it says "The original beta version [of batari Basic] was released in 2005. Version 1.0 was released in 2007." I thought the first versions of batari Basic were released before 2005, but if I remember correctly Fred considered the 0.99 release to be the first true "beta" release, so maybe that's what 2005 is referring to?

 

Anyway, my example was just a quickie demo to suggest what *could* be done, not anything I spent a lot of time trying to optimize, and I hadn't meant it to be an example of how something *should* be done. I only mentioned it because using a separate array for each direction allows up to 256 rooms. To break the 256-room barrier you could use sdata statements, or split the game into multiple "lands" and have separate sets of data statements for each land, allowing up to 256 rooms in each land, etc.

 

But yeah-- if I were doing it today, I'd do it differently than how I did it back in 2006.

[bogax]

Just for the hell of it I rewrote

SeaGtGruff's code with more tables.

This saved about 200 bytes, but it's

probably slower.

It's certainly not as easy to understand.

Most of the savings is just replacing

the string of if statments with on goto.

For the rest, it's probably not the

new tables but rearranging the old ones

so that seperate routines are not needed.

 

Mostly I was interested in how one might

replace long strings of arbitrary

if statements with looping through tables.

In this case it saves nothing and no doubt

takes longer. (but this wasn't a long

string of if statements)

 

 

move_around_rooms_with_more_tables.bas

Edited May 14, 2013 by bogax

[+Random Terrain]

On Random Terrain's page it says "The original beta version [of batari Basic] was released in 2005. Version 1.0 was released in 2007." I thought the first versions of batari Basic were released before 2005, but if I remember correctly Fred considered the 0.99 release to be the first true "beta" release, so maybe that's what 2005 is referring to?

 

Is there a batari Basic thread earlier than the one below from July 7, 2005?

 

atariage.com/forums/topic/72428-atari-2600-basic-compiler-is-here/

I'm probably going to get a mix of praise and criticism for this. Anyway, I've written a BASIC compiler for the Atari 2600. Yes, you read that right. This is not a joke!

 

 

The thread below where I was asking for someone to make a BASIC-like language that will allow the average person to make Atari 2600 games is from September 16, 2004:

 

atariage.com/forums/topic/57543-someone-please-make-a-basic-language-update-batari-did-it/

As I said in another thread, someone should make a BASIC-like language that will allow the average person to make Atari 2600 games from scratch. Besides allowing people to save their work, it should have a built-in compiler that converts the BASIC into a BIN file that will be ready to play using an emulator. Imagine regular people making Atari 2600 games fairly easily with a BASIC language!

[SeaGtGruff]

Is there a batari Basic thread earlier than the one below from July 7, 2005?

I couldn't remember if version 0.1 was released in 2005 or 2004, or maybe even before 2004-- and I was too tired at the time to go look it up! I do remember that the first four versions (0.1, 0.2, 0.3, and 0.35) were released pretty close to each other, then there was a "pause" before 0.99 was released.

 

Anyway, I was thinking that "on-goto" might not have been added to batari Basic yet when I wrote that "move_around_rooms.bas" example.