By the way, thanks deSilva and stevenmess2004 for some of the early comments in this neat thread. In my attempts to make a learning graphics driver, I ended up using the address variable stevenmess2004 mentioned and it works great and only needs 1 long per routine.
Added a "worm".
Filled boxes now pulsing. This shows the limits of this technique - to avoid flicker the vertical sync is waited for which slows down things considerably! Nevertheless it still flickers with a really large box...
Two phases now
- width(0): looks fine except text and some detail of box
- width(2): does not look so good...
We could make it wait for the vertical sync in cog for some fill commands (I'll just add a new command before the current fill command to make it wait and then you can do either). If we can't get the round pixels working (I don't think that we can) then we can just draw boxes as two triangles (quad) which should be quicker than the 4 fills plus 4 corners.
We should not forget that the main application is drawing static images, and doing fancy double buffered demonstrations which should not be delayed. Waiting for the sync in the main program is easy.
I shall play a little bit more with the triangles, I think......
deSilva said...
We should not forget that the main application is drawing static images, and doing fancy double buffered demonstrations which should not be delayed. Waiting for the sync in the main program is easy.
Yes, but I will make it into a separate call and it takes a while to get through the spin code as there is a reasonable amount of it.
Now if we can just find someone to do a new font.... Their not really my speciality.
I should have an update in a few minutes.
Post Edited (stevenmess2004) : 2/14/2008 12:43:33 AM GMT
Update time. have added a function boxSync that waits for the sync in the cog so it has a little more time. You now need to pass the sync ptr in when you start. Also am in the process of making quads work - The XOR works but it currently has a gap between the triangles Also added VIRAND's pixelColor function although this is not tested.
I don't know what can be done about overlapping boxes like in your demo though.
The "overlapping" boxes are o.k. This is a feature, not a bug Using XOR is a spicific technique with known limitations. It can NOT substitute full double buffering.
But it is is a nice work around when needing the memory for code and true data rather than for a second video buffer.... Its main application is "marking" things, as with cursors, marquees. general highlighting....
Time for an update.
State of affairs all for pixel width of 0
Lines - Works
Boxes - Works if you boxXOR or boxXORSync (I think). deSilva's demo doesn't but the boxes in the codes here work fine.
Vector Sprites - Works
Text -Works but the current font is ugly
Pixel Sprites -Appears to work
Triangles -Works
Arcs -Appears to work
Quads -Don't work, they have a line through the middle
Pixel widths of other than 0 will probably not be supported unless someone can come up with a new algorithm.
Would people be interested in being able to scale characters the same as vectors i.e. $100 is one allowing some fraction multiples instead of just integer?
Edit: updated table and download
Post Edited (stevenmess2004) : 2/15/2008 10:37:30 AM GMT
Here a new version of the test routines:
- I added a Glyph routine, using the ROM font (16x32).
The internal font looks VERY ugly in XOR mode only; "framed text demo" now displays an overlayed text, and then XORs it, showing the points of trouble
- I was not able to get boxXORsync to sync...
The demos:
(1) 20 seconds Moving ROM Glyphs, standard size (16x32), funnily look also good doubled (width(1)) in XOR mode, look also "interesting" in larger width
(2) Slow Worm, showing principle
(3) Fast Worm, showing that XOR works fine (no artefacts!), wrap around effects are normal and done with purpose
(4) Text Wheel shows effective speed, but also (known) problems with the vector font in XOR mode
(5) Pulsing Frames - to be improved soon to show speed
(6) Framed Text Drawn text is overlayed and then trying to delete it with XOR. (Known) artefacts remain.
(7) filled Boxes How to use boxXORsync ??
Stevenmess2004 said...
Also added VIRAND's pixelColor function although this is not tested.
Sorry about misunderstandings about my pixelcolor code. It is slow and only works
in 256x192 4-color mode. I was hoping and suggesting that if someone was reworking the driver,
they might be able to simply modify the gr.plot function to also read back the pixel color.
(My game project reads pixelcolors a lot, but the graphics driver does not.)
@VIRAND: As there is no free long in the COG anymore, so there is no chance at the moment to speed this up..
@Steven: It should be IF_NZ But is does not help terribly much... It makes it just SLOWER
I enclose an update using machine code - thus a new COG! - for extracting the ROM glyphs. This is simple, but nevertheless needs 12 instructions.... The speed-up however is - astonishing, as always...
deSilva said...
I enclose an update using machine code - thus a new COG! - for extracting the ROM glyphs. This is simple, but nevertheles needs 12 instructions....
I can make 12 more longs in the cog if we need them.
deSilva said...
@Steven: It should be IF_NZ But is does not help terribly much... It makes it just SLOWER
This just syncs starting drawing the box to the start of drawing the frame. So if you call boxXORsync for every box it will limit your box drawing rate to whatever the screen refresh rate is.
stevenmess2004 said...
So if you call boxXORsync for every box it will limit your box drawing rate to whatever the screen refresh rate is.
This is very well understood
It takes sometimes more than one frame to fill things!
The funny thing is it flickers less when I do
PRI moveBox(mX, mY, iOld, iNew)
' restricted to drawing in vertical sync only
if iNew>1
repeat until tv_params==1
gr.boxXOR(mX-iNew,mY-iNew, 2*iNew, 2*iNew)
if iOld >1
repeat until tv_params==1
gr.boxXOR(mX-iOld,mY-iOld, 2*iOld, 2*iOld)
rather than calling the (patched) boxXORsync. I now leave the boxXORsync in Version 112... I had a typo here just in these routines, responsible for the diagonal..
I'll see what I can do. I may be able to fit it in Since the fillSync doesn't seem to be working I'll take that out. I count 26 longs needed above. We can no doubt use some of the unused arguments as temp storage and the temp variables for storage as well. I count 18 longs of actual instructions so I may be able to fit that in.
deSilva, would it be possible to add an fps (or just the counter period) display? This could be helpful in optimising the boxes.
Post Edited (stevenmess2004) : 2/16/2008 1:01:33 AM GMT
This is quite astonishing for a program, for more than a year stuffed upto the last long
XORing glyphs is quite flexible, as the background will shine through the holes, which was formerly only possible by the vector font... Placing them on "white" will make them black, and placing them on black will make them white (assuming 0= white and 3 = black). This can be handy... I'll carry on with some demos
Here is the version with 18 longs free. Text scaling is now fixed. Just a note, a font fixed for the XOR mode will not look good when scaled as it will have gaps in it.
i.e. If the orignal font started at had a line ending at 2,2 and a line starting at 2,2 we would need to change the starting point of the second line to 2,3 or 3,2 so that the 2,2 point did not get written to twice. The problem comes when you scale the font. The end point will be 4,4 but the new start point will be 4,6 or 6,4 leaving a gap. Possible ways around this are to use a full vector which can be made to work properly but, that won't handle curves well and it will be a fair bit bigger. Second option is to use the ROM font which we are currently working on.
If people want I could put in an option to change the font (the current vector one) being used (it would just the start pointer in the cog).
Now to see If I can find any more space in the cog...
This version has 23 longs free. It may be possible to free 4 more longs in the cog but this would make lines and points plot slower.
Now to see what I can do with the ROM font...
Edit: Just updated and you can change the font though not tested - use setFont(fontBase)
Edit2: We could save even more space if we take out the ability to set the x,y offset or move it to spin. Don't know how much space but it would be a few.
Post Edited (stevenmess2004) : 2/16/2008 7:15:19 AM GMT
stevenmess2004 said...
... if we take out the ability to set the x,y offset or move it to spin.
You refer to gr.setup?
I think this would break to many programs... Still thinking of COMPATIBILITY. It should be possible to use your improved version without change in "historic" programs
That's fine it was just an idea. Compatibility is probably more important. It would be possible to just remove it from the cog and do it in the spin portion but that would be slower.
stevenmess2004 said...
...Just a note, a font fixed for the XOR mode will not look good when scaled as it will have gaps in it.
i.e. If the orignal font started at had a line ending at 2,2 and a line starting at 2,2 we would need to change the starting point of the second line to 2,3 or 3,2 so that the 2,2 point did not get written to twice. The problem comes when you scale the font.
I had also thought of not modifying the font, but systematically NOT writing the very first pixel with any line. This will have the same issues with scaling of course....
New Demos:
- Histogram, using XOR to add and subtract, nearly flickerfree
- Extracting 8x12 Clemens font, in a text wheel, but rather slow because done in SPIN
Using gr.drawGlyph for the GlyphBounce now... I have to call gr.drawGlyph twice, as it seems the buffer cannot be re-used... It would be nice to have a "text" and "textArc" routine in SPIN, using a generic setGlyph routine the buffer of which can directly be used for PIX or PIXARC
deSilva said...
New Demos:
- Histogram, using XOR to add and subtract, nearly flickerfree
Like the histogram, maybe it can be added to the HSS player as a graphics equalizer
deSilva said...
- Extracting 8x12 Clemens font, in a text wheel, but rather slow because done in SPIN
We may be able to load different routines into the cog for doing different fonts. How big do you think this would be in assembly?
deSilva said...
Using gr.drawGlyph for the GlyphBounce now... I have to call gr.drawGlyph twice, as it seems the buffer cannot be re-used... It would be nice to have a "text" and "textArc" routine in SPIN, using a generic setGlyph routine the buffer of which can directly be used for PIX or PIXARC
The buffer for the glyph is currently in the graphics driver and the address you pass in is ignored. It is simple to change this though... I'll see about doing some methods to print string later today.
re: Buffer....
The space needed fpr a glyph is not negligible (260 bytes)... Are there other buffers needed in GRAPHICS? Maybe the user should provide this buffer, to possibly allow him a caching strategy.. Or maybe not... Or maybe GRAPHICS checks for re-used?
Some functions as textdraw now return prematurely, to allow true parallal activity. This is useful for the glyph setting as well... It might restrict the use of a user provided buffer, and requires calling of gr.finish in some cases... This is not a problem - the user just has to understand this...
re: Histogram. This can be accomplished with a tricky use of tiles as well... However there are many more options with true graphics.
XORing is NOT flicker free - but it generally restricts the changes to such a small part that it in fact does not flicker, or this is hardly noticable (see: "Pulsing Rectangles"). When the amount of changes increases (see: the many characters now in "Glyph-Bounce") chances are that SOMETHING flickers...
Updating a histogram is not the classical XOR application, it can also be done by deleting and redrawing the complete column (or part of it)... However this will increase the time the eye will notice a flicker, in contrast to a "softer" XOR.
Comments
Thanks guys!
Filled boxes now pulsing. This shows the limits of this technique - to avoid flicker the vertical sync is waited for which slows down things considerably! Nevertheless it still flickers with a really large box...
Two phases now
- width(0): looks fine except text and some detail of box
- width(2): does not look so good...
Post Edited (deSilva) : 2/13/2008 11:46:43 PM GMT
I shall play a little bit more with the triangles, I think......
Now if we can just find someone to do a new font.... Their not really my speciality.
I should have an update in a few minutes.
Post Edited (stevenmess2004) : 2/14/2008 12:43:33 AM GMT
I don't know what can be done about overlapping boxes like in your demo though.
But it is is a nice work around when needing the memory for code and true data rather than for a second video buffer.... Its main application is "marking" things, as with cursors, marquees. general highlighting....
State of affairs all for pixel width of 0
Lines - Works
Boxes - Works if you boxXOR or boxXORSync (I think). deSilva's demo doesn't but the boxes in the codes here work fine.
Vector Sprites - Works
Text -Works but the current font is ugly
Pixel Sprites -Appears to work
Triangles -Works
Arcs -Appears to work
Quads -Don't work, they have a line through the middle
Pixel widths of other than 0 will probably not be supported unless someone can come up with a new algorithm.
Would people be interested in being able to scale characters the same as vectors i.e. $100 is one allowing some fraction multiples instead of just integer?
Edit: updated table and download
Post Edited (stevenmess2004) : 2/15/2008 10:37:30 AM GMT
Here a new version of the test routines:
- I added a Glyph routine, using the ROM font (16x32).
The internal font looks VERY ugly in XOR mode only; "framed text demo" now displays an overlayed text, and then XORs it, showing the points of trouble
- I was not able to get boxXORsync to sync...
The demos:
(1) 20 seconds Moving ROM Glyphs, standard size (16x32), funnily look also good doubled (width(1)) in XOR mode, look also "interesting" in larger width
(2) Slow Worm, showing principle
(3) Fast Worm, showing that XOR works fine (no artefacts!), wrap around effects are normal and done with purpose
(4) Text Wheel shows effective speed, but also (known) problems with the vector font in XOR mode
(5) Pulsing Frames - to be improved soon to show speed
(6) Framed Text Drawn text is overlayed and then trying to delete it with XOR. (Known) artefacts remain.
(7) filled Boxes How to use boxXORsync ??
---
Edit: small upgrade..
Post Edited (deSilva) : 2/15/2008 10:07:02 PM GMT
fillSync_ rdlong t1,syncPtr_ 'wait for sync pointer to be 1 cmp t1,#1 wz if_z jmp #fillSync_Is there anything wrong with it?
in 256x192 4-color mode. I was hoping and suggesting that if someone was reworking the driver,
they might be able to simply modify the gr.plot function to also read back the pixel color.
(My game project reads pixelcolors a lot, but the graphics driver does not.)
@Steven: It should be IF_NZ
I enclose an update using machine code - thus a new COG! - for extracting the ROM glyphs. This is simple, but nevertheless needs 12 instructions.... The speed-up however is - astonishing, as always...
It takes sometimes more than one frame to fill things!
The funny thing is it flickers less when I do
PRI moveBox(mX, mY, iOld, iNew) ' restricted to drawing in vertical sync only if iNew>1 repeat until tv_params==1 gr.boxXOR(mX-iNew,mY-iNew, 2*iNew, 2*iNew) if iOld >1 repeat until tv_params==1 gr.boxXOR(mX-iOld,mY-iOld, 2*iOld, 2*iOld)rather than calling the (patched) boxXORsync. I now leave the boxXORsync in Version 112... I had a typo here just in these routines, responsible for the diagonal..
I am afraid that is MUCH more than 12 LONGS
Post Edited (deSilva) : 2/16/2008 2:54:30 AM GMT
deSilva, would it be possible to add an fps (or just the counter period) display? This could be helpful in optimising the boxes.
Post Edited (stevenmess2004) : 2/16/2008 1:01:33 AM GMT
XORing glyphs is quite flexible, as the background will shine through the holes, which was formerly only possible by the vector font... Placing them on "white" will make them black, and placing them on black will make them white (assuming 0= white and 3 = black). This can be handy... I'll carry on with some demos
It is weird how the boxes flicker the most when they are a medium size and less when they are large.
i.e. If the orignal font started at had a line ending at 2,2 and a line starting at 2,2 we would need to change the starting point of the second line to 2,3 or 3,2 so that the 2,2 point did not get written to twice. The problem comes when you scale the font. The end point will be 4,4 but the new start point will be 4,6 or 6,4 leaving a gap. Possible ways around this are to use a full vector which can be made to work properly but, that won't handle curves well and it will be a fair bit bigger. Second option is to use the ROM font which we are currently working on.
If people want I could put in an option to change the font (the current vector one) being used (it would just the start pointer in the cog).
Now to see If I can find any more space in the cog...
Now to see what I can do with the ROM font...
Edit: Just updated and you can change the font though not tested - use setFont(fontBase)
Edit2: We could save even more space if we take out the ability to set the x,y offset or move it to spin. Don't know how much space but it would be a few.
Post Edited (stevenmess2004) : 2/16/2008 7:15:19 AM GMT
I think this would break to many programs... Still thinking of COMPATIBILITY. It should be possible to use your improved version without change in "historic" programs
I had also thought of not modifying the font, but systematically NOT writing the very first pixel with any line. This will have the same issues with scaling of course....
Next do drawGlyphArc...
Also, the pixelColor method is being worked on so it won't work just yet
Edit: bedtime for me now so I probably won't be able to look at this for another 14 hours at least
Post Edited (stevenmess2004) : 2/16/2008 12:48:20 PM GMT
- Histogram, using XOR to add and subtract, nearly flickerfree
- Extracting 8x12 Clemens font, in a text wheel, but rather slow because done in SPIN
Using gr.drawGlyph for the GlyphBounce now... I have to call gr.drawGlyph twice, as it seems the buffer cannot be re-used... It would be nice to have a "text" and "textArc" routine in SPIN, using a generic setGlyph routine the buffer of which can directly be used for PIX or PIXARC
Post Edited (deSilva) : 2/16/2008 6:55:40 PM GMT
We may be able to load different routines into the cog for doing different fonts. How big do you think this would be in assembly?
The buffer for the glyph is currently in the graphics driver and the address you pass in is ignored. It is simple to change this though... I'll see about doing some methods to print string later today.
The space needed fpr a glyph is not negligible (260 bytes)... Are there other buffers needed in GRAPHICS? Maybe the user should provide this buffer, to possibly allow him a caching strategy.. Or maybe not... Or maybe GRAPHICS checks for re-used?
Some functions as textdraw now return prematurely, to allow true parallal activity. This is useful for the glyph setting as well... It might restrict the use of a user provided buffer, and requires calling of gr.finish in some cases... This is not a problem - the user just has to understand this...
re: Histogram. This can be accomplished with a tricky use of tiles as well... However there are many more options with true graphics.
XORing is NOT flicker free - but it generally restricts the changes to such a small part that it in fact does not flicker, or this is hardly noticable (see: "Pulsing Rectangles"). When the amount of changes increases (see: the many characters now in "Glyph-Bounce") chances are that SOMETHING flickers...
Updating a histogram is not the classical XOR application, it can also be done by deleting and redrawing the complete column (or part of it)... However this will increase the time the eye will notice a flicker, in contrast to a "softer" XOR.