What's So Great About VbB's 'Convert to Data File'? (Example Program)

[+Random Terrain]

If you missed it, take a look at jwierer's blog:

 

Small update for VisualbB

 

In that latest version of VbB, we now have Convert to Data File! Just right click on a playfield file and select Convert to Data File from the menu. VbB automatically reverses the appropriate numbers so they can be used directly with playfield variables. This is great news for bB programmers who use the standard kernel. This will allow us to place random pieces of the playfield on the screen without using the very slow pfpixel with zeroes and ones data or the scrolling trick that theloon came up with, where you display some X and . data, scroll it down, display some more X and . data, scroll it down and so on. The scrolling trick was an improvement over pfpixel, but you had to rely on scrolling, which caused the score to bounce, and there was a slight delay of about one second.

 

Thanks to Convert to Data File, we now have a lightning fast way to place random pieces of the playfield on the screen. No pfpixel, no scrolling, no bouncing score, just an instant whack in the face with data surging directly into the playfield variables.

 

Below is an example program that displays random pieces of a maze when you move the joystick in different directions. Remember, this just one example of what you could do. You could also make adventure games that have randomly created rooms. Who knows what your imagination might come up with?

 

 

Here's the .bin file to use with an emulator or a Harmony cart on a real Atari 2600:

 

ex_random_maze_using_data_2012y_11m_20d_0544t.bin

 

 

Here's the bB code:

 

ex_random_maze_using_data_2012y_11m_20d_0544t.bas

 

 

Here is a simpler example:

 

If I want to draw the playfield the normal way, I could use something like this:

 

  playfield:
  XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
  XX............................XX
  XX............................XX
  XX..XXXXXXXXXXX..XXXXXXXXXXX..XX
  XX..XX....................XX..XX
  XX..XX....................XX..XX
  XX..XX....................XX..XX
  XX..XXXXX..XXXX..XXXX..XXXXX..XX
  XX............................XX
  XX............................XX
  XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
end

 

I could also use VbB to grab the Hex Data Values (with reversed data) and draw the playfield like this:

 

   dim _Loop = w

  for _Loop = 0 to 43
  var0[_Loop] = _Data_Screen_01[_Loop]
  next

  COLUPF = $CE

__Main_Loop

  drawscreen

  goto __Main_Loop


  data _Data_Screen_01
  $FF,$FF,$FF,$FF,$C0,$00,$00,$C0,$C0,$00,$00,$C0,$CF,$7F,$7F,$CF,
  $CC,$00,$00,$CC,$CC,$00,$00,$CC,$CC,$00,$00,$CC,$CF,$79,$79,$CF,
  $C0,$00,$00,$C0,$C0,$00,$00,$C0,$FF,$FF,$FF,$FF
end

 

 

 

Note: This will not work with the DPC+ kernel. If you want an explanation, RevEng told me "Unfortunately DPC+ uses ARM memory for the playfield, and bB can't access it outside of the pfpixel and playfield commands, so your program can't be directly translated to DPC+."

[+Gemintronic]

What would have to happen is a bit of code to read bits out of the DATA statement and pfpixel them row by row. Pretty sure bogax had something nailed down in this topic:

http://www.atariage.com/forums/topic/200939-accessing-data-as-binary-array/

[+Random Terrain]

What would have to happen is a bit of code to read bits out of the DATA statement and pfpixel them row by row. Pretty sure bogax had something nailed down in this topic:

http://www.atariage....s-binary-array/

 

This topic isn't about making a collision map of the playfield, it's about how you can instantly draw as much of a screen as you want for making random mazes, random rooms, or whatever else you can think of using the standard kernel. Although it doesn't seem to have much to do with this thread, I'm not exactly sure what bogax made in your DPC+ thread because there's no .bin file example program to run.

[+Gemintronic]

Yeah, sorry for the half-arsed response. THIS post could be used as a base to draw playfield pixels per DATA element. mapx and mapy could be subverted from changing the score to placing pfpixels with a loop.

[+Random Terrain]

Yeah, sorry for the half-arsed response. THIS post could be used as a base to draw playfield pixels per DATA element. mapx and mapy could be subverted from changing the score to placing pfpixels with a loop.

 

Yep, I looked at that post, but there doesn't seem to be a finished .bas file to download or a .bin file to run. It's hard to tell what we're supposed to do with those 4 code boxes in his post. Do you have a working example program?

[+Gemintronic]

Yep, I looked at that post, but there doesn't seem to be a finished .bas file to download or a .bin file to run. It's hard to tell what we're supposed to do with those 4 code boxes in his post. Do you have a working example program?

 

Working? Sorta..

 

UPDATE II: Fixed it in the third build!

bitplayfield3.zip

[+Random Terrain]

Working? Sorta..

 

Thanks. Yeah, DPC+ users might be able to put up with something that is so slow, since that's their only option:

 

theloon_bitplayfield.bin

 

[it's not really that slow, theloon slowed it down.]

 

 

But standard kernel users have a lightning fast alternative now (for displaying pieces of the screen) thanks to VbB's Convert to Data File.

 

 

We've gone from this:

 

ex_slow_maze_draw_with_pfpixel_2012y_11m_18d_2246t.bin

 

 

To this:

 

scroll_test_slow_2011y_08m_20d_0332t.bin

 

random_maze_test_16x16x16_with_scroll_32x23_2011y_08m_21d_2001t.bin

 

 

To being able to do this:

 

ex_random_maze_using_data_2012y_11m_20d_0544t.bin

 

 

Since people are having so much trouble with the limitations and bugs of the DPC+ version of bB, and now that I can quickly add data to the screen (thanks to jwierer), I think I'll start working on my adventure game using the standard kernel. It will suck not having 10 multicolored sprites, but I'd rather have screens that load faster than you can blink.

[+Gemintronic]

Which is hella righteous!

 

The slowdown on my code was an intentional drawscreen for every pfpixel command. Just take change

 

printpf

cellx = mapx & 7

cell = mapy + mapy * 4 + mapx / 8

if map[cell] & setbits[cellx] then pfpixel mapx mapy on else pfpixel mapx mapy off

drawscreen

return

 

to this:

 

printpf

cellx = mapx & 7

cell = mapy + mapy * 4 + mapx / 8

if map[cell] & setbits[cellx] then pfpixel mapx mapy on else pfpixel mapx mapy off

return

[+Random Terrain]

Which is hella righteous!

 

The slowdown on my code was an intentional drawscreen for every pfpixel command. Just take change

 

printpf

cellx = mapx & 7

cell = mapy + mapy * 4 + mapx / 8

if map[cell] & setbits[cellx] then pfpixel mapx mapy on else pfpixel mapx mapy off

drawscreen

return

 

to this:

 

printpf

cellx = mapx & 7

cell = mapy + mapy * 4 + mapx / 8

if map[cell] & setbits[cellx] then pfpixel mapx mapy on else pfpixel mapx mapy off

return

 

I thought you were giving me an example at normal speed. This is much faster:

 

theloon_bitplayfield_02.bin

 

I'm still not sure how you'd use it to display random chunks of the playfield.

[bogax]

I have the feeling I'm not doing a very good job of explaining myself

 

For that bit of code that's setup for 5 bytes per line ie x goes to 39

the only reason to do it that way is if for some reason you want to

visualize it that way. That is, if you want to conceptualize your data

as 40 pixels by (whatever) and use 5 bytes per line in a data statement.

the code itself doesn't care how the data is arranged in the data statement.

 

And that's sort of (partly) why I wasn't supplying working code.

It's just meant to be a discription of how to approach the problem.

 

Specific problems are likely to need specific solutions.

(does anybody actually use 40 pixel lines?)

 

That particular bit of code I didn't test except to see that it

compiled.

 

Usually I test the code but not always, and not always before I

post (I do try to remember to say if it's tested or not but I don't

always remember to do that either)

 

So I could post an actual working program usually but what good

would it actually be? It's usually just a hello world type thing

not really useful or meant/expected to be.

 

And I still haven't gottten any DPC+ stuff to compile

[+Gemintronic]

Mine should because it uses DATA statements (SDATA is broke in DPC+).

 

R.T. this is GREAT for random mazes. Imagine a big column of maze. You can pick and choose sections to mix and match. Remember my Destiny WIP? It used three horizontal slices of maze that it mixed and matched. Imagine what fun could be had when you can take ANY sized section of map data and patch it onto the playfield..

 

Sorry for no example. This was all done/thought about RIGHT NOW

[+Random Terrain]

Specific problems are likely to need specific solutions.

(does anybody actually use 40 pixel lines?)

 

I don't know about the DPC+ kernel, but the standard kernel only has 32 playfield pixels for each row.

 

 

 

 

Usually I test the code but not always, and not always before I

post (I do try to remember to say if it's tested or not but I don't always remember to do that either)

 

So I could post an actual working program usually but what good would it actually be? It's usually just a hello world type thing not really useful or meant/expected to be.

 

It was just this case that was confusing because there were 4 different code boxes and it wasn't clear if we were supposed to copy and paste bits of code or if everything was included in one of the boxes.

 

 

 

 

And I still haven't gottten any DPC+ stuff to compile

 

I've personally given up on DPC+. I keep waiting and waiting, but batari must be too busy to fix it. I'll just do the best I can with the standard kernel.

[+Random Terrain]

R.T. this is GREAT for random mazes. Imagine a big column of maze. You can pick and choose sections to mix and match. Remember my Destiny WIP? It used three horizontal slices of maze that it mixed and matched. Imagine what fun could be had when you can take ANY sized section of map data and patch it onto the playfield.

 

Yeah, that's the kind of thing this is for, except you don't have to use scrolling. And I see why bogax's program is so fast, even though he's using pfpixel. He's not reading hundreds of zeroes and ones, it looks like he's reading about the same amount of data that I am in my example program. That explains the speed.

[+Random Terrain]

After spending hours playing around to see if I could use the bogax code and unreversed data in my example program, it finally hit me that I should test the smaller version with the fire button:

 

theloon_bitplayfield_04.bin

 

theloon_bitplayfield_04.bas

 

 

It goes over 262 when you press the fire button to draw the screen again. Does DPC+ code run faster?

[bogax]

I'm still not sure what you guys are trying to do

 

Here's a couple that write the playfield byte wise

 

One needs the reversed data one has a bit of asm

to do the reversing.

 

set romsize 4k

dim mapx = a
dim mapy = b
dim pfy = c
const mem = $A4

COLUPF=$FF
COLUBK=$00

playfield:
....XX...XX...XXX...XX...XX....
....X.X..X.X..X....X....X......
....XX...XX...XX....X....X.....
....X....X.X..X......X....X....
....X....X.X..XXX..XX...XX.....
...............................
.....XX..XX....X....XX..XXX....
....X....X.X..X.X..X....X......
.....X...XX...XXX..X....XX.....
......X..X....X.X..X....X......
....XX...X....X.X...XX..XXX....
end

PROGRAMLOOP
if joy0fire then let z = z | 1
if !joy0fire && z then gosub DRAW_MAP

drawscreen

goto PROGRAMLOOP

DRAW_MAP
if mapy > 39 then mapy = 0 else mapy = mapy + 4
for pfy = 0 to 40 step 4

for mapx = 0 to 3
temp1 = mapy | mapx
temp2 = pfy | mapx
mem[temp2] = map[temp1]
next
if mapy > 39 then mapy = 0 else mapy = mapy + 4
next
z = 0
return

data map
%00001010, %00010111, %10001110, %00000000,
%00001010, %00010001, %10001010, %00000000,
%00001110, %00010011, %10001010, %00000000,
%00001010, %00010001, %10001010, %00000000,
%00001010, %01110111, %11101110, %00000000,
%00000000, %00000000, %00000000, %00000000,
%00001000, %01100100, %01110010, %00111000,
%00001000, %10010100, %01001010, %01001000,
%00000101, %10010010, %01110010, %01001000,
%00000010, %01100001, %01001011, %00111011,
%00000000, %00000000, %00000000, %00000000,
%00000000, %00000000, %00000000, %00000000
end

 

set romsize 4k

dim mapx = a
dim mapy = b
dim pfy = c
const mem = $A4

macro revb
asm
lda temp1
and #$0F
tax
lda temp1
lsr
lsr
lsr
lsr
tay
lda rev_tbl_lo,x
ora rev_tbl_hi,y
sta temp1
end
end

COLUPF=$FF
COLUBK=$00

playfield:
....XX...XX...XXX...XX...XX....
....X.X..X.X..X....X....X......
....XX...XX...XX....X....X.....
....X....X.X..X......X....X....
....X....X.X..XXX..XX...XX.....
...............................
.....XX..XX....X....XX..XXX....
....X....X.X..X.X..X....X......
.....X...XX...XXX..X....XX.....
......X..X....X.X..X....X......
....XX...X....X.X...XX..XXX....
end

PROGRAMLOOP
if joy0fire then let z = z | 1
if !joy0fire && z then gosub DRAW_MAP

drawscreen

goto PROGRAMLOOP

DRAW_MAP
if mapy > 39 then mapy = 0 else mapy = mapy + 4
for pfy = 0 to 40 step 4

for mapx = 0 to 3
temp1 = mapy | mapx
temp1 = map[temp1]
if mapx & 1 then callmacro revb
temp2 = pfy | mapx
mem[temp2] = temp1
next
if mapy > 39 then mapy = 0 else mapy = mapy + 4
next
z = 0
return

data map
%00001010, %11101000, %10001110, %00000000,
%00001010, %10001000, %10001010, %00000000,
%00001110, %11001000, %10001010, %00000000,
%00001010, %10001000, %10001010, %00000000,
%00001010, %11101110, %11101110, %00000000,
%00000000, %00000000, %00000000, %00000000,
%00001000, %00100110, %01110010, %00011100,
%00001000, %00101001, %01001010, %00010010,
%00000101, %01001001, %01110010, %00010010,
%00000010, %10000110, %01001011, %11011100,
%00000000, %00000000, %00000000, %00000000,
%00000000, %00000000, %00000000, %00000000
end

data rev_tbl_lo
%00000000, %10000000, %01000000, %11000000
%00100000, %10100000, %01100000, %11100000
%00010000, %10010000, %01010000, %11010000
%00110000, %10110000, %01110000, %11110000
end

data rev_tbl_hi
%00000000, %00001000, %00000100, %00001100
%00000010, %00001010, %00000110, %00001110
%00000001, %00001001, %00000101, %00001101
%00000011, %00001011, %00000111, %00001111
end

 

http://pastebin.com/VCPHUBeQ without asm

 

http://pastebin.com/tMp24XXT with asm

Edited November 22, 2012 by bogax

[+Random Terrain]

I'm still not sure what you guys are trying to do

 

If you run my example program in the first post and press the joystick in different directions, that is what this thread is about. I wanted a fast way to create random mazes using pieces of playfield data:

 

www.atariage.com/forums/topic/186523-random-maze-test-2011/

 

 

Below are the 3 versions that the random maze went through. Press reset or the fire button in all versions to get a new random maze.

 

 

This version of my random maze test used slow data suggested by jrok:

 

random_maze_test_32x23_with_slow_data_2011y_08m_18d_0830t.bin

 

 

This version uses the scroll down trick by theloon:

 

random_maze_test_16x16x16_with_scroll_32x23_2011y_08m_21d_2001t.bin

 

 

This last version uses data that Visual batari Basic can now produce:

 

random_maze_test_16x16x16_with_fast_data_32x23_2012y_11m_22d_0322t.bin

 

 

 

This last version is the fastest so far and what I have been looking for. I would like to use this for random mazes, random rooms in adventure games, and who knows what else. It might even be fast enough to animate a character made out of playfield pixels.