deSilva said...
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?
No other buffers are needed except for the screen and also a list of pointers to the tiles. It would probably be better to let the user provide the buffer. However, if we put in Clemens 8x12 font then we will need to make sure that the header changes (or the user changes it, could be done in spin when changing the font).
deSilva said...
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...
All functions should return as soon as the cog has got the arguments (8 hub accesses + a few other instructions)
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....
Missed this before,
We could just add a 1 pixel line at each of the intersections, it will make the font use a fair bit more space but it should work
Now we have an interesting situation. With getting the glyphs in the graphics cog, deSilva's demo runs slower than when a separate cog is dedicated to getting the glyphs. If we completely replace the text part of the driver than we would probably have enough room to store the entire glyph in the cog.
We could switch between the vector font and the ROM font by a small routine passed in using the arguments like some of the setup routines in what I have currently.
Could also write a routine to write the ROM font directly to the bitmap instead of to a buffer in the hub and then drawing it as a pixel sprite.
What do you suggest?
I have fixed it up to draw glyph strings and glyphs at an arc location now but its not tested yet. (Bit hard to use the TV when cricket is on )
stevenmess2004 said...
Now we have an interesting situation. With getting the glyphs in the graphics cog, deSilva's demo runs slower than when a separate cog is dedicated to getting the glyphs.
I can hardly understand that: Between two calls of drawGlyph there are more than 20 SPIN instructions = 100 to 150 µs (= 2k to 3k machine instructions in the GRAPHICS COG).. Setting the Glyph there will take 600 ns* 64 = less than 50 µs. Rendering to the screen will take more - but not more than before! So there is most likely some unclear piece of SPIN now in between...
said...
If we completely replace the text part of the driver than we would probably have enough room to store the entire glyph in the cog.
This is interesting but need not necessarily influence the speed of rendering much. There are many instructions when setting the PX pixels to non-aligned memory... fetching them from HUB will be in 10%-range, even less. Note that getting things from the HUB will take 7 clocks best case, which is little more than a COG-COG move
said...
We could switch between the vector font and the ROM font by a small routine passed in using the arguments like some of the setup routines in what I have currently.
This will be a nice feature! In fact there is hardly any difference between vector font and pixel font! A question is the size parameter: What shall be the base size "0"? alignment and spacing could work as expected...
said...
Could also write a routine to write the ROM font directly to the bitmap instead of to a buffer in the hub and then drawing it as a pixel sprite.
This will be an alternative LONG-PIX rather than the now WORD-PIX. I think it can be useful for other applications as well. It has also to pad-out the "hidden" character though....
said...
... but its not tested yet. (Bit hard to use the TV when cricket is on )
No PiP??
N.B. I had a bad number in a former posting: The space needed for a Glyph is only 132 bytes (not 260)
deSilva said...
I can hardly understand that: Between two calls of drawGlyph there are more than 20 SPIN instructions = 100 to 150 µs (= 2k to 3k machine instructions in the GRAPHICS COG).. Setting the Glyph there will take 600 ns* 64 = less than 50 µs. Rendering to the screen will take more - but not more than before! So there is most likely some unclear piece of SPIN now in between...
May have been my imagination then
[noparse][[/noparse]quote]This will be a nice feature! In fact there is hardly any difference between vector font and pixel font! A question is the size parameter: What shall be the bae size "0". alignment and spacing could work as expected...
To do this we will probably need to replace part of the text portion this will probably not be too hard except for some possible call/returns that could be interesting as they will probably have to be done without using the call/ret pseudo instructions.
As far as the size goes we could use either Clemens font or the standard font with Clemens font being the harder to use. However we would have around 50 to 90 longs to use.
Edit: No, the TV I use doesn't have pip. I really want to make something with around a 7-10inch screen from a portable DVD player + a keyboard + maybe a propGFX all in a nice case with plugs for serial and a few servos and maybe a speaker and mike. Probably won't happen for a while though
Post Edited (stevenmess2004) : 2/17/2008 10:01:05 AM GMT
There won't be an update tonight because I haven't been able to test anything, but there should be something new tomorrow. Been looking at the text part of the driver and it should be fairly easy to swap out the vector code for other code (ROM and Clemens font) fairly easily except for some call/ret instructions that may need to be replaced with some jmps. I plan on doing this at runtime using a small routine passed in in the arguments.
So the api calls would be something like
setVectorFont - copies in code for the vector font
setROMFont - copies in code for the ROM font
setClemensFont - copies in code for clemens font
Haven't decided on whether to use a buffer in the HUB for the ROM fonts or to try and fit a buffer in the cogs or to just write to the bitmap while reading yet.
stevenmess2004 said...
....to try and fit a buffer in the cogs..
Most likely little speed-up
said...
... or to just write to the bitmap while reading yet.
Should also yield little speed-up as there is no real parallel action, be it interleaved or not...
Edit: Oh, I just see - this was meant to save the buffer...
@Everybody: Confess, Scoundrel! Who is the other one downloading my secret code???
Somebody said...
Haven't decided on whether to use a buffer in the HUB for the ROM fonts or to try and fit a buffer in the cogs or to just write to the bitmap while reading yet.
If you use a buffer in HUB RAM for ROM font (for the clemens fonts?) then maybe
you can do similarly for the vector font to solve it's xor problems. Sorry for being redundant.
Unfortunately I had to go to tafe tonight and my class went longer than I thought it would (4 hours instead of 3) so the promised update won't be tonight. :-(
VIRAND said...
If you use a buffer in HUB RAM for ROM font (for the clemens fonts?) then maybe
you can do similarly for the vector font to solve it's xor problems. Sorry for being redundant.
This is not a bad idea, render the font to some space in the HUB and then XOR that into the bitmap. I'll have a look tomorrow. This would probably fit well with trying to have swappable text modes/drivers. The problem will be that the buffer size will be different for different font scales but that shouldn't be too much of a problem unless the scale gets really big.
deSilva said...
@Everybody: Confess, Scoundrel! Who is the other one downloading my secret code???
If you are worried about this we can switch to email. Just pm me.
Clemens - you will have noticed my code which extracts the small font is terribly wrong... would you mind to fix it? I then shall translate it to PASM and Steven will include it in GRAPHICS ....
That's what they call teamwork at some places
You're making fun of me... most o this code is a complete mystery to me. In fact the small glyphs look quite good except the "i" and "l" and some other chars are too thin. I'll see what I can do.
[noparse][[/noparse](to himself).................Ok, now lets put that rotating glyphs code all the way up in a repeat loop and now hmm,......well...how do I get them to display in lines... ]
Okay, so it was not so hard after all...
after the lines:
IF glyph&1
pattern >>= 1
in the setSmallGlyph(glyph) object, two lines must be added:
IF lookdown(glyph:"14IilYZ7V")
pattern >>= 2
I've "or"-d a lot last weekend after trying to understand what Phil was doing to downsample the font...·- in fact until then I didn't even know what "or" is for. (ignorant graphic designer).
Anyway, I've got an almost-good-looking intermediate font... I'll post it if it becomes worth it.
new method str(x,y,stringPtr) for printing strings using the ROM font. It is using spin at the moment.
This may not stay around if I can get the swapping code for different fonts (vector/Clemens/ROM) as I might need the space in the COG.
Also drawGlyph has changed. It is now supposed to be able to print at an arc location.
Syntax drawGlyph(x,y,xr,yr,angle,pixrot,bufferAddress,glyph) for at an arc location
drawGlyph(x,y,pixrot,0,0,0,bufferAddress,glyph) for just x,y
It works (is supposed to work) by checking if the yr value is 0 and if it is then it is obviously meant to be drawn at an x,y and otherwise at an arc
Only problem is that it puts the glyph in the buffer fine but it draws garbage on the screen. If you draw it later from the buffer then it works fine.
Anyone got any ideas?
I have a feeling that there is something else I should remember but what was it...
@deSilva, We could get greedy and use two cogs... One to render the glyph to a buffer and another to XOR it to the bitmap. However, I think that this may be a bit hard to synchronise
Has anyone ever used an 'org' with a number other than 0? From the manual it should work. I think that I may need it to do swappable text routines so that the jmps go to the right places. Anything that I should watch out for?
ORG NN works fine. In my Tutorial said it just (re-)sets the counter for the labeling.. You just have to move that code segment to location NN manually
@deSliva, Since we now don't need to use all the memory for a double buffer can we make the resolution higher?
This is starting to annoy me. I'm sure that it is something simple. In the code I posted above I changed
IF_Z JMP #pix_
JMP #pixArc_
to
DJNZ #pixArc_
JMP #pix_
Which works fine. However, to make the changeable text modes I need to be able to do call #pixArc_ and call #pix_ so that I can print a string and not just a single character. First problem is that the assembler does not like the 'call'. That is easily fixed by using 'jmpret'. The second problem is basically the same as above. With the code below it will print at an arc location but stalls when trying to draw at an x,y. Any suggestions?
stevenmess2004 said...
@deSliva, Since we now don't need to use all the memory for a double buffer can we make the resolution higher?
LOL We ARE using Hig-Res all the time Gee Whizz: 320x240 and 4 Colors - imagine, that is EGA!! (Well,nearly..)
A true VGA resolution 640x480 will have benefits on a true monitor or a very good living Room TV set only. It will need 40kB in MONOCHROME
said...
This is starting to annoy me. I'm sure that it is something simple. In the code I posted above I changed
IF_Z JMP #pix_
JMP #pixArc_
to
DJNZ #pixArc_
JMP #pix_
Which works fine.
This does not look good nevertheless - I'll have a look into the full code in a moment...
----
Edit: I see.. It's DJNZ p3, #pixArc_ and you want it to jmp if p3 is non-zero..
(a) But that should work only if p3 is non-one! Have you incremented p3 for that trick?? I guess you have
(b) A better way is using
TJNZ p3,....
But then don't forget to remove that incrementing....
---
deSilva said...
When you return from pixarc_ the flags will not be restored, of course
True, but it should at least start to draw both cases.
And the z flag is set several times in the pix routines so I may have to try something slightly different. Like adding another cmp arg4,zero which will be interesting because every long is used :-(
deSilva said...
LOL We are using Hig-Res al the Time Gee Whizz: 320x240 and 4 Colors - imagine, that is EGA!! (Well,nearly..)
What about interlaced TV mode?
Post Edited (stevenmess2004) : 2/20/2008 8:07:57 AM GMT
(a) See my EDIT above.
(b, wrt recent code)
Line 1739: You need a ORG after the RESes
Line 1695: What is this??
Line 1644: You can use COLOR1 rather than _11111 saving one LONG again
(c) Interlacing has nothing to do with it... Just another way to sort the lines when dumping them through the video line
Line 1695: To change to XOR mode I pass the routine in in the arguments and then run it from the arguments. Since it needs 8 instructions to change mode and there are 8 arguments and I need to make it jump back to the loop I needed to add a jmp #loop after the arguments to jump back.
Line 1739: I don't think I need an ORG because none of the labels for them are being used except for the hub addresses. I will need another ORG when I start moving other things in and out of the cog.
Line 1644: Will do this.
deSilva said...
Edit: I see.. It's DJNZ p3, #pixArc_ and you want it to jmp if p3 is non-zero..
(a) But that should work only if p3 is non-one! Have you incremented p3 for that trick?? I guess you have
(b) A better way is using
TJNZ p3,....
But then don't forget to remove that incrementing....
arg3 (p3) is passed in from spin. It is the y radius of the arc. If this is non-zero then the caller wanted to draw at an arc position. If it is zero then the user obviously wanted to draw at an x,y position. Yes, it should have been TJNZ, since I never passed in a value of 1 I never noticed.
All that still doesn't answer the question why the JMPRETs don't work. I'll try adding another CMP.
Line 1739: I don't think I need an ORG because none of the labels for them are being used except for the hub addresses. I will need another ORG when I start moving other things in and out of the cog.
Right! I now see how you do it. But make sure that the labels will not be used by accident, perhaps by naming them very specially...
said...
All that still doesn't answer the question why the JMPRETs don't work.
Not at the first glance... Alas, I will find very little time this week for our project :-(
Comments
Missed this before,
We could just add a 1 pixel line at each of the intersections, it will make the font use a fair bit more space but it should work
We could switch between the vector font and the ROM font by a small routine passed in using the arguments like some of the setup routines in what I have currently.
Could also write a routine to write the ROM font directly to the bitmap instead of to a buffer in the hub and then drawing it as a pixel sprite.
What do you suggest?
I have fixed it up to draw glyph strings and glyphs at an arc location now but its not tested yet. (Bit hard to use the TV when cricket is on
This is interesting but need not necessarily influence the speed of rendering much. There are many instructions when setting the PX pixels to non-aligned memory... fetching them from HUB will be in 10%-range, even less. Note that getting things from the HUB will take 7 clocks best case, which is little more than a COG-COG move
This will be a nice feature! In fact there is hardly any difference between vector font and pixel font! A question is the size parameter: What shall be the base size "0"? alignment and spacing could work as expected...
This will be an alternative LONG-PIX rather than the now WORD-PIX. I think it can be useful for other applications as well. It has also to pad-out the "hidden" character though....
No PiP??
N.B. I had a bad number in a former posting: The space needed for a Glyph is only 132 bytes (not 260)
Post Edited (deSilva) : 2/17/2008 9:38:22 AM GMT
[noparse][[/noparse]quote]This will be a nice feature! In fact there is hardly any difference between vector font and pixel font! A question is the size parameter: What shall be the bae size "0". alignment and spacing could work as expected...
To do this we will probably need to replace part of the text portion
As far as the size goes we could use either Clemens font or the standard font with Clemens font being the harder to use. However we would have around 50 to 90 longs to use.
Edit: No, the TV I use doesn't have pip. I really want to make something with around a 7-10inch screen from a portable DVD player + a keyboard + maybe a propGFX all in a nice case with plugs for serial and a few servos and maybe a speaker and mike. Probably won't happen for a while though
Post Edited (stevenmess2004) : 2/17/2008 10:01:05 AM GMT
The speed-down Steve noticed in "Glyph Bounce" is most likely not caused by different code, but because I doubled the number of players.
So the api calls would be something like
setVectorFont - copies in code for the vector font
setROMFont - copies in code for the ROM font
setClemensFont - copies in code for clemens font
Haven't decided on whether to use a buffer in the HUB for the ROM fonts or to try and fit a buffer in the cogs or to just write to the bitmap while reading yet.
Edit: Oh, I just see - this was meant to save the buffer...
@Everybody: Confess, Scoundrel! Who is the other one downloading my secret code???
Post Edited (deSilva) : 2/18/2008 7:52:09 AM GMT
If you use a buffer in HUB RAM for ROM font (for the clemens fonts?) then maybe
you can do similarly for the vector font to solve it's xor problems. Sorry for being redundant.
This is not a bad idea, render the font to some space in the HUB and then XOR that into the bitmap. I'll have a look tomorrow. This would probably fit well with trying to have swappable text modes/drivers. The problem will be that the buffer size will be different for different font scales but that shouldn't be too much of a problem unless the scale gets really big.
If you are worried about this we can switch to email. Just pm me.
That's what they call teamwork at some places
[noparse][[/noparse](to himself).................Ok, now lets put that rotating glyphs code all the way up in a repeat loop and now hmm,......well...how do I get them to display in lines... ]
I'll report back·when I'm making progress...
after the lines:
IF glyph&1 pattern >>= 1in the setSmallGlyph(glyph) object, two lines must be added:
IF lookdown(glyph:"14IilYZ7V") pattern >>= 2I've "or"-d a lot last weekend after trying to understand what Phil was doing to downsample the font...·- in fact until then I didn't even know what "or" is for. (ignorant graphic designer).
Anyway, I've got an almost-good-looking intermediate font... I'll post it if it becomes worth it.
new method str(x,y,stringPtr) for printing strings using the ROM font. It is using spin at the moment.
This may not stay around if I can get the swapping code for different fonts (vector/Clemens/ROM) as I might need the space in the COG.
Also drawGlyph has changed. It is now supposed to be able to print at an arc location.
Syntax drawGlyph(x,y,xr,yr,angle,pixrot,bufferAddress,glyph) for at an arc location
drawGlyph(x,y,pixrot,0,0,0,bufferAddress,glyph) for just x,y
It works (is supposed to work) by checking if the yr value is 0 and if it is then it is obviously meant to be drawn at an x,y and otherwise at an arc
Only problem is that it puts the glyph in the buffer fine but it draws garbage on the screen. If you draw it later from the buffer then it works fine.
Anyone got any ideas?
I have a feeling that there is something else I should remember but what was it...
Edit:
If I change the code to this
' 'drawGlyphArc(x, y, xr, yr, angle, pixrot, pixdef_ptr,glyph) 'drawGlyph (x, y, pixrot, 0, 0, 0, pixdef_ptr,glyph) ' arg 0 1 2 3 4 5 6 7 drawGlyphArc_ CMP arg3,zero WZ drawGlyph_ ROR arg7,#1 WC SHL arg7,#7 ADD arg7,h8000 MOV t2,#64 MOV t1,arg6 ADD t1,#4 :loop RDWORD t3,arg7 REV t3,#16 IF_NC SHR t3,#1 AND t3,:_11111111 MOV t4,t3 'don't need? SHL t4,#1 'don't need? OR t3,t4 'don't need? WRWORD t3,t1 ADD t1,#2 ADD arg7,#2 DJNZ t2,#:loop IF_Z JMP #pix_ JMP #pixarc_Then it will draw the arc but stops when trying to draw x,y
Edit 2: Now all fixed and I even got rid of the CMP instruction.
See second attached file.
Post Edited (stevenmess2004) : 2/19/2008 8:24:12 AM GMT
@Clemens, Please do. I'm looking forward to it.
@deSilva, We could get greedy and use two cogs... One to render the glyph to a buffer and another to XOR it to the bitmap.
This is starting to annoy me. I'm sure that it is something simple. In the code I posted above I changed
IF_Z JMP #pix_ JMP #pixArc_to
DJNZ #pixArc_ JMP #pix_Which works fine. However, to make the changeable text modes I need to be able to do call #pixArc_ and call #pix_ so that I can print a string and not just a single character. First problem is that the assembler does not like the 'call'. That is easily fixed by using 'jmpret'. The second problem is basically the same as above. With the code below it will print at an arc location but stalls when trying to draw at an x,y. Any suggestions?
drawGlyphArc_ drawGlyph_ ROR arg7,#1 WC SHL arg7,#7 ADD arg7,h8000 MOV t2,#64 MOV t1,arg6 ADD t1,#4 :loop RDWORD t3,arg7 REV t3,#16 IF_NC SHR t3,#1 AND t3,:_11111111 'MOV t4,t3 'don't need? 'SHL t4,#1 'don't need? 'OR t3,t4 'don't need? WRWORD t3,t1 ADD t1,#2 ADD arg7,#2 DJNZ t2,#:loop 'IF_Z JMP #pix_ ' JMP #pixarc_ ' DJNZ arg3,#pixarc_ ' JMP #pix_ CMP zero,arg3 WZ IF_NZ JMPRET pixret_,#pixarc_ IF_Z JMPRET pixret_,#pix_ JMP #loopA true VGA resolution 640x480 will have benefits on a true monitor or a very good living Room TV set only. It will need 40kB in MONOCHROME
----
Edit: I see.. It's DJNZ p3, #pixArc_ and you want it to jmp if p3 is non-zero..
(a) But that should work only if p3 is non-one! Have you incremented p3 for that trick?? I guess you have
(b) A better way is using
But then don't forget to remove that incrementing....
---
When you return from pixarc_ the flags will not be restored, of course
Post Edited (deSilva) : 2/20/2008 8:05:43 AM GMT
And the z flag is set several times in the pix routines so I may have to try something slightly different. Like adding another cmp arg4,zero which will be interesting because every long is used :-(
What about interlaced TV mode?
Post Edited (stevenmess2004) : 2/20/2008 8:07:57 AM GMT
(b, wrt recent code)
Line 1739: You need a ORG after the RESes
Line 1695: What is this??
Line 1644: You can use COLOR1 rather than _11111 saving one LONG again
(c) Interlacing has nothing to do with it... Just another way to sort the lines when dumping them through the video line
this is also an acceptable way of calling returning routines alternatively (a "call switch"):
Line 1739: I don't think I need an ORG because none of the labels for them are being used except for the hub addresses. I will need another ORG when I start moving other things in and out of the cog.
Line 1644: Will do this.
arg3 (p3) is passed in from spin. It is the y radius of the arc. If this is non-zero then the caller wanted to draw at an arc position. If it is zero then the user obviously wanted to draw at an x,y position. Yes, it should have been TJNZ, since I never passed in a value of 1 I never noticed.
All that still doesn't answer the question why the JMPRETs don't work. I'll try adding another CMP.
CMP zero,arg3 WZ IF_NZ JMPRET pixret_,#pixarc_ CMP zero,arg3 WZ IF_Z JMPRET pixret_,#pix_ JMP #loopand it still doesn't work.
Not at the first glance... Alas, I will find very little time this week for our project :-(
Missed this while I was posting.
I'll try this and see if it works.