Jump to content
IGNORED

Double Hi-Res Graphics


whiteplanet

Recommended Posts

The program should work fine with or without DOS.

 

The dbl-hi-res screen views random graphics for page 1 or a picture if one was previously loaded and random graphics for screen #2.

 

The four lines at the bottom of the screen should tell you which dbl-hi-res screen you are viewing, and while viewing screen #2 you will see text on text page #2.

 

While viewing screen#2 the program then clears screen #1 to all white, then switches to view screen #1 and text page #1.

 

I didn't get too extravagant with the graphics as the program was getting long enough.

 

When booting up, make sure the FLASH command is not invoked at any time. If you have a startup program, rename it to something else temporarily and let it boot straight to the applesoft prompt. Then follow the directions given earlier.

Link to comment
Share on other sites

  • 2 months later...
  • 4 weeks later...
  • 2 weeks later...
  • 3 weeks later...

 

Part Nine - is now up, where I tie everything together with a nice API -- as an added bonus I show off my (lack of) artistic talent!

 

 

I've also started using the domain http://battlestations.zone - all the old links to my previous (and somewhat pretentious) domain http://lastrationalman.blogspot.com will get redirected.

 

Thanks! Your articles are awesome and I am really looking forward to the future articles. Please keep them coming! I am really looking forward to seeing how to handle animated objects moving on a background.

  • Like 1
Link to comment
Share on other sites

  • 1 month later...

This deficiency about not being able to examine/change a DHGR screen at the bit level has been addressed. Please see my DHGR.BYTE program.

https://github.com/Michaelangel007/apple2_hgrbyte

 

Examples, and full assembly source is included.

 

Michael

AppleWin Developer

 

 

Oh what about sprite tools!

 

Speaking of DHR drawing programs, there are only two I know of for the Apple II - 816 Paint and Dazzle Draw. I use them both. Often I draw a sprite sheet using Dazzle Draw then write a BASIC program to load it and get it into the format I want and save it as a binary file. One annoying thing is that neither of these programs lets you manipulate individual bits.

Link to comment
Share on other sites

  • 1 month later...
  • 6 months later...

I take it that there are no more tutorials.

 

I apologize. Things have been busy for me for a while now. I do have some work half done (one on character generators, one on using a slice algorithm and other line drawing enhancements) but I'm not sure when I'll get them up.

  • Like 1
Link to comment
Share on other sites

  • 2 years later...

I know this topic is years old at this point but I've been having such a good time going through Sarkeizen's tutorial series.  Sarkeizen if by some chance you read this: thank you so much for demystifying DHGR.

 

I reached the (current?) end of the series and wanted more so I took a shot at doing a couple of the next steps mentioned.  I expanded the drawing driver to be able to do filled rectangles and single plots. Then I took a crack at a character generator so I could at least print some text to the screen which worked out better than I thought it would!  I then extended the driver to have a 'DrawString' command so its an easy matter of providing a couple bytes for location and an address to a null terminated string and it'll plot it out.

 

Then I took a shot at rendering tiles and have got that up and running:

 

1776552039_ScreenShot2021-03-24at5_43_31PM.thumb.png.1364f9a5b36f565ca50298c569753fd7.png

 

Bonus shot of the kludgiest tile editor ever:

1294852320_ScreenShot2021-03-24at5_47_25PM.thumb.png.c95f80614bd1cc7bc1ad5090417e26e1.png

 

I wrapped up the drawing commands into a set of macros which makes for some easy usage.  The code for the textbox in the screenshot looks like this:

 

  dhrBeginDraw
    dhrSetWhite
    dhrDrawRect 20, 20, 60, 30
    dhrDrawLine 65, 50, 71, 50
    dhrDrawLine 66, 51, 70, 51
    dhrDrawLine 67, 52, 69, 52
    dhrPut 68,53
    dhrSetDarkBlue
    dhrDrawLine 63, 52, 18, 52
    dhrDrawLineCont 18, 18
    dhrDrawLineCont 81, 18
    dhrDrawLineCont 81, 52
    dhrDrawLineCont 73, 52
    dhrSetBlack
    dhrDrawString 22, 22, hello
  dhrEndDraw

 

So at this point while I have a functional tile renderer I do not have a very performant one and am looking at ways to speed it up.  The blitter is actually plotting each pixel one at a time with the associated lookups for main/aux ram, color, etc.  I would love to find a way to somehow just copy bytes to the right place and speed it way up.  Sarkeizen if you ever come back to this I would kill for a fast dhires block blitting routine! :)

 

Edited by orphean
  • Like 1
Link to comment
Share on other sites

There is a bug I have to correct first, which isn't easy to find.  But the bug only happens when there is an odd number of pixels in the shape.

 

The draw routine is pretty basic.  It can draw a shape starting at any multiple of 4-bits or 1x color pixel.  Just needs left coordinates of (0-139) and top (0-191) and will not draw off the screen.

 

The shape table is set up exactly the same way as the hi-res shape table, except the data stores pixel colors and not direction bits.

 

Starting with address of shape table:

#0 = # of shapes

#1 = is always zero

#2.3 offset to 1st shape

#4.5 offset to 2nd shape

...

max # of shapes according to offset #0

 

(each shape has this setup)

Width byte in pixels

Height byte in lines

- followed by data of W/2 x H bytes

 

 

Note: the W/2 is used because each nybble holds the color of one pixel.  Meaning 2 pixels per byte.

 

Are you on Messenger at all, Orphean? 

Edited by Iamgroot
Link to comment
Share on other sites

Ah, I am not on Messenger Groot, at least not for some years.  That said, I think I'm starting to understand this better.  I decided to take a shot at a routine to clear the DHGR screen to any color since it would force me to really work through the structure of the screen memory. 

 

Since 4 bytes encodes 7 pixels on the screen, I made a routine that moved pre-computed byte values directly into screen memory in 4 byte increments (2 for Main, 2 for Aux):

; dhrClearScreenToColor
; Params: Color in A, 0-15
; Destroys A, X, Y
.proc dhrClearScreenToColor
  and #$0f
  tay
  lda clearColorLo, y
  sta CLRP
  lda clearColorHi, y
  sta CLRP+1
  ldy #0
  lda (CLRP), y
  sta A1
  iny
  lda (CLRP), y
  sta M1
  iny
  lda (CLRP), y
  sta A2
  iny
  lda (CLRP), y
  sta M2

  ldx #0
L:
  sta PAGE1

  lda M1

  sta $2000, x
  sta $2100, x
  sta $2200, x
  sta $2300, x
  sta $2400, x
  sta $2500, x
  sta $2600, x
  sta $2700, x
  sta $2800, x
  sta $2900, x
  sta $2A00, x
  sta $2B00, x
  sta $2C00, x
  sta $2D00, x
  sta $2E00, x
  sta $2F00, x
  sta $3000, x
  sta $3100, x
  sta $3200, x
  sta $3300, x
  sta $3400, x
  sta $3500, x
  sta $3600, x
  sta $3700, x
  sta $3800, x
  sta $3900, x
  sta $3A00, x
  sta $3B00, x
  sta $3C00, x
  sta $3D00, x
  sta $3E00, x
  sta $3F00, x

  inx
  lda M2

  sta $2000, x
  sta $2100, x
  sta $2200, x
  sta $2300, x
  sta $2400, x
  sta $2500, x
  sta $2600, x
  sta $2700, x
  sta $2800, x
  sta $2900, x
  sta $2A00, x
  sta $2B00, x
  sta $2C00, x
  sta $2D00, x
  sta $2E00, x
  sta $2F00, x
  sta $3000, x
  sta $3100, x
  sta $3200, x
  sta $3300, x
  sta $3400, x
  sta $3500, x
  sta $3600, x
  sta $3700, x
  sta $3800, x
  sta $3900, x
  sta $3A00, x
  sta $3B00, x
  sta $3C00, x
  sta $3D00, x
  sta $3E00, x
  sta $3F00, x

  dex
  sta PAGE2

  lda A1

  sta $2000, x
  sta $2100, x
  sta $2200, x
  sta $2300, x
  sta $2400, x
  sta $2500, x
  sta $2600, x
  sta $2700, x
  sta $2800, x
  sta $2900, x
  sta $2A00, x
  sta $2B00, x
  sta $2C00, x
  sta $2D00, x
  sta $2E00, x
  sta $2F00, x
  sta $3000, x
  sta $3100, x
  sta $3200, x
  sta $3300, x
  sta $3400, x
  sta $3500, x
  sta $3600, x
  sta $3700, x
  sta $3800, x
  sta $3900, x
  sta $3A00, x
  sta $3B00, x
  sta $3C00, x
  sta $3D00, x
  sta $3E00, x
  sta $3F00, x

  inx
  lda A2

  sta $2000, x
  sta $2100, x
  sta $2200, x
  sta $2300, x
  sta $2400, x
  sta $2500, x
  sta $2600, x
  sta $2700, x
  sta $2800, x
  sta $2900, x
  sta $2A00, x
  sta $2B00, x
  sta $2C00, x
  sta $2D00, x
  sta $2E00, x
  sta $2F00, x
  sta $3000, x
  sta $3100, x
  sta $3200, x
  sta $3300, x
  sta $3400, x
  sta $3500, x
  sta $3600, x
  sta $3700, x
  sta $3800, x
  sta $3900, x
  sta $3A00, x
  sta $3B00, x
  sta $3C00, x
  sta $3D00, x
  sta $3E00, x
  sta $3F00, x

  inx
  beq Done
  jmp L
Done:
  rts
.endproc

AllBlack:
  .byte 0, 0, 0, 0
AllDarkBlue:
  .byte %00010001, %00100010, %01000100, %00001000
AllDarkGreen:
  .byte %00100010, %01000100, %00001000, %00010001
AllMedBlue:
  .byte %00110011, %01100110, %01001100, %00011001
AllBrown:
  .byte %01000100, %00001000, %00010001, %00100010
AllGrey2:
  .byte %01010101, %00101010, %01010101, %00101010
AllGreen:
  .byte %01100110, %01001100, %00011001, %00110011
AllAqua:
  .byte %01110111, %01101110, %01011101, %00111011
AllRed:
  .byte %00001000, %00010001, %00100010, %01000100
AllViolet:
  .byte %00011001, %00110011, %01100110, %01001100
AllGrey1:
  .byte %00101010, %01010101, %00101010, %01010101
AllLtBlue:
  .byte %00111011, %01110111, %01101110, %01011101
AllOrange:
  .byte %01001100, %00011001, %00110011, %01100110
AllPink:
  .byte %01011101, %00111011, %01110111, %01101110
AllYellow:
  .byte %01101110, %01011101, %00111011, %01110111
AllWhite:
  .byte $7f, $7f, $7f, $7f

clearColorLo:
  .byte <AllBlack
  .byte <AllRed
  .byte <AllBrown
  .byte <AllOrange
  .byte <AllDarkGreen
  .byte <AllGrey1
  .byte <AllGreen
  .byte <AllYellow
  .byte <AllDarkBlue
  .byte <AllViolet
  .byte <AllGrey2
  .byte <AllPink
  .byte <AllMedBlue
  .byte <AllLtBlue
  .byte <AllAqua
  .byte <AllWhite

clearColorHi:
  .byte >AllBlack
  .byte >AllRed
  .byte >AllBrown
  .byte >AllOrange
  .byte >AllDarkGreen
  .byte >AllGrey1
  .byte >AllGreen
  .byte >AllYellow
  .byte >AllDarkBlue
  .byte >AllViolet
  .byte >AllGrey2
  .byte >AllPink
  .byte >AllMedBlue
  .byte >AllLtBlue
  .byte >AllAqua
  .byte >AllWhite

One thing that was unclear in Sarkeizen's writeup was which bit positions A, B, C, D, etc represented.  After some munging around I figured it out, here are the documented bit values in case it helps someone else:

  ; A1       M1       A2       M2
  ; PBBBAAAA PDDCCCCB PFEEEEDD PGGGGFFF
  ;  2341234  3412341  4123412  1234123

  ; AAAA BBBB CCCC DDDD EEEE FFFF GGGG
  ; 1000 1000 1000 1000 1000 1000 1000

  ; A1: %01100110
  ; M1: %01001100
  ; A2: %00011001
  ; M2: %00110011

And I made quick spreadsheet to generate the 'packed' values of each of the four bytes for all 16 colors which is where the color values came from:

table.thumb.png.1da1368638588b25a894ab1447b0c592.png

 

And in the end I have a very fast routine that clears the screen to any color!

 

So now for fast tile rendering, I just need to make the tiles a multiple of 7 for the width and, since I understand now how the bits relate to pixel data, I should be able to just copy the tile data directly into screen memory.  This also lets me use page flipping if I see some tearing happening.

 

I think my current block renderer is still useful for other purposes like when I need to read screen data to insert an image over existing image data. But I'm excited to see the performance of the new method.

 

Edited by orphean
Link to comment
Share on other sites

So, by incorporating what I learned with my fast dhires screen clear routine into a tile render I managed to vastly speed up tile rendering.  It's much, much quicker than my initial attempt but just slow enough to still cause a perceptible redraw.  But, by using dhires page flipping, it is just about perfect.  Plenty fast for scrolling and tile animation even when just dumbly drawing the entire map every frame.  Here's a little example of the page flipping map renderer in action:

 

tiles.thumb.gif.71aecd830cbbe32c08278415b3103438.gif

 

I left space around the map for UI and such but I'm quite happy with the results so far.

  • Like 1
Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...