fdraw: fast Apple II graphics routines

[fadden]

About 9.5 years back, after some discussion on comp.sys.apple2.programmer, I wrote some code to draw filled circles. It was trivial to add filled rectangles, so I added that and threw in a screen clear. I called it "fdraw v0.2" and kicked it out the door.

I had so much fun working on fhpack that I decided to revive fdraw, adding points, lines, and outline circles and rectangles. I gave it an ampersand interface ("&HPLOT") to make it easier to use from Applesoft, and wrote some demos. It got a bit bigger and a bit faster.

It's not done, and I don't know that it ever will be, so this is version 0.3.

Demo video is here: https://www.youtube.com/watch?v=z2RFGVoaROE

Source code and disk images are here: https://github.com/fadden/fdraw

Enjoy.

[Denis Molony]

About 33 years ago I needed to draw text on the hi-res screens, so I spent weeks creating shape tables for the ascii character set. I also had a lot of fun, but the output was very slow when plotting each letter.

Is there a better/faster way to achieve this? The characters need to be plottable at any position on the screen (ie not just mimic the layout of the text screen).

I've seen articles that talk about using the character ROM rather than shape tables, is that possible?

[fadden]

The character ROM is not addressable. IIRC there was a hardware hack (from Lazer?) that let you upload character data to the text generator, but I can't remember what it was called.

I'm sure you've seen the various Hi-Res Character Generators (Higher Text, Apple's HRCG, the fancy multi-font one in Starship Commander, ...), but most of them attempt to mimic the text screen. This tends to be faster and easier, because the characters line up on byte boundaries, so you just copy 8 bytes from the font to the screen. You can also use VTAB and HTAB for positioning. For arbitrary positioning you have to shift bits and write data into two adjacent bytes, merging with whatever was previously on-screen.

Beagle Graphics has an &PRINT command that lets you draw text at an arbitrary position on the DHGR screen (set with &GOTO). I'm not sure exactly what they're doing, but their font files are 768 bytes long -- 8 bytes for each of the characters from 32 through 127 -- so I'd guess its a standard bitmap font.

I believe Apple Mechanic had shape-table-based fonts, but those would have the performance issues you noted.

[gid...@sasktel.net]

This subject has come up a few times in comp.sys.apple. The best one and, really, only one I have seen so far is the one in Nibble magazine called "PRINTWORKS".

It has Horizontal Leading, Vertical Leading, character spacing, Horizontal and Vertical Print control, Inverse Printing and, Super and Sub characters.

It also comes with its own Font editor since the shape table is different than regular hi-res shape tables.

Nibble magazine, has been and still is, my biggest information source for learning, using their programs and writing new programs.

I have every magazine and it is well worth the price.

http://www.nibblemagazine.com/Nibble_Magazines.htm

Rob

[sicklittlemonkey]

On Saturday, 22 August 2015 10:16:14 UTC+12, Denis Molony wrote:
> Is there a better/faster way to achieve this? The characters need to be plottable at any position on the screen (ie not just mimic the layout of the text screen).

Just download Assembly Lines: The Complete Book.
https://archive.org/details/AssemblyLinesCompleteWagner

Chapter 31 walks you through a simple Hires Character Generator.

Cheers,
Nick.

[Steven Weyhrich]

Andy, I posted a comment on the YouTube video, but let me say it here also: Bravo, job well done! Now I just need a flux capacitor that is USB enabled, and email these routines to myself in 1982!

[Scott Alfter]

In article <88771691-121e-4099...@googlegroups.com>,

fadden <thef...@gmail.com> wrote:
>On Friday, August 21, 2015 at 3:16:14 PM UTC-7, Denis Molony wrote:
>> Is there a better/faster way to achieve this? The characters need to
>be plottable at any position on the screen (ie not just mimic the layout
>of the text screen).
>

>I'm sure you've seen the various Hi-Res Character Generators (Higher
>Text, Apple's HRCG, the fancy multi-font one in Starship Commander,
>...), but most of them attempt to mimic the text screen. This tends to
>be faster and easier, because the characters line up on byte boundaries,
>so you just copy 8 bytes from the font to the screen.

This. Positioning on arbitrary coordinates would slow things down
considerably, especially when you're already slinging around 8x more data to
render text as graphics.

>Beagle Graphics has an &PRINT command that lets you draw text at an
>arbitrary position on the DHGR screen (set with &GOTO). I'm not sure
>exactly what they're doing, but their font files are 768 bytes long -- 8
>bytes for each of the characters from 32 through 127 -- so I'd guess its
>a standard bitmap font.

I knocked together a text generator a while back, linked here:

https://alfter.us/wp/computers/apple-ii/software/

It's based on the same coordinates as the text screen (so it doesn't allow
arbitrary positioning), but it hooks into the system with
PR#A$xxxx/IN#A$xxxx so that ordinary text commands (PRINT, etc.) work.
Hi-Res (40-column) and Double Hi-Res (80-column) versions are included.
Scrolling is also implemented.

_/_
/ v \ Scott Alfter (remove the obvious to send mail)
(IIGS( https://alfter.us/ Top-posting!
\_^_/ >What's the most annoying thing on Usenet?

[Warren Ernst]

Loved the Demo, and the story behind revisiting your old code. Wonderful!

-Warr

[qkumba]

> I'm sure you've seen the various Hi-Res Character Generators (Higher Text, Apple's HRCG, the fancy multi-font one in Starship Commander, ...), but most of them attempt to mimic the text screen. This tends to be faster and easier, because the characters line up on byte boundaries, so you just copy 8 bytes from the font to the screen. You can also use VTAB and HTAB for positioning. For arbitrary positioning you have to shift bits and write data into two adjacent bytes, merging with whatever was previously on-screen.

However, you need the specialized version only when ((X Or Y) And 7) <> 0.

[Glaeken Trismegestus]

Thanks so much for releasing this.


--- news://freenews.netfront.net/ - complaints: ne...@netfront.net ---

[mark.l...@gmail.com]

thank you!! this looks like an incredible resource.

[Michael 'AppleWin Debugger Dev']

On Friday, August 21, 2015 at 5:12:44 PM UTC-7, fadden wrote:
> I'm sure you've seen the various Hi-Res Character Generators (Higher Text, Apple's HRCG, the fancy multi-font one in Starship Commander, ...), but most of them attempt to mimic the text screen. This tends to be faster and easier, because the characters line up on byte boundaries, so you just copy 8 bytes from the font to the screen. You can also use VTAB and HTAB for positioning. For arbitrary positioning you have to shift bits and write data into two adjacent bytes, merging with whatever was previously on-screen.

Add another one to the list. My tutorial aims to be complete. What is novel is that Javascript is used to read a PNG and generate the 7x8 hex bytes.

https://github.com/Michaelangel007/apple2_hgr_font_tutorial

Table of Contents:

Introduction
Functions we want & will write
Hard-Coded: A
Quirks of the Apple HGR screen
Non-Linear Memory
No FONT data in ROM
HGR bytes are reversed
Half-pixel shift
Font Data
Raw Font Data
Image to Font Data (Javascript)
Font -> Screen Memory Trace
DrawChar version 1
X Cursor Position
CursorCol()
DrawChar() version 2
DrawChar() version 3
Character Inspector
Character Inspector version 2
Character Inspector version 3
Y Cursor Position
Natural Params CursorColRow()
DrawString()
Recap
Copy text screen to HGR
Exercise 1: ScrollHgrUpLine()
Exercise 2: ScrollHgrUpPixel()
Solution 1: ScrollHgrUpLine()
Solution 2: ScrollHgrUpPixel()
References

[BLuRry]

On Friday, August 21, 2015 at 4:56:54 PM UTC-5, fadden wrote:

Related, we have quite a bit of tight/optimized routines in the lawless legends code. I wrote a very speedy tile drawing routine that employs unrolled loops to blit 14x16 size tiles to the screen. Of course, it didn't actually work until Martin fixed it and integrated to the rest of our code -- including his awesome memory manager which shuffles tilesets and map fragments around. If anyone needs help finding the code let me know. :D

-B