This is my snippet with PRINT functions that mimic Apple II text artefacts.
function _init()
sfx(0)
end
function _draw()
cls()
nprint("normal",1,0)
iprint("inverse",1,2)
fprint("flash",1,4)
hprint("hirez artefact",1,6)
hiprint("hirez artefact inverse",1,8)
nprint([[
nprint
iprint
fprint
hprint
hiprint
(x,y) coordinater are in
caracters not in pixels!
32 x 20
]],1,10)
end
-- apple ii prints
function iprint(_str,_x,_y)
l=#_str*4-1
rectfill(_x*4,_y*6,_x*4+l,_y*6+5,7)
print(_str,_x*4,_y*6,0)
end
function fprint(_str,_x,_y)
l=#_str*4-1
print(_str,_x*4,_y*6,7)
if (time()%.5>.2) then
rectfill(_x*4,_y*6,_x*4+l,_y*6+5,7)
print(_str,_x*4,_y*6,0)
end
end
function nprint(_str,_x,_y)
print(_str,_x*4,_y*6,7)
end
function hprint(str,_x,_y)
_x*=4
_y*=6
print(str,_x,_y,3)
print(str,_x+2,_y,2)
print(str,_x+1,_y,7)
end
function hiprint(str,_x,_y)
_x*=4
_y*=6
rectfill(_x,_y,_x+#str*4,_y+5,7)
print(str,_x,_y,3)
print(str,_x+2,_y,2)
print(str,_x+1,_y,0)
end
|
You beat me to the punch on this one, @BGelais. :)
Gold star for innovation.
However, these artifacts you wrote are more "forgiving" than a true Apple as can be seen thus:
The color white can only be seen if there are 2-pixels connected horizontally. There are no exceptions unless your monitor is truly B&W only.
Color shift can only occur from the 8th bit which ultimately shifts the 7-bits a half a pixel over. So colors such as orange cannot be mixed on the same byte with purple or green. See following:
Orange cannot be mixed with purple or green.
Aqua cannot be mixed with purple or green.
Purple cannot be mixed with orange or aqua.
Green cannot be mixed with orange or aqua.
Now they CAN be mixed if you use two bytes. That is you have some colored pixels appear in the first byte and new colors appear in the 2nd byte, but there will always be a 7-pixel distance disparity to this method.
Flashing text can only appear on real text either in normal 24-line text mode or when you are in mixed graphics mode, that is the pixel screen above of 280x160 and 4-lines of normal text will appear below. Or if you are using mixed graphics mode in LORES. Where you have 40x40 16-color pixels above and 4-lines of normal text below.
The standard resolution of the HIRES screen is 280x192 if you go full-screen.
Quoting from Wikipedia:
The Apple II display provides two pixels per NTSC subcarrier cycle. When the color burst reference signal is on and the computer attached to a color display, it can display green by showing one alternating pattern of pixels, magenta with an opposite pattern of alternating pixels, and white by placing two pixels next to each other. Later, blue and orange became available by tweaking the offset of the pixels by half a pixel-width in relation to the color-burst signal. The high-resolution display offers more colors simply by compressing more, narrower pixels into each subcarrier cycle.
Previous to discovering your post here I was working on a variation of the Apple ]['s curious and unique way of getting color to appear in 8192-bytes.
I'll post it a little later today. A method of achieving 6-colors in 128x128 pixeled screen using only 2048-bytes of storage and a method quite different than the Apple ][.
@dw817 Thanks for sharing this. Hopefully on others fantasy consoles like LowresNx and TIC-80 we can do custom multicolor sprite based font.
I see you are a lot like me, @BGelais, writing tools that can in turn be used to ease the creation of future carts.
Years ago for the Apple ][ Robert C Clardy wrote a program called, "Hi-Resolution Character Generator" or HRCG for short.
When I was 12-years old, I drew these fonts in it. Be aware that these fonts are NOT 7x8 but a true 8x8 is why the color shifts each time for each character.
^ COLOR COMPOSITE MONITOR ^
^ COLOR RGB MONITOR ^
^ COLOR TV ^
^ MONOCHROME MONITOR ^
It may help show the color shift better.
I wrote my own convert B&W to color for Pico-8 found HERE:
https://www.lexaloffle.com/bbs/?tid=45179
On HRCG, I'm definitely seeing a need for some type of program like this, written in Pico-8 where you can access your total sprites.
I was working on something like this years ago ... let me see if I can find that. Masses of code I wrote.
BTW is there a way in Pico-8 to create a variable type or array that is a byte where it can only contain a value from 0-255 and is stored this way instead of using 4-bytes per variable ?
A={BASE 8}
And oh yeah, since the advent of Tac-08 for the RG-350 which runs some carts and P8 for my cellphone which runs ALL carts, I am definitely back into coding Pico-8. :)
[Please log in to post a comment]
