Jump to content

Photo

VBXE - programming, examples, programming queries


132 replies to this topic

#51 Rybags OFFLINE  

Rybags

    Quadrunner

  • Topic Starter
  • 15,230 posts
  • Location:Australia

Posted Tue Jan 19, 2010 8:06 AM

Just thinking... maybe we can use the ADD facility of the blit somehow.

Drawing a line, you always have the situation where either X or Y is always inc/decrementing by one each point. The other co-ordinate's change is controlled by the COLAC=COLAC+DELTAC, then you compare to ENDPT to decide whether that co-ordinate gets changed.

Just forget long lines for a bit... we might be limited to 255 pixel long lines.

We could use blits to prepare a list of all the COLAC values that will be encountered during the given line draw. Then we just do a bunch of compares. Of course, the blit hasn't done the COLAC=COLAC-ENDPT operation that's supposed to occur when a step occurs, but maybe we can adjust our compare value to compensate.

Unsure if this approach will work. In theory though if we could accelerate this part of the process, we could end up with a quicker line draw.

#52 Heaven/TQA OFFLINE  

Heaven/TQA

    Quadrunner

  • 10,359 posts
  • Location:Baden-Württemberg, Germany

Posted Tue Jan 19, 2010 8:27 AM

that would be some of my thoughts... should be still quicker than doing it by hand...

what about a texture mapper? f.e. like in Alternate Reality: The Dungeon? Or Encounter?

#53 Rybags OFFLINE  

Rybags

    Quadrunner

  • Topic Starter
  • 15,230 posts
  • Location:Australia

Posted Tue Jan 19, 2010 8:32 AM

There's pattern fill, but you don't get scaling with it.

Kludge-o-matic method might be to use multiple mip-mapping levels along with different X-step or zoom* values.

#54 Heaven/TQA OFFLINE  

Heaven/TQA

    Quadrunner

  • 10,359 posts
  • Location:Baden-Württemberg, Germany

Posted Tue Jan 19, 2010 9:06 AM

well...if the core would supply fractional "adds" than it would be good... ;)

#55 flashjazzcat OFFLINE  

flashjazzcat

    Quadrunner

  • 12,763 posts
  • Location:United Kingdom

Posted Tue Jan 19, 2010 11:15 AM

If anyone could post a verified working code snippet showing 80 col text mode characters with their background colours changed with the attribute byte, I'd be incomprehensibly grateful. Posted Image

Enjoying this discussion, BTW. New ways to abuse the blitter are always interesting.

...It's OK. I think I have it cracked. TEXTMODE.COM sets every colour between 128-255 to turquise!

Edited by flashjazzcat, Tue Jan 19, 2010 12:11 PM.


#56 flashjazzcat OFFLINE  

flashjazzcat

    Quadrunner

  • 12,763 posts
  • Location:United Kingdom

Posted Tue Jan 19, 2010 1:21 PM

I require three distinct colour schemes on the screen:

1) light turqoise on dark
2) white on black
3) black on white

I'm attempting to set up the palette so that colour 1 is light turq, while colour 129 is dark turqoise (background). In turn, colour 2 is white, and colour 130 is black... and so on. Bit 7 of the attribute byte will always be set, while bits 0 and 1 simply select one of the three possible colour schemes.

User adjustments will then be accomplished using palette adjustment. Does this seem a sensible solution?

#57 Rybags OFFLINE  

Rybags

    Quadrunner

  • Topic Starter
  • 15,230 posts
  • Location:Australia

Posted Wed Jan 20, 2010 8:41 AM

Thinking again about using blits to do adds.

We could do array processing of 16-bit adds (you'd need to do a certain number of operations to gain any time benefit).

VBXE doesn't do Carry from lo-hi bytes though, but there's an easy way around that. Just compare the initial value with the new value (low bytes only). If the new value of the low byte is less than the initial value, then obviously a Carry has been generated and the high byte should be incremented.

e.g. 250 + 7 = 1 (less than initial value, Carry generated)
250 + 4 = 254 (not less than initial value, no Carry)
250 + 0 = 250 (not less than initial value, no Carry)
1 + 255 = 0 (less than initial value, Carry generated)

The compare would need to be repeated to check for overflow, but in many/most cases we're probably in a controlled situation where that won't happen so we could skip it.

So, we'd have something like:

. setup blits to add Array1 elements to Array2 elements - 1 blit for lo, 1 for hi bytes.
. run the blits (results get stored in Array2)
. run a loop that performs the carry check. For quicker execution the arrays are best stored with all low bytes in one block, high bytes in another. So the code for the carry check should be as simple as e.g. for 256 element array:

  ldx #0
checkcarry  lda array2_lowbyte,x
  cmp array1_lowbyte,x
  bcs no_inc1
  inc array2_highbyte,x
noinc1  inx
  bne checkcarry

Of course, some more extra speed could be had by unrolling that loop a bit.

The method could be expanded to higher order (24/32 etc) binary addition too.

Edited by Rybags, Wed Jan 20, 2010 8:41 AM.


#58 phaeron OFFLINE  

phaeron

    River Patroller

  • 2,281 posts
  • Location:USA

Posted Wed Jan 20, 2010 10:51 PM

  ldx #0
checkcarry  lda array2_lowbyte,x
  cmp array1_lowbyte,x
  bcs no_inc1
  inc array2_highbyte,x
noinc1  inx
  bne checkcarry


12 CPU cycles/byte is pretty expensive by blitter speeds, considering that doing a read-modify-write pass with the blitter can run as fast as 0.38 cycles/byte.

I did some sketches with logic operations, and I'm beginning to think that the fastest way to do this is using the blitter with a 64K lookup table to compute the carry. It's expensive in blitter time, but it's still much faster than the CPU at ~3 cycles/byte.

#59 Rybags OFFLINE  

Rybags

    Quadrunner

  • Topic Starter
  • 15,230 posts
  • Location:Australia

Posted Wed Jan 20, 2010 11:36 PM

But how's a lookup table going to work with an array processing situation?

I can't quite visulise how the blit could do a pass through our data again and tell us which bytes require Carry.

#60 phaeron OFFLINE  

phaeron

    River Patroller

  • 2,281 posts
  • Location:USA

Posted Thu Jan 21, 2010 1:07 AM

But how's a lookup table going to work with an array processing situation?

I can't quite visulise how the blit could do a pass through our data again and tell us which bytes require Carry.


It's similar to the trick I did with the rotate program to set up the shears entirely on the blitter:
  • Create a list of N 1x1 blits. Source pattern replication works nicely for this.
  • Blit one set of addends into the source low bytes of the blits (dest X step = 21).
  • Blit another set of addends into source mid bytes of the blits.
  • Patch the final NEXT bit and execute the blit list. Each blit copies one entry from a 256x256 table into a destination array with 00 (no carry) or 01 (carry).
  • Use the result as source for a blit into the high byte array in add mode to add in lo->hi carry.

Not the fastest way to do a table lookup and you do need to align the lookup tables in memory, but it's still faster than the 6502.

Edited by phaeron, Thu Jan 21, 2010 1:08 AM.


#61 Rybags OFFLINE  

Rybags

    Quadrunner

  • Topic Starter
  • 15,230 posts
  • Location:Australia

Posted Thu Jan 21, 2010 1:58 AM

Ahh... I got it now.

That technique could be used to do all kinds of table-lookup generation.

Next up: see if somehow we can do line-draw acceleration.

#62 flashjazzcat OFFLINE  

flashjazzcat

    Quadrunner

  • 12,763 posts
  • Location:United Kingdom

Posted Sun Jan 24, 2010 11:55 AM

Any guidelines or tips on exporting palettes from Photoshop or similar when designing 256 colour bitmapped images for VBXE?



#63 Heaven/TQA OFFLINE  

Heaven/TQA

    Quadrunner

  • 10,359 posts
  • Location:Baden-Württemberg, Germany

Posted Sun Jan 24, 2010 1:45 PM

question regarding 24bit macros in mads... is .long correct working for vbxe programming?

look:

$00100:
  Source: $04000 Xinc=+0 Yinc=+320
  Dest:   $00040 Xinc=+0 Yinc=+3841
  Size:   272 x 1
  Masks:  AND=$00, XOR=$00, COLL=$00
  Zoom:   1 x 1
  Patt:   disabled
  Mode:   0 (Copy)

says the debugger of Altirra and here is my BCB code snippet while using MADS...

char_bcb: 
		;.byte $00,$40,$00 ;source adress
		.long $004000 ;source adress
		.byte <320,>320 ;source step
		.long $004000 ;destination adress
		.byte <320,>320 ;dest. step
		.byte 15,0 ;size x
		.byte 15	;size y
		.byte 255 ;and
        .byte 0       ; XOR
        .byte 0       ;  collision AND
        .byte 0       ; zoom
        .byte 0       ; pattern
        .byte 9       ; control

????

#64 Heaven/TQA OFFLINE  

Heaven/TQA

    Quadrunner

  • 10,359 posts
  • Location:Baden-Württemberg, Germany

Posted Sun Jan 24, 2010 1:58 PM

well... should make my bcb correct... ;) my one is 18 bytes instead of 21...

#65 phaeron OFFLINE  

phaeron

    River Patroller

  • 2,281 posts
  • Location:USA

Posted Sun Jan 24, 2010 2:06 PM

question regarding 24bit macros in mads... is .long correct working for vbxe programming?

look:

char_bcb: 
		;.byte $00,$40,$00 ;source adress
		.long $004000 ;source adress
		.byte <320,>320 ;source step
		.long $004000 ;destination adress
		.byte <320,>320 ;dest. step
		.byte 15,0 ;size x
		.byte 15	;size y
		.byte 255 ;and
        .byte 0       ; XOR
        .byte 0       ;  collision AND
        .byte 0       ; zoom
        .byte 0       ; pattern
        .byte 9       ; control


.long does produce a 24-bit value that should work, but you are missing the source/destination X step bytes.

#66 Heaven/TQA OFFLINE  

Heaven/TQA

    Quadrunner

  • 10,359 posts
  • Location:Baden-Württemberg, Germany

Posted Sun Jan 24, 2010 2:25 PM

now the imho correct bcb:

Altirra> db 4100
4100: 00 40 00 40 01 01 00 40-00 40 01 01 0F 00 0F FF |.@.@...@.@......|
Altirra> db 4110
4110: 00 00 01 00 09 00 00 00-00 00 00 00 00 00 00 00 |................|

btw... how can I disassemble a complete block in Altirra?

#67 Heaven/TQA OFFLINE  

Heaven/TQA

    Quadrunner

  • 10,359 posts
  • Location:Baden-Württemberg, Germany

Posted Sun Jan 24, 2010 2:43 PM

Altirra> .vbxe_bl
$00000:
  Source: $00024 Xinc=-55 Yinc=+2162
  Dest:   $04000 Xinc=+1 Yinc=+320
  Size:   256 x 1
  Masks:  AND=$00, XOR=$00, COLL=$00
  Zoom:   1 x 1
  Patt:   disabled
  Mode:   0 (Copy)

what could be the reason?

a12:
        lda #0
        sta $D650
        lda #$01          ;$000100 = $4100 bank #0
        sta $D651       ; blitter addr
        lda #0          ;
        sta $D652



#68 Heaven/TQA OFFLINE  

Heaven/TQA

    Quadrunner

  • 10,359 posts
  • Location:Baden-Württemberg, Germany

Posted Sun Jan 24, 2010 2:52 PM

is there in Altirra an option where I can debug directly vbxe ram or look into it?

#69 Heaven/TQA OFFLINE  

Heaven/TQA

    Quadrunner

  • 10,359 posts
  • Location:Baden-Württemberg, Germany

Posted Sun Jan 24, 2010 3:18 PM

RTFM... now altirra shows the correct bcb in debugger...



char_bcb: 
		.long $004000 ;source adress
		.word 320 ;source step y
		.byte 1
		.long $004000+100+16*320 ;destination adress
		.word 320 ;dest. step y
		.byte 1
		.byte 15,0 ;size x
		.byte 15	;size y
		.byte 255 	;and
        .byte 0     ; XOR
        .byte 0       ;  collision AND
        .byte 1       ; zoom
        .byte 0       ; pattern
        .byte 1       ; control


#70 phaeron OFFLINE  

phaeron

    River Patroller

  • 2,281 posts
  • Location:USA

Posted Sun Jan 24, 2010 3:18 PM

Odd, that blitter setup should work. Any chance you may have accidentally hit the VBXE reset range at $D080-D0FF?

There currently isn't a way to peek directly at VBXE RAM -- you have to use the MEMAC A and B windows, switching banks by poking the control registers with the (e)nter command as necessary. The debugger currently only works in CPU view; giving it access to extended RAM isn't something I've gotten around to yet.

To see more of memory at once, you'll have to use the memory window. The 'db' command doesn't take a length parameter yet.

#71 Heaven/TQA OFFLINE  

Heaven/TQA

    Quadrunner

  • 10,359 posts
  • Location:Baden-Württemberg, Germany

Posted Sun Jan 24, 2010 3:24 PM

ah... ok... was too used to db start,end or db start-end or db start end

#72 Heaven/TQA OFFLINE  

Heaven/TQA

    Quadrunner

  • 10,359 posts
  • Location:Baden-Württemberg, Germany

Posted Sun Jan 24, 2010 3:29 PM

ok... most of the time it was my fault... damned... ;) always stupid bugs... this time... I have not enabled the blitter to start... ;)

Attached Thumbnails

  • vbxe_test.PNG

Edited by Heaven/TQA, Sun Jan 24, 2010 3:30 PM.


#73 Rybags OFFLINE  

Rybags

    Quadrunner

  • Topic Starter
  • 15,230 posts
  • Location:Australia

Posted Sun Jan 24, 2010 4:16 PM

Any guidelines or tips on exporting palettes from Photoshop or similar when designing 256 colour bitmapped images for VBXE?


For the pics I did (used Photoshop), I just converted from 24-bit to Indexed Color with one of the "Local" methods to bring it down to 256 colours.

You're only losing 1 bit per channel of RGB precision which is barely noticable. Of course the smaller palette means the pic will lose a bit of realism but it depends on the image.

I save as BMP with the image flipped (ie, right way up). Then it's a case of just skipping the header - 66 bytes (?)
Then you have the RGB for the palette which can just be loaded to RAM, stored in a Palette and discarded, followed by the bitmap data.

#74 Heaven/TQA OFFLINE  

Heaven/TQA

    Quadrunner

  • 10,359 posts
  • Location:Baden-Württemberg, Germany

Posted Sun Jan 24, 2010 4:24 PM

i am skipping 1078 bytes?

#75 Rybags OFFLINE  

Rybags

    Quadrunner

  • Topic Starter
  • 15,230 posts
  • Location:Australia

Posted Sun Jan 24, 2010 4:50 PM

Short program I have - skip 54 bytes, then read 256 times (R, G, B, null byte), then picture data.




0 user(s) are browsing this forum

0 members, 0 guests, 0 anonymous users