deSilva, would you be able to run this through your test program and tell me if this gives the correct output? I just changed the code so that it does the XOR instead of the overwrite. You can't change between modes yet but I just want to check that this is what we need.
Okay, here is a version of graphics that can switch between XOR and normal. (I assume it is doing the XOR properly, someone who knows please tell me) If you run the graphics_demo you will see both and switching between them
deSilva, we could pass in a small asm code up to 8 longs long in the argument list and then run it. We could even move the routines for changing between these modes out of the cog and put something else in there.
If people think that this is working properly and don't want anything else put in here than I will see if I can post it in the object exchange if I get a couple of people to test it.
What does "fait ton jeu" mean in english? I'm afraid I only ever learnt one language - Australian english, the only real english. I have enough trouble understanding the American or British english so when something else comes along I totally lost.
This version does the same thing but the routine is passed in in the argument space (8 longs) so we still have 15 longs free in the cog
Can someone *Please* tell me if this does what it is supposed to do and does anyone want anything else put in here before I put it in the object exchange.
There remain pixels at three corners, this leads to the suspicion that the gr.line routine re-visit the first pixel.
To verify this, I included a "third" visit.
This works fine!
I think it all has the same root cause, at least with textoutput: revisiting already set pixels. I now remember I also ran into that issue last autumn, and put it all aside, lacking any memory. But you are more lucky now!
(1) In most graphics applications you need polygons rather that isolated lines. So "chaining" them as Chip does (setting a starting point and then carry on) is more useful.
(2) gr.finish does not work any longer:
PUB finish
'' Wait for any current graphics command to finish
'' use this to insure that it is safe to manually manipulate the bitmap
'setcommand(_loop, 0) 'make sure last command finished
setcommand(constant((@loop-@loop)>>2), 0)
I've fixed the problem with normal lines and I'm looking at the wide lines now. And I'm finally trying to learn what some of the more interesting instructions do
The 'pulsing frame' works, the text almost works. I think that I am going to have to change the font to make it work properly because some of it overlaps :-(
Okay, to make the text work just normally you have to make sure that none of it overlaps. I've fixed 'W', 'i' and 't' (They are ugly but they work). However, it still doesn't work properly when rotated because the pixels get shifted and they might overlap again. So, is there someone who will volunteer to make a new vector font? Possibly using a larger size and variable width text?
See attached version which does lines and some text properly. The pulsing frame in deSilva's test file works really well
stevenmess2004 said...
Can someone *Please* tell me if this does what it is supposed to do and does anyone want anything else put in here before I put it in the object exchange.
I have just one suggestion, for an improved GRAPHICS driver:
How about a function to read the color of a single pixel?
It could probably share code with gr.plot since it does the same thing except read instead of write the screen buffer.
I use this one to do it in Spin for 256x192:
PUB PixelColor(qx,qy): qc | sad 'recall the color of a pixel at x,y
sad:=Onscreen_Buffer+(qx&12)+((191-qy)*4)+(qx&240)*48 'get the byte address of pixel x,y
qc:=byte[noparse][[/noparse]sad]>>((qx&3)*2)&3 'get the desired pixel's color out of the 4-pixel group
stevenmess2004 said...
What does "fait ton jeu" mean in english?
Poem: Fait ton jeu de ...SoLiTuDe...
Done your game ... ... SoLiTuDe
Do not loose
Done have yet tone Thursday
Are you out
Draws ai
Whenever she lives
It makes me relive
Through her eyes
Filled with hope
Still Depressed
Because she wants to have it all
But when she has everything
Etc...........................................
Unless someone can come up with an algorithm that doesn't overwrite pixels I don't think that the XOR will work properly :-( Anyone got any ideas? It shouldn't be too hard for straight lines but curved lines and text will be a problem.
I have been thinking about this. To draw thick lines we just need to draw x copies of them spaced one pixel apart so that's easy. We can do the same thing with a curve, just draw it with a radius of 1 pixel less/more. However this isn't going to get us the nicely rounded ends. And the reason the XOR isn't working on the boxes is because that they have their own rdlong/wrlong that I just found so I can fix that as well. Anyone got ideas for the round corners and ends?
If I'm following you right, I think I have an idea...
To handle the font's curves and rounded ends and revisited pixels:
How about clearing the offscreen buffer, drawing all the text in it normally, and then XOR it onto the onscreen buffer?
You could but then you would still need an offscreen buffer which we are trying to get rid of with the XOR to reduce the amount of memory. I have got the boxes working except for a line at the top and the bottom.
No one spending his nights in Monte Carlo Casino?
The croupiers say: "Faites vos jeux!" asking for a risky investment, and shortly after: "Rien ne va plus!"
I was also thinking of that...
I think one can live with the fact that XOR mode works with width(0) only....
As the time needed to draw THICK lines increases dramatically, flicker again will sneak in by the back door...
It is more tricky with THICK text... It would be really nice to have this...
A "better" font is a very good idea, and should just need HUB memory, where we have plenty of now.
A proportional font needs more intelligent handling of spacing. At the moment spacing is counted from the left most side of the character rather than being a value for inter-character spacing (this allows some "kerning").
Also different alignment (center, right) is more tricky with proportional fonts. But this can be done all in SPIN...
----
Edit. Steven, I have a timeslot in around 10 hours when I could test a new version (finish, box,..)
We could use a standard vector for the font and make the last point in the vector the start point of the next character. This will require some changes to the vector though as vectors can't do curves but if we remove some of the font stuff then there will be more room in the cog. I can also make more room by taking out a couple of functions and passing them in in the arguments.
We could also use the ROM font for the text although this might be a bit big (13 lines or something)
If we want to save more memory we could put the bitmap over the DAT area where the program is stored. When the program is in the cog we don't care about it being in the hub anymore
Post Edited (stevenmess2004) : 2/13/2008 9:25:39 AM GMT
Here is an update incase I don't get another one done tonight. Boxes are almost working. The box disappears except for a line at the top and the bottom.
Triangles work fine, quads leave a line on the diagonal.
Post Edited (stevenmess2004) : 2/13/2008 10:02:12 AM GMT
Edit: I'm pretty sure that I can fix the line in the quad by changing the coordinates of the second triangle in the spin code but its too late now to muck around with it tonight.
Edit 2: I should have mentioned that finish should work now.
Post Edited (stevenmess2004) : 2/13/2008 12:20:38 PM GMT
Comments
I think that thats happend more than once to most users of this forum (including me and I haven't been posting for long)
I'll start coding it shortly.
deSilva, we could pass in a small asm code up to 8 longs long in the argument list and then run it. We could even move the routines for changing between these modes out of the cog and put something else in there.
If people think that this is working properly and don't want anything else put in here than I will see if I can post it in the object exchange if I get a couple of people to test it.
Can someone *Please* tell me if this does what it is supposed to do and does anyone want anything else put in here before I put it in the object exchange.
I am very pressed at the moment with another task...
I used the version dated Feb 11, and it does not what it should.
Here is a test program, it is configured for the Hydra, and I changed the name of your improved GRAPHICS to GRAPHICS_XOR.
Note that the vertical lines in the frame are missing...
I have an hour or two now, and shall immediately try the new version dated Feb 12 - stay tuned!
This works nearly:
gr.width(0) gr.setOverWrite REPEAT 2 gr.plot(10,10) gr.line(10,230) gr.line(300,230) gr.line(300,10) gr.line(10,10) setXORThere remain pixels at three corners, this leads to the suspicion that the gr.line routine re-visit the first pixel.
To verify this, I included a "third" visit.
This works fine!
gr.width(0) gr.setOverWrite REPEAT 2 gr.plot(10,10) gr.line(10,230) gr.plot(10,230) gr.line(300,230) gr.plot(300,230) gr.line(300,10) gr.plot(300,10) gr.line(10,10) setXORHowever wider lines (width(1)) behave still strange...
---
Edit:
gr.box seems completely unaffected by XOR:
gr.setOverWrite REPEAT 2 gr.box(10,10, 290,220) waitcnt(cnt+clkfreq*2) gr.setXORI include a version of the testprogram with these snippets inside..
Post Edited (deSilva) : 2/12/2008 8:30:13 PM GMT
The other stuff I will need to investigate more
(2) gr.finish does not work any longer:
The "zero" is not a valid command, I think...
See attached version which does lines and some text properly. The pulsing frame in deSilva's test file works really well
I have just one suggestion, for an improved GRAPHICS driver:
How about a function to read the color of a single pixel?
It could probably share code with gr.plot since it does the same thing except read instead of write the screen buffer.
I use this one to do it in Spin for 256x192:
PUB PixelColor(qx,qy): qc | sad 'recall the color of a pixel at x,y
sad:=Onscreen_Buffer+(qx&12)+((191-qy)*4)+(qx&240)*48 'get the byte address of pixel x,y
qc:=byte[noparse][[/noparse]sad]>>((qx&3)*2)&3 'get the desired pixel's color out of the 4-pixel group
Poem: Fait ton jeu de ...SoLiTuDe...
Done your game ... ... SoLiTuDe
Do not loose
Done have yet tone Thursday
Are you out
Draws ai
Whenever she lives
It makes me relive
Through her eyes
Filled with hope
Still Depressed
Because she wants to have it all
But when she has everything
Etc...........................................
To handle the font's curves and rounded ends and revisited pixels:
How about clearing the offscreen buffer, drawing all the text in it normally, and then XOR it onto the onscreen buffer?
The croupiers say: "Faites vos jeux!" asking for a risky investment, and shortly after: "Rien ne va plus!"
I was also thinking of that...
As the time needed to draw THICK lines increases dramatically, flicker again will sneak in by the back door...
It is more tricky with THICK text... It would be really nice to have this...
A "better" font is a very good idea, and should just need HUB memory, where we have plenty of now.
A proportional font needs more intelligent handling of spacing. At the moment spacing is counted from the left most side of the character rather than being a value for inter-character spacing (this allows some "kerning").
Also different alignment (center, right) is more tricky with proportional fonts. But this can be done all in SPIN...
----
Edit. Steven, I have a timeslot in around 10 hours when I could test a new version
Post Edited (deSilva) : 2/13/2008 8:48:54 AM GMT
We could also use the ROM font for the text although this might be a bit big (13 lines or something)
If we want to save more memory we could put the bitmap over the DAT area where the program is stored. When the program is in the cog we don't care about it being in the hub anymore
Post Edited (stevenmess2004) : 2/13/2008 9:25:39 AM GMT
Triangles work fine, quads leave a line on the diagonal.
Post Edited (stevenmess2004) : 2/13/2008 10:02:12 AM GMT
Edit: I'm pretty sure that I can fix the line in the quad by changing the coordinates of the second triangle in the spin code but its too late now to muck around with it tonight.
Edit 2: I should have mentioned that finish should work now.
Post Edited (stevenmess2004) : 2/13/2008 12:20:38 PM GMT