fun with tables

[bogax]

Not sure how useful this is likely

to be.

 

I modified SeaGtGruff's move_around_rooms

code to use tables to choose a new room

from more than 256 possibilities based

on a couple of indexes using a bit of asm.

 

In bB a table index can only go up to 256

(I don't know what the limit on entries in

the actual table is but it can be more than

256)

So you need to use more than one table

to index more than 256 entries.

You can do that by using different routines

for different tables (as is done in SeaGtGruff's

code) This needs more code and a lot of

jumping around

 

 

Here I've put (the pointer to) the tables in

tables then select a table with one index

then point into the selected table with another

index. Unfortunately this is (relatively)

complicated and needs a bit of asm.

 

First you have to create a table of

pointers to tables. Since you need two bytes

to specify a table and bB tables have one

byte entries the table of pointers is

split into tables of hi and lo bytes.

Since the target table is changing and

not hard coded in rom you need a couple

(consecutive) bytes of ram to point to it.

I used temp1 and temp2.

 

You need to create the tables of pointers to

tables

data pointers_hi
>table0_name, >table1_name, >table2_name
end

data pointers_lo
<table0_name, <table1_name, <table2_name
end

 

bB adds a "." to the beginning of labels

but not for table names so you don't need

the a "."

 

So you look up the table pointers and put

the lo part of the pointer in temp1 and the

hi part of the pointer in temp2.

 

Then a bit of asm looks into the pointed to

table and puts the result in a variable.

 

This is packaged in a macro called lookup

rem parameter 1 is the destination variable
rem parameter 2 is a variable containing
rem the index into the tables of
rem pointers to tables
rem parameter 3 is a variable used to index
rem into the selected table

macro lookup
temp1 = pointers_lo[{2}] : temp2 = pointers_hi[{2}]
asm
ldy {3}
lda (temp1),y
sta {1}
end
end

 

here I've molested SeaGtGruff's code

 

tables_of_tables.bas

 

if lookup is a function you can pass

constants (but it's slower and uses

another level of stack)

 

rem first parameter is the index into
rem the table of pointers table
rem second parameter is the index into
rem the selected table

function lookup
asm
tax
lda pointers_lo,x
sta temp1
lda pointers_hi,x
sta temp2
lda (temp1),y
end
return

 

tables_of_tables_w_function.bas

Edited May 14, 2013 by bogax

[+Random Terrain]

Can you do "fun with chairs" next?

[SeaGtGruff]

here I've molested SeaGtGruff's code

Molest away!

[+Gemintronic]

When batari starts to dig back into bB enhancements I hope he'll continue with his aim of gynourmous 512k EEPROM support. In that case we'll have to think bigger than 256 element game maps.My thought is that normal DATA statements can have up to 256 elements - which equates to 16x16 map locations. You could have a 16x16 world array of 16x16 map location arrays for the player to march through.If I'm making enough sense, can an example of that be done?

[ferghead]

I do a podcast on 2600 games, and I was in email contact with Ed Riddle. He said that Indy 500 was "largely table driven." I have no idea what that means, can you explain it to a uses-the-computer-for-the-internet-only person?

[+Gemintronic]

I do a podcast on 2600 games, and I was in email contact with Ed Riddle. He said that Indy 500 was "largely table driven." I have no idea what that means, can you explain it to a uses-the-computer-for-the-internet-only person?

 

That means complicated math like car rotations can't be done nicely on the 2600. Instead, you create a cheat sheet using a portion of game data as a table to look up correct values. So, instead of calculating how many pixels to move when you go 90 degrees you look it up on a nice chart you put into storage.

[bogax]

That means complicated math like car rotations can't be done nicely on the 2600. Instead, you create a cheat sheet using a portion of game data as a table to look up correct values. So, instead of calculating how many pixels to move when you go 90 degrees you look it up on a nice chart you put into storage.

 

Which is a lot faster but takes a lot more space.

 

But it's not necessarily only speeding up calculations.

It might be look up what to do for this player moving in that

direction with those conditions.

[bogax]

I moved the SeaGruff's playfields into a data statement.

There's a macro that adds a constant to an 8.8 variable.
Apparently if the constant is declared with const bB prepends
a # but DASM doesn't seem to mind (here the constant is
the label from a data statement which doesn't have that
problem)


http://basicplay.netau.net/

tables_of_tables_2.bas

Edited September 3, 2014 by bogax