3 ms·

And he did it on an Apple 2. Those machines were good programming workstations, in the day, fast storage, lots of tools, and so forth, but high resolution grap

And he did it on an Apple 2. Those machines were good programming workstations, in the day, fast storage, lots of tools, and so forth, but high resolution graphics were hard to do fast. And it is not even palette shifting. The Apple has absolute colors. He literally made another draw routine that performed the XOR operation. For a modern day example of similar dedication, check this out: https://m.facebook.com/LawlessLegends/ https://m.facebook.com/LawlessLegends/ Python scripts create in line assembly for the ray caster, PLASMA byte code interpreter, big world, animations, and excellent use of the 6 colors and artifact art. A game this big would have been epic in the day. The team has been grinding away at it for some years now. It will end up being an exemplary example of an RPG, and on the Apple, that kind of game is in the sweet spot. What Jordan did was not really considered possible. PoP amazed many people!

DonHopkins 7y ago
Not just absolute colors, but absolutely bizarre Rube-Goldbergesque colors! https://en.wikipedia.org/wiki/Apple_II_graphics https://en.wikipedia.org/wiki/Apple_II_graphics
- ddingus 7y ago
  The big complication was 7 pixels per byte. Artifact colors work on even "bit boundaries" aligned with the colorburst. On pretty much every other computer, the same bit patterns resulted in the dame artifact colors, but the Apple had even and odd byte patterns, because the repeat took two bytes, not one like other machines. On the other hand, having that high bit shift the pixel clock a little meant 6 colors, plus black and white. Because of how artifacting works, that is actually enough to do anything. Until the PC and some machines like the color computer 3, artifact colors were limited. Red blue, kinds of things. The secondary complication was the screen addressing, which cost a table lookup. Had it been linear, overall draw speed would have been a bit faster.
  - DonHopkins 7y ago
    Right, within every even/odd group of seven pixels, the even/odd colors for each of those pixels were reversed. With the high bit switching between different sets of colors. And on top of that the vertical scan line interleaving. So many levels of owch! And punching through all that with an 8 bit 6502. It's really hard to appreciate how fucking hard any Apple ][ game that uses hires graphics had to work just to put a dot on the screen. https://en.wikipedia.org/wiki/Composite_artifact_colors#Apple_II https://en.wikipedia.org/wiki/Composite_artifact_colors#Appl... Even more amazing were the text/hires graphics adventure engines that stippled together different colors to get a wider palette. It was so hard for the poor 6502, that part of the visceral pleasure of the game was just sitting there watching it draw each scene. And all the visible text (IN UPPER CASE OF COURSE) must fit in the characteristic four lines at the bottom. Since it drew the scene so slowly, there was enough time to read the text before it scrolled off the top. Talk about making lemonade out of lemons, due to technical limitations! Hi-Res Adventure #4: Ulysses and the Golden Fleece for the Apple II https://www.youtube.com/watch?v=QTFNKbkxeY8 https://www.youtube.com/watch?v=QTFNKbkxeY8
    - LocalH 7y ago
      Not to mention that the HGR screen was also interleaved, rather than linear. Also, if you factor in DHGR, you remove the half-pixel shift, but instead you operate like you do in 80 column text mode, with the even columns of 7 pixels being in the normal high-res memory map, and the odd columns being in the auxiliary 80-column memory, on top of the normal HGR interleaving. Certainly a lot to wrap your head around as compared to other video subsystems. http://www.appleoldies.ca/graphics/dhgr/dhgrtechnote.txt http://www.appleoldies.ca/graphics/dhgr/dhgrtechnote.txt
      - DonHopkins 7y ago
        When your only registers are a 8 bits X, Y, and A, the hires screen memory was practically encrypted! It felt so fucking amazing to finally have a computer with a normal 1 pixel : 1 byte memory mapped display. But before that, I played around with the Sun CG1 graphics board (on a Sun 2: I mmap'ed /dev/cgone0, but maybe it was actually a cgtwo card, not sure), which was kinda but not really memory mapped. http://www.sunhelp.org/faq/FrameBufferHistory.html http://www.sunhelp.org/faq/FrameBufferHistory.html It had 8 bit color mapped pixels, and it had an implicit read position and write position, such that you could address a row and column of pixels at a time, one pair for reading and one for writing ("rop mode memory"). When you accessed a column of the row block of memory, that set which column you could address in the other column block of memory. When you accessed a row of the the column block of memory, that set which row you could address in the other row block of memory! As it turned out, that just happened to be useful for drawing lines and filling trapazons and performing raster operations, but it made random access quite inefficient, and was a huge pain in the ass for anything else. (Although nowhere near as painful as Apple ][ graphics, but a lot more expensive!) I think the early X10 and X11 servers actually supported it (SunView [SunTools at the time] certainly did), but it was really really slow. I learned later than John Gilmore had written weird union structs the .h file to describe the memory mapped registers, when he was at Sun in its early days: https://donhopkins.com/home/archive/forth/cg/cg2reg.h https://donhopkins.com/home/archive/forth/cg/cg2reg.h Here's some Forth and 68K code I wrote to play around with that card (notice how register offsets gr_x_select / gr_y_select, 68k code xsel / ysel, and Forth words lineaddr / coladdr work together -- yes Forth can mmap device registers, and that is RPN 68k assembly code, with opcodes at the end of the line!): https://donhopkins.com/home/archive/forth/cg/cgone.f https://donhopkins.com/home/archive/forth/cg/cgone.f : getfb 0 bytes/fb [""] /dev/cgone0 mapin >fb ! ; https://donhopkins.com/home/archive/forth/cg/cg.f https://donhopkins.com/home/archive/forth/cg/cg.f code xsel ( x --- addr ) >fb l#) d0 long move gr_x_select gr_update + l# d0 long add d0 sp ) add next c; code ysel ( y --- addr ) >fb l#) d0 long move gr_y_select gr_update + l# d0 long add d0 sp ) add next c; https://donhopkins.com/home/archive/forth/cg/fline.f https://donhopkins.com/home/archive/forth/cg/fline.f https://donhopkins.com/home/archive/forth/cg/iline.f https://donhopkins.com/home/archive/forth/cg/iline.f
scarface74 7y ago
Did it use double hires graphics? That was even harder to do correctly. Half the graphics memory was in the first 64K of memory ($2000-$4000) and the other half was stored in the second bank switched 64K of memory.
- ddingus 7y ago
  The only double hires was on the title screen. Maybe the princess scenes too.

DonHopkins 7y ago

Not just absolute colors, but absolutely bizarre Rube-Goldbergesque colors! https://en.wikipedia.org/wiki/Apple_II_graphics https://en.wikipedia.org/wiki/Apple_II_graphics

ddingus 7y ago
The big complication was 7 pixels per byte. Artifact colors work on even "bit boundaries" aligned with the colorburst. On pretty much every other computer, the same bit patterns resulted in the dame artifact colors, but the Apple had even and odd byte patterns, because the repeat took two bytes, not one like other machines. On the other hand, having that high bit shift the pixel clock a little meant 6 colors, plus black and white. Because of how artifacting works, that is actually enough to do anything. Until the PC and some machines like the color computer 3, artifact colors were limited. Red blue, kinds of things. The secondary complication was the screen addressing, which cost a table lookup. Had it been linear, overall draw speed would have been a bit faster.
- DonHopkins 7y ago
  Right, within every even/odd group of seven pixels, the even/odd colors for each of those pixels were reversed. With the high bit switching between different sets of colors. And on top of that the vertical scan line interleaving. So many levels of owch! And punching through all that with an 8 bit 6502. It's really hard to appreciate how fucking hard any Apple ][ game that uses hires graphics had to work just to put a dot on the screen. https://en.wikipedia.org/wiki/Composite_artifact_colors#Apple_II https://en.wikipedia.org/wiki/Composite_artifact_colors#Appl... Even more amazing were the text/hires graphics adventure engines that stippled together different colors to get a wider palette. It was so hard for the poor 6502, that part of the visceral pleasure of the game was just sitting there watching it draw each scene. And all the visible text (IN UPPER CASE OF COURSE) must fit in the characteristic four lines at the bottom. Since it drew the scene so slowly, there was enough time to read the text before it scrolled off the top. Talk about making lemonade out of lemons, due to technical limitations! Hi-Res Adventure #4: Ulysses and the Golden Fleece for the Apple II https://www.youtube.com/watch?v=QTFNKbkxeY8 https://www.youtube.com/watch?v=QTFNKbkxeY8
  - LocalH 7y ago
    Not to mention that the HGR screen was also interleaved, rather than linear. Also, if you factor in DHGR, you remove the half-pixel shift, but instead you operate like you do in 80 column text mode, with the even columns of 7 pixels being in the normal high-res memory map, and the odd columns being in the auxiliary 80-column memory, on top of the normal HGR interleaving. Certainly a lot to wrap your head around as compared to other video subsystems. http://www.appleoldies.ca/graphics/dhgr/dhgrtechnote.txt http://www.appleoldies.ca/graphics/dhgr/dhgrtechnote.txt
    - DonHopkins 7y ago
      When your only registers are a 8 bits X, Y, and A, the hires screen memory was practically encrypted! It felt so fucking amazing to finally have a computer with a normal 1 pixel : 1 byte memory mapped display. But before that, I played around with the Sun CG1 graphics board (on a Sun 2: I mmap'ed /dev/cgone0, but maybe it was actually a cgtwo card, not sure), which was kinda but not really memory mapped. http://www.sunhelp.org/faq/FrameBufferHistory.html http://www.sunhelp.org/faq/FrameBufferHistory.html It had 8 bit color mapped pixels, and it had an implicit read position and write position, such that you could address a row and column of pixels at a time, one pair for reading and one for writing ("rop mode memory"). When you accessed a column of the row block of memory, that set which column you could address in the other column block of memory. When you accessed a row of the the column block of memory, that set which row you could address in the other row block of memory! As it turned out, that just happened to be useful for drawing lines and filling trapazons and performing raster operations, but it made random access quite inefficient, and was a huge pain in the ass for anything else. (Although nowhere near as painful as Apple ][ graphics, but a lot more expensive!) I think the early X10 and X11 servers actually supported it (SunView [SunTools at the time] certainly did), but it was really really slow. I learned later than John Gilmore had written weird union structs the .h file to describe the memory mapped registers, when he was at Sun in its early days: https://donhopkins.com/home/archive/forth/cg/cg2reg.h https://donhopkins.com/home/archive/forth/cg/cg2reg.h Here's some Forth and 68K code I wrote to play around with that card (notice how register offsets gr_x_select / gr_y_select, 68k code xsel / ysel, and Forth words lineaddr / coladdr work together -- yes Forth can mmap device registers, and that is RPN 68k assembly code, with opcodes at the end of the line!): https://donhopkins.com/home/archive/forth/cg/cgone.f https://donhopkins.com/home/archive/forth/cg/cgone.f : getfb 0 bytes/fb [""] /dev/cgone0 mapin >fb ! ; https://donhopkins.com/home/archive/forth/cg/cg.f https://donhopkins.com/home/archive/forth/cg/cg.f code xsel ( x --- addr ) >fb l#) d0 long move gr_x_select gr_update + l# d0 long add d0 sp ) add next c; code ysel ( y --- addr ) >fb l#) d0 long move gr_y_select gr_update + l# d0 long add d0 sp ) add next c; https://donhopkins.com/home/archive/forth/cg/fline.f https://donhopkins.com/home/archive/forth/cg/fline.f https://donhopkins.com/home/archive/forth/cg/iline.f https://donhopkins.com/home/archive/forth/cg/iline.f

scarface74 7y ago

Did it use double hires graphics? That was even harder to do correctly. Half the graphics memory was in the first 64K of memory ($2000-$4000) and the other half was stored in the second bank switched 64K of memory.

ddingus 7y ago
The only double hires was on the title screen. Maybe the princess scenes too.