Jump to content

Photo

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

Random Maze Example Program

15 replies to this topic

#1 Random Terrain OFFLINE  

Random Terrain

    Visual batari Basic User

  • 28,327 posts
  • Controlled Randomness
    Replay Value
    Nonlinear
  • Location:North Carolina (USA)

Posted Tue Nov 20, 2012 5:25 AM

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:

Attached File  ex_random_maze_using_data_2012y_11m_20d_0544t.bin   8KB   160 downloads


Here's the bB code:

Attached File  ex_random_maze_using_data_2012y_11m_20d_0544t.bas   29.71KB   174 downloads


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+."

#2 Gemintronic OFFLINE  

Gemintronic

    Jason S. - Lead Developer & CEO

  • 8,854 posts

Posted Tue Nov 20, 2012 1:11 PM

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/

#3 Random Terrain OFFLINE  

Random Terrain

    Visual batari Basic User

  • Topic Starter
  • 28,327 posts
  • Controlled Randomness
    Replay Value
    Nonlinear
  • Location:North Carolina (USA)

Posted Tue Nov 20, 2012 1:47 PM

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.

#4 Gemintronic OFFLINE  

Gemintronic

    Jason S. - Lead Developer & CEO

  • 8,854 posts

Posted Tue Nov 20, 2012 1:55 PM

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.

#5 Random Terrain OFFLINE  

Random Terrain

    Visual batari Basic User

  • Topic Starter
  • 28,327 posts
  • Controlled Randomness
    Replay Value
    Nonlinear
  • Location:North Carolina (USA)

Posted Tue Nov 20, 2012 2:04 PM

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?

#6 Gemintronic OFFLINE  

Gemintronic

    Jason S. - Lead Developer & CEO

  • 8,854 posts

Posted Tue Nov 20, 2012 2:37 PM

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!

Attached Files



#7 Random Terrain OFFLINE  

Random Terrain

    Visual batari Basic User

  • Topic Starter
  • 28,327 posts
  • Controlled Randomness
    Replay Value
    Nonlinear
  • Location:North Carolina (USA)

Posted Tue Nov 20, 2012 3:00 PM

Working? Sorta..


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

Attached File  theloon_bitplayfield.bin   4KB   126 downloads

[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:

Attached File  ex_slow_maze_draw_with_pfpixel_2012y_11m_18d_2246t.bin   32KB   133 downloads


To this:

Attached File  scroll_test_slow_2011y_08m_20d_0332t.bin   32KB   92 downloads

Attached File  random_maze_test_16x16x16_with_scroll_32x23_2011y_08m_21d_2001t.bin   32KB   123 downloads


To being able to do this:

Attached File  ex_random_maze_using_data_2012y_11m_20d_0544t.bin   8KB   100 downloads


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.

#8 Gemintronic OFFLINE  

Gemintronic

    Jason S. - Lead Developer & CEO

  • 8,854 posts

Posted Tue Nov 20, 2012 3:04 PM

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

#9 Random Terrain OFFLINE  

Random Terrain

    Visual batari Basic User

  • Topic Starter
  • 28,327 posts
  • Controlled Randomness
    Replay Value
    Nonlinear
  • Location:North Carolina (USA)

Posted Tue Nov 20, 2012 3:14 PM

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:

Attached File  theloon_bitplayfield_02.bin   4KB   130 downloads

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

#10 bogax OFFLINE  

bogax

    Dragonstomper

  • 724 posts

Posted Tue Nov 20, 2012 3:41 PM

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

#11 Gemintronic OFFLINE  

Gemintronic

    Jason S. - Lead Developer & CEO

  • 8,854 posts

Posted Tue Nov 20, 2012 4:25 PM

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 :)

#12 Random Terrain OFFLINE  

Random Terrain

    Visual batari Basic User

  • Topic Starter
  • 28,327 posts
  • Controlled Randomness
    Replay Value
    Nonlinear
  • Location:North Carolina (USA)

Posted Tue Nov 20, 2012 4:35 PM

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.

#13 Random Terrain OFFLINE  

Random Terrain

    Visual batari Basic User

  • Topic Starter
  • 28,327 posts
  • Controlled Randomness
    Replay Value
    Nonlinear
  • Location:North Carolina (USA)

Posted Tue Nov 20, 2012 5:01 PM

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.

#14 Random Terrain OFFLINE  

Random Terrain

    Visual batari Basic User

  • Topic Starter
  • 28,327 posts
  • Controlled Randomness
    Replay Value
    Nonlinear
  • Location:North Carolina (USA)

Posted Wed Nov 21, 2012 10:39 PM

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:

Attached File  theloon_bitplayfield_04.bin   4KB   129 downloads

Attached File  theloon_bitplayfield_04.bas   1.37KB   125 downloads


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

#15 bogax OFFLINE  

bogax

    Dragonstomper

  • 724 posts

Posted Thu Nov 22, 2012 2:06 AM

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 by bogax, Thu Nov 22, 2012 2:21 AM.


#16 Random Terrain OFFLINE  

Random Terrain

    Visual batari Basic User

  • Topic Starter
  • 28,327 posts
  • Controlled Randomness
    Replay Value
    Nonlinear
  • Location:North Carolina (USA)

Posted Thu Nov 22, 2012 3:11 AM

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:

Attached File  random_maze_test_32x23_with_slow_data_2011y_08m_18d_0830t.bin   32KB   136 downloads


This version uses the scroll down trick by theloon:

Attached File  random_maze_test_16x16x16_with_scroll_32x23_2011y_08m_21d_2001t.bin   32KB   93 downloads


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

Attached File  random_maze_test_16x16x16_with_fast_data_32x23_2012y_11m_22d_0322t.bin   32KB   96 downloads



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.




0 user(s) are browsing this forum

0 members, 0 guests, 0 anonymous users