CPCWiki forum

General Category => Programming => Topic started by: AMSDOS on 11:43, 23 November 10

Title: Silly Programming Ideas - Turning Text into Graphics
Post by: AMSDOS on 11:43, 23 November 10
I remember posting this program on the CPCZone boards a few years ago, at the time I asked if anyone had tried anything simular, the reply I recall was Character Matrices (http://www.cpctech.org.uk/source/charspr.html) is simular. Character Matrices indeed though has some function about it though and it's much faster because it's not redefining as many characters as well as offerening a multicoloured sprite.

In my example below, it's not really defining a true sprite, at least not in the sense of an object which is defined as a true character and it's not really designed to be moved around like a proper sprite. In short the program below is designed to draw up the 64 points of the Text Cursor and using Transparent Mode, plot each one of those points and use a colour to represent each of those points, thus creating what looks like a sprite!

Originally the main purpose to all of this was to see if it could be done, and now it's been done I've had nearly zero ideas for it. I was looking to covert it to Pascal though have various changes done with this original program to perhaps make it slightly faster, in a way it's kind of made it a programming game because I'm trying to incorporate more arrays into it!  :)
In some regards I thought it could make for a really crude way of making Sprites with it, by using an array as the editor for the object and then displaying and converting it back into another array as the sprite values!  :)  Otherwise it's a nice crude way of doing graphics which I guess could be larger than a typical sprite, though not worth capturing it as a screen. This example below is 8x8, though I made a larger version using the same principals!  :)

Anyway I'll comment more when I can about the program below, it kind of speaks for itself I guess!  ;D

10 SYMBOL AFTER 32: char=33
20 L=1:WHILE (L<>9)
30 GOSUB 1000
40 FOR m=1 to 8
50 SYMBOL char,v1,v2,v3,v4,v5,v6,v7,v8
60 char=char+1
70 GOSUB 1100
80 NEXT m
90 L=L+1
100 WEND
110 RUN 2000
1000 IF L=1 THEN v1=128:v2=0:v3=0:v4=0:v5=0:v6=0:v7=0:v8=0
1010 IF L=2 THEN v2=128:v1=0
1020 IF L=3 THEN v3=128:v2=0
1030 IF L=4 THEN v4=128:v3=0
1040 IF L=5 THEN v5=128:v4=0
1050 IF L=6 THEN v6=128:v5=0
1060 IF L=7 THEN v7=128:v6=0
1070 IF L=8 THEN v8=128:v7=0
1080 RETURN
1100 IF L=1 THEN v1=v1/2
1110 IF L=2 THEN v2=v2/2
1120 IF L=3 THEN v3=v3/2
1130 IF L=4 THEN v4=v4/2
1140 IF L=5 THEN v5=v5/2
1150 IF L=6 THEN v6=v6/2
1160 IF L=7 THEN v7=v7/2
1170 IF L=8 THEN v8=v8/2
1180 RETURN
2000 MODE 0:GOSUB 3000:x=10:y=10:GOSUB 2500
2010 GOSUB 2100
2020 x=11:y=10:GOSUB 2500
2030 GOSUB 2100
2040 SYMBOL AFTER 32:PEN 1:MODE 2:END
2100 WHILE INKEY$<>CHR$(13):WEND:RETURN
2500 BORDER 0:INK 1,26:INK 0,0:INK 2,2:INK 3,11:INK 4,25:num=33
2510 n2=1:WHILE n2<>65
2520 GOSUB 4000
2530 WEND
2540 RETURN
3000 DIM o(64):FOR n=1 to 64:READ o(n):NEXT n:RETURN
3010 DATA 1,0,0,0,0,0,0,1
3020 DATA 2,1,1,1,1,1,1,2
3030 DATA 2,3,3,4,4,4,3,2
3040 DATA 2,3,3,4,3,3,3,2
3050 DATA 2,3,4,4,4,3,3,2
3060 DATA 2,3,3,4,3,3,3,2
3070 DATA 2,3,4,4,4,4,3,2
3080 DATA 0,2,2,2,2,2,2,0
4000 PEN o(n2):LOCATE x,y:PRINT CHR$(22);CHR$(1)+CHR$(num):num=num+1:n2=n2+1:RETURN
Title: Re: Silly Programming Ideas - Turning Text into Graphics
Post by: ervin on 23:30, 23 November 10
Hi there.

Interesting idea. Could this sort of thing come in handy for score panels or something like that?

By the way, copying the code from your post causes the carriage returns to be dropped, so getting it into notepad or winape etc. is problematic.

Anyway, here is the code pasted directly into my reply. This should be copyable with all carriage returns intact:

10 SYMBOL AFTER 32: char=33
20 L=1:WHILE (L<>9)
30 GOSUB 1000
40 FOR m=1 to 8
50 SYMBOL char,v1,v2,v3,v4,v5,v6,v7,v8
60 char=char+1
70 GOSUB 1100
80 NEXT m
90 L=L+1
100 WEND
110 RUN 2000
1000 IF L=1 THEN v1=128:v2=0:v3=0:v4=0:v5=0:v6=0:v7=0:v8=0
1010 IF L=2 THEN v2=128:v1=0
1020 IF L=3 THEN v3=128:v2=0
1030 IF L=4 THEN v4=128:v3=0
1040 IF L=5 THEN v5=128:v4=0
1050 IF L=6 THEN v6=128:v5=0
1060 IF L=7 THEN v7=128:v6=0
1070 IF L=8 THEN v8=128:v7=0
1080 RETURN
1100 IF L=1 THEN v1=v1/2
1110 IF L=2 THEN v2=v2/2
1120 IF L=3 THEN v3=v3/2
1130 IF L=4 THEN v4=v4/2
1140 IF L=5 THEN v5=v5/2
1150 IF L=6 THEN v6=v6/2
1160 IF L=7 THEN v7=v7/2
1170 IF L=8 THEN v8=v8/2
1180 RETURN
2000 MODE 0:GOSUB 3000:x=10:y=10:GOSUB 2500
2010 GOSUB 2100
2020 x=11:y=10:GOSUB 2500
2030 GOSUB 2100
2040 SYMBOL AFTER 32:PEN 1:MODE 2:END
2100 WHILE INKEY$<>CHR$(13):WEND:RETURN
2500 BORDER 0:INK 1,26:INK 0,0:INK 2,2:INK 3,11:INK 4,25:num=33
2510 n2=1:WHILE n2<>65
2520 GOSUB 4000
2530 WEND
2540 RETURN
3000 DIM o(64):FOR n=1 to 64:READ o(n):NEXT n:RETURN
3010 DATA 1,0,0,0,0,0,0,1
3020 DATA 2,1,1,1,1,1,1,2
3030 DATA 2,3,3,4,4,4,3,2
3040 DATA 2,3,3,4,3,3,3,2
3050 DATA 2,3,4,4,4,3,3,2
3060 DATA 2,3,3,4,3,3,3,2
3070 DATA 2,3,4,4,4,4,3,2
3080 DATA 0,2,2,2,2,2,2,0
4000 PEN o(n2):LOCATE x,y:PRINT CHR$(22);CHR$(1)+CHR$(num):num=num+1:n2=n2+1:RETURN
Title: Re: Silly Programming Ideas - Turning Text into Graphics
Post by: Gryzor on 11:48, 24 November 10
Screenie? :)
Title: Re: Silly Programming Ideas - Turning Text into Graphics
Post by: Devilmarkus on 11:50, 24 November 10
Quote from: ervin on 23:30, 23 November 10
By the way, copying the code from your post causes the carriage returns to be dropped, so getting it into notepad or winape etc. is problematic.

Hmmm I tried it in JavaCPC (copied the code and paste with F11 into JavaCPC screen).
There it worked good.
Title: Re: Silly Programming Ideas - Turning Text into Graphics
Post by: redbox on 12:30, 24 November 10
Quote from: Gryzor on 11:48, 24 November 10
Screenie? :)

Not much to look at, more a proof of (a weird!) concept.  Interesting to see though CP/M User!
Title: Re: Silly Programming Ideas - Turning Text into Graphics
Post by: Gryzor on 12:41, 24 November 10
Ooh! Nice pound symbol :D
Title: Re: Silly Programming Ideas - Turning Text into Graphics
Post by: AMSDOS on 09:04, 25 November 10
ervin wrote:

Hi there.

Interesting idea. Could this sort of thing come in handy for score panels or something like that?



There maybe a number of applications one could apply this in, even if you wanted to have it to simply draw something to screen and then grabbing that image for the purpose of making a sprite you could, I seem to recall something like that in Sean McManus' Easi-Sprite Driver (http://www.sean.co.uk/books/amstrad/amstrad8.shtm) program.

I think the only problem with this method (excluding execution speed), is once you start making larger images (and I'll be posting an example of that soon), you have to work out where everything goes. Naturally the array gets bigger and while it's straightfoward plotting the 64 points of the text cursor in one position, I found the best way to setup the array is to work in that 8x8 context, which means working out the position is relevant to which portion! (It'll all become clear when I post the second program  ;D ). In the end it's probably easier to have an larger array and plot the contents of that array to screen. That was the approach I applied in my original BOUNCY.PAS (http://turpas3.angelfire.com/bouncy.pas) program which has an array with the information for the Ball in it and using a routine to plot that array to screen. As it demonstrates though it's not really designed for moving things around though. But for Graphical fixtures it would work quite well.

By the way, copying the code from your post causes the carriage returns to be dropped, so getting it into notepad or winape etc. is problematic.

Yes unfortunately I like to use Code to make it appear friendly and code like, the only way I know around this problem is to click Quote on the post with the Code in it, and in the Edit box, copy the program from that and paste that into whatever!
Title: Re: Silly Programming Ideas - Turning Text into Graphics
Post by: AMSDOS on 09:07, 25 November 10
Gryzor wrote:

Ooh! Nice pound symbol :D

There should be two!  ;)

Title: Re: Silly Programming Ideas - Turning Text into Graphics
Post by: AMSDOS on 10:13, 25 November 10
Okay so how does this program I posted work.

The seemly clever bit of the program is the initial setup phase, I've done the initial symbol after 32 and told where to start redefining which is "char" set to 33 - explanation mark(!)  ;D 

The second line (20) "L" represents the Line, this is set to 1 - I then setup a Loop ("WHILE L<>9") which checks to see if L has reached 9.

Line 30 simply goes to a Subroutine - this can be significantly improved with a statement like "ON L GOSUB 1000,1010,1020,etc" because the Subroutine represents what's in L.

Line 40 Starts another Loop - this one is used to represent the bit points in the symbol, in this part it becomes more confusing, so I'll explain further. Picture a 8x8 square grid, for each line there is 8 square boxes, this loop is here to address each of those boxes, as opposed to the While which works on each line, which ensures that all 64 squares are covered with a pixel!  ;D

Line 50 deals with defining all those pixels. earlier I set char to 33 which is where it starts redefining, all the "v" variables from 1 to 8 are there to represent the line - because I'm doing 1 line at a time, 7 of those variables must be set to 0, the subroutine from 1000 to 1080 deals with this by determining which line is being redefined the value for the left most pixel.

Line 60 Increments the character number so no overwriting is happening.

Line 70 goes a second subroutine, again like the first "ON L GOSUB ...." could have been used to speed up the process. This subroutine divides the value by half, so the theory here (which works) is Left Most Pixel Position is 128 as setup in the first subroutine, and second pixel position is 64, the 3rd is 32, 4th is 16, 5th is 8, 6th equals 4, 7th has 2 and the 8th has 1.

Line 80 Simply exits the FOR loop from Line 40 once the 8th position has been dealt with.

Line 90 Increments "L" so it's pointing to the next line

Line 100 Defines where the WHILE statement ends. To which it'll go back and check to see if "L" is not equal to 9 and to which it will run through the whole process again for redefining the next line.

Line 110 Simply takes it to the next phase of the program to draw the image!  ;D

The next parts of the program are two huge subroutines the first being defined from 1000-1080 and the second from 1100-1180, do they make sense cause I've sort of explained them, but anyway!  ;D

One line should be enough to explain:

Line 1000 being the most important cause it needs to tell 7 of the "v" variables to be 0, this is important because we only plotting one pixel in each character, this is done to ensure we get a sprite like image. The line which is worked on gets set to 128, this is because 128 equals the Left Most Pixel in the matrix, so Line 1, Row 1, Row 2, Row 3, etc, equals 128. Earlier I said the initial GOSUB 1000 in line 30 could be improved to read something like "ON L GOSUB 1000,1010,1020, etc" if that were the case then "IF" statements wouldn't be required because it's going straight to the relevant line, it would just need a RETURN at the end of each statement! 

Line 1100 takes the value which is being worked on and divides it by 2, so if v1 contains 128 as set in Line 1000 and is the variable being worked on, then Line 1100 will divide that so it becomes 64, this as I explained earlier is because the next pixel along equals 64 and then it will come back and do the 3rd, 4th, 5th, 6th, 7th & 8th spots. So that effectively completes the first line!  :)  Again like the first subroutine, if I'd used something like "ON L GOSUB" I wouldn't have required the "IF" statements!  :)

I call this bit the clever bit even though it can be improved on cause it's not doing this:


SYMBOL AFTER 32
SYMBOL 33,128,0,0,0,0,0,0,0
SYMBOL 34,64,0,0,0,0,0,0,0
SYMBOL 35,32,0,0,0,0,0,0,0
SYMBOL 36,16,0,0,0,0,0,0,0
SYMBOL 37,8,0,0,0,0,0,0,0
SYMBOL 38,4,0,0,0,0,0,0,0
SYMBOL 39,2,0,0,0,0,0,0,0
SYMBOL 40,1,0,0,0,0,0,0,0
Title: Re: Silly Programming Ideas - Turning Text into Graphics
Post by: AMSDOS on 11:24, 25 November 10
So with all the pixels defined and ready to go, the next part of the program deals with using them and displaying an colourful image.

2000 - deals with going to another subroutine (line 3000) which sets up the data for the image into an array, followed by setting up some Text-Based Co-ordinates to display the image, then going to another routine at 2500 which works over those points.

2010 - Simply calls a routine at 2100 which waits for a "Enter" or "Return" .

2020 - Bit like 2000 in that it sets up another position to draw another set of characters and then going through the subroutine to go through the whole process.

2030 - Same as 2010.

2040 - This line Resets everything - the character table, pen, mode and finally exits.

2100 - Simply checks if "Enter" or "Return" has been pressed before continuing!  ;D

2500 - 2540 - Line 2500 is somewhat misleading because it's setting up screen inks and borders, this should have been in Line 2000!  ;D  The num equals 33 is important though as it represents the start of our first pixel.  :)  Another variable "n2" is setup and set as 1, a loop is then generated to check and see if this is not equal to 65, as long as it's not equal to 65, the loop will proceed, continuing to Line 4000 which is the line which does all the displaying and positioning of the character. It is there where num is incremented, and the loop number "n2" is also incremented before returning to the loop.

3000 - 3080 - Line 3000 simply sets up the data in the following 8 lines and puts them into an array called "o". The array "o" has 64 positions to cater of each position from that 8x8 grid found in the text cursor.

4000 - Starts by placing the colour from the position of the array into the pen, it then proceeds by placing the x and y variables (as given earlier in lines 2000 and 2020) into a text co-ordinate position, followed by print it out in transparent mode - transparent mode is obtained by initating it with "chr$(22);chr$(1)+chr$(num)" - transparent mode is important because here I'm writing over one spot continously, naturally if you changed this to "chr$(22);chr$(0)+chr$(num)" the pixels would overwrite themselves and you'd be left with the last pixel at the bottom on show!  :)  "chr$(1)" which proceeds "chr$(22)" enables the program to go into transparent mode and that way each pixel from the redefined routine will be on display. The last "chr$(num)" represents the character to show in this case it starts at 33, and gets incremented to follow the redefined symbols which have been created - as show with "num=num+1" and the program then increments the value for the loop from line 2510 by adding 1 to "n2".

Pretty much sums it up.  Unfortunately the followup program which allows larger images may take more explaining!  :-[
Title: Re: Silly Programming Ideas - Turning Text into Graphics
Post by: AMSDOS on 09:24, 28 November 10
This is what happens in my followup code when you try to make things bigger when you try demonstrating redefined pixels to generate sprite like graphics!  ;D  Of course by this point I've taken what I knew was a silly idea and made it bigger by using bigger graphics, I think what encouraged me to do such a thing at the time was pure curiosity to see what the code would look like. Indeed though there are probably numerous ways one would achieve something like this and it dawned upon me when I posted the original program that there maybe a type-in out there which demonstrates the same sort of thing!  ;D  The result will look something like shown in my signature!  ;)

10 SYMBOL AFTER 32:char=33
20 l=1:WHILE (l<>9)
30 GOSUB 120
40 FOR m=1 TO 8
50 SYMBOL char,v1,v2,v3,v4,v5,v6,v7,v8
60 char=char+1
70 GOSUB 210
80 NEXT m
90 l=l+1
100 WEND
110 RUN 2000
120 IF l=1 THEN v1=128:v2=0:v3=0:v4=0:v5=0:v6=0:v7=0:v8=0
130 IF l=2 THEN v2=128:v1=0
140 IF l=3 THEN v3=128:v2=0
150 IF l=4 THEN v4=128:v3=0
160 IF l=5 THEN v5=128:v4=0
170 IF l=6 THEN v6=128:v5=0
180 IF l=7 THEN v7=128:v6=0
190 IF l=8 THEN v8=128:v7=0
200 RETURN
210 IF l=1 THEN v1=v1/2
220 IF l=2 THEN v2=v2/2
230 IF l=3 THEN v3=v3/2
240 IF l=4 THEN v4=v4/2
250 IF l=5 THEN v5=v5/2
260 IF l=6 THEN v6=v6/2
270 IF l=7 THEN v7=v7/2
280 IF l=8 THEN v8=v8/2
290 RETURN
2000 MODE 0:GOSUB 3000:x=10:y=10:n=193:n2=1:mv=65:GOSUB 2500
2010 x=10:y=11:n=257:n2=65:mv=129:GOSUB 2500
2020 x=10:y=12:n=321:n2=129:mv=193:GOSUB 2500
2030 GOSUB 2100
2040 SYMBOL AFTER 32:PEN 1:MODE 2:END
2100 WHILE INKEY$<>CHR$(13):WEND:RETURN
2500 BORDER 0:INK 1,26:INK 0,0:INK 7,2:INK 6,1:INK 4,3:INK 8,4:INK 9,16:num=33
2510 WHILE n2<>mv
2520 GOSUB 4000
2530 WEND
2540 RETURN
3000 DIM o(384):FOR n=1 TO 384:READ o(n):NEXT n:RETURN
3010 DATA 0,4,4,4,4,4,4,0
3020 DATA 0,4,4,4,4,4,4,4
3030 DATA 0,4,4,4,4,4,4,9
3040 DATA 4,4,4,4,4,4,4,9
3050 DATA 4,4,4,4,4,4,9,9
3060 DATA 4,4,4,4,1,0,9,0
3070 DATA 4,9,4,9,1,0,9,0
3080 DATA 0,9,4,9,1,0,9,0
3090 DATA 0,9,9,9,1,0,9,0
3100 DATA 0,4,9,9,1,1,9,1
3110 DATA 0,4,9,9,9,1,9,1
3120 DATA 0,4,9,9,9,9,9,9
3130 DATA 0,7,4,9,9,9,0,9
3140 DATA 7,7,7,9,9,9,9,9
3150 DATA 7,7,7,8,7,7,7,8
3160 DATA 7,7,9,8,7,7,7,8
3170 DATA 7,9,9,9,8,8,8,8
3180 DATA 0,9,9,8,6,1,6,1
3190 DATA 0,8,8,8,8,6,6,6
3200 DATA 0,8,8,8,8,8,8,8
3210 DATA 0,4,6,6,6,0,6,6
3220 DATA 0,4,4,4,4,0,4,4
3230 DATA 0,0,0,0,0,0,0,0
3240 DATA 0,0,0,0,0,0,0,0
3250 DATA 0,0,0,0,0,0,0,0
3260 DATA 4,4,0,0,0,0,0,0
3270 DATA 4,4,0,0,0,0,0,0
3280 DATA 4,4,0,0,0,0,0,0
3290 DATA 9,4,4,0,0,0,0,0
3300 DATA 1,4,4,0,0,0,0,0
3310 DATA 1,4,4,0,0,0,0,0
3320 DATA 1,4,4,0,0,0,0,0
3330 DATA 1,4,0,0,0,0,0,0
3340 DATA 9,9,0,0,0,0,0,0
3350 DATA 9,9,0,0,0,0,0,0
3360 DATA 9,9,0,0,0,0,0,0
3370 DATA 9,9,0,0,0,0,0,0
3380 DATA 9,8,0,0,0,0,0,0
3390 DATA 7,8,0,0,0,0,0,0
3400 DATA 9,9,0,0,0,0,0,0
3410 DATA 9,9,0,0,0,0,0,0
3420 DATA 8,9,0,0,0,0,0,0
3430 DATA 6,8,0,0,0,0,0,0
3440 DATA 8,8,8,0,0,0,0,0
3450 DATA 6,6,4,0,0,0,0,0
3460 DATA 4,4,4,0,0,0,0,0
3470 DATA 0,0,0,0,0,0,0,0
3480 DATA 0,0,0,0,0,0,0,0
4000 PEN o(n2):LOCATE x,y:PRINT CHR$(22);CHR$(1)+CHR$(num):PEN o(n): LOCATE x+1,y:PRINT CHR$(num):num=num+1:n2=n2+1:n=n+1:RETURN
Title: Re: Silly Programming Ideas - Turning Text into Graphics
Post by: AMSDOS on 10:20, 28 November 10
Going back to what I did with the first program I posted in here, here's what it would look like when I use the plotting feature:

10 MODE 0:BORDER 0:INK 1,26:INK 0,0:INK 2,2:INK 3,11:INK 4,25
20 GOSUB 3000
30 x=100:y=100:p=1
40 WHILE p<>65
50 WHILE x<>132
60 PLOT x,y,o(p):p=p+1:x=x+4
70 WEND
80 x=100:y=y-2
90 WEND
100 WHILE INKEY$<>CHR$(13):WEND:MODE 2:END
3000 DIM o(64):FOR n=1 TO 64:READ o(n):NEXT n:RETURN
3010 DATA 1,0,0,0,0,0,0,1
3020 DATA 2,1,1,1,1,1,1,2
3030 DATA 2,3,3,4,4,4,3,2
3040 DATA 2,3,3,4,3,3,3,2
3050 DATA 2,3,4,4,4,3,3,2
3060 DATA 2,3,3,4,3,3,3,2
3070 DATA 2,3,4,4,4,4,3,2
3080 DATA 0,2,2,2,2,2,2,0


Naturally when dealing with Graphics you have to deal with plotting positions based on the mode being used - so with this example it's in MODE 0, so every pixel is 4 columns along, 2 rows down - well that's what I've got to get the effect right. Also I have a nested loop, in my Pascal BOUNCY.PAS I used one loop which dealt with the length of the array which is a bit like what I've got here, though have used a second loop based on X which resets once the loop is reached, and moves to the next row. Maybe somewhat faster than what I'm currently used in my Pascal example.

But it just shows how much easier or shorter when things are done graphically!  ;D
Title: More Unusual Programming Ideas - INK Animation
Post by: AMSDOS on 11:54, 22 April 11
INK Animation seems to be something the CPC is very good at (even in BASIC), in the past I've seen some interesting demos which simply alternate between colours to make it appear as if movement is happening, usually a whole series of drawing is first applied & usually it's done in MODE 0 so you get 16 colours (or 15 if you're not alternating ink 0), once the drawing is complete the ink animation begins, some of that can be found within the AA Type-ins section on CPC-Wiki and lots of 10-liners have also been made using this process.

What I've done though is a little bit different (has possibly been done before with better effect) though this is real bizarre idea of having two tiny objects with 2 colours animating between one and the other in mode 1. In this example there's a hint that BASIC maybe a tad slow and that using the Firmware and Assembly would eliminate that (can anyone see why?  :) ). Otherwise the Animation switch is pretty good.

So in this program below I can move between 2 objects which have 2 colours each, both of these images uses the same colour and yet to make it seem like their different I came up with this program  :-[ :

10 MODE 1:WHILE 1
20 GOSUB 100
30 FOR delay=1 TO 500:NEXT
40 GOSUB 130
50 FOR delay=1 TO 500:NEXT
60 WEND
100 INK 0,1:PAPER 0:CLS:INK 1,26:INK 2,2:INK 3,0
110 PLOT 100,100,1:PLOT 98,98,2:PLOT 100,98,2:PLOT 102,98,2
120 RETURN
130 INK 1,1:PAPER 1:CLS:INK 0,26:INK 3,6:INK 2,1
140 PLOT 200,200,0:PLOT 198,198,3:PLOT 200,198,3:PLOT 202,198,3
150 RETURN


To make this program seem useful in MODE 1, one simply doesn't have the resources to alternate between colours like one would in MODE 0, in MODE 0 flicking between animations to make it appear something is happening, multi-coloured objects can utilise the various inks and then do a swap by turning a bunch of inks off and turning another set on. In MODE 1 the process is similar with regard to certain inks (2 in this example are being turned on and off when required), though to make a 2 coloured object appear at different intervals some variation process needs to occur. My program above gets around this by changing what is the background, so for each object, the paper switches backward and forward, with that I need to change the ink so it appears the background appears in the same colour and unfortunately I need to clear the screen to retain it otherwise I'd give away how the thing works!  ;D  It's not much to look at, though using this approach it allows for simple two object animations to be done in two colours in MODE 1. The effect as well is quite smooth and with the aid of another languages, larger images could be applied!  ;D
Title: Perhaps More Unusual Programming Ideas - Smooth'ish Vertical Scrolling.
Post by: AMSDOS on 11:04, 01 May 11
This is perhaps the easiest way I can think of with regard to producing an scrolling effect and indeed it seems to work.
At the moment it's simply a bunch of screen addresses followed by LDIR - 15 of them which moves the line 15 lines down. Just to test the whole effect I'm plotting a series of dots near the top of the screen (not at the top cause the scroll routine will smear those pixels down), when this is appllied I can call the Scrolling routine which will move those dots down the screen, making it appear as if your moving through a starfield.
After having a few thoughts about this over the last couple of days, I'm wondering how effective that scrolling method would go in a loop with a couple of pointers pointing to the addresses of where the screen is and where it has to go. The third paramater (BC) which is the length across is basically a constant.
Title: Re: Silly Programming Ideas - Turning Text into Graphics
Post by: MacDeath on 13:00, 01 May 11
QuoteTurning Text into Graphics
Good, you just re-invented ASCII art.
:D
Title: Re: Silly Programming Ideas - Turning Text into Graphics
Post by: AMSDOS on 00:06, 02 May 11
Quote from: MacDeath on 13:00, 01 May 11
Good, you just re-invented ASCII art.
:D

Just the kind of thing those Amstrad Magazines would have knocked back!  :laugh:  Though I can only imagine that since the ones I read were long gone when I wrote that program.
One has to wonder though what sort of Type-ins were being knocked back when they were at their peak though? Towards the closing of AA for example I heard they were getting a lot of Disc Utilities!  ;D 
On ESP (http://www.amstrad.es/forum/viewtopic.php?f=7&t=2315) I came across this huge Fleaz program which could perhaps go under this category (it's in English too!!)  ;D 
Title: Using Assembly Loops to Plot a series of Pixels for Drawing Images
Post by: AMSDOS on 10:44, 18 June 11
Quote from: CP/M User on 10:20, 28 November 10
Going back to what I did with the first program I posted in here, here's what it would look like when I use the plotting feature:

10 MODE 0:BORDER 0:INK 1,26:INK 0,0:INK 2,2:INK 3,11:INK 4,25
20 GOSUB 3000
30 x=100:y=100:p=1
40 WHILE p<>65
50 WHILE x<>132
60 PLOT x,y,o(p):p=p+1:x=x+4
70 WEND
80 x=100:y=y-2
90 WEND
100 WHILE INKEY$<>CHR$(13):WEND:MODE 2:END
3000 DIM o(64):FOR n=1 TO 64:READ o(n):NEXT n:RETURN
3010 DATA 1,0,0,0,0,0,0,1
3020 DATA 2,1,1,1,1,1,1,2
3030 DATA 2,3,3,4,4,4,3,2
3040 DATA 2,3,3,4,3,3,3,2
3050 DATA 2,3,4,4,4,3,3,2
3060 DATA 2,3,3,4,3,3,3,2
3070 DATA 2,3,4,4,4,4,3,2
3080 DATA 0,2,2,2,2,2,2,0

From this example I posted in November last year in BASIC, I've come up with some Assembly equivalents using the firmware, the first example is similar to this BASIC example above:

org &4000
ld a,1     
call &bc0e    ;; Set Screen Mode 1

ld hl,data_colour   ;; Address of Data Colour
ld (addrcolour),hl   ;; Place this into Address Colour

.loop
ld hl,(addrcolour)   ;; Place Contents of Address Colour into HL
ld a,(hl)    ;; Put Contents of HL into A
call do_colour

ld de,(xpos)    ;; XPOS data into DE
ld hl,(ypos)    ;; YPOS data into HL
call &bbea    ;; GRA ABSOLUTE PLOT

ld hl,(xpos)    ;; Obtain Contents of XPOS
inc hl     ;; Is 16bit Value so Increment 
inc hl     ;; Twice
ld (xpos),hl    ;; Place next value into XPOS

ld a,(fcount)    ;; First Counter Position into A
inc a     ;; Increment this 
ld (fcount),a    ;; Put New Value into First Count Position
ld b,a     ;; Put this value into B

ld a,(xlcount)    ;; Place First Counter Marker into A

cp b     ;; Has value of B reached A value
jr nz,loop    ;; If No Loop back, otherwise continue

ld a,(fcount)    ;; At this stage fcount equals 8
xor a     ;; This will make it 0 again
ld (fcount),a    ;; And put that value into fcount

ld hl,(ypos)    ;; YPOS of data can now be Incremented
inc hl     ;; Again 16bit Value means Incrementing
inc hl     ;; it Twice
ld (ypos),hl    ;; And put that value into YPOS.

ld a,(xpos)    ;; Value of XPOS needs to return back to where it was.
sub 16     ;; Subtracting 16 will resolve this.
ld (xpos),a    ;; New Value goes into XPOS.

ld a,(scount)    ;; Second counter goes into A
inc a     ;; Increase it.
ld (scount),a    ;; Place back into Second Counter
ld b,a     ;; Put value of Second counter into B

ld a,(ylcount)    ;; Place Y-counting position into A

cp b     ;; Compare A to value of B
jr nz,loop    ;; If reached exit, otherwise return

ld a,0     ;; \
ld hl,fcount    ;; \\
ld (hl),a    ;; Returns loop values back to 0
ld hl,scount    ;; //
ld (hl),a    ;; /

ld hl,100    ;; Return the value of ypos
ld (ypos),hl    ;; back to it's original place.

ret     ;; Program exits here.

.do_colour
   call &bbde    ;; GRA SET PEN - A = Pen Colour
   ld hl,(addrcolour)   ;; Take address of address colour
   inc hl     ;; Increment it by 1
   ld (addrcolour),hl   ;; Put this value into Address Colour
   ret     ;; Return to Main Loop Routine.

.fcount defb 0
.scount defb 0
.xlcount
defb 8     ;; Number of times to loop across.
.ylcount
defb 8     ;; Number of times to loop down
.xpos defw 100    ;; Left Position the image
.ypos defw 100    ;; Bottom Position of the image.
.data_colour
  defb 1,1,0,1,0,1,1,0
  defb 0,3,3,3,3,3,0,0
  defb 0,0,2,2,2,0,0,0
  defb 0,0,2,2,2,0,0,0
  defb 0,0,2,2,2,0,0,0
  defb 0,0,2,2,2,0,0,0
  defb 0,0,2,2,2,0,0,0
  defb 0,0,0,1,0,0,0,0

.addrcolour
  defw 0     ;; This points to the address position
      ;; within the data colour.


In the second and third examples though I've modified the assembly routine above, so it doesn't set the graphics ink or plot if a zero ink colour is found. Wasn't sure if this approach would enhance the time to plot the image, the following routine uses 8x8 sprite which is too difficult to tell if it's any faster, though the last example I've got here is displaying an image 15x23 in size and uses a lot of zero's, in that example it appears it takes less time to display the entire image because it's not processing all the zero colour points.


org &4000
; ld a,1     
; call &bc0e    ;; Set Screen Mode 1

ld hl,data_colour   ;; Address of Data Colour
ld (addrcolour),hl   ;; Place this into Address Colour
.loop
ld hl,(addrcolour)   ;; Place Contents of Address Colour into HL
ld a,(hl)    ;; Put Contents of HL into A
cp 0
jr z,iszero

call &bbde    ;; GRA SET PEN - A = Pen Colour

ld de,(xpos)    ;; XPOS data into DE
ld hl,(ypos)    ;; YPOS data into HL
call &bbea    ;; GRA ABSOLUTE PLOT

.iszero
ld hl,(addrcolour)   ;; Take address of address colour
inc hl     ;; Increment it by 1
ld (addrcolour),hl   ;; Put this value into Address Colour

ld hl,(xpos)    ;; Obtain Contents of XPOS
inc hl     ;; Is 16bit Value so Increment 
inc hl     ;; Twice
ld (xpos),hl    ;; Place next value into XPOS

ld a,(fcount)    ;; First Counter Position into A
inc a     ;; Increment this 
ld (fcount),a    ;; Put New Value into First Count Position
ld b,a     ;; Put this value into B

ld a,(xlcount)    ;; Place First Counter Marker into A

cp b     ;; Has value of B reached A value
jr nz,loop    ;; If No Loop back, otherwise continue

ld a,(fcount)    ;; At this stage fcount equals 8
xor a     ;; This will make it 0 again
ld (fcount),a    ;; And put that value into fcount

ld hl,(ypos)    ;; YPOS of data can now be Incremented
inc hl     ;; Again 16bit Value means Incrementing
inc hl     ;; it Twice
ld (ypos),hl    ;; And put that value into YPOS.

ld a,(xpos)    ;; Value of XPOS needs to return back to where it was.
sub 16     ;; Subtracting 16 will resolve this.
ld (xpos),a    ;; New Value goes into XPOS.

ld a,(scount)    ;; Second counter goes into A
inc a     ;; Increase it.
ld (scount),a    ;; Place back into Second Counter
ld b,a     ;; Put value of Second counter into B

ld a,(ylcount)    ;; Place Y-counting position into A

cp b     ;; Compare A to value of B
jr nz,loop    ;; If reached exit, otherwise return

ld a,0     ;; \
ld hl,fcount    ;; \\
ld (hl),a    ;; Returns loop values back to 0
ld hl,scount    ;; //
ld (hl),a    ;; /

ld hl,100    ;; Return the value of ypos
ld (ypos),hl    ;; back to it's original place.
ret     ;; Program exits here.

.fcount defb 0
.scount defb 0
.xlcount
defb 8     ;; Number of times to loop across.
.ylcount
defb 8     ;; Number of times to loop down
.xpos defw 100    ;; Left Position the image
.ypos defw 100    ;; Bottom Position of the image.
.data_colour
  defb 1,1,0,1,0,1,1,0
  defb 0,3,3,3,3,3,0,0
  defb 0,0,2,2,2,0,0,0
  defb 0,0,2,2,2,0,0,0
  defb 0,0,2,2,2,0,0,0
  defb 0,0,2,2,2,0,0,0
  defb 0,0,2,2,2,0,0,0
  defb 0,0,0,1,0,0,0,0

.addrcolour
  defw 0     ;; This points to the address position
      ;; within the data colour.



org &4000

xor a     ;; Setup data for Screen Mode
call &bc0e    ;; Set Screen Mode 0

call setup_inks    ;; Setup inks for image

ld hl,data_colour   ;; Address of Data Colour
ld (addrcolour),hl   ;; Place this into Address Colour
.loop
ld hl,(addrcolour)   ;; Place Contents of Address Colour into HL
ld a,(hl)    ;; Put Contents of HL into A
cp 0
jr z,iszero

call &bbde    ;; GRA SET PEN - A = Pen Colour

ld de,(xpos)    ;; XPOS data into DE
ld hl,(ypos)    ;; YPOS data into HL
call &bbea    ;; GRA ABSOLUTE PLOT

.iszero
ld hl,(addrcolour)   ;; Take address of address colour
inc hl     ;; Increment it by 1
ld (addrcolour),hl   ;; Put this value into Address Colour

ld hl,(xpos)    ;; Obtain Contents of XPOS
inc hl     ;; XPOS needs to be Incremented   
inc hl     ;; 4 times because this image
inc hl     ;; is done in mode 0
inc hl     ;; (e.g. 100..104..108..112..116..etc)
ld (xpos),hl    ;; Place next value into XPOS

ld a,(fcount)    ;; First Counter Position into A
inc a     ;; Increment this 
ld (fcount),a    ;; Put New Value into First Count Position
ld b,a     ;; Put this value into B

ld a,(xlcount)    ;; Place First Counter Marker into A

cp b     ;; Has value of B reached A value
jr nz,loop    ;; If No Loop back, otherwise continue

ld a,(fcount)    ;; At this stage fcount equals 8
xor a     ;; This will make it 0 again
ld (fcount),a    ;; And put that value into fcount

ld hl,(ypos)    ;; value of YPOS goes into HL
dec hl     ;; value of YPOS is decreased
dec hl     ;; Twice (100..98..96..94..etc)
ld (ypos),hl    ;; And put that value into YPOS.

ld a,(xpos)    ;; Value of XPOS needs to return back to where it was.
sub 60     ;; Subtracting 60 will resolve this.
ld (xpos),a    ;; New Value goes into XPOS.

ld a,(scount)    ;; Second counter goes into A
inc a     ;; Increase it.
ld (scount),a    ;; Place back into Second Counter
ld b,a     ;; Put value of Second counter into B

ld a,(ylcount)    ;; Place Y-counting position into A

cp b     ;; Compare A to value of B
jr nz,loop    ;; If reached exit, otherwise return

ld a,0     ;; \
ld hl,fcount    ;; \\
ld (hl),a    ;; Returns loop values back to 0
ld hl,scount    ;; //
ld (hl),a    ;; /

ld hl,100    ;; Return the value of ypos
ld (ypos),hl    ;; back to it's original place.

ret     ;; Program exits here.

.setup_inks
ld hl,colours
ld a,0
.inks_loop
ld c,(hl)
ld b,c
push af
push hl
call &bc32
pop hl
pop af
inc hl
inc a
cp 8
jr c,inks_loop
ret     ;; Return to Main Loop Routine.

.fcount defb 0
.scount defb 0
.xlcount
defb 15     ;; Number of times to loop across.
.ylcount
defb 23     ;; Number of times to loop down
.xpos defw 100    ;; Left Position the image
.ypos defw 100    ;; Bottom Position of the image.

.colours
defb 0,26,11,2,1,3,6,16

.data_colour
  defb 0,0,0,0,0,0,0,1,0,0,0,0,0,0,0
  defb 0,0,0,0,0,0,1,0,1,0,0,0,0,0,0
  defb 0,0,0,0,0,1,0,0,0,1,0,0,0,0,0
  defb 0,0,0,0,1,0,0,0,0,0,1,0,0,0,0
  defb 0,0,0,1,0,0,0,0,0,0,0,1,0,0,0
  defb 0,0,1,0,0,0,0,0,0,0,0,0,1,0,0
  defb 0,1,0,0,1,5,1,0,1,5,1,0,0,1,0
  defb 1,0,0,0,0,1,0,0,0,1,0,0,0,0,1
defb 1,0,0,0,0,0,0,0,0,0,0,0,0,0,1
  defb 0,1,0,0,0,0,0,0,0,0,0,0,0,1,0
  defb 0,0,1,4,4,4,4,4,4,4,4,4,1,0,0
  defb 0,1,4,4,1,4,4,4,4,4,1,4,4,1,0
  defb 0,1,4,4,1,4,4,4,4,4,1,4,4,1,0
  defb 1,4,4,1,7,1,4,4,4,1,7,1,4,4,1
  defb 0,1,4,3,1,3,4,4,4,3,1,3,4,1,0
  defb 0,1,4,4,3,4,4,4,4,4,3,4,4,1,0
  defb 0,0,1,4,4,4,4,4,4,4,4,4,1,0,0
defb 0,0,1,2,2,2,2,2,2,2,2,2,1,0,0
  defb 0,0,0,1,1,2,2,2,2,2,1,1,0,0,0
  defb 0,0,0,0,0,1,1,2,1,1,0,0,0,0,0
  defb 0,0,0,0,0,1,0,1,0,1,0,0,0,0,0
  defb 0,0,0,0,0,1,0,0,0,1,0,0,0,0,0
defb 0,0,0,0,1,1,1,0,1,1,1,0,0,0,0

.addrcolour
  defw 0     ;; This points to the address position
      ;; within the data colour.


I wouldn't say that these were silly in nature, I've only posted them here as a comparasion to the BASIC program and as examples of setting about drawing an image from minimal code. In terms of improving the assembly code, I'm thinking it's possible - the last program for instance has this bit:

ld hl,(xpos)
inc hl
inc hl
inc hl
inc hl
ld (xpos),hl


which I did have working with:

ld hl,(xpos)
ld bc,4
add hl,bc
ld (xpos),hl


though I'm guessing that it could be done with SLA which I think is faster again, though for this occassion SLA has be stumped.

Let me know if this would be a worthwhile article for the Wiki programming section.

EDIT: Unfortunately I forgot to attach those additional files, so there here now, in that process I found out I had Plot Image already been uploaded from a previous conversation!  :o  So it can be found here (http://www.cpcwiki.eu/forum/index.php?action=dlattach;topic=1959.0;attach=1596)!  :)
Title: Re: Silly Programming Ideas - Turning Text into Graphics
Post by: AMSDOS on 11:24, 30 October 11
Noticed there was some interest earlier in the year when it came to some Big Large Chunky Sprites, when I was a kid I made this Crude Text Graphical Program, which was replaced when AA had the BASIC Art program in AA73 (which was fantastic cause it worked on my 464 and featured a Fill Routine!  :) ), followed by GPAINT on the AA80 Covertape! One of the things I did on my own Graphical Editor was make some Blocky Images (using character 143) I could get some reasonible images out of it!

Anyway I was playing around in BASIC and came up with this which from DATA I already had and wrote the BASIC viewer to see how it would look (using Traditional character 143).

10 MODE 0: INK 0,0:INK 1,26:INK 4,3:INK 6,1:INK 7,2:INK 8,4:INK 9,16
20 DIM col(242):GOSUB 100:a=1
30 FOR y=1 TO 22
40 FOR x=1 TO 11
50 LOCATE x,y:PEN col(a):PRINT CHR$(143);
60 a=a+1
70 NEXT x:NEXT y
80 CALL &BB18:PEN 1:MODE 2:END
100 ' Set up Colours
110 FOR a=1 TO 241
120 READ c
130 col(a)=c
140 NEXT a:RETURN
150 DATA 0,4,4,4,4,4,4,0,0,0,0
160 DATA 0,4,4,4,4,4,4,4,4,4,0
170 DATA 0,4,4,4,4,4,4,9,4,4,0
180 DATA 4,4,4,4,4,4,4,9,4,4,0
190 DATA 4,4,4,4,4,4,9,9,9,4,4
200 DATA 4,4,4,4,1,0,9,0,1,4,4
210 DATA 4,9,4,9,1,0,9,0,1,4,4
220 DATA 0,9,4,9,1,0,9,0,1,4,4
230 DATA 0,9,9,9,1,0,9,0,1,4,0
240 DATA 0,4,9,9,1,1,9,1,9,9,0
250 DATA 0,4,9,9,9,1,9,1,9,9,0
260 DATA 0,4,9,9,9,9,9,9,9,9,0
270 DATA 0,7,4,9,9,9,0,9,9,9,0
280 DATA 7,7,7,9,9,9,9,9,9,8,0
290 DATA 7,7,7,8,7,7,7,8,7,8,0
300 DATA 7,7,9,8,7,7,7,8,9,9,0
310 DATA 7,9,9,9,8,8,8,8,9,9,0
320 DATA 0,9,9,8,6,1,6,1,8,9,0
330 DATA 0,8,8,8,8,6,6,6,6,8,0
340 DATA 0,8,8,8,8,8,8,8,8,8,8
350 DATA 0,4,6,6,6,0,6,6,6,6,4
360 DATA 0,4,4,4,4,0,4,4,4,4,4


Though the main reason I did that, was to trial this effect using SCR FILL BOX (&BC44). SCR FILL BOX is a funny Firmware instruction I reckon, it's described as a "Commonly used ROM subroutine" along with a number of other Firmware routines which are Commonly Used, though I haven't seen many people use SCR FILL BOX, except for one of the articles in an Early Australian Amstrad Magazine which has included it in their program which includes other Firmware Routines (not found as BASIC commands), and my Assembly Book has the wrong detail regarding one of the entry conditions for this SCR FILL BOX routine, specifying the INK number must be in the Accumulator which should be the Encoded INK Mask value, another reason I couldn't understand the funny stripes when I used to try and play around with it.

It wasn't easy coming up with a SCR FILL BOX routine which displays an image like the BASIC program does above and was making stupid mistakes until I realised what I had wrong, my main problem was in the way SCR FILL BOX has the registers setup for setting up the right entry of the registers which are as follows (from Kev Thacker's CPC Guide v1.2):


A = encoded ink to fill area with
H = left column of area-1
D = right column of area-1
L = top row-1
E = bottom row-1


On Exit:


AF,BC,DE,HL changed.


SCR FILL BOX is always a good one to do as a test to see what it does cause it's not as clear as it seems until you've thrown some values at it.


org &4000

ld a,&ff
ld h,0
ld d,0
ld l,0
ld e,0
call &bc44
ret


This for example will place a Red Square on the top left hand corner which is 8 pixels across and 8 pixels down. Try changing that to do something like this:


org &4000

ld a,&ff
ld h,0
ld d,2
ld l,0
ld e,0
call &bc44
ret


And it will draw across the screen 3 character lengths at 8 pixels doing 24 pixels in fairly reasonible time!  :)

Though this is what I ended up with which I haven't commented on yet, which is merely what I've got in BASIC form above, though a bit quicker using the SCR FILL BOX  :)  It's a funny routine this SCR FILL BOX for one thing it's using Text Based numbering to place the image on screen! Though could be useful for when dealing with Large Blocky Graphics to be shown on Screen, perhaps not in the same league as those who have written Blocky Graphics Routines for use in Games. I suspect it anyone knows of any AMSOFT games which feature large Blocky Graphics, then it will be using the SCR FILL BOX routine. At this time the only game I can thing of with a large Sprite onscreen is the opening screen in Mutant Monty, though I think that graphic has too much detail for it to be considered as a large blocky sprite using SCR FILL BOX.


;; Big BUB using SCR FILL BOX (&BC44)

org &4000

ld a,0
call &bc0e

call setupcols
call drawimg
call resval

call &bb18

ld a,2
call &bc0e

ret

.setupcols
ld hl,cols
ld a,0
.inkloop
ld c,(hl)
ld b,c
push af
push hl
call &bc32
pop hl
pop af
inc hl
inc a
cp 10
jr c,inkloop
ret

.drawimg
ld hl,(bubptr)
ld a,(hl)

push af

ld a,(lftcol)
ld h,a

ld a,(rftcol)
ld d,a

ld a,(toprow)
ld l,a

ld a,(botrow)
ld e,a

pop af

call &bc44

ld hl,(bubptr)
inc hl
ld (bubptr),hl

ld a,(lftcol)
inc a
ld (lftcol),a

ld a,(rftcol)
inc a
ld (rftcol),a

ld a,(fcount)
inc a
ld (fcount),a

ld b,a
ld a,(xval)
cp b
jr nz,drawimg

ld a,(fcount)
xor a
ld (fcount),a

ld a,(toprow)
inc a
ld (toprow),a

ld a,(botrow)
inc a
ld (botrow),a

ld a,(lftcol)
xor a
ld (lftcol),a

ld a,(rftcol)
xor a
ld (rftcol),a

ld a,(scount)
inc a
ld (scount),a
ld b,a
ld a,(yval)
cp b
jr nz,drawimg
ret

.resval
xor a
ld (fcount),a
ld (scount),a
ld (lftcol),a
ld (rftcol),a
ld (toprow),a
ld (botrow),a
ld hl,bub
ld (bubptr),hl
ret

.cols defb 0,26,0,0,3,0,1,2,4,16

.fcount defb 0
.scount defb 0

.lftcol defb 0
.rftcol defb 0

.toprow defb 0
.botrow defb 0

.yval   defb 22
.xval   defb 11

.bubptr defw bub

.bub
defb &00,&30,&30,&30,&30,&30,&30,&00,&00,&00,&00
defb &00,&30,&30,&30,&30,&30,&30,&30,&30,&30,&00
defb &00,&30,&30,&30,&30,&30,&30,&c3,&30,&30,&00
defb &00,&30,&30,&30,&30,&30,&30,&c3,&30,&30,&00
defb &30,&30,&30,&30,&30,&30,&c3,&c3,&c3,&30,&30
defb &30,&30,&30,&30,&c0,&00,&c3,&00,&c0,&30,&30
defb &30,&c3,&30,&c3,&c0,&00,&c3,&00,&c0,&30,&30
defb &00,&c3,&30,&c3,&c0,&00,&c3,&00,&c0,&30,&30
defb &00,&c3,&c3,&c3,&c0,&00,&c3,&00,&c0,&30,&00
defb &00,&30,&c3,&c3,&c0,&c0,&c3,&c0,&c3,&c3,&00
defb &00,&30,&c3,&c3,&c3,&c0,&c3,&c0,&c3,&c3,&00
defb &00,&30,&c3,&c3,&c3,&c3,&c3,&c3,&c3,&c3,&00
defb &00,&fc,&30,&c3,&c3,&c3,&00,&c3,&c3,&c3,&00
defb &fc,&fc,&fc,&c3,&c3,&c3,&c3,&c3,&c3,&03,&00
defb &fc,&fc,&fc,&03,&fc,&fc,&fc,&03,&fc,&03,&00
defb &fc,&fc,&c3,&03,&fc,&fc,&fc,&03,&c3,&c3,&00
defb &fc,&c3,&c3,&c3,&03,&03,&03,&03,&c3,&c3,&00
defb &00,&c3,&c3,&03,&3c,&c0,&3c,&c0,&03,&c3,&00
defb &00,&03,&03,&03,&03,&3c,&3c,&3c,&3c,&03,&00
defb &00,&03,&03,&03,&03,&03,&03,&03,&03,&03,&03
defb &00,&30,&3c,&3c,&3c,&00,&3c,&3c,&3c,&3c,&30
defb &00,&30,&30,&30,&30,&00,&30,&30,&30,&30,&30

;; Masks to be used in PENs

;; pen 0 = &00
;; pen 1 = &c0
;; pen 4 = &30
;; pen 6 = &3c
;; pen 7 = &FC
;; pen 8 = &03
;; pen 9 = &c3
Title: Re: Silly Programming Ideas - Turning Text into Graphics
Post by: AMSDOS on 09:44, 31 October 11
Thanks for your support!  :)

I've attached a followup to the Assembly Routine I posted Yesterday with some comments added to the file which I hope will help people follow the process. The routine can probably be cut down in size with the number of variables it's using and the additional code cause it's mainly 4 variables with 2 only requiring different values at the same time, the second variable only really needs what's in the other for this to work, changing that would mess up the process.
Title: Re: Silly Programming Ideas - Turning Text into Graphics
Post by: AMSDOS on 11:28, 01 November 11
This is the final version of the SCR FILL BOX routine which is more refined, compact & commented which does the same job! Too many variables (memory locations) were used!  :laugh:
Title: Other Silly Programming Ideas - Graphical Mumbo Jumbo.
Post by: AMSDOS on 10:39, 05 November 11
Some more BASIC code, I don't really expect anyone to use it, though if curiosity gets the better of you, you can click "quote" alongside this post and extract the source code that way (with the Carriage Returns):

10 MODE 1:ORIGIN 0,0,100,200,200,100
20 CLG
30 WHILE INKEY$<>" "
40 a=INT(RND*3)+1:PLOT INT(RND*100)+100,INT(RND*100)+100,a
50 WEND


This program sets up a Graphics Window (as shown in ORIGIN), followed by a Clear of that Graphical Window which does nothing, setting up a GRAPHICS PAPER before that with any value apart from 0 would show the effect CLG has on it though which is interesting, apart from that move it inside the while loop with some CALL &BD19 or FRAMEs will definitely do something in there!  :)  As it is it will Enter the Loop (and continue until SPACE bar has been pressed) and just randomibly draw dots in that Graphics Window in various colours!  :)  Not ground breaking.  :laugh:

10 MODE 1
20 xc=2:yc=2:x=0:y=0
30 WHILE INKEY$=""
40 CALL &BD19:CALL &BD19:CALL &BD19:CALL &BD19:ORIGIN x,y:PLOT 100,100,1:DRAW 125,100:DRAW 125,125:DRAW 100,125:DRAW 100,100
50 ox=x:oy=y:x=x+xc:y=y+yc
60 CALL &BD19:CALL &BD19:CALL &BD19:CALL &BD19:ORIGIN ox,oy:PLOT 100,100,0:DRAW 125,100:DRAW 125,125:DRAW 100,125:DRAW 100,100
70 IF x=100 then xc=-2
80 if y=100 then yc=-2
90 if x=0 then xc=2
100 if y=0 then yc=2
110 wend


This code is perhaps the more interesting of the two. This program goes about drawing a box on screen and then rubs it out, looping backwards and fowards until someone presses a key!  :o  Though the co-ordinates of the box never changes, it's pretty obvious to see that the ORIGIN is responcible for making that box move because the origin co-ordinates x & y are changing which is making the rest of the screen appear to move. While I'd placed a number of Frame Flyback instructions in there (CALL &BD19), this example carries on blinking a lot. Perhaps it could be improved!  :laugh:  Applying this approach in Assembly though (even using standard Firmware instructions) will ultimately reduce that flicker though!  ;D
Title: Re: Silly Programming Ideas - Turning Text into Graphics
Post by: AMSDOS on 13:33, 05 November 11
Going back to that first program in the previous post, I did some adjustments to it primarily line 30 (unfortunately it's a BASIC 1.1 program, firmware may have a routine for this though):

10 MODE 1:ORIGIN 0,0,100,200,200,100
20 WHILE INKEY$=""
30 FOR delay=1 TO a:CALL &BD19:CALL &BD19:GRAPHICS PAPER a:CLG:NEXT delay
40 a=INT(RND*3)+1:PLOT INT(RND*100)+100,INT(RND*100)+100,a
50 WEND


And got an interesting effect from it. To me it's tricking the eye cause it appears more than one pixel dot while the program is flashing through. I put a CALL &BB18 which halts until a keypress is made which suggested that it's only showing one, though perhaps with the program running faster it's generated this extra effect which won't show up on close examination.  :laugh:
Title: Re: Silly Programming Ideas - Turning Dotty! :p
Post by: AMSDOS on 11:37, 22 November 11
This is quite a straightfoward effect, writing it up in BASIC I mean  :)  Though the effect is just that, another display effect for them demos or games or just for more ideas/possibilities which haven't been considered until now!  ;D

Below is only a demonstration of the effect (singular colour), though it wouldn't be hard to apply something like that image from that Array into this sort of thing.  :laugh:  Obviously though to apply the effect in MODE 0 or MODE 2, the key to generating that effect in those modes would be based on the STEP done in those FOR loops.

10 MODE 1:BORDER 0:INK 0,0:INK 1,13
20 FOR x=0 TO 638 STEP 4
30 FOR y=400 TO 0 STEP -4
40 PLOT x,y,1
50 NEXT y
60 NEXT x
70 CALL &BB18 ' KM WAIT KEY


Title: Re: Silly Programming Ideas - Turning Text into Graphics
Post by: Bryce on 13:25, 22 November 11
How long do I have to stare at it with squinted eyes before I see the Mona Lisa in 3D?

Bryce.
Title: Re: Silly Programming Ideas - Turning Text into Graphics
Post by: AMSDOS on 10:25, 23 November 11
Quote from: Bryce on 13:25, 22 November 11
How long do I have to stare at it with squinted eyes before I see the Mona Lisa in 3D?

Bryce.

Er? Until you find the right pixel with the right painting in it (kind of like a Where's Wally book).  :laugh:

This program below produces a dotty image of Bub, is kind of tricky given it's an image with boundaries - one sort of has to apply where the image will finish along the x-position and y-position, perhaps "while..wend" is more suitable, and it simply counts along the array.

10 MODE 0:INK 0,0:INK 1,26:INK 4,3:INK 6,1:INK 7,2:INK 8,4:INK 9,16
20 DIM col(242):GOSUB 1000:a=1
30 FOR y=400 to 224 step -8
40 FOR x=0 to 88 step 8
50 plot x,y,col(a)
60 a=a+1
70 next x
80 next y
90 call &bb18
100 mode 2:call &bc02:end
1000 ' Set up Colours
1010 FOR a=1 TO 241
1020 READ c
1030 col(a)=c
1040 NEXT a:RETURN
1050 DATA 0,4,4,4,4,4,4,0,0,0,0
1060 DATA 0,4,4,4,4,4,4,4,4,4,0
1070 DATA 0,4,4,4,4,4,4,9,4,4,0
1080 DATA 4,4,4,4,4,4,4,9,4,4,0
1090 DATA 4,4,4,4,4,4,9,9,9,4,4
1100 DATA 4,4,4,4,1,0,9,0,1,4,4
1110 DATA 4,9,4,9,1,0,9,0,1,4,4
1120 DATA 0,9,4,9,1,0,9,0,1,4,4
1130 DATA 0,9,9,9,1,0,9,0,1,4,0
1140 DATA 0,4,9,9,1,1,9,1,9,9,0
1150 DATA 0,4,9,9,9,1,9,1,9,9,0
1160 DATA 0,4,9,9,9,9,9,9,9,9,0
1170 DATA 0,7,4,9,9,9,0,9,9,9,0
1180 DATA 7,7,7,9,9,9,9,9,9,8,0
1190 DATA 7,7,7,8,7,7,7,8,7,8,0
1200 DATA 7,7,9,8,7,7,7,8,9,9,0
1210 DATA 7,9,9,9,8,8,8,8,9,9,0
1220 DATA 0,9,9,8,6,1,6,1,8,9,0
1230 DATA 0,8,8,8,8,6,6,6,6,8,0
1240 DATA 0,8,8,8,8,8,8,8,8,8,8
1250 DATA 0,4,6,6,6,0,6,6,6,6,4
1260 DATA 0,4,4,4,4,0,4,4,4,4,4


The final result can be shown in the image!  :laugh:
Title: Re: Silly Programming Ideas - Turning Text into Graphics
Post by: AMSDOS on 10:01, 24 November 11
I've modified the last program so now it's running on WHILE..WEND loops instead of FOR..NEXT. It was a pain in the butt trying to get it to work (I'm bad when it comes to WHILE..WEND loops!  :o ), and the program is obviously larger than the last one, using more variables (I've added comments to explain it as well). The advantage with this program now though, is you simply tell where the image can go - x & y positions and the program will do the rest, unlike the last example which requires the start and end positions! I've also altered the y coordinate in this as well (instead of stepping 8 pixels which should have been 4) which produces a more natural look of the image, instead of a stretched one!  8)

10 MODE 0:BORDER 0:INK 0,0:INK 1,26:INK 4,3:INK 6,1:INK 7,2:INK 8,4:INK 9,16
20 DIM col(242):GOSUB 1000:a=1:y=398:x=0
30 c1=0:c2=0
40 WHILE (c1<>22):WHILE (c2<>11)
50 PLOT x,y,col(a)
60 x=x+8 ' increment x position by 8 pixels, generates dotted effect. Change to 4 for undotted effect.
70 a=a+1 ' increment for colour array, with image colour in it
80 c2=c2+1 ' increment loop (x coordinate) position by 1
90 WEND ' c2 trigger - works on x coordinate
100 c2=0 ' reset loop position to the start (for x coordinate)
110 y=y-4 ' position y position down 4 pixels, generates dotted effect. Change to 2 for undotted effect or 8 for more dotted effect.
120 x=0 ' return x position to begining, can be anywhere depending on position of image
130 c1=c1+1 ' increment loop (y coordinate) position by 1
140 WEND ' c1 triggers back to first loop if total has not been reached, otherwise exits
150 CALL &BB18
160 MODE 2:CALL &BC02:END
1000 ' Set up Colours
1010 FOR a=1 TO 241
1020 READ c
1030 col(a)=c
1040 NEXT a:RETURN
1050 DATA 0,4,4,4,4,4,4,0,0,0,0
1060 DATA 0,4,4,4,4,4,4,4,4,4,0
1070 DATA 0,4,4,4,4,4,4,9,4,4,0
1080 DATA 4,4,4,4,4,4,4,9,4,4,0
1090 DATA 4,4,4,4,4,4,9,9,9,4,4
1100 DATA 4,4,4,4,1,0,9,0,1,4,4
1110 DATA 4,9,4,9,1,0,9,0,1,4,4
1120 DATA 0,9,4,9,1,0,9,0,1,4,4
1130 DATA 0,9,9,9,1,0,9,0,1,4,0
1140 DATA 0,4,9,9,1,1,9,1,9,9,0
1150 DATA 0,4,9,9,9,1,9,1,9,9,0
1160 DATA 0,4,9,9,9,9,9,9,9,9,0
1170 DATA 0,7,4,9,9,9,0,9,9,9,0
1180 DATA 7,7,7,9,9,9,9,9,9,8,0
1190 DATA 7,7,7,8,7,7,7,8,7,8,0
1200 DATA 7,7,9,8,7,7,7,8,9,9,0
1210 DATA 7,9,9,9,8,8,8,8,9,9,0
1220 DATA 0,9,9,8,6,1,6,1,8,9,0
1230 DATA 0,8,8,8,8,6,6,6,6,8,0
1240 DATA 0,8,8,8,8,8,8,8,8,8,8
1250 DATA 0,4,6,6,6,0,6,6,6,6,4
1260 DATA 0,4,4,4,4,0,4,4,4,4,4

Title: Re: Silly Programming Ideas - Turning Text into Graphics
Post by: tastefulmrship on 10:27, 24 November 11
@ CPM/User
If you're going to be using ONLY integer values for your variables, may I suggest using either a DEFINT a-z at the beginning of your programs or add a % symbol to the end of all your INTEGER variables, especially now as your programs are growing more and more complex. This will seriously speed up the BASIC programming, as it only needs to process INTEGERs rather than FLOATING POINT numbers.

For example;

10 t=TIME
20 FOR l=1 TO 5000
30 NEXT l
40 PRINT (TIME-t)/300
50 '
60 t=TIME
70 FOR l%=1 TO 5000
80 NEXT l%
90 PRINT (TIME-t)/3000


The first LOOP takes 5.5 seconds to run as the CPU is processing FLOATING POINT numbers and the second LOOP only takes 2.4 seconds as the CPU only needs to process INTEGERs.


I hope this may help you in the future,
- JTMS...
Title: Re: Silly Programming Ideas - Turning Text into Graphics
Post by: AMSDOS on 23:55, 25 November 11
Quote from: tastefulmrship on 10:27, 24 November 11
@ CPM/User
If you're going to be using ONLY integer values for your variables, may I suggest using either a DEFINT a-z at the beginning of your programs or add a % symbol to the end of all your INTEGER variables, especially now as your programs are growing more and more complex. This will seriously speed up the BASIC programming, as it only needs to process INTEGERs rather than FLOATING POINT numbers.

Yeah sloppy BASIC programming on my behalf!  :(  I'm only writing them so they exist and then perhaps code them to Assembly using the Firmware, which is unfair I guess in a sense because it makes the Assembly look even faster and the BASIC even slower!  :o  I'm somewhat hesitant using DEFINT a-z, which obviously works, though is defining everything as Integer, if I can at least DEFINT x,y,a,c,c1,c2 would that work as an alternative?
I like the idea of having "%" as a way of recognising the type of variable that's being used, though coding it throughout the program is time consuming!  :(
Title: Re: Silly Programming Ideas - Turning Text into Graphics
Post by: tastefulmrship on 10:02, 26 November 11
Quote from: CP/M User on 23:55, 25 November 11
I'm somewhat hesitant using DEFINT a-z, which obviously works, though is defining everything as Integer, if I can at least DEFINT x,y,a,c,c1,c2 would that work as an alternative?
Yes, you can set DEFINT to define as many letters as you want and exclude the ones you don't want. (For more details; User Guide, page 174)
For example; If variables 'money_earned', 'money_spent' & 'tax_owed' are FLOATING POINT but all others are INTEGER, then use DEFINT a-l,n-s,u-z at the beginning of the program. As long, of course, as none of your INTEGER variables start with m or t, but see below for a solution to that problem!

(NOTE: All memory addresses, despite being INTEGER numbers, still need to be defined as REAL numbers, so make sure their variable 'letter' is not included in the DEFINT)

Quote from: CP/M User on 23:55, 25 November 11
I like the idea of having "%" as a way of recognising the type of variable that's being used, though coding it throughout the program is time consuming!  :(
It all depends on your variable-name convention. If you like to use single-character variable names, then yes you're doubling your programming effort whenever you use the "%" extension. However, if (like me) you like to use longer, descriptive variable names, then adding the "%" enhances that description. And if you use it regularly, it's like always adding a "$" for STRINGs; it simply becomes common practice.

There's more about variable extensions in the User Guide (page 115), but here are the three extensions for variables;

% - Integer
! - Floating Point (Real)
$ - Strings

So, if you use DEFINT a-z, and then define a variable called 'mem_loc', you can always add the "!" to override the DEFINT command and define the variable as a REAL number (or in this case, a memory location), so your variable will, obviously, be 'mem_loc!'.

Now, you can take that a step further if you REALLY want and use the DEFSTR command so you don't even have to include the "$" to all STRING variables! Or DEFREAL to define your FLOATING POINT variables (kinda redundant as the system defines all variables, without extensions, as REAL by default). This all becomes VERY confusing, so I would recommend adding the extensions to existing variables instead.

Doing this can create ANOTHER problem; if you forget to add your "%" to 'x_position' variable, the system will create a new REAL variable called 'x_position', give it its default value of '0' and continue to use this instead of 'x_position%'! Debugging problems like this can be a real nightmare, even when EDITing in MODE 2 (the best MODE for BASIC editing!).

So, you're left with a simple question; do you want to speed up your BASIC programs/games for the user or do you want to make your programs easy to program for yourself? There's no right or wrong answer to that, it's all down to personal choice.


There's a lot more to LocoBASIC than most people know, or even care about. There are some really useful commands (BASIC 1.0) that are rarely used, but can substantially enhance programs! Yes, it will never be as fast as Z80, but I like the challenge of creating programs/games in BASIC to run as fast as possible. I believe my POCORO LEGENDS game is in a pretty playable state and it's 100% BASIC.
(Ok, also, I don't know enough Z80 to program properly in assembler!)

- JTMS... (redefining tl;dr)
Title: Re: Silly Programming Ideas - Turning Text into Graphics
Post by: AMSDOS on 12:37, 26 November 11
Okay so what your saying is you cannot DEFINT <first letter here> or DEFINT <variable name>, which will take the first letter of that "name", and make everything which begins with that letter an Integer regardless, unless I use the symbols to define what they are, which is BASICs real way of defining what's what! A bit of a nuisance cause as you say, your going through the entire program to make it like that. Declaring variables in Pascal for example is necessarily, otherwise the programs won't compile or run without them, though they work more effectively as names - apple can be defined as an Integer for instance and army can be defined as a real (decimal numbers), using alternative names which aren't declared and it won't work!  :)   I could see how that would also help make those programs easier to read.  :D
Title: Re: Silly Programming Ideas - Turning Text into Graphics
Post by: tastefulmrship on 12:59, 26 November 11
Quote from: CP/M User on 12:37, 26 November 11
Okay so what your saying is you cannot DEFINT <first letter here> or DEFINT <variable name>, which will take the first letter of that "name", and make everything which begins with that letter an Integer regardless, unless I use the symbols to define what they are, which is BASICs real way of defining what's what! A bit of a nuisance cause as you say, your going through the entire program to make it like that. Declaring variables in Pascal for example is necessarily, otherwise the programs won't compile or run without them, though they work more effectively as names - apple can be defined as an Integer for instance and army can be defined as a real (decimal numbers), using alternative names which aren't declared and it won't work!  :)   I could see how that would also help make those programs easier to read.  :D
I'm saying that DEFINT is a good idea if all your variables are INTEGERS, but the "%" extension is easier to manage, even in larger programs. I see it as no different to the "$" extension for STRINGs these days.
Either way, it will speed up larger BASIC programs/games. Use it only if you feel the need.

In your example, LocoBASIC variables would read 'apple' and 'army!' with DEFINT a or 'apple%' and 'army' without DEFINT a.

I don't know if it only applies to REAL variables, but using a new variable in the middle of a program (ie one that hasn't been pre-declared; eg a 'tempX' variable to store the player's old x position) will cause the system to pause while it creates the variable in system memory, which is not good in the middle of a game! I found this out during my POCORO programming. So, having a 'set-up' section where variables are pre-declared is also a good idea.
Title: Re: Silly Programming Ideas - Turning Text into Graphics
Post by: AMSDOS on 02:40, 27 November 11
Quote from: tastefulmrship on 12:59, 26 November 11
I'm saying that DEFINT is a good idea if all your variables are INTEGERS, but the "%" extension is easier to manage, even in larger programs. I see it as no different to the "$" extension for STRINGs these days.
Either way, it will speed up larger BASIC programs/games. Use it only if you feel the need.

In your example, LocoBASIC variables would read 'apple' and 'army!' with DEFINT a or 'apple%' and 'army' without DEFINT a.

I don't know if it only applies to REAL variables, but using a new variable in the middle of a program (ie one that hasn't been pre-declared; eg a 'tempX' variable to store the player's old x position) will cause the system to pause while it creates the variable in system memory, which is not good in the middle of a game! I found this out during my POCORO programming. So, having a 'set-up' section where variables are pre-declared is also a good idea.

In that case I would have liked to have gone though all the BASIC attachments I've posted (on here) and corrected them, though given I cannot do that, the only way I can simplify it is to correct all of them and post that into a Disk Image!  8)

UPDATED: All the BASIC stupid mistakes i've made solved (http://www.cpcwiki.eu/forum/index.php?action=dlattach;topic=1560.0;attach=2972).

Featuring: 17Kb of Absolute Madness, you've been warned!  :laugh: :laugh: :laugh:

Early Comments: "Hmm,some examples appear faster, others are harder to pick up speed wise when compared to the original programs."
Title: Re: Perhaps More Unusual Programming Ideas - Smooth'ish Vertical Scrolling.
Post by: AMSDOS on 07:49, 25 July 12
Quote from: CP/M User on 11:04, 01 May 11
This is perhaps the easiest way I can think of with regard to producing an scrolling effect and indeed it seems to work.
At the moment it's simply a bunch of screen addresses followed by LDIR - 15 of them which moves the line 15 lines down. Just to test the whole effect I'm plotting a series of dots near the top of the screen (not at the top cause the scroll routine will smear those pixels down), when this is appllied I can call the Scrolling routine which will move those dots down the screen, making it appear as if your moving through a starfield.
After having a few thoughts about this over the last couple of days, I'm wondering how effective that scrolling method would go in a loop with a couple of pointers pointing to the addresses of where the screen is and where it has to go. The third paramater (BC) which is the length across is basically a constant.

EDIT:Refined code:

;; LDIR Scroll - This shifts the screen down a row at a time, kind of giving a smooth scroll.
;; CP/M User.


org &4000

ld b,15 ;; This is how many lines to scroll down.
.loop
push bc ;; This protects the Loop Counter (not required at this stage)

ld hl,(adr_hl) ;; This holds the address pointer and is place into HL
ld e,(hl) ;; Though the Contents from that address goes into DE
inc hl ;; Cause it's 16bit data this is the only way I know
ld d,(hl) ;; How to do it, there maybe other ways. I dunno.

ex de,hl ;; The data above needs to go into HL and not DE


push hl ;; I need to protect my data in HL


ld hl,(adr_de) ;; This holds the address pointer and is place into HL
ld e,(hl) ;; Though the Contents from that address goes into DE
inc hl ;; Cause it's 16bit data this is the only way I know
ld d,(hl) ;; How to do it, there maybe other ways. I dunno.


pop hl ;; But restore it again for this routine


ld bc,&1f ;; BC is used here to address the length of the data on screen upto &4f.
ldir ;; This wonderful instruction can make things move around very quickly.
pop bc ;; Restores Loop Counter value so loop can address it.


ld hl,(adr_hl) ;; Increment Start Position to the next spot
inc hl
inc hl
ld (adr_hl),hl ;; And store it in that pointer variable.


ld hl,(adr_de) ;; Increment Destination to the next position
inc hl
inc hl
ld (adr_de),hl ;; And store it in that pointer variable


djnz loop ;; returns to loop if any remaining lines, otherwise proceed to exit


ld hl,begin ;; Restores pointer to the beginning
ld (adr_hl),hl ;; should the user want to continue calling routine


ld hl,dest ;; Restores pointer to the Destination
ld (adr_de),hl ;; should the user want to continue calling routine


ret ;; exit routine


.adr_hl defw begin ;; pointer position to where the start position is for HL register
.adr_de defw dest ;; pointer position to where the start position is for DE register


.dest defw &f850 ;; These are Screen co-ordinate positions for DE, move from bottom to top of the screen
.begin defw &f050
defw &e850
defw &e050
defw &d850
defw &d050
defw &c850
defw &c050
defw &f800
defw &f000
defw &e800
defw &e000
defw &d800
defw &d000
defw &c800
defw &c000


Demonstration:

10 MODE 1:INK 1,26:INK 2,13
20 WHILE INKEY$<>" "
30 PLOT (RND*240),396,INT(RND*2)+1
40 CALL &BD19:CALL &4000:CALL &BD19
50 WEND
Title: Re: Silly Programming Ideas - Turning Text into Graphics
Post by: AMSDOS on 13:39, 28 July 12
Using the scroll routine above, along with a setup routine for it and a routine for plotting an image on & off screen, this is what I've come up with.


[attachurl=2]


This was a bit of a test to see how the Plot Image Routine would cope plotting and unplotting an image off the screen as well. In this situation I've made a bypass effect if it encounters a zero cause the object is 16x8 pixels in size and takes up a few zeros. To unclear the image (cause this is done in mode 1), I've used Pen 4 which acts as pen 0 except won't bypass and unplot the area. The effect is a quickish blinking ship moving left & right smoothly moving through space.
Title: Re: Silly Programming Ideas - Turning Text into Graphics
Post by: AMSDOS on 09:50, 03 August 12
This is the CP/M 2.2 version of the previous attachment including the Turbo Pascal source.
Title: Re: Silly Programming Ideas - Turning Text into Graphics
Post by: AMSDOS on 09:14, 11 August 12

I made this following program which is a BASIC variation of an Assembly  Sprite Routine:

10 MODE 1:BORDER 0

20 GOSUB 1000
30 DIM scr%(8):scr%(1)=&C000:scr%(2)=&C800:scr%(3)=&D000:scr%(4)=&D800:scr%(5)=&E000:scr%(6)=&E800:scr%(7)=&F000:scr%(8)=&F800
40 GOSUB 100
50 FOR p%=0 TO &4E:addr%=&4000:CALL &BD19:CALL &BD19:GOSUB 110
60 addr%=&4010:CALL &BD19:CALL &BD19:GOSUB 110:NEXT p%
70 CALL &BB18:END
100 ' Poke Sprite to Screen
110 FOR y%=1 TO 8
120 a%=scr%(y%)+p%:POKE a%,PEEK(addr%):addr%=addr%+1
130 b%=scr%(y%)+1+p%:POKE b%,PEEK(addr%):addr%=addr%+1
140 NEXT y%
150 RETURN
1000 ' Poke Sprite Data to Memory
1010 FOR addr%=&4000 TO &401F:READ a$
1020 POKE addr%,VAL("&"+a$)
1030 NEXT addr%:RETURN
1040 DATA D0,60,77,CC,03,08,03,08
1050 DATA 03,08,03,08,03,08,10,00
1060 DATA 00,00,00,00,00,00,00,00
1070 DATA 00,00,00,00,00,00,00,00



Certainly by no means was I writing this compare it with an Assembly Sprite Routine, I always knew this was going to be slower, though I'm sort of surprised at the pace this program runs, though it's only being told to do 2 things, draw the image & wipe it off and it just makes it look like an image is moving across the top of the screen (which is what it is).  :)


I wrote this though to see how my encoded sprite moves across the screen and given I can see now how that information gets passed to the screen I can understand a little better how an Assembly Sprite Routine draws this information to screen.
Title: Re: Silly Programming Ideas - Turning Text into Graphics
Post by: AMSDOS on 08:47, 12 August 12

This is what I came up with using SCR PIXELS, though it's not as clear cut as what I thought it would be because it wants Encoded INK information as well as Mask Data.  :o  I've attached a Disk Image (with Demonstration program) and Source file as well.

;; 8x8 Sprite using SCR PIXELS.


;; Entry from BASIC:
;; CALL &4000,<address of sprite>,<colour data for image>,<x-coordinate>,<y-coordinate>

;; E.g. CALL &4000,&40AD,&40BF,80,100

org &4000


ld hl,addrimgdata ;; Address of the Colour Data comes in here and stored
ld e,(ix+04)
ld d,(ix+05)
ld (hl),e
inc hl
ld (hl),d


ld hl,addofimage ;; Address of the Sprite Data comes in here and stored
ld e,(ix+06)
ld d,(ix+07)
ld (hl),e
inc hl
ld (hl),d


ld hl,ypos ;; Value of YPOS comes in here and is stored,
ld e,(ix+00)
ld d,(ix+01)
ld (hl),e
inc hl
ld (hl),d


ld hl,xpos ;; And the same for XPOS as well.
ld e,(ix+02)
ld d,(ix+03)
ld (hl),e
inc hl
ld (hl),d


ld hl,(xpos)
ex hl,de ;; haha.
ld hl,(ypos)


call &bc1d ;; SCR DOT Position coverts this into a Screen Address


ld (scraddr),hl ;; Screen Address of Location
ld (storscraddr),hl ;; This is used because Scradr has to be Incremented


.loop ld hl,(addrimgdata) ;; Colour Information about the object needs to be
ld a,(hl) ;; Gathered here and encoded when using SCR PIXELS.
call &bc2c ;; SCR INK ENCODE

ld b,a ;; Information goes into B register.


ld hl,(addrimgdata) ;; This points to that information of the Colour Data.
inc hl ;; It's Incremented and stored for the next Bit Mask
ld (addrimgdata),hl ;; which is used for SCR PIXELS.


ld hl,(addofimage) ;; This points to the Bit Mask Data (the patten which
ld c,(hl) ;; gets drawn), and gets stored into the C register.


ld hl,(scraddr) ;; Address of the screen address.


call &bc5c ;; SCR PIXELS. Entry: B = Encoded INK Colour
;; C = Bit Mask Pattern
;; HL = Address to draw the Image.


ld hl,(scraddr) ;; I then have to increment the value of screen
inc hl ;; address to the next position to draw the next spot
ld (scraddr),hl ;; along. It gets stored so I can reuse my registers.


ld hl,(addofimage) ;; The address for the Bit Mask Pattern is also
inc hl ;; increment to point to the next value and is also
ld (addofimage),hl ;; stored as well.


;; An advance understanding of assembly might be able to pull off some PUSHing..POPing
;; to generate the right effect, though in this situation I found SCR PIXELS to be very
;; tricky to apply in a looping situation due to the extra information required from it.


ld a,(count1) ;; This is my loop sequence and again I needed to store
inc a ;; values into memory. I wanted to use my old friend
ld (count1),a ;; DJNZ, though was proving to be a nightmare.
ld b,a ;; This one checks if count1 equals loop1 and if it


ld a,(loop1) ;; doesn't it will jump back to loop to do another pass.


cp b
jr nz,loop ;; The Jump is applied here back to the loop label.


ld a,(count1) ;; If it has reacted this point then count1 equals loop1
xor a ;; it must be set back to zero so it can work when it
ld (count1),a ;; returns back to the main loop.

ld hl,(storscraddr) ;; This is used to calculate the previous line.
call &bc29 ;; SCR PREVIOUS LINE
ld (scraddr),hl ;; I store the value into scraddr for the main loop
ld (storscraddr),hl ;; and I also store the screen address for this routine.

ld a,(count2) ;; Once all that is done I have to do the same thing
inc a ;; here and check to see if count2 equals loop2. And
ld (count2),a ;; again the values need to be stored in memory and
ld b,a ;; recalled again for when I need to check.


ld a,(loop2) ;; As long as count2 is not equal to loop 2, it will


cp b ;; return back to the main loop, otherwise it will
jr nz,loop ;; proceed to exit, back to BASIC if called from there.



ld a,(count2) ;; though upon exit count2 needs to return to 0
xor a ;; Just so this routine can be recalled again.
ld (count2),a ;; values are returned into it's rightful place.


ret


.loop1 defb 2
.loop2 defb 8
.xpos defw 0
.ypos defw 0
.count1 defb 0
.count2 defb 0
.scraddr defw 0
.storscraddr defw 0
.bitmask defb 0
.addofimage defw 0
.rocket defb &d0,&60
defb &77,&cc
defb &03,&08
defb &03,&08
defb &03,&08
defb &03,&08
defb &03,&08
defb &10,&00
.addrimgdata defw 0
.imgdata defb 1,1,3,3,2,2,2,2,2,2,2,2,2,2,1,0
.blankimgdata defb 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0
Title: Re: Silly Programming Ideas - Turning Text into Graphics
Post by: AMSDOS on 12:04, 02 September 12
I've built together a little collection of routines, demos and examples from bits of code I've put together, I've put it all together on my Profile Page (in CPCWiki) as a way of informing people what I've created.  :o  And I've slipped in a Link in my Signature in case anyone can do something with it.  8)
Title: Re: Silly Programming Ideas - Turning Text into Graphics
Post by: Gryzor on 12:22, 03 September 12
Quote from: CP/M User on 12:04, 02 September 12
I've built together a little collection of routines, demos and examples from bits of code I've put together, I've put it all together on my Profile Page (in CPCWiki) as a way of informing people what I've created.  :o  And I've slipped in a Link in my Signature in case anyone can do something with it.  8)


Ooh nice work mate!
Title: Re: Silly Programming Ideas - Turning Text into Graphics
Post by: AMSDOS on 04:49, 29 September 12
Until Yesterday I didn't know what the story was with SCR FLOOD BOX (&BC47) thinking it was a Firmware Equivalent to the BASIC 1.1 'FILL' command, though I tested it to discovered it works in 1.0 Firmware, though I also discovered it can simply be a 1x1 Pixel.


In order to draw a Sprite using SCR FLOOD BOX I've just made some adjustments to SCR PIXELS routine (posted above), which had produce a more compacted piece of code because unlike SCR PIXELS, SCR FLOOD BOX doesn't need to know the Mask of the PEN to draw with. C = Encoded PEN to be used, D & E give the width and height, which will always be 1 for this routine & HL holds the Screen Address, Using SCR DOT POSITION (&BC1D) sorts that out and I'm using SCR PREVIOUS LINE (&BC29) to Calculate the Next Line, so in some ways it's similar to SCR PIXELS (&BC5C), though it's compacted cause doesn't need as much information to draw the image to screen.




;; 8x9 Sprite using SCR FLOOD BOX.


;; Until Yesterday I didn't even know if SCR FLOOD BOX did 1x1 Encoded INK Pixels
;; and just thought it was based on BASIC 1.1 FILL command. :(


;; Entry from BASIC:
;; CALL &4000,<address of sprite>,<x-coordinate>,<y-coordinate>

;; E.g. CALL &4000,&4094,80,100

org &4000


ld hl,addofimage ;; Address of the Sprite Data comes in here and stored
ld e,(ix+04)
ld d,(ix+05)
ld (hl),e
inc hl
ld (hl),d


ld hl,ypos ;; Value of YPOS comes in here and is stored,
ld e,(ix+00)
ld d,(ix+01)
ld (hl),e
inc hl
ld (hl),d


ld hl,xpos ;; And the same for XPOS as well.
ld e,(ix+02)
ld d,(ix+03)
ld (hl),e
inc hl
ld (hl),d


ld hl,(xpos)
ex hl,de ;; haha.
ld hl,(ypos)


call &bc1d ;; SCR DOT POSITION coverts this into a Screen Address


ld (scraddr),hl ;; Screen Address of Location
ld (storscraddr),hl ;; This is used because Scradr has to be Incremented


.loop ld d,1 ;; Width of the Image
ld e,d ;; Height of the Image


ld hl,(addofimage) ;; This points to the Bit Mask Data (the patten which
ld c,(hl) ;; gets drawn), and gets stored into the C register.


ld hl,(scraddr) ;; Address of the screen address.


call &bc47 ;; SCR FLOOD BOX.
;; Entry: C = Encoded INK
;; D = Width of the Image
;; E = Height of the Image
;; HL = Address to draw the Image.


ld hl,(scraddr) ;; I then have to increment the value of screen
inc hl ;; address to the next position to draw the next spot
ld (scraddr),hl ;; along. It gets stored so I can reuse my registers.


ld hl,(addofimage) ;; The address for the Bit Mask Pattern is also
inc hl ;; increment to point to the next value and is also
ld (addofimage),hl ;; stored as well.


ld a,(count1) ;; This is my loop sequence and again I needed to store
inc a ;; values into memory. I wanted to use my old friend
ld (count1),a ;; DJNZ, though was proving to be a nightmare.
ld b,a ;; This one checks if count1 equals loop1 and if it


ld a,(loop1) ;; doesn't it will jump back to loop to do another pass.


cp b
jr nz,loop ;; The Jump is applied here back to the loop label.


ld a,(count1) ;; If it has reacted this point then count1 equals loop1
xor a ;; it must be set back to zero so it can work when it
ld (count1),a ;; returns back to the main loop.

ld hl,(storscraddr) ;; This is used to calculate the previous line.
call &bc29 ;; SCR PREVIOUS LINE
ld (scraddr),hl ;; I store the value into scraddr for the main loop
ld (storscraddr),hl ;; and I also store the screen address for this routine.

ld a,(count2) ;; Once all that is done I have to do the same thing
inc a ;; here and check to see if count2 equals loop2. And
ld (count2),a ;; again the values need to be stored in memory and
ld b,a ;; recalled again for when I need to check.


ld a,(loop2) ;; As long as count2 is not equal to loop 2, it will


cp b ;; return back to the main loop, otherwise it will
jr nz,loop ;; proceed to exit, back to BASIC if called from there.



ld a,(count2) ;; though upon exit count2 needs to return to 0
xor a ;; Just so this routine can be recalled again.
ld (count2),a ;; values are returned into it's rightful place.


ret


.loop1 defb 2 ;; Width of the Image
.loop2 defb 9 ;; Height of the Image
.xpos defw 0 ;; Store XPOS here for use with SCR DOT POSITION
.ypos defw 0 ;; Store YPOS here for use with SCR DOT POSITION
.count1 defb 0 ;; Checks for when the Width of the Image is Reached
.count2 defb 0 ;; Checks for when the Height of the Image is Reached
.scraddr defw 0 ;; Holds the screen address in relation to the Width.
.storscraddr defw 0 ;; Retains original screen address to calculate next line.
.addofimage defw 0 ;; Points to the address of the image to Display
.rocket defb &00,&00 ;; What I'm using as my Display image.
defb &d0,&60
defb &77,&cc
defb &03,&08
defb &03,&08
defb &03,&08
defb &03,&08
defb &03,&08
defb &10,&00



I've made this image 8x9 in size, the 9th line is a blank so once it's been Compiled the Rocket can blast off without the flame:


10 MODE 1:FOR y%=0 TO 190:CALL &BD19:CALL &4000,&4094,100,y%:NEXT y%
Title: Re: Silly Programming Ideas - Turning Text into Graphics
Post by: AMSDOS on 08:50, 30 September 12
I've just updated my "Silly" programs disc, some of the improved programs I'd thought I had done weren't enhanced to run faster in BASIC to my shock horror. Some of the more recent programs I've done since my original disk image have been added (e.g. BASSPR.BAS), and I've modified one of my earlier BASIC programs which is now using a 2D Array to display the image.
Title: Re: Silly Programming Ideas - Turning Text into Graphics
Post by: AMSDOS on 12:37, 30 September 12
Just found this other program I made 4 years ago which I sort of forgot about. It's a simple Command Driven program which lets you plot and draw lines to the screen. I think I only made it so I wasn't typing:


plot 100,100
draw 100,200
draw 150,100
draw 100,100



all over the screen. I haven't even given it provision for Colours, though it's kind of nifty if you're drawing shapes. You would have to remember (or write down) where you've been though cause it's not saving the data.


10 ' BASIC Graphics
20 ' CP/M User - 2008
30 INK 0,0:INK 1,26:BORDER 1:MODE 1: WINDOW#1,1,14,25,25: WINDOW#2,20,40,25,25
40 WHILE 1
50 LOCATE 1,25:INPUT#1,"Command:-";c$:CLS#1
60 IF c$="d" THEN LOCATE 1,1:PRINT#1,"Draw Selected":LOCATE 1,1:INPUT#2,"xco-ordinate";x%: CLS#2:LOCATE 1,1:INPUT#2,"yco-ordinate";y%: DRAW x%,y%: CLS#2
70 IF c$="e" THEN MODE 2:END
80 IF c$="p" THEN LOCATE 1,1:PRINT#1,"Plot Selected":INPUT#2,"xco-ordinate";x%: CLS#2:LOCATE 15,25:INPUT#2,"y co-ordinate";y%: PLOT x%,y%: CLS#2:CLS#1
90 WEND



It's Command Driven so when it asks for "Command" you can select:


"p" - for plot. Important to begin with this cause this acts as a move as well.
"d" - for draw. the X & Y co-ordinates work in relation to where to draw to and move to that point. To Draw from that spot to another spot simply "d" for draw again, otherwise "p" can be used to move to another spot on screen to draw another shape.
Title: Re: Silly Programming Ideas - Turning Text into Graphics
Post by: AMSDOS on 07:52, 14 October 12
More silly routines for this thread, this one is graphically moving a smiley face left and right on the screen changing colour every so often, though the colour changing process is being done due to EVERY which is outside the loop. It kind of has me thinking in another dimension because it's not clear cut BASIC and if you don't know what EVERY does, it could be confusing.




10 EVERY 5,2 GOSUB 1000
20 x%=1:y%=100:dir%=1:num%=1:MODE 0
30 WHILE INKEY$=""
40 TAG:MOVE x%,y%:PEN num%:CALL &BD19:PRINT " ";CHR$(224);" ";:TAGOFF
50 x%=x%+dir%
60 IF x%=320 THEN dir%=-1
70 IF x%=1 THEN dir%=1
80 WEND
90 CALL &BC02:MODE 2:PEN 1:END
1000 num%=num%+1:i%=(RND*26)
1010 IF num%=15 THEN num%=1
1020 INK num%,i%
1030 RETURN
Title: Re: Silly Programming Ideas - Turning Text into Graphics
Post by: Gryzor on 10:09, 14 October 12
Man, it really tripped my girl out, I can tell you that :D
Title: Re: Silly Programming Ideas - Turning Text into Graphics
Post by: AMSDOS on 08:57, 15 October 12
Quote from: Gryzor on 10:09, 14 October 12
Man, it really tripped my girl out, I can tell you that :D


Hmm, trippy cause?


1) It's a Smiley Face
2) Moving Left/Right onscreen
3) It's Changing Colour
4) All the Above


I guess it's got some hipp-ish influence about it (if I can say that).
Title: Re: Silly Programming Ideas - Turning Text into Graphics
Post by: AMSDOS on 10:02, 20 October 12
I'm doing this rotating square the hard way from BASIC and this is what I came up with:


5 MODE 1:p=0:GOSUB 2000
10 EVERY 10,1 GOSUB 1000
15 WHILE INKEY$="":WEND:END
20 MOVE 100,100
30 DRAW 200,100,c
40 DRAW 200,200,c
50 DRAW 100,200,c
60 DRAW 100,100,c
65 RETURN
70 MOVE 75,125
80 DRAW 125,225,c
90 DRAW 225,175,c
100 DRAW 175,75,c
110 DRAW 75,125,c
115 RETURN
120 MOVE 75,150
130 DRAW 150,225,c
140 DRAW 225,150,c
150 DRAW 150,75,c
160 DRAW 75,150,c
165 RETURN
170 MOVE 75,175
180 DRAW 175,225,c
190 DRAW 225,125,c
200 DRAW 125,75,c
210 DRAW 75,175,c
220 RETURN
1000 oldp=oldp+1:p=p+1
1020 c=1:IF p=1 THEN CALL &BD19:GOSUB 20
1021 c=0:IF oldp=1 THEN CALL &BD19:GOSUB 20
1030 c=1:IF p=2 THEN CALL &BD19:GOSUB 70
1031 c=0:IF oldp=2 THEN CALL &BD19:GOSUB 70
1040 c=1:IF p=3 THEN CALL &BD19:GOSUB 120
1041 c=0:IF oldp=3 THEN CALL &BD19:GOSUB 120
1050 c=1:IF p=4 THEN CALL &BD19:GOSUB 170
1051 c=0:IF oldp=4 THEN CALL &BD19:GOSUB 170
1060 IF p=5 THEN p=0
1065 IF oldp=5 THEN oldp=0
1070 RETURN
2000 MOVE 50,50
2010 DRAW 250,50,2
2020 DRAW 250,250,2
2030 DRAW 50,250,2
2040 DRAW 50,50,2
2050 RETURN



though I was wondering if there's a better way of doing it - e.g. using some maths or applying some "DRAWR" instead?
It has some funny rotational look to it when it reaches the complete cycle and I'm trying to delete the first square when the second is being drawn up, so I'm thinking I need to create a dummy position for 1 and start the cycle at 2.


INK swapping would have been more ideal for this, though I'm working in MODE 1, and I need every Colour I can get from it. :(


EDIT: I'll attach the source code.
Title: Re: Silly Programming Ideas - Turning Text into Graphics
Post by: HAL6128 on 11:07, 22 October 12
I would prefer drawing with a transformation matrix and XOR modus. (A precalculated table could also increase speed). Flickering is still a problem under BASIC. Best is use two small screens in BASIC.

10 GOSUB 130:' initialize
20 :
30 MOVE -100,-100:DRAWR 200,0:DRAWR 0,200:DRAWR -200,0:DRAWR 0,-200
40 :
50 ' ****** Main Loop
55 GOSUB 290
60 FOR rot=1 TO 5
65 GOSUB 290
70 GOSUB 360
80 GOSUB 290
100 NEXT rot
110 GOTO 60
120 :
130 '****** Initializing
140 MODE 1
150 DEFINT a-z:DEG:ORIGIN 100,100
160 theta=30:sinus!=SIN(theta):cosinus!=COS(theta)
170 DIM x(4),y(4),a(4),b(4),tmp(4)
180 FOR i=1 TO 4
190 READ x(i),y(i)
200 NEXT i
210 FOR i=1 TO 4
220 READ a(i),b(i)
230 NEXT i
240 RETURN
250 :
260 DATA -50,-50,50,-50,50,50,-50,50
270 DATA 1,2,2,3,3,4,4,1
280 :
290 ' ****** Draw & Delete
300 FOR i=1 TO 4
310 MOVE x(a(i)),y(a(i))
320 DRAW x(b(i)),y(b(i)),1,1
330 NEXT i
340 RETURN
350 :
360 ' ****** Transformation
370 FOR i=1 TO 4
380 tmp(i)=x(i)*cosinus!-y(i)*sinus!
390 y(i)=y(i)*cosinus!+x(i)*sinus!
400 x(i)=tmp(i)
410 NEXT i
420 RETURN
Title: Re: Silly Programming Ideas - Turning Text into Graphics
Post by: AMSDOS on 11:21, 23 October 12
Quote from: HAL 6128 on 11:07, 22 October 12
I would prefer drawing with a transformation matrix and XOR modus. (A precalculated table could also increase speed). Flickering is still a problem under BASIC. Best is use two small screens in BASIC.

10 GOSUB 130:' initialize
20 :
30 MOVE -100,-100:DRAWR 200,0:DRAWR 0,200:DRAWR -200,0:DRAWR 0,-200
40 :
50 ' ****** Main Loop
55 GOSUB 290
60 FOR rot=1 TO 5
65 GOSUB 290
70 GOSUB 360
80 GOSUB 290
100 NEXT rot
110 GOTO 60
120 :
130 '****** Initializing
140 MODE 1
150 DEFINT a-z:DEG:ORIGIN 100,100
160 theta=30:sinus!=SIN(theta):cosinus!=COS(theta)
170 DIM x(4),y(4),a(4),b(4),tmp(4)
180 FOR i=1 TO 4
190 READ x(i),y(i)
200 NEXT i
210 FOR i=1 TO 4
220 READ a(i),b(i)
230 NEXT i
240 RETURN
250 :
260 DATA -50,-50,50,-50,50,50,-50,50
270 DATA 1,2,2,3,3,4,4,1
280 :
290 ' ****** Draw & Delete
300 FOR i=1 TO 4
310 MOVE x(a(i)),y(a(i))
320 DRAW x(b(i)),y(b(i)),1,1
330 NEXT i
340 RETURN
350 :
360 ' ****** Transformation
370 FOR i=1 TO 4
380 tmp(i)=x(i)*cosinus!-y(i)*sinus!
390 y(i)=y(i)*cosinus!+x(i)*sinus!
400 x(i)=tmp(i)
410 NEXT i
420 RETURN



Thanks for that. Unfortunately this is becoming more complicated than what I thought, though this routine may help me get my head around rotation. I tried a few other things using DRAWR, the main issue seems to be keeping the shape relatively same size throughout it's rotation cycle.


The routines I was doing in BASIC wasn't relying on XOR mode and was more of a clear the old position when about to draw the new. In that situation I was delaying after the image was drawn (with a FOR loop) and then clearing the image as quick as possible which seems to help with the Flicker problem.
Title: Re: Silly Programming Ideas - Turning Text into Graphics
Post by: AMSDOS on 11:09, 24 October 12
I made some adjustments to your program so it displays the contents of the X,Y Array, put some KM WAIT KEYs in there (&BB18) so it shows the initial position for the X, Y Array on the Left and the modified positions in the right column. I was also playing around with the "theta" variable.  :D
Title: Re: Silly Programming Ideas - Turning Text into Graphics
Post by: Devilmarkus on 23:41, 24 October 12
Indeed, DRAW and PLOT is very slow...

My example:

10 MODE 1
20 DEG
30 g=1
40 WINDOW #1,14,27,7,16:PAPER #1,0:INK 0,0:BORDER 0:INK 1,13
50 A%=100:B%=50
60 FOR p%=0 TO 88 STEP 2
70 MOVE 320+SIN(p%)*A%,200+COS(p%)*B%,g:DRAW 320,300
80 MOVE 320+SIN(p%+90)*A%,200+COS(p%+90)*B%:DRAW 320,300
90 MOVE 320+SIN(p%+180)*A%,200+COS(p%+180)*B%:DRAW 320,300
100 MOVE 320+SIN(p%+270)*A%,200+COS(p%+270)*B%:DRAW 320,300
110 MOVE 320+SIN(p%)*A%,200+COS(p%)*B%:DRAW 320+SIN(p%+90)*A%,200+COS(p%+90)*B%
120 DRAW 320+SIN(p%+180)*A%,200+COS(p%+180)*B%:DRAW 320+SIN(p%+270)*A%,200+COS(p%+270)*B%
130 DRAW 320+SIN(p%)*A%,200+COS(p%)*B%
150 CALL &BD19:CLS #1
160 NEXT
170 GOTO 60



Perhaps anybody can improve this?
Title: Re: Silly Programming Ideas - Turning Text into Graphics
Post by: ervin on 01:00, 25 October 12
Yes, DRAW is very slow, but I think SIN and COS are slower.
Pre-calculating the calls to SIN and COS makes it quite a bit faster (at the expense of a short wait when the program first starts).

10 print "Pre-calculating..."
20 DEG
21 dim s0(88):dim s90(88):dim s180(88):dim s270(88)
22 dim c0(88):dim c90(88):dim c180(88):dim c270(88)
23 for p%=0 to 88 step 2
24 s0(p%)=320+sin(p%)*100:s90(p%)=320+sin(p%+90)*100:s180(p%)=320+sin(p%+180)*100:s270(p%)=320+sin(p%+270)*100
25 c0(p%)=200+cos(p%)*50:c90(p%)=200+cos(p%+90)*50:c180(p%)=200+cos(p%+180)*50:c270(p%)=200+cos(p%+270)*50
26 next p%
27 mode 1
40 WINDOW #1,14,27,7,16:PAPER #1,0:INK 0,0:BORDER 0:INK 1,13
60 FOR p%=0 TO 88 STEP 2
61 cls #1
70 MOVE s0(p%),c0(p%),1:DRAW 320,300
80 MOVE s90(p%),c90(p%):DRAW 320,300
90 MOVE s180(p%),c180(p%):DRAW 320,300
100 MOVE s270(p%),c270(p%):DRAW 320,300
110 MOVE s0(p%),c0(p%):DRAW s90(p%),c90(p%)
120 DRAW s180(p%),c180(p%):DRAW s270(p%),c270(p%)
130 DRAW s0(p%),c0(p%)
150 CALL &BD19
160 NEXT
170 GOTO 60
Title: Re: Silly Programming Ideas - Turning Text into Graphics
Post by: HAL6128 on 08:49, 25 October 12
I've measured with the help of the TIME command both examples and precalulating increases speed of this example at a factor of 2,5. Impressive!
Clearing screen (of the reduced window size) took 0,02 seconds.
Drawing frame of the first example took ~0,5 second and the second example took ~0,2 second.
So, clearing screen is faster than redrawing the lines (deleting) with XOR mode.
I've measured that if the size of the object becomes smaller than drawing speed grows (of course). In the second example it varies from 0,23 to 0,17 seconds.
So,drawing command is indeed slower the bigger the object is. The reason for the low speed of the drawing command is it's all-purpose functionality (checking clipping, algorithm, mask, check mode etc.)?? Am I right? I don't know the firmware code behind.

By the way, the CALL &BD19 (wait for the frame flyback). What is the best position in a program for that command. Before printing, deleting?

Title: Re: Silly Programming Ideas - Turning Text into Graphics
Post by: Devilmarkus on 12:25, 25 October 12
Quote from: HAL 6128 on 08:49, 25 October 12
By the way, the CALL &BD19 (wait for the frame flyback). What is the best position in a program for that command. Before printing, deleting?

After you painted something and before you clean something
Title: Re: Silly Programming Ideas - Turning Text into Graphics
Post by: Devilmarkus on 17:05, 25 October 12
With buffer:
10 ON BREAK GOSUB 280
20 PRINT "Pre-calculating..."
30 FOR t=0 TO 11:READ a:POKE &8000+t,a:NEXT
40 DEG
50 DIM s0(88):DIM s90(88):DIM s180(88):DIM s270(88)
60 DIM c0(88):DIM c90(88):DIM c180(88):DIM c270(88)
70 FOR p%=0 TO 88 STEP 2
80 s0(p%)=320+SIN(p%)*100:s90(p%)=320+SIN(p%+90)*100:s180(p%)=320+SIN(p%+180)*100:s270(p%)=320+SIN(p%+270)*100
90 c0(p%)=200+COS(p%)*50:c90(p%)=200+COS(p%+90)*50:c180(p%)=200+COS(p%+180)*50:c270(p%)=200+COS(p%+270)*50
100 NEXT p%
110 MODE 1
120 CALL &8000
130 OUT &BC00,12:OUT &BD00,&D0
140 WINDOW #1,14,27,7,16:PAPER #1,0:INK 0,0:BORDER 0:INK 1,13
150 FOR p%=0 TO 86 STEP 4
160 CLS #1
170 MOVE s0(p%),c0(p%),1:DRAW 320,300
180 MOVE s90(p%),c90(p%):DRAW 320,300
190 MOVE s180(p%),c180(p%):DRAW 320,300
200 MOVE s270(p%),c270(p%):DRAW 320,300
210 MOVE s0(p%),c0(p%):DRAW s90(p%),c90(p%)
220 DRAW s180(p%),c180(p%):DRAW s270(p%),c270(p%)
230 DRAW s0(p%),c0(p%)
240 CALL &8000
250 NEXT
260 GOTO 150
270 DATA &11,&00,&40,&21,&00,&C0,&01,&00,&40,&ED,&B0,&C9
280 MODE 1:END


The ASM code:
org &8000
LD DE,&4000
LD HL,&C000
LD BC,&4000
LDIR
ret


Any idea how to speed up the LDIR function? :D
Title: Re: Silly Programming Ideas - Turning Text into Graphics
Post by: TFM on 19:22, 25 October 12
Quote from: Devilmarkus on 17:05, 25 October 12
Any idea how to speed up the LDIR function? :D

Yepp! You can do it like FutureOS does it. Like LDI:LDI:LDI:LDI:LDI:LDI:LDI:LDI:LDI: and so on....

Nothing is faster in copying data.
Title: Re: Silly Programming Ideas - Turning Text into Graphics
Post by: ervin on 01:58, 26 October 12
One way to speed up LDIR is to do less of it!  :D
I've broken down the single big LDIR into 8 smaller ones, to only copy data for the character rows that the pyramid is actually drawn to.

Since the pyramid is now spinning faster (i.e. STEP 4), we can also speed up (by a factor of 2) the pre-calc by using STEP 4.
Also, the pre-calc arrays can each be shrunk by 2 bytes, as the last 2 bytes will never be referenced.

The next step for someone to implement is replacing CLS #1 with stack abuse to clear the screen...  ;)
Then WINDOW #1 will no longer be required.

10 ON BREAK GOSUB 280
20 PRINT "Pre-calculating..."
30 FOR t=0 TO 88:READ a:POKE &8000+t,a:NEXT
40 DEG
50 DIM s0(86):DIM s90(86):DIM s180(86):DIM s270(86)
60 DIM c0(86):DIM c90(86):DIM c180(86):DIM c270(86)
70 FOR p%=0 TO 86 STEP 4
80 s0(p%)=320+SIN(p%)*100:s90(p%)=320+SIN(p%+90)*100:s180(p%)=320+SIN(p%+180)*100:s270(p%)=320+SIN(p%+270)*100
90 c0(p%)=200+COS(p%)*50:c90(p%)=200+COS(p%+90)*50:c180(p%)=200+COS(p%+180)*50:c270(p%)=200+COS(p%+270)*50
100 NEXT p%
110 MODE 1
120 CALL &8000
130 OUT &BC00,12:OUT &BD00,&D0
140 WINDOW #1,14,27,7,16:PAPER #1,0:INK 0,0:BORDER 0:INK 1,13
150 FOR p%=0 TO 86 STEP 4
160 CLS #1
170 MOVE s0(p%),c0(p%),1:DRAW 320,300
180 MOVE s90(p%),c90(p%):DRAW 320,300
190 MOVE s180(p%),c180(p%):DRAW 320,300
200 MOVE s270(p%),c270(p%):DRAW 320,300
210 MOVE s0(p%),c0(p%):DRAW s90(p%),c90(p%)
220 DRAW s180(p%),c180(p%):DRAW s270(p%),c270(p%)
230 DRAW s0(p%),c0(p%)
240 CALL &8000
250 NEXT
260 GOTO 150
270 DATA &11,&e0,&41,&21,&e0,&C1,&01,&20,&03,&ED,&B0
271 DATA &11,&e0,&49,&21,&e0,&C9,&01,&20,&03,&ED,&B0
272 DATA &11,&e0,&51,&21,&e0,&D1,&01,&20,&03,&ED,&B0
273 DATA &11,&e0,&59,&21,&e0,&D9,&01,&20,&03,&ED,&B0
274 DATA &11,&e0,&61,&21,&e0,&E1,&01,&20,&03,&ED,&B0
275 DATA &11,&e0,&69,&21,&e0,&E9,&01,&20,&03,&ED,&B0
276 DATA &11,&e0,&71,&21,&e0,&F1,&01,&20,&03,&ED,&B0
277 DATA &11,&e0,&79,&21,&e0,&F9,&01,&20,&03,&ED,&B0
279 DATA &C9
280 MODE 2:END
Title: Re: Silly Programming Ideas - Turning Text into Graphics
Post by: AMSDOS on 11:38, 26 October 12
Nice programs folks.  :D


What does:


130 OUT &BC00,12:OUT &BD00,&D0



do?


is it just a fancy:


call &bd19?


I was taking a different approach when it came to "drawing" something onscreen and then wiping it, applying a short burst delay with a "FOR..NEXT" loop after the object has been drawn, and then applying no delay for deleting the object, making it seem like the object is more visually onscreen rather than offscreen. The consequence in that is the rotation of the image is slowed down, but then I figured it all boils down to how slow is too slow.  :D


If COS & SIN are considered Slow in BASIC, then Turbo Pascal equivalents is a nightmare, no lookup tables, it makes Locomotive BASIC look fast. Using Arrays in BASIC and TP of course is the secret, which will enhance performance.  :D
Title: Re: Silly Programming Ideas - Turning Text into Graphics
Post by: Devilmarkus on 11:59, 26 October 12
130 OUT &BC00,12:OUT &BD00,&D0

= Screen ram (visible) is @ &4000, while CPC still sends screen data to &C000 (Thats why I LDIRed the ram from C000 to 4000)
Title: Re: Silly Programming Ideas - Turning Text into Graphics
Post by: AMSDOS on 23:02, 26 October 12
Quote from: Devilmarkus on 11:59, 26 October 12
130 OUT &BC00,12:OUT &BD00,&D0

= Screen ram (visible) is @ &4000, while CPC still sends screen data to &C000 (Thats why I LDIRed the ram from C000 to 4000)


Sorry I misread your Assembly program.  :o  Makes sense to move the data from the screen to 2nd screen if it's there, the OUTs threw me cause I would of been doing a SCR SET BASE (&BC08) instead.  :D 


Would of made a nice type-in in it's day.  :D
Title: Re: Silly Programming Ideas - Turning Text into Graphics
Post by: AMSDOS on 09:00, 28 October 12
Just had a couple of bits of information totally unrelated, though linked to this thread:  ;D


* What I didn't realise was GRA PLOT ABSOLUTE (&BBEA) or simply PLOT in BASIC (I was doing this in BASIC 1.0, but it should work in BASIC 1.1) will work in conjunction with SCR ACCESS (&BC59), so using XOR mode from SCR ACCESS will work for those as well. Personally I like having the 0s around the graphic and move it in that fashion, though XOR Sprites is possible. It might even be possible to take the Plot Image Routines I made earlier and stick a XOR in it for effect.


* Adjusting the 'theta' variable from "HAL 6128's" program can produce some interesting effects, having it as low as 1 could produce an extremely animated square and returning to where it was, I'd adjusted it to 15 which gives a nice animation effect - about 6 squares before returning to where it was.  ;D  My adjustments to it and adding information has help me to understand the rotation cycles a little better instead of blowing up my image.  :)
Title: Re: Silly Programming Ideas - Turning Text into Graphics
Post by: AMSDOS on 10:53, 01 November 12
I think I've got this right now, I've just got no means of testing it at the moment. :(




10 MODE 1
20 ' WHILE 1
30 GOSUB 100
40 GOSUB 200
50 GOSUB 300
60 GOSUB 400
70 GOSUB 500
80 GOSUB 600
90 ' WEND
100 MOVE 50,150
110 DRAW 50,50,1
120 DRAW 150,50
130 DRAW 150,150
140 DRAW 50,150
150 RETURN
200 MOVE 39,135
210 DRAW 65,39,2
220 DRAW 161,65
230 DRAW 135,161
240 DRAW 39,135
250 RETURN
300 MOVE 32,118
310 DRAW 82,32,3
320 DRAW 168,82
330 DRAW 118,168
340 DRAW 32,118
350 RETURN
400 MOVE 30,100
410 DRAW 100,30,1
420 DRAW 170,100
430 DRAW 100,170
440 DRAW 30,100
450 RETURN
500 MOVE 32,82
510 DRAW 118,32,2
520 DRAW 168,118
530 DRAW 82,168
540 DRAW 32,82
550 RETURN
600 MOVE 39,65
610 DRAW 135,39,3
620 DRAW 161,135
630 DRAW 65,161
640 DRAW 39,65
650 RETURN
Title: Re: Silly Programming Ideas - Turning Text into Graphics
Post by: Gryzor on 12:58, 01 November 12
Quote from: CP/M UserI think I've got this right now, I've just got no means of testing it at the moment.


Code: [Select]
10 MODE 1
20 ' WHILE 1
30 GOSUB 100
40 GOSUB 200
50 GOSUB 300
60 GOSUB 400
70 GOSUB 500
80 GOSUB 600
90 ' WEND
100 MOVE 50,150
110 DRAW 50,50,1
120 DRAW 150,50
130 DRAW 150,150
140 DRAW 50,150
150 RETURN
200 MOVE 39,135
210 DRAW 65,39,2
220 DRAW 161,65
230 DRAW 135,161
240 DRAW 39,135
250 RETURN
300 MOVE 32,118
310 DRAW 82,32,3
320 DRAW 168,82
330 DRAW 118,168
340 DRAW 32,118
350 RETURN
400 MOVE 30,100
410 DRAW 100,30,1
420 DRAW 170,100
430 DRAW 100,170
440 DRAW 30,100
450 RETURN
500 MOVE 32,82
510 DRAW 118,32,2
520 DRAW 168,118
530 DRAW 82,168
540 DRAW 32,82
550 RETURN
600 MOVE 39,65
610 DRAW 135,39,3
620 DRAW 161,135
630 DRAW 65,161
640 DRAW 39,65
650 RETURN
 
Unexpected Return in 150 :D
Title: Re: Silly Programming Ideas - Turning Text into Graphics
Post by: Devilmarkus on 13:54, 01 November 12


10 MODE 1
20 ' WHILE 1
30 GOSUB 100
40 GOSUB 200
50 GOSUB 300
60 GOSUB 400
70 GOSUB 500
80 GOSUB 600
90 GOTO 30 ' WEND
100 MOVE 50,150
110 DRAW 50,50,1
120 DRAW 150,50
130 DRAW 150,150
140 DRAW 50,150
150 RETURN
200 MOVE 39,135
210 DRAW 65,39,2
220 DRAW 161,65
230 DRAW 135,161
240 DRAW 39,135
250 RETURN
300 MOVE 32,118
310 DRAW 82,32,3
320 DRAW 168,82
330 DRAW 118,168
340 DRAW 32,118
350 RETURN
400 MOVE 30,100
410 DRAW 100,30,1
420 DRAW 170,100
430 DRAW 100,170
440 DRAW 30,100
450 RETURN
500 MOVE 32,82
510 DRAW 118,32,2
520 DRAW 168,118
530 DRAW 82,168
540 DRAW 32,82
550 RETURN
600 MOVE 39,65
610 DRAW 135,39,3
620 DRAW 161,135
630 DRAW 65,161
640 DRAW 39,65
650 RETURN

Title: Re: Silly Programming Ideas - Turning Text into Graphics
Post by: Gryzor on 20:03, 01 November 12
Nice, thanks! Missed that!
Title: Re: Silly Programming Ideas - Turning Text into Graphics
Post by: AMSDOS on 20:10, 01 November 12
Oops, Line 90 should of had a END in it.  :D
Title: Re: Silly Programming Ideas - Turning Text into Graphics
Post by: AMSDOS on 08:43, 03 November 12
This is what I came up with in BASIC/Assembly which is based on the last example, unfortunately I forgot to include the Assembly source (the data is in that). It's using GRA LINE ABSOLUTE, though I've been trying to get it to work in conjunction with GRA LINE RELATIVE. The issue I'm having, is having it appear to rotate around like this example is showing. The benefit of GRA LINE RELATIVE is having the image(s) draw onscreen anywhere, though the trick is working out the next position to move to & draw the relevant box.
Title: Re: Silly Programming Ideas - Turning Text into Graphics
Post by: Devilmarkus on 13:26, 03 November 12
Nice thing!
Now check this mod:
31 PRINT CHR$(23);CHR$(1)

Also swap the pen in line 70 (second |DRAWIMAGE)  to 1 ;)

So your rectangle will not destroy any background (if exists)
Title: Re: Silly Programming Ideas - Turning Text into Graphics
Post by: AMSDOS on 00:59, 01 December 12
There was this funny little Type-in in AA58 which twisted and turned with a series of lines which allowed you to either scroll up or scroll down the screen called Twister. The program itself was using Text Based Cursor Up/Down commands LF & VT to either scroll up or down the screen. I thought would be interesting to see how the LDIR Scroll (which only scrolls up) would go on it. I made some modifications to the original program and it produces this interesting spiral scrolling effect. I made two programs (SPIRAL1.BAS & SPIRAL2.BAS), the first one just draws the lines in the same colours up the screen and the second one I've made it to produce it in a series of random colours which looks interesting too. :) In the Disk Image I've attached the Binary as well as the Source Code for the Scrolling Routine.
Title: Re: Silly Programming Ideas - Turning Text into Graphics
Post by: AMSDOS on 11:08, 02 December 12

Regarding the Rotating Square I was trying to do earlier, this is what I came up with which is all done using Draw Relative (DRAWR) which has some advantages when it comes to placement onscreen (cause everything is being done Relative), the following example is the second program I've attached, I've only modified it in terms of where it starts on screen (using the PLOT statements), though if you look at the first example you will see all the dimensions of the Square are the same (only the positioning has changed), though I did have to work out all the correct positions in order to getting the image to appear to rotate in the correct positions.  :D

5 MODE 1
10 PLOT 150,200
20 DRAWR 0,-100,2
30 DRAWR 100,0
40 DRAWR 0,100
50 DRAWR -100,0
60 PLOT 139,185
70 DRAWR 26,-96
80 DRAWR 96,26
90 DRAWR -26,96
100 DRAWR -96,-26
110 PLOT 132,168
120 DRAWR 50,-86
130 DRAWR 86,50
140 DRAWR -50,86
150 DRAWR -86,-50
160 PLOT 130,150
170 DRAWR 70,-70
180 DRAWR 70,70
190 DRAWR -70,70
200 DRAWR -70,-70
210 PLOT 132,132
220 DRAWR 86,-50
230 DRAWR 50,86
240 DRAWR -86,50
250 DRAWR -50,-86
260 PLOT 139,115
270 DRAWR 96,-26
280 DRAWR 26,96
290 DRAWR -96,26
300 DRAWR -26,-96
Title: Re: Silly Programming Ideas - Turning Text into Graphics
Post by: AMSDOS on 04:42, 26 May 13
Time to give this ol' Thread a dust down, yesterday I came across an earlier Bouncing Ball Demo I made in BASIC, which is Text Based in nature (using standard LOCATE, PRINT to display & remove the Ball which is a standard "O"), so it moves around the screen really fast, the general idea being I could setup a Window (which I have) and bounce it around that.


Today I thought that would be a good example to stick a background pattern into the Window and have the Ball Bouncing over the top of that, which I thought this would be a good example to use the Transparency Command Code in something simple, which could help me with more complicated programs which use it.


10 DIM board$(11,25):GOSUB 1000
20 GOSUB 160:WINDOW wx1%,wx2%,wt%,wb%:PAPER 1: PEN 0: CLS
30 FOR y%=1 TO 25:FOR x%=1 TO 11:BORDER 3:INK 0,3:INK 2,9:PEN 2:LOCATE x%,y%:PRINT board$(x%,y%);:NEXT x%:NEXT y%
40 x%=0:y%=0:xd%=1:yd%=1
50 WHILE INKEY(47)=-1
60 x%=x%+xd%:y%=y%+yd%:oldx%=x%:oldy%=y%
70 PRINT CHR$(22);CHR$(1);:LOCATE x%,y%:PEN 0:PRINT "O"
80 PRINT CHR$(22);CHR$(0);
90 CALL &BD19:CALL &BD19
100 LOCATE oldx%,oldy%:PEN 2:PRINT board$(oldx%,oldy%)
110 IF x%=sx2% THEN xd%=-1
120 IF x%=sx1% THEN xd%=1
130 IF y%=wb% THEN yd%=-1
140 IF y%=wt% THEN yd%=1
150 WEND:MODE 2:PAPER 0:PEN 1:CALL &BC02:END
160 MODE 0:wx1%=5:wx2%=15:wt%=1:wb%=25:sx1%=1:sx2%=11:RETURN
1000 FOR y%=1 TO 25
1010 FOR x%=1 TO 11
1020 board$(x%,y%)=CHR$(207)
1030 NEXT x%:NEXT y%:RETURN



So what I did in this case is setup an 2 Dimensional String based Array, used a subroutine (Line 1000-1030) to place the Background pattern into the Array, Line 20 is one of the original lines which leads to another subroutine (Line 160 - which is also original), which changes the screen mode & sets up the Co-ordinates for the Window before returning. Line 30 is an absolute joke, which more or less does what the subroutine at 1000-1030 does minus printing the result, plus it's constantly changing the INKs, BORDERs & PENs in that Nested Loop, lagging the program even more, sadly it's come to this cause the original program is also weird - a "MODE 0" in a subroutine at the end of the program for example. I couldn't stand the original program just having a GOTO 60 where line 150 now resides, so I changed it to a WHILE loop which exits when Space is pressed & plus I'm resetting the screen INKs and PAPER & PEN colours back to the default colours because I seem to get a little irritated these days by ESCaping from the program and changing everything back to the way it was. Line 40 sets up the positions for the "O" and the Direction it's heading. Initially I had X% & Y% set to 1, but because I'm adding 1 (Line 60) before display the ball, I've changed them to 0 so that when it comes to display it, it will show up in 1,1 and not 2,2 which is what the original did. Line 50 is the Loop - Space Bar will exit the program and restore all the screen colours. Line 60 relates to line 40, does all the work of working out where the Ball will be position next, I've also setup oldx% & oldy% which is used for the 2D Array. The opening Command Code in Line 70 activates the Transparency, so by this stage I've got my Window setup, the background pattern is there, so to make it appear as if the Ball is positioned over the Background pattern, I can use this command to activate the Transparency, LOCATE the position for the Ball & then place the Ball there. Line 80 is the reverse, so it switches it off, I'm unsure if this is needed, I've seen other examples have it there, though in my case in Line 90 I'm doing a Frame Flyback the 464 way, and then in line 100 I'm restoring the position from where the Ball was, so it restores the background pattern. Initially I thought I'd need line 80 because I'm moving the ball, in this case it's a simple process of alternating between Ball & Background, so it looks like the Ball is moving across the Background. Lines 110-140 are merely there as part of the original program to check where the ball is and if it's hitting a marker, so then it can bounce back the other way. Line 150 is where the Loop finishes and where the program Exits back to BASIC with all the colours restored.


Updated: Before anyone downloads that old spaghetti version of my program, I've updated it, I'll keep the old one on show here in case anyone wants to see how Bad it is.  ;D  Another thing I updated in it too is in the old version, once you exited the program and typed in CAT there would be a long pause before displaying the Directory and then another pause before coming up with Ready. Apparently this is because I'm using a 464, a 6128 doesn't seem to have this problem, so what was happening was my 2D array was doing something which was holding up the Disc Drive, so once the program exits and I have no need for the Array, it gets erased, which resolves the Disk Drive hold up. This new program is a bit more polished, though a bit tricky to sort things out, which is why the original has things scattered around in it.
Title: Re: Silly Programming Ideas - Turning Text into Graphics
Post by: AMSDOS on 09:31, 11 July 13
Quote from: TFM/FS on 19:22, 25 October 12

Yepp! You can do it like FutureOS does it. Like LDI:LDI:LDI:LDI:LDI:LDI:LDI:LDI:LDI: and so on....

Nothing is faster in copying data.

I've written a scroller using LDI, and to be honest I'm having trouble understanding why a continuous stream of LDIs is better than having one LDI looping around so many times. In my case it's the Horizon, so I'm looping it 80 times to get that effect. It works, though it's slower than LDIR with BC set to a length of 80, though it might have something to do with me using a DJNZ loop since LDI increments and decrements anyway.
Title: Re: Silly Programming Ideas - Turning Text into Graphics
Post by: redbox on 10:24, 11 July 13
Quote from: AMSDOS on 09:31, 11 July 13
I've written a scroller using LDI, and to be honest I'm having trouble understanding why a continuous stream of LDIs is better than having one LDI looping around so many times. In my case it's the Horizon, so I'm looping it 80 times to get that effect. It works, though it's slower than LDIR with BC set to a length of 80, though it might have something to do with me using a DJNZ loop since LDI increments and decrements anyway.

Each instruction takes a set amount of time to execute in the processor.  The LDI instruction is faster than LDIR.

So:
LDI (16 clock cycles) = 80 * 16 = 1280 clock cycles
LDIR (21 clock cycles) = 80 * 21 = 1680 clock cycles
LD r,value (7 clock cycles) : LDI (16 clock cycles) : DJNZ (13 clock cycles) = (7+16+13) * 80 = 2880 clock cycles.

I've used clock cycles instead of the exact CPC speed (it has an overhead if I remember), but hopefully you get the idea.

Title: Re: Silly Programming Ideas - Turning Text into Graphics
Post by: AMSDOS on 10:50, 11 July 13
Quote from: redbox on 10:24, 11 July 13
Each instruction takes a set amount of time to execute in the processor.  The LDI instruction is faster than LDIR.

So:
LDI (16 clock cycles) = 80 * 16 = 1280 clock cycles
LDIR (21 clock cycles) = 80 * 21 = 1680 clock cycles
LD r,value (7 clock cycles) : LDI (16 clock cycles) : DJNZ (13 clock cycles) = (7+16+13) * 80 = 2880 clock cycles.

I've used clock cycles instead of the exact CPC speed (it has an overhead if I remember), but hopefully you get the idea.

Hmmm, I see what you mean.   :-[

So the next thing I was wondering about is on this website (http://www.smspower.org/Development/Z80ProgrammingTechniques) they have examples of assembler code to tell the assembler how many times to repeat for things like "ldi" instead of typing it out, I think the Winape Assembler supports this, though the instructions maybe different depending on what statements it's using.
Title: Re: Silly Programming Ideas - Turning Text into Graphics
Post by: redbox on 11:40, 11 July 13
Quote from: AMSDOS on 10:50, 11 July 13
So the next thing I was wondering about is on this website (http://www.smspower.org/Development/Z80ProgrammingTechniques) they have examples of assembler code to tell the assembler how many times to repeat for things like "ldi" instead of typing it out, I think the Winape Assembler supports this, though the instructions maybe different depending on what statements it's using.

Yes, Winape does have a 'repeat' macro.


repeat 80
   ldi
rend
Title: Re: Silly Programming Ideas - Turning Text into Graphics
Post by: AMSDOS on 09:54, 13 July 13
Quote from: redbox on 11:40, 11 July 13
Yes, Winape does have a 'repeat' macro.


repeat 80
   ldi
rend


Thanks for that, this is what I came up with


;; LDI Scroll - This shifts the screen down in rows at a time.
;; Top Row needs to be blank so contents don't push it all the way down the screen

org &4000

xor a ;; Position for Loop equals 0.
.loop
ld hl,(adr_hl) ;; This holds the address pointer and is place into HL
ld e,(hl) ;; Though the Contents from that address goes into DE
inc hl ;; Cause it's 16bit data this is the only way I know
ld d,(hl) ;; How to do it, there maybe other ways. I dunno.

ex de,hl ;; The data above needs to go into HL and not DE

push hl ;; I need to protect my data in HL

ld hl,(adr_de) ;; This holds the address pointer and is place into HL
ld e,(hl) ;; Though the Contents from that address goes into DE
inc hl ;; Cause it's 16bit data this is the only way I know
ld d,(hl) ;; How to do it, there maybe other ways. I dunno.

pop hl ;; But restore it again for this routine

repeat 80
ldi ;; Moves things along.
rend

ld hl,(adr_hl) ;; Increment Start Position to the next spot
inc hl
inc hl
ld (adr_hl),hl ;; And store it in that pointer variable.

ld hl,(adr_de) ;; Increment Destination to the next position
inc hl
inc hl
ld (adr_de),hl ;; And store it in that pointer variable

inc a ;; Increment Loop

cp 192 ;; Check if this equals 192.

jp nz,loop ;; returns if not equal to 192, otherwise exit

ld hl,begin ;; Restores pointer to the beginning
ld (adr_hl),hl ;; should the user want to continue calling routine

ld hl,dest ;; Restores pointer to the Destination
ld (adr_de),hl ;; should the user want to continue calling routine

ret ;; exit routine

.adr_hl defw begin ;; pointer position to where the start position is for HL register
.adr_de defw dest ;; pointer position to where the start position is for DE register

;; Below these are Screen co-ordinate positions for DE, move from bottom to top of the screen

.dest defw &C780,&CF80,&D780,&DF80,&E780,&EF80,&F780,&FF80
.begin defw &C730,&CF30,&D730,&DF30,&E730,&EF30,&F730,&FF30
defw &C6E0,&CEE0,&D6E0,&DEE0,&E6E0,&EEE0,&F6E0,&FEE0
defw &C690,&CE90,&D690,&DE90,&E690,&EE90,&F690,&FE90
defw &C640,&CE40,&D640,&DE40,&E640,&EE40,&F640,&FE40
defw &C5F0,&CDF0,&D5F0,&DDF0,&E5F0,&EDF0,&F5F0,&FDF0
defw &C5A0,&CDA0,&D5A0,&DDA0,&E5A0,&EDA0,&F5A0,&FDA0
defw &C550,&CD50,&D550,&DD50,&E550,&ED50,&F550,&FD50
defw &C500,&CD00,&D500,&DD00,&E500,&ED00,&F500,&FD00
defw &C4B0,&CCB0,&D4B0,&DCB0,&E4B0,&ECB0,&F4B0,&FCB0
defw &C460,&CC60,&D460,&DC60,&E460,&EC60,&F460,&FC60
defw &C410,&CC10,&D410,&DC10,&E410,&EC10,&F410,&FC10
defw &C3C0,&CBC0,&D3C0,&DBC0,&E3C0,&EBC0,&F3C0,&FBC0
defw &C370,&CB70,&D370,&DB70,&E370,&EB70,&F370,&FB70
defw &C320,&CB20,&D320,&DB20,&E320,&EB20,&F320,&FB20
defw &C2D0,&CAD0,&D2D0,&DAD0,&E2D0,&EAD0,&F2D0,&FAD0
defw &C280,&CA80,&D280,&DA80,&E280,&EA80,&F280,&FA80
defw &C230,&CA30,&D230,&DA30,&E230,&EA30,&F230,&FA30
defw &C1E0,&C9E0,&D1E0,&D9E0,&E1E0,&E9E0,&F1E0,&F9E0
defw &C190,&C990,&D190,&D990,&E190,&E990,&F190,&F990
defw &C140,&C940,&D140,&D940,&E140,&E940,&F140,&F940
defw &C0F0,&C8F0,&D0F0,&D8F0,&E0F0,&E8F0,&F0F0,&F8F0
defw &C0A0,&C8A0,&D0A0,&D8A0,&E0A0,&E8A0,&F0A0,&F8A0
defw &C050,&C850,&D050,&D850,&E050,&E850,&F050,&F850
defw &C000,&C800,&D000,&D800,&E000,&E800,&F000,&F800


I tested it with my existing Assembly Starscrl code and it's faster than the Firmware SCR HW ROLL (&BC4D) because my Starship at the bottom was struggling to stay on screen, it needed 3 Frame Flybacks and even then it was still blinking away, however in order to make the screen look like it's rolling, the first row needs to stay blank to prevent things from being pushed down the screen, something SCR HW ROLL doesn't have a problem with.
Title: Re: Silly Programming Ideas - Turning Text into Graphics
Post by: TFM on 20:08, 16 July 13
Quote from: redbox on 10:24, 11 July 13
LDI (16 clock cycles) = 80 * 16 = 1280 clock cycles
LDIR (21 clock cycles) = 80 * 21 = 1680 clock cycles
Ok, don't kick my butt, but I gotta correct this... for the circumstances on the CPC...
LDI (20 clock cycles) = 5 ys
LDIR (24 clock cycles) = 6 ys[nb]as Long as BC is not 1[/nb]
Title: Re: Silly Programming Ideas - Turning Text into Graphics
Post by: redbox on 21:06, 16 July 13
Quote from: TFM/FS on 20:08, 16 July 13
Ok, don't kick my butt, but I gotta correct this... for the circumstances on the CPC...
LDI (20 clock cycles) = 5 ys
LDIR (24 clock cycles) = 6 ys[nb]as Long as BC is not 1[/nb]

Thanks TFM.

I knew there was overhead on the CPC, but didn't know how much it was  8)
Title: Re: Silly Programming Ideas - Turning Text into Graphics
Post by: AMSDOS on 10:12, 17 July 13
Does that mean LDIR is faster or slower if BC is not equal to 1?

It's unusual when people say LDIR is 21 or 24, but then it repeats itself, so for every repeat that's 21 or 24 due to the nature of the instruction - if it was say 24 for the entire 4000h it had to transfer, I guess our machine would be whipping all the others.  ;D
Title: Re: Silly Programming Ideas - Turning Text into Graphics
Post by: redbox on 12:31, 17 July 13
Quote from: AMSDOS on 10:12, 17 July 13
It's unusual when people say LDIR is 21 or 24, but then it repeats itself, so for every repeat that's 21 or 24 due to the nature of the instruction - if it was say 24 for the entire 4000h it had to transfer, I guess our machine would be whipping all the others.  ;D

Well, that would be DMA  :)

LDIR is a powerful instruction and the block moving of memory with the Z80 is good, it's just that the CPC has a lot of screen RAM (16kb) so it feels slow.  If you only had 8kb (or 4kb even) then it would come into it's own a lot more.
Title: Re: Silly Programming Ideas - Turning Text into Graphics
Post by: TFM on 16:00, 17 July 13
Well, yes, it may feel slow. But for Scrolling one should make a Screen split and use Hardware Scrolling, then everything is quick.
Title: Re: Silly Programming Ideas - Turning Text into Graphics
Post by: AMSDOS on 11:01, 18 July 13
I had another silly idea for a scroll routine, though I'll have to play around with the idea first to see if it's going to work.  ;D
Title: Re: Silly Programming Ideas - Turning Text into Graphics
Post by: TFM on 17:43, 18 July 13
So you are going to use RLD, are you?
Title: Re: Silly Programming Ideas - Turning Text into Graphics
Post by: AMSDOS on 08:02, 19 July 13
Quote from: TFM/FS on 17:43, 18 July 13
So you are going to use RLD, are you?

I don't know anything about RLD and my assembly book only gives a little bit of information about it, nothing about what it uses or if it only takes in a number from the Accumulator. There is a website on this instruction, though I don't know if it's worthwhile making a scroller out of it.

In BASIC though a simple VT to move the Cursor Up one line works well if the fastest Speed Key setting is applied and can be just another way to speed up your program if cursor control is being applied.

10 MODE 0:INK 0,0:INK 1,26:INK 2,13
20 SPEED KEY 1,1
30 WHILE INKEY$<>" "
40  PLOT (RND*638),398,(RND*2)
50  LOCATE 1,1:PRINT CHR$(11)
60  CALL &BD19:CALL &BD19
70 WEND
80 MODE 2:CALL &BC02
90 SPEED KEY 30,2


Line 60 is totally optional as it is waiting for the Frame Flyback, though if that is removed, the program flies off it's head.

Personally I think it's so fast that your brain hasn't got time to process if it's pixel perfect scrolling and it kind of looks smooth.  ;D
Title: Re: Silly Programming Ideas - Turning Text into Graphics
Post by: TFM on 18:44, 19 July 13
RLD (and RRD) moves nibbles through (HL) and uses A to store them. It can be used for 1-pixel precise scrolling in MODE 0 f.e.[nb]However, I personally use other ways, because RLD is not really quick.[/nb]
Title: Re: Silly Programming Ideas - Turning Text into Graphics
Post by: AMSDOS on 12:33, 16 July 14
I put together a program (or two) from this thread to come up with a way to draw an image to screen and then convert it into the bytes you get which can be used for a sprite.


10 ' MODE 0 8x8 Plot Image -> Sprite Generator
20 ' Use Lines 1050 to 1120 to Setup your image, the INK numbers reflect
30 ' the image to display, when the program starts enter the palette numbers for
40 ' those INKs to display the image.
50 ' Once the Image has been drawn, press any key and this program will generate
60 ' byte values which can be used for Sprite Driver.
70 '
80 DIM c%(15),col%(64),sp%(32):INK 0,0:BORDER 0:GOSUB 1200:MODE 0
90 GOSUB 1000:a%=1:y%=398:x%=0
100 c1%=0:c2%=0
110 WHILE (c1%<>8):WHILE (c2%<>8)
120 PLOT x%,y%,col%(a%)
130 x%=x%+4
140 a%=a%+1
150 c2%=c2%+1
160 WEND
170 c2%=0
180 y%=y%-2
190 x%=0
200 c1%=c1%+1
210 WEND
220 GOSUB 1300:CALL &BB18
230 MODE 2
240 r%=0:WHILE r%<>32
250 FOR p%=1 TO 4
260  PRINT sp%(p%+r%);
270 NEXT p%
280 PRINT:r%=r%+4
290 WEND
300 END
1000 ' Sprite Array
1010 FOR a%=1 TO 64
1020 READ c%
1030 col%(a%)=c%
1040 NEXT a%:RETURN
1050 DATA 0,0,0,0,0,0,0,0
1060 DATA 0,0,4,4,4,4,0,0
1070 DATA 0,4,1,0,1,4,4,0
1080 DATA 0,4,1,0,0,4,4,0
1090 DATA 0,4,1,1,1,4,4,0
1100 DATA 0,4,4,4,4,4,4,0
1110 DATA 0,0,4,4,4,4,0,0
1120 DATA 0,0,0,0,0,0,0,0
1200 ' Set up Colours
1210 MODE 2
1220 FOR i%=1 TO 15
1230  PRINT"Enter Colour for INK ";i%;:INPUT c%(i%)
1240  INK i%,c%(i%):NEXT i%
1250 RETURN
1300 ' 8x8 Sprite Details
1310 RESTORE 1350:FOR p%=1 TO 32
1320  READ a$
1330  sp%(p%)=PEEK(VAL("&"+a$))
1340 NEXT p%:RETURN
1350 DATA c000,c001,c002,c003
1360 DATA c800,c801,c801,c803
1370 DATA d000,d001,d002,d003
1380 DATA d800,d801,d802,d803
1390 DATA e000,e001,e002,e003
1400 DATA e800,e801,e802,e803
1410 DATA f000,f001,f002,f003
1420 DATA f800,f801,f802,f803



So the program is limited to Mode 0, and 8x8 (64 byte characters), but you can arrange your own colours at the start and multicoloured images are possible, so you can design your own designs by editing lines 1050 to 1120, I use paint to generate the image I'm after, followed by editing those lines, once the program has drawn the image, any key will return the bytes for that, however the dimensions are not returned though which some sprite drivers like to have, for a 8x8 sprite, the height is 8 and width will be 4 (cause it's dealing in bytes).
Title: Re: Silly Programming Ideas - Turning Text into Graphics
Post by: HAL6128 on 22:03, 17 July 14
With some basic thread ideas (creating sprite within BASIC) I tried to program a game (try attached disc, use Cursor and Copy keys). Hmm, unfinished, no sound, only one level and buggy. Just a try. :(
A port of CandyCrash. I named it ColorFlash and it's pure BASIC. For some reason it is possible to create sprites and play around with them. But the game has to be somekind of "static". And BASIC is very limited in memory for such things, ...or better: I don't know how to do it better. :D

Honestly, I got stuck because I've lost overview of the variables during programming. Than a bug appears. I couldn't solve it. I got frustrated and stopped it.

I don't know how you  guys develop a game / application. Maybe more in a structured and well-prepare way?
Title: Re: Silly Programming Ideas - Turning Text into Graphics
Post by: AMSDOS on 10:42, 18 July 14
Quote from: HAL 6128 on 22:03, 17 July 14
With some basic thread ideas (creating sprite within BASIC) I tried to program a game (try attached disc, use Cursor and Copy keys). Hmm, unfinished, no sound, only one level and buggy. Just a try. :(
A port of CandyCrash. I named it ColorFlash and it's pure BASIC. For some reason it is possible to create sprites and play around with them. But the game has to be somekind of "static". And BASIC is very limited in memory for such things, ...or better: I don't know how to do it better. :D

Honestly, I got stuck because I've lost overview of the variables during programming. Than a bug appears. I couldn't solve it. I got frustrated and stopped it.

I don't know how you  guys develop a game / application. Maybe more in a structured and well-prepare way?


I could only get the game to do some row clear once and an extra square appeared on the left hand side where that row was cleared, after that it did nothing except remain visible. I haven't work with games that size before, though you've done the right thing my commenting which should help explain what's happening.
Title: Re: Silly Programming Ideas - Turning Text into Graphics
Post by: pelrun on 05:58, 19 July 14
Quote from: HAL 6128 on 22:03, 17 July 14
I don't know how you  guys develop a game / application.


Debugging is a skill, and even when you're good at it it can be incredibly frustrating. BASIC is pretty terrible for non-trivial programs too (especially when you don't have named procedures like BBC BASIC) which just multiplies the difficulties.


Also, there's an element of stubbornness involved, because getting everything finished takes about 50x longer than you expect. So don't be too hard on yourself; software is hard.
Title: Re: Silly Programming Ideas - Turning Text into Graphics
Post by: AMSDOS on 12:47, 19 July 14
Quote from: HAL 6128 on 22:03, 17 July 14
With some basic thread ideas (creating sprite within BASIC) I tried to program a game (try attached disc, use Cursor and Copy keys). Hmm, unfinished, no sound, only one level and buggy. Just a try. :(
A port of CandyCrash. I named it ColorFlash and it's pure BASIC. For some reason it is possible to create sprites and play around with them. But the game has to be somekind of "static". And BASIC is very limited in memory for such things, ...or better: I don't know how to do it better. :D

Honestly, I got stuck because I've lost overview of the variables during programming. Than a bug appears. I couldn't solve it. I got frustrated and stopped it.

I don't know how you  guys develop a game / application. Maybe more in a structured and well-prepare way?


I had another look at your ColorFlash program, personally I'd go through and change all the PRINT statements so they have a semi-column ";" at the end of them. Though I'm unsure if the issue your referring to would be resolved. I'm pretty hopeless at your game I'm lucky to get to 250 let alone 400 in your game, so I'm probably not unveiling these so called "bug", though semi-column at the end of all print statements maybe a start because that prevents BASIC from any Returns/Enters from occurring.
Title: Re: Silly Programming Ideas - Turning Text into Graphics
Post by: SyX on 14:48, 19 July 14
Quote from: HAL 6128 on 22:03, 17 July 14
I don't know how you  guys develop a game / application. Maybe more in a structured and well-prepare way?
Everything you can put in paper before to start, it helps a lot.

Locomotive Basic is good enough for a lot of projects, but a more structured language or one that force you to follow an structure (declare variables, use functions/procedures, ...) is better in the long term and for learning, because helps to reduce the complexity and force you to follow those rules.

And if you are using  a language as c (z88dk or sdcc) or pascal in CPC, you can compile the code in the PC too and that is perfect for debugging/testing complex algorithms.
Title: Re: Silly Programming Ideas - Turning Text into Graphics
Post by: arnoldemu on 15:16, 19 July 14
Quote from: HAL 6128 on 22:03, 17 July 14
I don't know how you  guys develop a game / application. Maybe more in a structured and well-prepare way?

If you program it in C:

* Use comments to describe exactly what is happening
* Use comments to seperate functions e.g. /*-------------------------------------------*/
* Use useful variable names
* Split your program into multiple files (e.g. sprites.c)

If you program in asm:

Very similar to how I would do C. I may comment the code more.

I often write part of the code, make a test program for it. e.g. sprite drawing code.
I position sprites in different places, move them about, check the clipping works.
Make tests for all parts.
Then I join all together.

If you program in BASIC:

You can use rem statements, gosub and split up your code. You can use sensible variable names.
Then use a tool such as Beebug's toolkit to reduce the size after - this removes REMs and shortens variable names I think - at least there is one that did this on BBC.

When program becomes big, it is more of a problem to keep track of what is happening. Here you need to be able to trace it, either with prints, or to step through it using a debugger (ok if you are using asm and an emulator - you can step through and look at all registers and memory etc) - not for basic - don't know how you can do that.

If you make it in modules, you can debug each seperately and remove as many bugs as you can before you join all parts together.

There is a lot of work debugging and fixing bugs at the end so you need lots of patience.


Title: Re: Silly Programming Ideas - Turning Text into Graphics
Post by: SyX on 15:58, 19 July 14
 @HAL 6128 (http://www.cpcwiki.eu/forum/index.php?action=profile;u=365), all the tips of arnoldemu are very sensible and those days you have the luck of being abl to use the old magazines lists and tutorials for learning how structure better your code, magazines as Computing with the Amstrad (http://www.cpcwiki.eu/index.php/Computing_with_the_Amstrad) has a LOT of good quality basic programs and a lot of them are already in CPC-Power (http://www.cpc-power.com/index.php?page=staff&stafftype=1&lenom=Computing%20With%20The%20Amstrad) for you don't need to type them (load"" and list #9 to redirect to the printer, usually a text file in your favourite emulator).
Title: Re: Silly Programming Ideas - Turning Text into Graphics
Post by: AMSDOS on 09:36, 20 July 14
Quote from: arnoldemu on 15:16, 19 July 14

Then use a tool such as Beebug's toolkit to reduce the size after - this removes REMs and shortens variable names I think - at least there is one that did this on BBC.


Funnily enough I think the scans I did from my copy of Australian Personal Computer (Dec. 86) has a program (called CPC Progdoc)which is set out to just do that.


APC Dec 1986 - CPCWiki (http://www.cpcwiki.eu/index.php/APC_Dec_1986)


Unfortunately I haven't typed it in, but I think the scan I've provided should be more than adequate for typing it in.
Title: Re: Silly Programming Ideas - Turning Text into Graphics
Post by: HAL6128 on 19:15, 20 July 14
Quote from: arnoldemu on 15:16, 19 July 14
When program becomes big, it is more of a problem to keep track of what is happening. Here you need to be able to trace it, either with prints, or to step through it using a debugger (ok if you are using asm and an emulator - you can step through and look at all registers and memory etc) - not for basic - don't know how you can do that.

If you make it in modules, you can debug each seperately and remove as many bugs as you can before you join all parts together.

There is a lot of work debugging and fixing bugs at the end so you need lots of patience.
Debugging is exactly the problem I have. Tracing back to the root cause. Which value of variable creates a problem. Damn!!
But thank you all for your hints. Programing in modules might be a good and better start next time.
Maybe I start learning another more structured programing language like C. I'm a little bit familiar with machine code but far away from being good enough, and MC it's soooo flexible, you're not so forced to keep a structure e.g. like declaring variable before using it.

@SyX (http://www.cpcwiki.eu/forum/index.php?action=profile;u=324): Good idea printing out the source code and transfer it via Emulator to a PC. I made an attempt with the help of the application NOTEPAD.  There it is possible to highlight the source code syntax!
@AMSDOS (http://www.cpcwiki.eu/forum/index.php?action=profile;u=330): I don't know why I put all that semicolons after the "Print" statements. I will check it. Normally I use it only if I print a character at the border. Thanks for checking!!
Title: Re: Silly Programming Ideas - Turning Text into Graphics
Post by: AMSDOS on 08:46, 21 July 14
Quote from: HAL 6128 on 19:15, 20 July 14@AMSDOS (http://www.cpcwiki.eu/forum/index.php?action=profile;u=330): I don't know why I put all that semicolons after the "Print" statements. I will check it. Normally I use it only if I print a character at the border. Thanks for checking!!


I didn't notice if you were using any Windows in your game, I have a couple in my game (including one for the playing area), and I had to put some Semicolons cause some funny stuff some occurring along the edge of the window. If you're not using Windows there maybe something else going on, though PRINT statements without semicolons forces a Carriage Return, you can see the devastation it makes if you're in TAG more and using PRINT because it will literally print those characters alongside whatever your printing.
Title: Re: Silly Programming Ideas - Turning Text into Graphics
Post by: AMSDOS on 10:58, 11 November 14
Earlier in this topic (on page 2), I was playing with the idea of Drawing a large Bub Character onscreen in BASIC and then writing a similar routine in Assembly using SCR FILL BOX. A while ago I was pondering in how to make the character appear from the bottom of the screen and wasn't able to generate the effect correctly until now.


I've gone back to the BASIC and changed how the drawing takes place and using a physical cursor down to move the line up. The idea here was to simply draw each line at the same position until it gets to the end, the trouble I was having earlier was trying to overcomplicate things and was using 2 FOR Loops for the original program when it was better to using a WHILE loop for the "y%" variable to control when I can increment the Loop, which comes after doing a physical cursor down.




10 MODE 0: INK 0,0:INK 1,26:INK 4,3:INK 6,1:INK 7,2:INK 8,4:INK 9,16
20 DIM col%(242):GOSUB 100:a%=1
30 WHILE (y%<>22)
40 FOR x%=1 TO 11
50 LOCATE x%,25:PEN col%(a%):PRINT CHR$(143);
60 a%=a%+1
70 NEXT x%:LOCATE 1,25:PRINT CHR$(10):y%=y%+1:WEND
80 CALL &BB18:PEN 1:MODE 2:END
100 ' Set up Colours
110 FOR a%=1 TO 241
120 READ c%
130 col%(a%)=c%
140 NEXT a%:RETURN
150 DATA 0,4,4,4,4,4,4,0,0,0,0
160 DATA 0,4,4,4,4,4,4,4,4,4,0
170 DATA 0,4,4,4,4,4,4,9,4,4,0
180 DATA 4,4,4,4,4,4,4,9,4,4,0
190 DATA 4,4,4,4,4,4,9,9,9,4,4
200 DATA 4,4,4,4,1,0,9,0,1,4,4
210 DATA 4,9,4,9,1,0,9,0,1,4,4
220 DATA 0,9,4,9,1,0,9,0,1,4,4
230 DATA 0,9,9,9,1,0,9,0,1,4,0
240 DATA 0,4,9,9,1,1,9,1,9,9,0
250 DATA 0,4,9,9,9,1,9,1,9,9,0
260 DATA 0,4,9,9,9,9,9,9,9,9,0
270 DATA 0,7,4,9,9,9,0,9,9,9,0
280 DATA 7,7,7,9,9,9,9,9,9,8,0
290 DATA 7,7,7,8,7,7,7,8,7,8,0
300 DATA 7,7,9,8,7,7,7,8,9,9,0
310 DATA 7,9,9,9,8,8,8,8,9,9,0
320 DATA 0,9,9,8,6,1,6,1,8,9,0
330 DATA 0,8,8,8,8,6,6,6,6,8,0
340 DATA 0,8,8,8,8,8,8,8,8,8,8
350 DATA 0,4,6,6,6,0,6,6,6,6,4
360 DATA 0,4,4,4,4,0,4,4,4,4,4



The Assembly program I made earlier is a little bit easier to modify, none of the loops needed changing. row variable becomes a constant pointing to the line 25 (or 24 in this case being 0 based), and using SCR HW ROLL (&BC4D) to roll the screen up.
The effect from the Assembly is interesting as the character emerges very quickly from the bottom of the screen using Block Imagery to cover the screen.




   org &4000


   ;; Main Routine


   ld a,0
   call &bc0e      ;; Set Screen Mode 0


   call setupcols      ;; CALL to Setup Screen Inks
   call drawimg      ;; Main Routine to Draw using SCR FILL BOX
   call resval      ;; Reset values so program can execute again once Exit.
   call &bb18      ;; KM WAIT KEY, Waits for any key to be pressed
   ld a,2
   call &bc0e      ;; Set Screen Mode 2
   ret         ;; Program exits here


.setupcols
   ld hl,cols      ;; Adress of Cols (Colours) points to HL Register
   ld a,0         ;; Accumulator contains PEN Colour
.inkloop
   ld c,(hl)      ;; Place INK value into C
   ld b,c         ;; And B
   push af         ;; Preserve Accumulator by PUSHing onto the Stack
   push hl         ;; Preserve HL Reigister by PUSHing onto the Stack
   call &bc32      ;; SCR SET INK, Entry: A = Ink no, B = First Colour,
            ;; C = Second Colour. Exit: AF & HL are corrupt.
   pop hl         ;; Restore previous HL Register by POPing off the stack
   pop af         ;; Restore previous Accumulator value by POPing off the stack
   inc hl         ;; hl = hl + 1
   inc a         ;; a = a + 1
   cp 10         ;; Does A = 10?
   jr c,inkloop      ;; Loop back to inkloop if A <> 10
   ret         ;; Return to Main routine


.drawimg
   ld hl,(bubptr)      ;; Address of INK values goes into HL
   ld a,(hl)      ;; Accumulator contains the contents that address points at,
            ;; in this case the encoded INK value.


   push af         ;; Those values are then PUSHed onto Stack to protect


   ld a,(column)      ;; Contents of Column is loaded into Accumulator
   ld h,a         ;; and then put into H register
   ld d,a         ;; and D register


   ld a,(row)      ;; Contents of Row is loaded into Accumulator
   ld l,a         ;; and then put into L register
   ld e,a         ;; and E register


   pop af         ;; Accumulator can now be restored to hold encoded INK value


   call &bc44      ;; SCR FILL BOX Routine, Entry = all the above registers are
            ;; used, H, D, L & E work using Text Based Co-ordinates &
            ;; accumulator uses Encoded INK to draw an 8 x 8 pixel shape.

   ld hl,(bubptr)      ;;
   inc hl         ;; Increase Address of pointer to INK values
   ld (bubptr),hl      ;;
   
   ld a,(column)      ;;
   inc a         ;; Increase Address of Column
   ld (column),a      ;;


   ld a,(fcount)      ;;
   inc a         ;; Increment First Counter for X Co-ordinate Position
   ld (fcount),a      ;;


   ld b,a         ;; If the First Counter hasn't reached the value
   ld a,(xval)      ;; in the X Co-ordinate Position (xval), then
   cp b         ;; Return to the start (drawimg), otherwise continue
   jr nz,drawimg      ;; to the second part adjust the Y Co-ordinate position.


   ld a,(fcount)      ;;
   xor a         ;; First Counter Position (fcount) must return to 0
   ld (fcount),a      ;;
   ld (column),a      ;; Column can also return to 0

   ld b,1
   ld a,0
   call &bc4d


   ld a,(scount)      ;;
   inc a         ;; Increment Second Counter for Y Co-ordinate Position
   ld (scount),a      ;;


   ld b,a         ;; If the Second Counter hasn't reached the value
   ld a,(yval)      ;; in the Y Co-ordinate Position (yval), then
   cp b         ;; Return to the start (drawimg), otherwise proceed
   jr nz,drawimg      ;; to the end of this cycle.
   
   ret         ;; Return to Main Routine


.resval
   xor a         ;; Fancy way of Returning Accumulator to 0.
   ld (fcount),a      ;;
   ld (scount),a      ;;
   ld (column),a      ;; Return all these Variables back to 0
   ld hl,bub      ;; Restore original address to the inks
   ld (bubptr),hl      ;; by returning the address of the inks to the Pointer
   ret         ;; Return to Main Routine


.cols   defb 0,26,0,0,3,0,1,2,4,16   ;; Setup INKs using these colours


.fcount   defb 0         ;; Value of First Counter (used during the X Co-ordinate Position)
.scount defb 0         ;; Value of Second Counter (used during the Y Co-ordinate Position)


.column defb 0         ;; Position of Column


.row defb 24         ;; Position of Row




.yval   defb 22         ;; Image to be draw is 22 columns in height
.xval   defb 11         ;; By 11 Rows Across as defined in 'bub'


.bubptr defw bub


.bub            ;; Dimension 11 x 22 in size
   defb &00,&30,&30,&30,&30,&30,&30,&00,&00,&00,&00
   defb &00,&30,&30,&30,&30,&30,&30,&30,&30,&30,&00
   defb &00,&30,&30,&30,&30,&30,&30,&c3,&30,&30,&00
   defb &00,&30,&30,&30,&30,&30,&30,&c3,&30,&30,&00
   defb &30,&30,&30,&30,&30,&30,&c3,&c3,&c3,&30,&30
   defb &30,&30,&30,&30,&c0,&00,&c3,&00,&c0,&30,&30
   defb &30,&c3,&30,&c3,&c0,&00,&c3,&00,&c0,&30,&30
   defb &00,&c3,&30,&c3,&c0,&00,&c3,&00,&c0,&30,&30
   defb &00,&c3,&c3,&c3,&c0,&00,&c3,&00,&c0,&30,&00
   defb &00,&30,&c3,&c3,&c0,&c0,&c3,&c0,&c3,&c3,&00
   defb &00,&30,&c3,&c3,&c3,&c0,&c3,&c0,&c3,&c3,&00
   defb &00,&30,&c3,&c3,&c3,&c3,&c3,&c3,&c3,&c3,&00
   defb &00,&fc,&30,&c3,&c3,&c3,&00,&c3,&c3,&c3,&00
   defb &fc,&fc,&fc,&c3,&c3,&c3,&c3,&c3,&c3,&03,&00
   defb &fc,&fc,&fc,&03,&fc,&fc,&fc,&03,&fc,&03,&00   
   defb &fc,&fc,&c3,&03,&fc,&fc,&fc,&03,&c3,&c3,&00
   defb &fc,&c3,&c3,&c3,&03,&03,&03,&03,&c3,&c3,&00
   defb &00,&c3,&c3,&03,&3c,&c0,&3c,&c0,&03,&c3,&00
   defb &00,&03,&03,&03,&03,&3c,&3c,&3c,&3c,&03,&00
   defb &00,&03,&03,&03,&03,&03,&03,&03,&03,&03,&03
   defb &00,&30,&3c,&3c,&3c,&00,&3c,&3c,&3c,&3c,&30
   defb &00,&30,&30,&30,&30,&00,&30,&30,&30,&30,&30


;; Masks to be used in PENs


;; pen 0 = &00
;; pen 1 = &c0
;; pen 4 = &30
;; pen 6 = &3c
;; pen 7 = &FC
;; pen 8 = &03
;; pen 9 = &c3
Title: Re: Silly Programming Ideas - Turning Text into Graphics
Post by: ervin on 14:26, 20 November 14
Nice work!
:)

It's quite shocking to see how much faster something is in machine code, innit?

Title: Re: Silly Programming Ideas - Turning Text into Graphics
Post by: AMSDOS on 06:07, 22 November 14

Quote from: ervin on 14:26, 20 November 14
Nice work!
:) 


Thanks

QuoteIt's quite shocking to see how much faster something is in machine code, innit?


After some thought I thought I'm actually being really unfair to the BASIC program in this case, because in the BASIC program I'm using LOCATE, PEN & PRINT to print the appropriate box. In assembly that's &BB75 (TXT SET CURSOR), &BB90 (TXT SET PEN) and &BB5A (TXT OUTPUT), which I've replaced with &BC44 (SCR FILL BOX), which so conveniently places where you want the patten on screen, along with the INK mask & displaying the image. The sad news is there is no SCR FILL BOX in BASIC, so I guess the Sean McManus approach would be to write an small Assembly routine. I think the simplest approach would be to take the PEN number and encode it using SCR INK ENCODE (&BC2C) followed by SCR FILL BOX, and modify the assembly. The result should be a little bit fairer.


EDIT: I've attached a copy of the patched BASIC with the appropriate M/C bits being used for SCR INK ENCODE & SCR FILL BOX as well as a SCR HW ROLL (&BC4D), though was surprised to see how much faster it was when compared to my earlier BASIC. From this perspective the Assembly appears much quicker, it might take a little longer when I transform the Encoded INK into it's INK number. SCR INK ENCODE would have to called each time the routine loops through. From my short M/C routine here I made for BASIC, preserving the Accumulator is enough to quickly get the Encoded INK for use with SCR FILL BOX.


10 IF PEEK(&4000)<>221 THEN GOSUB 1000
20 MODE 0: INK 0,0:INK 1,26:INK 4,3:INK 6,1:INK 7,2:INK 8,4:INK 9,16
30 DIM col%(242):GOSUB 100:a%=1:y%=0
40 WHILE (y%<>22)
50 FOR x%=1 TO 11
60 CALL &4000,col%(a%),x%,24
70 a%=a%+1
80 NEXT x%:CALL &4016:y%=y%+1:WEND
90 CALL &BB18:PEN 1:MODE 2:END
100 ' Set up Colours
110 RESTORE 150:FOR a%=1 TO 241
120 READ c%
130 col%(a%)=c%
140 NEXT a%:RETURN
150 DATA 0,4,4,4,4,4,4,0,0,0,0
160 DATA 0,4,4,4,4,4,4,4,4,4,0
170 DATA 0,4,4,4,4,4,4,9,4,4,0
180 DATA 4,4,4,4,4,4,4,9,4,4,0
190 DATA 4,4,4,4,4,4,9,9,9,4,4
200 DATA 4,4,4,4,1,0,9,0,1,4,4
210 DATA 4,9,4,9,1,0,9,0,1,4,4
220 DATA 0,9,4,9,1,0,9,0,1,4,4
230 DATA 0,9,9,9,1,0,9,0,1,4,0
240 DATA 0,4,9,9,1,1,9,1,9,9,0
250 DATA 0,4,9,9,9,1,9,1,9,9,0
260 DATA 0,4,9,9,9,9,9,9,9,9,0
270 DATA 0,7,4,9,9,9,0,9,9,9,0
280 DATA 7,7,7,9,9,9,9,9,9,8,0
290 DATA 7,7,7,8,7,7,7,8,7,8,0
300 DATA 7,7,9,8,7,7,7,8,9,9,0
310 DATA 7,9,9,9,8,8,8,8,9,9,0
320 DATA 0,9,9,8,6,1,6,1,8,9,0
330 DATA 0,8,8,8,8,6,6,6,6,8,0
340 DATA 0,8,8,8,8,8,8,8,8,8,8
350 DATA 0,4,6,6,6,0,6,6,6,6,4
360 DATA 0,4,4,4,4,0,4,4,4,4,4
1000 RESTORE 1040:FOR addr%=&4000 TO &401D
1010 READ a$
1020 POKE addr%,VAL("&"+a$)
1030 NEXT addr%:RETURN
1040 DATA DD,7E,04,CD,2C,BC
1050 DATA F5,DD,7E,02,67,57
1060 DATA DD,7E,00,6F,5F,F1
1070 DATA CD,44,BC,C9,06,01
1080 DATA 3E,00,CD,4D,BC,C9
Title: Re: Silly Programming Ideas - Turning Text into Graphics
Post by: AMSDOS on 10:37, 21 March 15

For Decades I'd been toying with the idea of making a Block Editor, with the influence from the Rock Hopper Board Designer (ACU June 1985), and back in the early days made a crude editor, without having much understanding of Array's & the Transparent Command ("PRINT CHR$(22)+CHR$(1);").  :D


So a while ago I went back to scratch, on the Understanding I needed an Array & better Transparency management that I would see from the Board Designer, but had problems because my Block Editor operates a little bit differently to the Rock Hopper Board Designer, which relies on Game Board Symbols 1 = Rock 2 = Grass 3 = Treasure, and so on, compared to my one Block Shape (143). Fortunately my new ideas of using the Array as a series of PEN numbers has got the result I'm happy with:


10 ' Block Editor
20 '
30 GOSUB 110
40 WHILE ch$<>"E"
50 GOSUB 210
60 GOSUB 310
70 GOSUB 510
80 WEND:MODE 2:PEN 1:CALL &BC02:END
100 ' Initialise Variables
110 MODE 0
120 DIM grid%(25,20)
130 x%=10:y%=10
140 oldx%=x%:oldy%=y%
150 c%=1
160 INK 0,0 : ' <- Use this line to add INK Values.
170 RETURN
200 ' Print Cursor
210 PRINT CHR$(22)+CHR$(1);
220 LOCATE x%,y%
230 PEN 15
240 PRINT"X";
250 PRINT CHR$(22)+CHR$(0);
260 oldx%=x%:oldy%=y%
270 RETURN
300 ' Check for Keypress
310 ch$=UPPER$(INKEY$):IF ch$="" THEN 310
320 IF ch$=" " THEN GOSUB 610
330 IF ch$="Q" THEN y%=y%-1
340 IF ch$="A" THEN y%=y%+1
350 IF ch$="O" THEN x%=x%-1
360 IF ch$="P" THEN x%=x%+1
370 IF ch$="C" THEN c%=c%+1
380 IF y%>25 THEN y%=25
390 IF y%<1 THEN y%=1
400 IF x%<1 THEN x%=1
410 IF x%>19 THEN x%=19
420 IF c%=14 THEN c%=0
430 RETURN
500 ' Preserve Block
510 LOCATE oldx%,oldy%
520 PEN grid%(oldy%,oldx%)
530 PRINT CHR$(22)+CHR$(0);CHR$(143);CHR$(22)+CHR$(1);
540 RETURN
600 ' Print Block
610 LOCATE x%,y%
620 grid%(y%,x%)=c%
630 PEN grid%(y%,x%)
640 PRINT CHR$(143);
650 RETURN



At the moment it's only a simple MODE 0 Block Editor move the Cursor around with Q,A,O,P, Pressing C will change the PEN colour (starts at Pen 1 after Pen 13 Moves back to Pen 0), using Standard PEN set (except for PEN 0), edit Line 160 for appropriate INKS.  :D


Program isn't going to Save 17k Screens (but program can easily be added if desired), I was going to work out how to Load/Save information from the Array to produce smaller files.


The only odd thing I had happen when I got the program to this point was if I used Row Column 20 for my X-Coordinate, the cursor wasn't being erased when I was moving the cursor along the Y-Coordinate and the Screen Rolls when I get to the Bottom.  :(  For this reason I left it so the Cursor won't progress back Row Column 19, unsure if it's the positioning of where oldx & oldy reside in line 260.
Title: Re: Silly Programming Ideas - Turning Text into Graphics
Post by: AMSDOS on 09:27, 23 March 15
So the little problem I was having with the Block Editor above was when I change Line 410 to read:


410 IF x%>20 THEN x%=20


If I take my 'X' to Column 20 and run it up and down the screen it's not being deleted and the Cursor is Rolls the screen down when I take it to the Bottom of the screen.


It seems my placement of the LOCATE in the Preserve Block is the Culprit in this case, I've changed the code to read:


500 ' Preserve Block
510 PEN grid%(oldy%,oldx%)
520 PRINT CHR$(22)+CHR$(0);
530 LOCATE oldx%,oldy%
540 PRINT CHR$(143);
550 PRINT CHR$(22)+CHR$(1);
560 RETURN


So now it will work as a 20x25 Block Editor
Title: Re: Silly Programming Ideas - Turning Text into Graphics
Post by: AMSDOS on 13:44, 25 April 15
Updated: version of Block Editor so now it's possible to Load a Save Contents and have altered Cursor so Arrow Keys now control it (instead of Q,A,O,P combination) & instead of using Space Bar to draw pixel, Keys 0-9 & A-E can be used to draw corresponding Pen Colours (A-E use PEN colours 10-14). I haven't implemented user defined INK colours yet and include some sort of export tool.
Title: Re: Silly Programming Ideas - Turning Text into Graphics
Post by: AMSDOS on 12:49, 23 May 15


Current version of the Block Editor now has provision to edit inks and the program will save those Inks & display them again when the "filename.blk" is loaded. Consequently this has resulted in a change of the file format which the earlier version of the Block Editor won't support.

Initially I was thinking of incorporating various ways of Saving these screens into this program, though I'm thinking of writing a Converter program to handle this which could in turn transform it into one of my Assembly Drawing routines.


I've tried to make this program easy to use from the Keyboard with:


Arrow Keys  - Move Cursor around the screen
Space Bar - Place Block (Default Pen 1)
L - Load File (at the prompt, and no I haven't included a Catalogued Directory)
S - Save File (asks for filename)
I - Takes you to the Ink Palette menu with further Options.
Left, Right Arrows - Place the cursor under the Colour, I ditched the idea of using 0-9 & A-E to select each Coloured Block because my program was lagging form a massive Keypress routine, so this can be used to select the appropriate colour
Up, Down Arrow - In conjunction with the Left, Right Arrows to select from above, this can be used to select INK number & Colour.
Enter / Return - Exit from Ink Palette & back to main Editor


Enter / Return - from the main editor this will exit the program, so take care not to use this without saving your image because the Image will be wiped when this program is executed and returned to the default Palette.



10 ' Block Editor
20 '
30 GOSUB 110
40 WHILE INKEY(18)=-1
50 GOSUB 310
60 GOSUB 410
70 WEND:MODE 2:PEN 1:CALL &BC02:END
100 ' Initialise Variables
110 MODE 0
120 GOSUB 1210
130 DIM grid%(25,20)
140 x%=10:y%=10
150 oldx%=x%:oldy%=y%
160 c%=1
170 RESTORE 230
180 FOR p%=0 TO 14
190  READ cl%
200  grid%(0,p%)=cl%
210  INK p%,grid%(0,p%)
220 NEXT p%
230 DATA 1,24,20,6,26,0,2,8,10,12,14,16,18,22,9
240 RETURN
300 ' Print Cursor
310 PRINT CHR$(22)+CHR$(1);
320 LOCATE x%,y%
330 PEN 15
340 PRINT"X";
350 oldx%=x%:oldy%=y%
360 RETURN
400 ' Check for Keypress
410 WHILE ch$=""
420 ch$=UPPER$(INKEY$)
430 IF ch$=CHR$(240) AND (y%<>1) THEN y%=y%-1 : pr%=1
440 IF ch$=CHR$(241) AND (y%<>25) THEN y%=y%+1 : pr%=1
450 IF ch$=CHR$(242) AND (x%<>1) THEN x%=x%-1 : pr%=1
460 IF ch$=CHR$(243) AND (x%<>20) THEN x%=x%+1 : pr%=1
470 IF pr%=1 THEN pr%=0 : GOSUB 610
480 IF ch$=" " THEN GOSUB 710
490 IF ch$="I" THEN sx%=x% : sy%=y% : GOSUB 1310
500 IF ch$="S" THEN sx%=x% : sy%=y% : GOSUB 810 : MODE 0 : GOSUB 1110
510 IF ch$="L" THEN sx%=x% : sy%=y% : GOSUB 910 : MODE 0 : GOSUB 1110
520 WEND
530 ch$=""
540 RETURN
600 ' Preserve Block
610 PEN grid%(oldy%,oldx%)
620 PRINT CHR$(22)+CHR$(0);
630 LOCATE oldx%,oldy%
640 PRINT CHR$(143);
650 PRINT CHR$(22)+CHR$(1);
660 RETURN
700 ' Print Block
710 LOCATE x%,y%
720 grid%(y%,x%)=c%
730 PEN grid%(y%,x%)
740 PRINT CHR$(143);
750 RETURN
800 ' Save File
810 MODE 1:PEN 1
820 INPUT"Enter Filename:";fl$
830 OPENOUT "!"+fl$
840  FOR y%=0 TO 25
850  FOR x%=0 TO 20
860   PRINT#9,grid%(y%,x%);
870  NEXT x% : PRINT#9
880  NEXT y%
890 CLOSEOUT:RETURN
900 ' Load File & Inks
910 MODE 1:PEN 1
920 INPUT"Enter Filename:";fl$
930 OPENIN "!"+fl$
940  FOR y%=0 TO 25
950  FOR x%=0 TO 20
960   INPUT#9,grid%(y%,x%)
970  NEXT x%
980  NEXT y%
990 CLOSEIN
1000 FOR i%=0 TO 14
1010  INK i%,grid%(0,i%)
1020 NEXT i%
1030 RETURN
1100 ' Draw in Screen & Window Setup
1110 y%=1
1120 WHILE y%<=25
1130 FOR x%=1 TO 20
1140  LOCATE x%,y%
1150  PEN grid%(y%,x%)
1160  PRINT CHR$(143);
1170 NEXT x%
1180 y%=y%+1
1190 WEND
1200 x%=sx% : y%=sy%
1210 WINDOW 1,20,1,25
1220 WINDOW#1,1,20,24,25
1230 RETURN
1300 ' Select Pen and or Change Inks
1310 CLS#1
1320 xp%=1
1330 FOR p%=0 TO 14
1340  PEN#1,p%
1350  LOCATE#1,xp%,1
1360  PRINT#1,CHR$(143);
1370  xp%=xp%+1
1380 NEXT p%
1390 p%=c% : xp%=p%+1
1400 WHILE INKEY(18)=-1
1410  LOCATE#1,xp%,2
1420  PEN#1,15
1430  PRINT#1,CHR$(244);
1440  ich$=UPPER$(INKEY$)
1450  IF ich$=CHR$(243) AND xp%<15 THEN oxp%=xp%:xp%=xp%+1: p%=xp%-1 : c%=p% : GOSUB 1610
1460  IF ich$=CHR$(242) AND xp%>1 THEN oxp%=xp%:xp%=xp%-1: p%=xp%-1 : c%=p% : GOSUB 1610
1470  IF ich$=CHR$(240) AND grid%(0,p%)<26 THEN grid%(0,p%)=grid%(0,p%)+1 : INK p%,grid%(0,p%)
1480  IF ich$=CHR$(241) AND grid%(0,p%)>0 THEN grid%(0,p%)=grid%(0,p%)-1 : INK p%,grid%(0,p%)
1490 WEND
1500 CLS#1
1510 y%=24
1520 GOSUB 1120
1530 RETURN
1600 ' Cursor Update
1610 LOCATE#1,1,1:PRINT#1,CHR$(22)+CHR$(0);
1620 LOCATE#1,oxp%,2
1630 PRINT#1," ";
1640 LOCATE#1,1,1:PRINT#1,CHR$(22)+CHR$(1);
1650 RETURN
Title: Re: Silly Programming Ideas - Turning Text into Graphics
Post by: AMSDOS on 09:31, 12 December 15
I've put together a program in BASIC which demonstrates the use of Condensed Text.


I'm working on a program which uses all 3 Screen Modes and needed something to support that, in this programs case, I've setup a variable (mo%) which can equal 1,2 or 4 when using Mode 2,1 or 0.


[attachimg=3]


And the resulting program looks like this:


[attachimg=2]
Title: Re: Silly Programming Ideas - Turning Text into Graphics
Post by: AMSDOS on 21:19, 12 December 15
Hi folks,


Unfortunately I made a slight blunder in the Condensed Text program above, which has resulted in me making this correction, the blunder only becomes apparent when x% starts to become any value other than 0.


The following line needs to be amended to this:



3110  MOVE x%+(mo%*w%),y%



So now x% can be used to correctly position the text across the screen.
Title: Re: Silly Programming Ideas - Turning Text into Graphics
Post by: AMSDOS on 11:56, 20 December 15
Earlier in this topic I made a command-line Graphics prompt program, which I've now extended into Moving Pixel (Plot Mode), along with Lines & even I've also added the Bresenham Circle Routine.

The program has a number of options:-

Press:-
'M' to change the screen Mode (initially Mode 2)

'P' enter Plot Mode, while in Plot Mode (TAB to Exit), Cursor Keys to Move Pixel, CTRL to change the Graphics Pen, SPACE to Draw a Point in that Colour, though Graphics are XORed so colour may change, the Space Key can be used remove the point and it's a little bit odd, the dot will disappear when a Pixel has been plotted.

'D' enter Draw Mode (TAB to Exit), Up/Down to Increase/Decrease Y Coordinate, Left/Right Decrease/Increase X Coordinate, Space Draws the Line.

'C' enter Circle Mode (Tab to Exit), Up/Down to Increase/Decrease Radius, Space to Draw.

Program is still a WIP, so maybe I can improve it.


10 ' BASIC Graphics
20 ' Updated - 20.12.2015
30 INK 0,0:INK 1,26:BORDER 1: mo%=2: MODE mo%: GOSUB 1710
31 GOSUB 1510 : CALL &100 : GOSUB 1610
40 c%=1:exit=0
50 WHILE exit=0
70 IF INKEY(61)<>-1 THEN WHILE INKEY$<>"":WEND:PRINT CHR$(23);CHR$(0):CLS#1:LOCATE#1,1,1:PRINT#1,"Draw";:GOSUB 210
71 IF INKEY(62)<>-1 THEN WHILE INKEY$<>"":WEND:PRINT CHR$(23);CHR$(0):CLS#1:LOCATE#1,1,1:PRINT#1,"Circle": GOSUB 410 : CLS#1
72 IF INKEY(38)<>-1 THEN mo%=mo%+1 : GOSUB 1810
80 IF INKEY(58)<>-1 THEN exit=1
90 IF INKEY(27)<>-1 THEN WHILE INKEY$<>"":WEND:PRINT CHR$(23);CHR$(1):CLS#1:LOCATE#1,1,1:PRINT#1,"Plot":GOSUB 1020
100 WEND : WHILE INKEY$<>"" : WEND : MODE 2 : CALL &BC02 : END
200 ' Draw Subroutine
210 WHILE INKEY(68)=-1
220  LOCATE#1,6,1
230  PRINT#1,x%;
240  LOCATE#1,11,1
250  PRINT#1,"x";
260  LOCATE#1,12,1
270  PRINT#1,y%;
280  IF INKEY(8)<>-1 AND x%>0 THEN x%=x%-jp%
290  IF INKEY(1)<>-1 AND x%<638 THEN x%=x%+jp%
300  IF INKEY(0)<>-1 AND y%<398 THEN y%=y%+2
310  IF INKEY(2)<>-1 AND y%>16 THEN y%=y%-2
311  IF INKEY(47)<>-1 THEN DRAW x%,y%,c%
320 WEND
340 CLS#1
350 RETURN
400 ' Circle Subroutine
410 WHILE INKEY(68)=-1
420  LOCATE#1,8,1
430  PRINT#1,"Radius";
440  LOCATE#1,15,1
450  PRINT#1,r%;
460  IF INKEY(0)<>-1 AND r%<100 THEN r%=r%+1
470  IF INKEY(2)<>-1 AND r%>0 THEN r%=r%-1
480  IF INKEY(47)<>-1 THEN GOSUB 1310
490 WEND
500 RETURN
600 ' Change Colour
610 IF PEEK(&107)=0 AND c%=16 THEN c%=0
611 IF PEEK(&107)=1 AND c%=4 THEN c%=0
612 IF PEEK(&107)=2 AND c%=2 THEN c%=0
613 PRINT CHR$(23);CHR$(0);
614 PLOT x%,y%,c%
615 PRINT CHR$(23);CHR$(1);
620 RETURN
1000 ' Plot Subroutine
1020 PLOT x%,y%,c%
1030 WHILE INKEY(68)=-1
1040  IF INKEY(8)<>-1 AND x%>0 THEN oldx%=x%:GOSUB 1210:x%=x%-jp%:GOSUB 1230
1050  IF INKEY(1)<>-1 AND x%<638 THEN oldx%=x%:GOSUB 1210:x%=x%+jp%:GOSUB 1230
1060  IF INKEY(0)<>-1 AND y%<398 THEN oldy%=y%:GOSUB 1220:y%=y%+2:GOSUB 1230
1070  IF INKEY(2)<>-1 AND y%>16 THEN oldy%=y%:GOSUB 1220:y%=y%-2:GOSUB 1230
1071  IF INKEY(23)<>-1 THEN c%=c%+1:GOSUB 610:WHILE INKEY$<>"":WEND
1072  IF INKEY(47)<>-1 THEN GOSUB 1230:WHILE INKEY$<>"":WEND
1080  LOCATE#1,6,1:PRINT#1,x%;"x";y%;
1090 WEND
1091 CLS#1: GOSUB 1230
1100 WHILE INKEY$<>"":WEND
1110 RETURN
1200 ' Remove old point
1210 PLOT oldx%,y%,c%:RETURN
1220 PLOT x%,oldy%,c%:RETURN
1230 PLOT x%,y%,c%:RETURN
1300 ' Plot Circle
1310 cx%=x% : cy%=y%
1320 xp%=r% : yp%=0 : decision%=1-xp%
1330 ORIGIN cx%,cy%
1340 WHILE xp%>=yp%
1350  GOSUB 1410
1360  yp%=yp%+stp%
1370  IF decision%<0 THEN decision%=decision%+2*yp%+1 ELSE xp%=xp%-stp%:decision%=decision%+2*(yp%-xp%+1)
1380 WEND
1381 ORIGIN 0,0
1390 RETURN
1400 ' Routine to Plot Circle
1410 PLOT -yp%,xp%,c% : PLOT yp%,xp%,c%
1420 PLOT -xp%,yp%,c% : PLOT xp%,yp%,c%
1430 PLOT -xp%,-yp%,c% : PLOT xp%,-yp%,c%
1440 PLOT -yp%,-xp%,c% : PLOT yp%,-xp%,c%
1450 RETURN
1500 ' Detect which mode is being used
1510 FOR addr%=&100 TO &107
1520  READ a$
1530  POKE addr%,VAL("&"+a$)
1540 NEXT addr%
1550 RETURN
1560 DATA cd,11,bc,32,07,01,c9,00
1600 ' Assign Appropriate Value depending on Mode
1610 IF PEEK(&107)=0 THEN stp%=2:jp%=4:x%=320:y%=200
1620 IF PEEK(&107)=1 THEN stp%=2:jp%=2:x%=320:y%=200
1630 IF PEEK(&107)=2 THEN stp%=1:jp%=1:x%=320:y%=200
1640 RETURN
1700 ' Setup Window
1710 WINDOW#1,1,20,25,25
1720 RETURN
1800 ' Change Mode
1810 IF mo%=3 THEN mo%=0
1820 MODE mo%
1830 GOSUB 1710
1840 LOCATE#1,1,1
1850 PRINT#1,"Mode";mo%
1855 CALL &100
1860 GOSUB 1610
1870 RETURN


Haven't put a save feature in it yet cause I'm working that part of the program in with the Menu System, but I got some screenshots.


[attachimg=1]


[attachimg=2]


[attachimg=3]


[attachimg=4]


[attachimg=5]


Title: Re: Silly Programming Ideas - Turning Text into Graphics
Post by: AMSDOS on 11:28, 11 January 16
I've made some changes to the Condensed Text Demo to allow for some Multicoloured Characters, the example I made (which I forgot to dump), adds a data statement at the end of the program which holds the Graphical Pen numbers, the Longest Line has 32 characters in it, so the data needs to be that length, a restore is added at the start of the routine to Display the text and a Read b$ to read the colour data & plot to set the graphics pen for the text.  Result looks good.


[attachimg=1]


Program attached below:
Title: Re: Silly Programming Ideas - Turning Text into Graphics
Post by: AMSDOS on 03:47, 06 February 16




Earlier on I found this interesting early program (http://www.cpc-power.com/index.php?page=detail&num=10852) from Home Computing Weekly to Redesign the Character Set:


(http://www.cpc-power.com/extra_lire_fichier.php?extra=cpcold&fiche=10852&slot=2&part=A&type=.png)


It lets you redefine the character set between 124-255, but it's useful because you can see what your defining as you go from character to character, though you have to be sure to start defining each character with 'N' for New Character, to which is asks which character your defining and once you've defined that character press Enter/Return to Store it in that position.  Plus it has lots of options as the screenshot shows, though Loading & Saving saves the Character Set to a Binary File, which is where my program comes in.


With my program it takes a Character Definitions from the Binary File, and converts it to BASIC ASCII file, so it asks for the 1st Redefined Character in the set, followed by the last Redefined Character, covering any characters in-between that range. I've given the user the opportunity to move the character set if they want, so for example my condensed character set which was redefined on characters 230 to 255, I can simply move it to character 65, the program works out the length of the set, so if you're using a character below 32, the program will pull you up on it, likewise if the Length of the Set is exceeding 255, it will let you know and tell you how low you can go with that set. When all that's done it asks for the filename with the redefined characters in it, followed by the name of the name of the ASCII BASIC, the program does the rest.





Title: Re: Silly Programming Ideas - Turning Text into Graphics
Post by: AMSDOS on 10:19, 06 February 16
I've put together this program for inputting a filename using condensed text. Up & Down Arrows to select the letter, Right Arrow to Select the Next Position & Left Arrow to Select the Previous Position. The program works, though if you use the Left Arrow to Edit the Previous Character, the Character to the right gets deleted, this is the filling effect from the print using a full width character, which unfortunately deletes the character to the right. I've tried variations of this, but this seems to be the best result I can get.




10 ' Select Filename Demo using Condensed Characters
20 '
30 MODE 0:SYMBOL AFTER 64
40 DIM file$(8):GOSUB 1010
50 a$="FILE:":x%=0 : y%=398 : mo% = 4 : GOSUB 2090
60 x% = 80 : y% = 398 : mo% = 4
70 spot%=1
80 a=65 : a$=CHR$(a)
90 GOSUB 2090
100 WHILE INKEY(18)=-1
110  IF INKEY(0)<>-1 AND a<90 THEN a=a+1 : a$=CHR$(a) : file$(spot%)=a$ : GOSUB 2090
120  IF INKEY(2)<>-1 AND a>65 THEN a=a-1 : a$=CHR$(a) : file$(spot%)=a$ : GOSUB 2090
130  IF INKEY(1)<>-1 AND spot%<8 THEN spot%=spot% + 1 : file$(spot%)=a$ : a=ASC(file$(spot%)) : x% = x% + 16 : GOSUB 2090
140  IF INKEY(8)<>-1 AND spot%>1 THEN spot%=spot% - 1 : file$(spot%)=a$ : a=ASC(file$(spot%)) : x% = x% - 16
150 FOR d%=1 TO 100:NEXT d%
160 WEND
170 WHILE INKEY$<>"":WEND
180 SYMBOL AFTER 256:MODE 2:END
1000 ' Condensed Characters (4 x 8)
1010 FOR num%= 65 TO 90
1020  FOR c%=1 TO 8:READ c(c%):NEXT c%
1030  SYMBOL num%,c(1),c(2),c(3),c(4),c(5),c(6),c(7),c(8)
1040 NEXT num%
1050 RETURN
1060 DATA 32, 80, 80, 112, 80, 80, 80, 0
1070 DATA 96, 80, 80, 96, 80, 80, 96, 0
1080 DATA 32, 80, 64, 64, 64, 80, 32, 0
1090 DATA 96, 80, 80, 80, 80, 80, 96, 0
1100 DATA 112, 64, 64, 96, 64, 64, 112, 0
1110 DATA 112, 64, 64, 96, 64, 64, 64, 0
1120 DATA 32, 80, 64, 112, 80, 80, 32, 0
1130 DATA 80, 80, 80, 112, 80, 80, 80, 0
1140 DATA 112, 32, 32, 32, 32, 32, 112, 0
1150 DATA 16, 16, 16, 16, 16, 80, 32, 0
1160 DATA 80, 80, 96, 96, 80, 80, 80, 0
1170 DATA 64, 64, 64, 64, 64, 64, 112, 0
1180 DATA 80, 112, 112, 80, 80, 80, 80, 0
1190 DATA 16, 80, 112, 112, 112, 80, 80, 0
1200 DATA 112, 80, 80, 80, 80, 80, 112, 0
1210 DATA 96, 80, 80, 96, 64, 64, 64, 0
1220 DATA 32, 80, 80, 80, 80, 80, 32, 16
1230 DATA 96, 80, 80, 96, 80, 80, 80, 0
1240 DATA 32, 80, 64, 32, 16, 80, 32, 0
1250 DATA 112, 32, 32, 32, 32, 32, 32, 0
1260 DATA 80, 80, 80, 80, 80, 80, 112, 0
1270 DATA 80, 80, 80, 80, 80, 32, 32, 0
1280 DATA 80, 80, 80, 80, 112, 112, 80, 0
1290 DATA 80, 80, 112, 32, 112, 80, 80, 0
1300 DATA 80, 80, 80, 32, 32, 32, 32, 0
1310 DATA 112, 16, 32, 32, 32, 64, 112, 0
2000 ' Display Text
2010 ' Entry Conditions:-
2020 '   x% = X coordinate
2030 '   y% = Y coordinate
2040 '   mo% = value relating to screen mode, appropriate values are
2050 '         1 for mode 2, 2 for mode 1 & 4 for mode 0
2060 '   a$ = character string to display, for this program char set 65 to 90
2070 '        are used to appropriately display capitals "A" to "Z"
2080 '
2090 FOR p%=1 TO LEN(a$)
2100  TAG
2110  MOVE x%+(mo%*w%),y%
2120  PRINT MID$(a$,p%,1);
2130  w%=w%+4
2140  TAGOFF
2150 NEXT p%
2160 w%=0
2170 RETURN
Title: Re: Silly Programming Ideas - Turning Text into Graphics
Post by: AMSDOS on 00:50, 07 February 16
For those interested, I've made some updates to the previous program, so now you use the Up/Down Key to select the Letter you want, but now you have to press Space to go to the next letter, if you made a mistake & need to go back, press Del and it will Delete the Current Letter and go back to the previous one for editing.


Here's the modifications:




130  IF INKEY(47)<>-1 AND spot%<8 THEN file$(spot%)=a$ : spot%=spot% + 1 : file$(spot%)=a$ : a=ASC(file$(spot%)) : x% = x% + 16 : GOSUB 2090
140  IF INKEY(79)<>-1 AND spot%>1 THEN a$=" " : file$(spot%)=a$ : GOSUB 2090 : spot% = spot% - 1 : a$ = file$(spot%) : a = ASC(file$(spot%)) : x% = x% - 16
171 a$="":FOR l%=1 TO 8:a$=a$+file$(l%):NEXT l%



For the last line (171), it simply takes the letters from the Array and stores them in a$, so when the program exits (with Enter or Return), a$ will contain the word.






Title: Re: Silly Programming Ideas - Turning Text into Graphics
Post by: AMSDOS on 11:26, 05 June 16
This particular program mightn't have much practical application for others here, but it's a funny & fun way of filling the Screen up using SCR FILL BOX. Earlier I was using SCR HW ROLL to have Bub pop up from the bottom of the screen, but this time I'm using Rolling the Graphics from Right of Screen.
I found a small routine which uses "SCR GET LOCATION" followed by a "SCR SET OFFSET" (after some INCs) which causes Roll, the Catch is whole scroll Rolls, forcing anything from the left side to appear on the Right, my demo program uses this scroll first to avoid issues.
The 2nd image I've got I'm using SCR SW ROLL, this does allow me to Roll a specific region of the screen without affecting what else is on it (provided it doesn't overlap), which has allowed me to come up with this funny effect.


The program will have more practical application if the area as used by SCR SW ROLL was adjustable, which will just require a slight adjustment to the M/C Data. For the SCR SW ROLL, H & D holds the Left & Right Columns, L & E holds the Top and Bottom Lines.




10 IF PEEK(&4000)<>221 THEN GOSUB 2010
20 MODE 0:GOSUB 5010
30 DIM col%(323),house%(180):GOSUB 1000:GOSUB 4010:a%=1:y%=0
40 WHILE (x%<>19)
50   FOR y%=0 TO 16
60     CALL &4000,col%(a%),19,y%
70     a%=a%+1
80   NEXT y%:CALL &4026:x%=x%+1:WEND
90 a%=1 : y%=0
100 WHILE (y%<>9)
110   FOR x%=0 TO 19
120     CALL &4000,house%(a%),x%,24
130     a%=a%+1
140   NEXT x% : CALL &4016 : y%=y%+1 : WEND
150 CALL &BB18:PEN 1:MODE 2:END
1000 ' Set up Colours
1010 RESTORE 3010:FOR a%=1 TO 323
1020 READ c%
1030 col%(a%)=c%
1040 NEXT a%:RETURN
2000 ' Poke M/C
2010 RESTORE 2050:FOR addr%=&4000 TO &4031
2020 READ a$
2030 POKE addr%,VAL("&"+a$)
2040 NEXT addr%:RETURN
2050 DATA DD,7E,04,CD,2C,BC
2060 DATA F5,DD,7E,02,67,57
2070 DATA DD,7E,00,6F,5F,F1
2080 DATA CD,44,BC,C9,06,01
2090 DATA 3E,00,26,00,16,19
2100 DATA 2E,0E,1E,18,CD,50
2110 DATA BC,C9,C0,CD,0B,BC
2120 DATA 23,23,23,23,CD,05
2130 DATA BC,C9
3000 ' 1st Block of Data for Horizontal Scroll
3010 DATA 10,10,10,7,7,7,0,3,3,3,4,4,4,0,0,0,0
3020 DATA 0,0,0,0,0,7,0,0,0,0,0,0,4,0,0,0,0
3030 DATA 0,0,0,0,0,7,0,0,0,0,0,0,4,0,0,0,0
3040 DATA 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0
3050 DATA 0,0,0,0,7,7,0,0,0,0,0,4,4,0,0,0,0
3060 DATA 0,0,10,7,0,0,0,0,0,3,4,0,0,0,0,0,0
3070 DATA 10,10,0,7,0,0,0,3,3,0,4,0,0,0,0,0,0
3080 DATA 0,0,10,7,0,0,0,0,0,3,4,0,0,0,0,0,0
3090 DATA 0,0,0,0,7,7,0,0,0,0,0,4,4,0,0,0,0
3100 DATA 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0
3110 DATA 10,10,10,7,7,7,0,3,3,3,4,4,4,0,0,0,0
3120 DATA 0,0,10,0,0,0,0,0,0,0,0,0,4,0,0,0,0
3130 DATA 0,0,0,7,0,0,0,0,0,0,0,0,4,0,0,0,0
3140 DATA 10,10,10,0,7,7,0,0,0,0,0,0,0,0,0,0,0
3150 DATA 0,0,0,0,0,0,0,0,0,0,0,4,4,0,0,0,0
3160 DATA 0,10,10,7,7,0,0,0,0,3,4,0,0,0,0,0,0
3170 DATA 10,0,0,0,0,7,0,3,3,0,4,0,0,0,0,0,0
3180 DATA 10,0,0,0,0,7,0,0,0,3,4,0,0,0,0,0,0
3190 DATA 10,10,10,7,7,7,0,0,0,0,0,4,4,0,0,0,0
4000 ' 2nd Block of Data for Vertical Scroll
4010 RESTORE 4060
4020 FOR a%=1 TO 180
4030   READ c%
4040   house%(a%)=c%
4050 NEXT a% : RETURN
4060 DATA 0,0,0,0,0,0,0,0,0,0,1,0,0,1,1,1,0,0,0,0
4070 DATA 0,0,0,0,0,0,0,0,0,1,3,1,0,1,11,1,0,0,0,0
4080 DATA 0,0,0,0,0,0,0,0,1,3,3,3,1,1,11,1,0,0,0,0
4090 DATA 0,0,0,0,0,0,0,1,3,3,3,3,3,1,11,1,0,0,0,0
4100 DATA 0,0,0,0,0,0,1,3,3,3,3,3,3,3,1,1,0,0,0,0
4110 DATA 0,0,0,0,0,1,3,3,3,3,3,3,3,3,3,1,0,0,0,0
4120 DATA 0,0,0,0,1,3,3,3,3,3,3,3,3,3,3,3,1,0,0,0
4130 DATA 0,0,0,1,10,10,10,10,10,10,1,10,10,10,10,10,10,1,0,0
4140 DATA 0,0,0,1,10,10,10,10,10,1,2,1,10,10,10,10,10,1,0,0
5000 ' Ink Data
5010 RESTORE 5070
5020 FOR i%=0 TO 14
5030   READ c%
5040   INK i%,c%
5050 NEXT i%
5060 RETURN
5070 DATA 1,24,20,6,26,0,2,8,10,12,14,16,18,22,9
Title: Re: Silly Programming Ideas - Turning Text into Graphics
Post by: AMSDOS on 04:24, 25 June 16

I've written this following program, which takes a number from a string array, converts it to it's integer equivalent (still within an array), calculates it into an integer (based on the array positioning) and then converts it back into a string!


Why?!?


Rather trying to explain in words, I'll post this program



10 ' Condensed Graphical Numbers Demo
20 '
30 ' A BASIC approach for squeezing more text across the screen (useful in MODE
40 ' 0). I have redefined characters 220 to 229 to become condensed numbers "0"
50 ' to "9".
60 '
70 MODE 0 : INK 1,26 : BORDER 0
80 DIM s$(2),n%(2)
90 s$(0)="1" : s$(1)="0" : s$(2)="0"
100 IF c(1)<>64 THEN GOSUB 1000 ' Define Character Set
110 x% = 0 : y% = 398 : mo% = 4 : GOSUB 520
120 MODE 2 : CALL &BC02 : END
500 ' Convert string number into integer and then
510 ' back to a string (using condensed number set).
520 n%(0)=ASC(s$(0))-48
530 n%(1)=ASC(s$(1))-48
540 n%(2)=ASC(s$(2))-48
550 n%(0)=n%(0)-1
560 n%(1)=n%(1)-1 : IF n%(1)<0 THEN n%(1)=9
570 n%(2)=n%(2)-1 : IF n%(2)<0 THEN n%(2)=9
580 WHILE (n%(1)>-1)
590   WHILE (n%(2)>-1)
600    result%=(n%(1)*10)+n%(2)
610    s$(1)=CHR$(n%(1)+220)
620    s$(2)=CHR$(n%(2)+220)
630    a$=s$(1)+s$(2)
640    GOSUB 2090
650    CALL &BB18
660    n%(2)=n%(2)-1
670  WEND
680  n%(1)=n%(1)-1 : n%(2)=9
690 WEND : RETURN
1000 ' Setup Condensed Character Set
1010 SYMBOL AFTER 219
1020 RESTORE 1060:FOR num%= 220 TO 229
1030  FOR c%=1 TO 8:READ c(c%):NEXT c%
1040  SYMBOL num%,c(1),c(2),c(3),c(4),c(5),c(6),c(7),c(
1050 NEXT num% : RETURN
1060 DATA 64, 160, 224, 224, 160, 160, 64, 0
1070 DATA 64, 192, 64, 64, 64, 64, 224, 0
1080 DATA 64, 160, 32, 64, 64, 128, 224, 0
1090 DATA 64, 160, 32, 64, 32, 160, 64, 0
1100 DATA 32, 160, 160, 224, 32, 32, 32, 0
1110 DATA 224, 128, 192, 32, 160, 160, 64, 0
1120 DATA 64, 160, 128, 192, 160, 160, 64, 0
1130 DATA 224, 32, 32, 64, 64, 128, 128, 0
1140 DATA 64, 160, 160, 64, 160, 160, 64, 0
1150 DATA 64, 160, 160, 96, 32, 160, 64, 0
2000 ' Display Text
2010 ' Entry Conditions:-
2020 '   x% = X coordinate
2030 '   y% = Y coordinate
2040 '   mo% = value relating to screen mode, appropriate values are
2050 '         1 for mode 2, 2 for mode 1 & 4 for mode 0
2060 '   a$ = character string to display, for this program char set 220 to 229
2070 '        are used to appropriately display numbers "0" to "9"
2080 '
2090 FOR p%=1 TO LEN(a$)
2100  TAG
2110  MOVE x%+(mo%*w%),y%
2120  PRINT MID$(a$,p%,1);
2130  w%=w%+4
2140  TAGOFF
2150 NEXT p%
2160 w%=0
2170 RETURN



So what I've done here is setup some Condensed Numbers (char 220-229) , the main work is carried out between 500 to 690, when I first typing this program, I started it as a String Array, immediately I've put that value (100 in this case) into an Integer based array, so num%(0)=1, num%(1)=0 and num%(2)=0 - to get that ASCII is used and subtracted by 48 to get the actual value (lines 520-540). Next I deduct num%(0) so it equals 0 (line 550), so this example only works between 99 & 0. 560 & 570 do the same thing, but subtracting 0 returns -1, so the IF in those lines checks for that and causes num%(1) & num%(2) to equal 9. The Nested WHILE loop I've setup (line 580 & 590) check num%(1) & num%(2) are greater than -1. Line 600 converts the figure from those positions of the array into an Integer value, so the value held in result% can have a value between 0 & 99. 610 & 620 then updates the string values based on the values calculated from the Integer array + 220 to equal the 0-9 values for the condensed characters. a$ (in line 630), which is used for printing the condensed character set can now equal those values in s$(1) & s$(2) and GOSUB 2090 to display.

The result% I had in Line 600 isn't doing anything here, but for a game (which is what I was working this for), it can be used to check if a result has been reached. But the conversion of the string array to the Integer based array allows for the necessary calculations, which gets updated to s$(1) & s$(2) for printing the relevant numbers.
Title: Re: Silly Programming Ideas - Turning Text into Graphics
Post by: AMSDOS on 10:25, 25 June 16
I found this last example of 3D ASCII Writing on Rosetta Code (http://rosettacode.org/wiki/Write_language_name_in_3D_ASCII#ZX_Spectrum_Basic) (for ZX BASIC), which I quite like, so I wrote one for Locomotive BASIC.  :)  Initially it wasn't perfect, so the screenshot (http://rosettacode.org/mw/images/f/f1/Basic.jpg) on Rosetta code helped heaps.




10 INK 0,0 : INK 1,24 : INK 2,2 : MODE 1
20 d%=0 : c%=2 : GOSUB 50
30 d%=1 : c%=1 : GOSUB 50
40 PEN 1 : END
50 RESTORE
60 FOR n%=1 TO 5
70   READ a$
80   FOR j%=1 TO LEN(a$)
90     PEN c% : LOCATE j%+7+d%,n%+5
100    IF MID$(a$,j%,1)="X" THEN PRINT CHR$(143);
110  NEXT j%
120 NEXT n%
130 RETURN
140 DATA "XXX  XXXX XXX X XXX"
150 DATA "X  X X  X X   X X  "
160 DATA "XXX  XXXX XXX X X  "
170 DATA "X  X X  X   X X X  "
180 DATA "XXX  X  X XXX X XXX"



I'm not sure what the rules are with Rosetta code, so please feel free to post this Locomotive BASIC, I've tried to keep it as close to the ZX BASIC version, so it's interesting to compare.
Title: Re: Silly Programming Ideas - Turning Text into Graphics
Post by: AMSDOS on 04:52, 05 July 16
This is my 2nd version of the Condensed Graphical Numbers I wrote earlier, and it was a lot harder writing it than what I thought be.
My earlier version concentrates on counting down the number sequence from a Nest While Loop, which may have some use in Games, though the Nested Loop would have to be in that Game.
As it is the game I'm writing has Loops galore and it just needs a routine to count down when the Money Bags are being Collected, which I hope this program will address. The program also Loops, but it's a single loop and it's only happening for Demonstration purposes, the main guts has no loops (apart from the FOR loop to help reduce the flickering), so this should help make this program more practical for Games, which just needs a counting sequence, when a certain event occurs in the Game. I've left heaps of comments in this to help explain the process.




10 ' Condensed Graphical Numbers Demo 2
20 '
30 ' A BASIC approach for squeezing more text across the screen (useful in MODE
40 ' 0). I have redefined characters 220 to 229 to become condensed numbers "0"
50 ' to "9". Modified original program so no nested loops for counting down the
60 ' numbers, and the program now accepts numbers between 999 and 1. So, this
70 ' routine is more useful for setting a number, and counting down when
80 ' collecting objects in a game. No Nested Loops means this will not be stuck
90 ' carrying out that operation. But Line 110 has a loop in it, so it appears
100 ' to operate similar to the last version.
110 '
120 MODE 0 : INK 1,26 : BORDER 0
130 DIM s$(2),n%(2)
140 n%(0)=9 : n%(1)=9 : n%(2)=9
150 GOSUB 1000 ' Define Character Set
160 x% = 32 : y% = 398 : mo% = 4 : WHILE 1 : GOSUB 610 : WEND
500 ' 610 - this subtracts the 100s counter if 10s & 1s equal 0
510 '       10s & 1s equal 9 when that condition is reached.
520 ' 620 - stores values from n% array as an Integer Variable result%
530 ' 630-650 - converts value from n% array into a String Array.
540 ' 660 - Puts string Arrays into a String for Condensed Number Routine.
550 ' 670 - Condensed Number Routine, x%, y% & mo% were set earlier.
560 ' 680 - Delay loop to reduce flicker.
570 ' 690 - Subtract 1 counter. 10 counter is subtract if not equal to 0
580 '                           AND 1 s counter is less than 0. 1s counter is
590 '                           returned to equal 9.
600 ' 700 - if 100s/10s & 1s counter has reached 0, print final number & exit.
610   IF (n%(1)=0) AND (n%(2)<0) THEN n%(0)=n%(0)-1 : n%(1)=9 : n%(2)=9
620    result%=(n%(0)*100)+(n%(1)*10)+n%(2)
630    s$(0)=CHR$(n%(0)+220)
640    s$(1)=CHR$(n%(1)+220)
650    s$(2)=CHR$(n%(2)+220)
660    a$=s$(0)+s$(1)+s$(2)
670    GOSUB 2090
680    FOR d%=1 TO 100:NEXT d%
690    n%(2)=n%(2)-1 : IF (n%(1)<>0) AND (n%(2)<0) THEN n%(1)=n%(1)-1:n%(2)=9
700    IF (n%(0)=0) AND (n%(1)=0) AND (n%(2)=0) THEN s$(2)=CHR$(220):a$=s$(0)+s$(1)+s$(2):GOSUB 2090:LOCATE 1,10:END
710 RETURN
1000 ' Setup Condensed Character Set
1010 SYMBOL AFTER 219
1020 RESTORE 1060:FOR num%= 220 TO 229
1030  FOR c%=1 TO 8:READ c(c%):NEXT c%
1040  SYMBOL num%,c(1),c(2),c(3),c(4),c(5),c(6),c(7),c(8)
1050 NEXT num% : RETURN
1060 DATA 64, 160, 224, 224, 160, 160, 64, 0
1070 DATA 64, 192, 64, 64, 64, 64, 224, 0
1080 DATA 64, 160, 32, 64, 64, 128, 224, 0
1090 DATA 64, 160, 32, 64, 32, 160, 64, 0
1100 DATA 32, 160, 160, 224, 32, 32, 32, 0
1110 DATA 224, 128, 192, 32, 160, 160, 64, 0
1120 DATA 64, 160, 128, 192, 160, 160, 64, 0
1130 DATA 224, 32, 32, 64, 64, 128, 128, 0
1140 DATA 64, 160, 160, 64, 160, 160, 64, 0
1150 DATA 64, 160, 160, 96, 32, 160, 64, 0
2000 ' Display Text
2010 ' Entry Conditions:-
2020 '   x% = X coordinate
2030 '   y% = Y coordinate
2040 '   mo% = value relating to screen mode, appropriate values are
2050 '         1 for mode 2, 2 for mode 1 & 4 for mode 0
2060 '   a$ = character string to display, for this program char set 220 to 229
2070 '        are used to appropriately display numbers "0" to "9"
2080 '
2090 FOR p%=1 TO LEN(a$)
2100  TAG
2110  MOVE x%+(mo%*w%),y%
2120  PRINT MID$(a$,p%,1);
2130  w%=w%+4
2140  TAGOFF
2150 NEXT p%
2160 w%=0
2170 RETURN
Title: Re: Silly Programming Ideas - Turning Text into Graphics
Post by: AMSDOS on 11:57, 13 July 16

I've came up with some routines for drawing some Block Graphics in Mode 0. Initially I was trying to Scroll some Block Graphics with SCR FILL BOX, but was doing my head in. 
Earlier I was also using TAG and character 133 to make up some text (specifically with the 3D text routine), but had problems when bits of that was disappearing, I change the Write mode to XOR. but then the colour was clashing and had to set another ink colour to get the right colours, so I wrote a routine in BASIC to draw a block which worked.
Today I've updated the code to draw a block from Assembly and make some BASIC demonstration programs from it to produce some colourful Square Block Effects from Mode 0, my second program (shown below) includes some data to display a Welcome Message which gets drawn using Square Effects (I just decided to randomise those Colours), once that's complete Left and Right Arrow can be used to Print some Coloured Blocks along the Left and Right Edge of the Screen,  so it's quite silly!



100 MODE 0
110 IF PEEK(&4000)<>6 THEN GOSUB 1000
120 GOSUB 2000
130 INK 14,11:INK 15,9
140 a%=0:y2%=0
150 WHILE a%<29
160 FOR y%=174 TO 238 STEP 16
170   x%=624
180   IF ob%(a%,y2%)=1 THEN c%=INT(RND*14)+1 : CALL &4000,x%,y%,c%
190   y2%=y2%+1
200 NEXT y%
210 CALL &403C:a%=a%+1:y2%=0
220 WEND
230 WHILE INKEY(18)=-1
240   IF INKEY(1)<>-1 THEN CALL &403C:x%=624:c%=INT(RND*14)+1:GOSUB 280
250   IF INKEY(8)<>-1 THEN CALL &4045:x%=0:c%=INT(RND*14)+1:GOSUB 280
260 WEND
270 WHILE INKEY$<>"":WEND:MODE 2:END
280 FOR y%=398 TO 8 STEP -16
290   IF c%<>0 THEN c%=INT(RND*14)+1
300   CALL &4000,x%,y%,c%
310 NEXT y%
320 RETURN
1000 RESTORE 1050
1010 FOR a%=&4000 TO &4051
1020   READ a$
1030   POKE a%,VAL("&"+a$)
1040 NEXT:RETURN
1050 DATA 06,08,DD,7E,00,CD,DE,BB,DD,6E,02,DD,66,03,22,50
1060 DATA 40,EB,DD,6E,04,DD,66,05,22,4E,40,C5,2A,4E,40,EB
1070 DATA 2A,50,40,CD,C0,BB,21,0C,00,EB,21,00,00,CD,F9,BB
1080 DATA C1,2A,50,40,2B,2B,22,50,40,10,E0,C9,CD,0B,BC,23
1090 DATA 23,CD,05,BC,C9,CD,0B,BC,2B,2B,CD,05,BC,C9,00,00
1100 DATA 00,00
2000 RESTORE 2080 : DIM ob%(28,4)
2010 FOR x%=0 TO 28
2020   FOR y%=4 TO 0 STEP -1
2030    READ n%
2040    ob%(x%,y%)=n%
2050   NEXT y%
2060 NEXT x%
2070 RETURN
2080 DATA 1,1,1,1,1
2090 DATA 0,0,1,1,0
2100 DATA 1,1,1,1,1
2110 DATA 0,0,0,0,0
2120 DATA 1,1,1,1,1
2130 DATA 1,0,1,0,1
2140 DATA 1,0,0,0,1
2150 DATA 0,0,0,0,0
2160 DATA 1,1,1,1,1
2170 DATA 0,0,0,0,1
2180 DATA 0,0,0,0,1
2190 DATA 0,0,0,0,0
2200 DATA 0,1,1,1,0
2210 DATA 1,0,0,0,1
2220 DATA 1,0,0,0,1
2230 DATA 0,0,0,0,0
2240 DATA 0,1,1,1,0
2250 DATA 1,0,0,0,1
2260 DATA 0,1,1,1,0
2270 DATA 0,0,0,0,0
2280 DATA 1,1,1,1,1
2290 DATA 0,1,1,0,0
2300 DATA 1,1,1,1,1
2310 DATA 0,0,0,0,0
2320 DATA 1,1,1,1,1
2330 DATA 1,0,1,0,1
2340 DATA 1,0,0,0,1
2350 DATA 0,0,0,0,0
2360 DATA 1,1,1,0,1



[attachimg=1]
Title: Re: Silly Programming Ideas - Turning Text into Graphics
Post by: AMSDOS on 06:07, 09 August 16

Following on from my last post, I've made some adjustments to the Draw Block routine, so now it's possible to set Width & Height of the Block, which could be anything from a pixel 1 x 1 to the whole screen 640x200 can be drawn. I didn't write it just to fill in the whole screen, though now various Block Sizes can be used, which I hope could be useful for defining different block sizes.


org &4000


;; Draw a Block
;; CALL &4000,<xpos>,<ypos>,<width>,<height>,<col>


.begin ld a,(ix+02)
ld b,a
ld l,(ix+04)
ld h,(ix+05)
ld (width),hl
ld a,(ix+00)
call &bbde
ld l,(ix+06)
ld h,(ix+07)
ld (ypos),hl
ex hl,de
ld l,(ix+08)
ld h,(ix+09)
ld (xpos),hl
.loop
push bc
ld hl,(xpos)
ex hl,de
ld hl,(ypos)
call &bbc0
ld hl,(width)
ex hl,de
ld hl,0
call &bbf9
pop bc
ld hl,(ypos)
dec hl
dec hl
ld (ypos),hl
djnz loop
ret


.xpos defw 0
.ypos defw 0
.width defw 0







10 INK 0,0 : INK 1,25 : INK 2,2 : MODE 0
20 IF PEEK(&4000)<>&DD THEN GOSUB 2020
30 x%=214 : y%=0 : c%=2 : GOSUB 60
40 x%=222 : y%=0 : c%=1 : GOSUB 60
50 LOCATE 1,15 : END
60 RESTORE 160
70 FOR n%=1 TO 5
80   READ a$
90   FOR j%=1 TO LEN(a$)
100    IF MID$(a$,j%,1)="X" THEN GOSUB 1040
110    w%=w%+2
120  NEXT j%
130  w%=0 : y%=y%+8
140 NEXT n%
150 RETURN
160 DATA "X  X XXXX X    X    XXXX"
170 DATA "X  X X    X    X    X  X"
180 DATA "XXXX XXX  X    X    X  X"
190 DATA "X  X X    X    X    X  X"
200 DATA "X  X XXXX XXXX XXXX XXXX"
1000 ' Draw Square Block
1010 ' x% = graphical xpos.
1020 ' y% = graphical ypos.
1030 ' c% = graphical pen.
1040 CALL &4000,x%+(4*w%),398-y%,4,4,c%
1050 RETURN
2000 ' Draw a Block M/C Routine
2010 ' To use CALL &4000,<xpos>,<ypos>,<width>,<height>,<colour>
2020 MEMORY &3FFF
2030 RESTORE 2090
2040 FOR addr%=&4000 TO &404F
2050   READ a$
2060   POKE addr%,VAL("&"+a$)
2070 NEXT addr%
2080 RETURN
2090 DATA DD,7E,02,47
2100 DATA DD,6E,04,DD
2110 DATA 66,05,22,4B
2120 DATA 40,DD,7E,00
2130 DATA CD,DE,BB,DD
2140 DATA 6E,06,DD,66
2150 DATA 07,22,49,40
2160 DATA EB,DD,6E,08
2170 DATA DD,66,09,22
2180 DATA 47,40,C5,2A
2190 DATA 47,40,EB,2A
2200 DATA 49,40,CD,C0
2210 DATA BB,2A,4B,40
2220 DATA EB,21,00,00
2230 DATA CD,F9,BB,C1
2240 DATA 2A,49,40,2B
2250 DATA 2B,22,49,40
2260 DATA 10,E0,C9,00
2270 DATA 00,00,00,00
2280 DATA 00,00,00,00
Title: Re: Silly Programming Ideas - Turning Text into Graphics
Post by: Gryzor on 11:28, 09 August 16
Aw this is really cute :D
Title: Re: Silly Programming Ideas - Turning Text into Graphics
Post by: AMSDOS on 23:39, 09 August 16
Quote from: Gryzor on 11:28, 09 August 16Aw this is really cute :D 



It's definitely 10-Liner material, so I'll have a go at making it one (which I'm not very good at).


:laugh: 


Well it was very manageable, managed to write it all with 3 Lines to Spare!  :laugh:  Though I recoded the M/C Data and Array Data, so it's all done in 1 Line each, the good news is no GOTOs were necessary.  :D


[attachimg=1]


I could of use the same approach in Line 6 as I did in Line 7 for poking the M/C, though it's good to show different approaches, so have left it like that.  :)


I've attached a file so no need to type it in, otherwise be careful typing it in, the M/C isn't Data Checked.
Title: Re: Silly Programming Ideas - Turning Text into Graphics
Post by: Gryzor on 11:51, 11 August 16
I hope you don't mind me posting the code here for easy copying and pasting :)




1 DEFINT a-z:DIM o(28,4):GOSUB 7:GOSUB 6:MODE 0:INK 5,15:INK 14,11:INK 15,9:a=0:y2=0
2 WHILE a<29:FOR y=174 TO 238 STEP 16:x=624:IF o(a,y2)=1 THEN c=INT(RND*14)+1:CALL &4000,x,y,c
3 y2=y2+1:NEXT y:CALL &403C:a=a+1:y2=0:WEND:WHILE INKEY(18)=-1:IF INKEY(1)<>-1 THEN CALL &403C:x=624:c=INT(RND*14)+1:GOSUB 5:ELSE IF INKEY(8)<>-1 THEN CALL &4045:x=0:c=INT(RND*14)+1:GOSUB 5
4 WEND:WHILE INKEY$<>"":WEND:MODE 2:END
5 FOR y=398 TO 8 STEP -16:IF c<>0 THEN c=INT(RND*14)+1:CALL &4000,x,y,c:NEXT y:RETURN
6 p=0:READ a$:FOR a=0 TO 77:POKE &4000+a,VAL("&"+MID$(a$,p+1,2)):p=p+2:NEXT a:RETURN:DATA 0608DD7E00CDDEBBDD6E02DD6603225040EBDD6E04DD6605224E40C52A4E40EB2A5040CDC0BB210C00EB210000CDF9BBC12A50402B2B22504010E0C9CD0BBC2323CD05BCC9CD0BBC2B2BCD05BCC9
7 w$="1111100110111110000011111101011000100000111110000100001000000111010001100010000001110100010111000000111110110011111000001111110101100010000011101":p=1:FOR x=0 TO 28:FOR y=4 TO 0 STEP -1:o(x,y)=VAL(MID$(w$,p,1)):p=p+1:NEXT y:NEXT x:RETURN
Title: Re: Silly Programming Ideas - Turning Text into Graphics
Post by: Morri on 14:55, 11 August 16
Looks like the beginnings of a cool demo scroller.  8)
Title: Re: Silly Programming Ideas - Turning Text into Graphics
Post by: AMSDOS on 09:17, 12 August 16
Quote from: Morri on 14:55, 11 August 16
Looks like the beginnings of a cool demo scroller.  8)


It's not really something I was taking seriously, when I got it down to 7 Lines I was thinking of David Hall's Omega Scroll 10-Liner, though that allows you to Enter the Text you wish to scroll, I'm unsure if it worked on the 464 though, which came out as Gibberish.


EDIT: Oddly enough I had a look at that Omega Scroll program on my 464 Emulator and it worked just fine, so that Gibberish that must of occurred was probably me typing it in incorrectly.  :D  For some reason I thought I had the same program from when I was using a 464 to when I upgraded to the 6128, unfortunately I don't have a real 464 to test this, but I think most likely I typed the program in with errors.
Title: Re: Silly Programming Ideas - Turning Text into Graphics
Post by: AMSDOS on 06:33, 03 December 16
Following on the theme of 10 Liners, I was looking at the condensed text (4x8) program I wrote earlier and suddenly realised the data from the symbol definitions fits in nicely with the Sixteen Times Table, so can write a program like this:



1 DEFINT a-z:SYMBOL AFTER 229:DIM o(8,26):GOSUB 9:MODE 0:INK 1,26:TAG:c=230:FOR x=0 TO 400 STEP 16:MOVE x,398:PRINT CHR$(c);:c=c+1:NEXT x:CALL &BB18:END
9 d$="2557555065565560254445206555556074464470744644402547552055575550722222701111152055665550444444705775555015777550755555706556444025555521655655502542152072222220555555705555522055557750557275505552222071222470"
10 p=1:FOR c=1 TO 26:FOR d=1 TO 8:o(d,c)=VAL(MID$(d$,p,1))*16:p=p+1:NEXT d:SYMBOL c+229,o(1,c),o(2,c),o(3,c),o(4,c),o(5,c),o(6,c),o(7,c),o(8,c):NEXT c:RETURN



which lets me redefine the entire alphabet. I've redefined it from characters 230 to 255, so like my last 10 Liner I've set up a string in Line 9 which holds VALues which, when they are multiplied by 16 in Line 10, the corresponding value gets stored into the array, when d in the FOR loop reaches 8 or 9, the loop exits and SYMBOL redefines the data from the array, when that's done the program returns and a short demonstration follows on Line 1.


But I thought it someone wanted to create a simple 10 Liner game with Condensed text, that is probably the best approach. It may also be possible to squeeze numbers into those 2 Lines, unfortunately my condensed numbers need some shifting as larger values are being used in my SYMBOL redefining.
Title: Re: Silly Programming Ideas - Turning Text into Graphics
Post by: AMSDOS on 00:57, 19 March 17
Another BASIC program for the Silly Vaults, again a Bouncing Ball routine with Transparent Mode On & Off. Initially I was filling in the centre of the Ball, though changed that to use 1 redefined character & PAPER to do the same thing with Transparent Mode turned off. I can then turn on Transparent Mode to print the Middle colour in the Ball. The effect looks better with a Background, though for the Background to work I need to Redefine another Character to print around the Ball, this is when BASIC starts revealing itself because in order to Print the 1st Character with the Transparent Mode turned off, the area around the Ball is cleared, I then turn on Transparent Mode, Print the area around the Outer Edge of the Ball, followed by the middle colour, so when the program is on display a Square effect is noticeable (as my 2nd Screen shot will show). I've taken the liberty to apply the Print Ball/Enter Loop/Delete Ball/Print Ball in the next position approach as that seems to work best in BASIC in helping to reduce flicker.




10 DEFINT a-z:MODE 0
20 SYMBOL 255,56,68,130,130,130,68,56,0
30 SYMBOL 254,130,1,0,1,0,1,130,85
40 SYMBOL 253,0,0,8,0,0,0,0,0
50 INK 0,0:INK 1,1:INK 2,2:INK 3,11:INK 4,18:PAPER 2:BORDER 2:CLS
60 GOSUB 380
70 x=10 : y=10 : e=1 : f=1
80 GOSUB 250
90 WHILE INKEY(18)=-1
100 CALL &BD19:CALL &BD19
110 IF x=20 THEN e=-1
120 IF x=1 THEN e=1
130 IF y=25 THEN f=-1
140 IF y=1 THEN f=1
150 GOSUB 350
160 x=x+e
170 y=y+f
180 GOSUB 250
190 WEND
200 CALL &BC02 : INK 1,26 : PEN 1
210 PRINT CHR$(22);CHR$(0);
220 MODE 2
230 END
240 ' Draw Ball
250 PEN 1
260 LOCATE 1,1:PRINT CHR$(22);CHR$(0);
270 LOCATE x,y : PRINT CHR$(255);
280 PEN 4
290 LOCATE 1,1:PRINT CHR$(22);CHR$(1);
300 LOCATE x,y : PRINT CHR$(254);
310 PEN 3
320 LOCATE x,y : PRINT CHR$(253);
330 RETURN
340 ' Erase Ball
350 PEN 4 : LOCATE 1,1:PRINT CHR$(22);CHR$(0);:LOCATE x,y : PRINT CHR$(207);
360 RETURN
370 ' Draw Background
380 FOR y=1 TO 25
390 PEN 4
400 LOCATE 1,y
410 PRINT STRING$(20,CHR$(207));
420 NEXT y
430 RETURN






Title: Re: Silly Programming Ideas - Turning Text into Graphics
Post by: AMSDOS on 07:26, 23 July 17
Back to this old thread, I've made a couple of updates to this old thing from Nov 2011:

10 MODE 1
20 xc=2:yc=2:x=0:y=0
30 WHILE INKEY$=""
40 CALL &BD19:CALL &BD19:CALL &BD19:CALL &BD19:ORIGIN x,y:PLOT 100,100,1:DRAW 125,100:DRAW 125,125:DRAW 100,125:DRAW 100,100
50 ox=x:oy=y:x=x+xc:y=y+yc
60 CALL &BD19:CALL &BD19:CALL &BD19:CALL &BD19:ORIGIN ox,oy:PLOT 100,100,0:DRAW 125,100:DRAW 125,125:DRAW 100,125:DRAW 100,100
70 IF x=100 then xc=-2
80 if y=100 then yc=-2
90 if x=0 then xc=2
100 if y=0 then yc=2
110 wend


As it shows is using a heap of FRAME FLYBACKs (&BD19), though still flickers.  :D What I should of done was:


25 ORIGIN x,y:PLOT 100,100,1:DRAW 125,100:DRAW 125,125:DRAW 100,125:DRAW 100,100
35 ox=x:oy=y:x=x+xc:y=y+yc
40 ORIGIN ox,oy:PLOT 100,100,0:DRAW 125,100:DRAW 125,125:DRAW 100,125:DRAW 100,100
50 ORIGIN x,y:PLOT 100,100,1:DRAW 125,100:DRAW 125,125:DRAW 100,125:DRAW 100,100
DELETE 60


though rather than drag that program out any further, I wanted to have some fun with this idea of adding a couple more shapes to it and see how BASIC handles it.

I was quite surprised how well this 1st program went. I've kept it to a series of 3 shapes with their own set of variables, so shape 1 uses x & y, shape 2 uses w & z and shape 3 uses u & v. They each have their own directional variables, shape 1 uses a & b to allow it to move diagonally like the original program did, shape 2 uses c to move the shape horizontally across the screen & shape 3 uses d which moves the shape vertically up and down the screen, to make things a little bit more interesting shape 3 begins moving very slowly, though once it reaches of one those checkpoints it could speed up. Using this approach yes it possible to move a series of graphical shapes by just using ORIGIN:


10 ' Attack of the Moving Shapes!
20 ' Simulate the Movement of Multiple Shapes using ORIGIN in Locomotive BASIC
30 ' 3 Shapes are used: Square, Triangle & Rectangle
40 ' Related Variables for each shape are:
50 ' Square,   x, y = xpos,ypos positions,
60 '           a, b = directional guides to move square Diagonally
70 ' Triangle, w, z = xpos,ypos positons, c = directional guide
80 ' Rectangle,u, v = xpos,ypos positions, d = directional guide
90 ' An leading 'o' followed by variable is used for deleting an old position.
100 MODE 0:BORDER 11:INK 0,11:INK 1,26
110 PRINT CHR$(23)+CHR$(1); ' XOR Mode
120 a%=4:b%=4:c%=8:d%=2
130 x%=100:y%=100
140 w%=296:z%=300
150 u%=304:v%=12
160 ORIGIN x%,y%:GOSUB 1010
170 ORIGIN w%,z%:GOSUB 1110
180 ORIGIN u%,v%:GOSUB 1210
190 WHILE INKEY(47)=-1
200   ox%=x%:oy%=y%
210   ow%=w%
220   ov%=v%
230   x%=x%+a%:y%=y%+b%
240   w%=w%+c%
250   v%=v%+d%
260   ORIGIN ox%,oy%:GOSUB 1010
270   ORIGIN ow%,z%:GOSUB 1110
280   ORIGIN u%,ov%:GOSUB 1210
290   ORIGIN x%,y%:GOSUB 1010
300   ORIGIN w%,z%:GOSUB 1110
310   ORIGIN u%,v%:GOSUB 1210
320   IF x%=200 THEN a%=-4
330   IF y%=200 THEN b%=-4
340   IF x%=0 THEN a%=4
350   IF y%=0  THEN b%=4
360   IF w%=600 THEN c%=-8
370   IF w%=0 THEN c%=8
380   IF v%>370 THEN d%=-INT(RND*7)+2
390   IF v%<10 THEN d%=INT(RND*7)+2
400 WEND:MODE 2:END
1000 ' Draw Box
1010 PLOT 0,0,1
1020 DRAW 25,0
1030 DRAW 25,25
1040 DRAW 0,25
1050 DRAW 0,0
1060 RETURN
1100 ' Draw Triangle
1110 PLOT 0,0,2
1120 DRAW 25,0
1130 MOVE 25,2:DRAW 12,25
1140 MOVE 10,18:DRAW 0,0
1150 RETURN
1200 ' Draw Rectangle
1210 PLOT 0,0,3
1220 DRAW 50,0
1230 DRAW 50,25
1240 DRAW 0,25
1250 DRAW 0,2
1260 RETURN


I then decided to bring more organization to the program by using an array instead. Applying it that way, it's introduced some FOR loops to deal with the positions for the 3 shapes & reduced the amount of variable/ORIGIN being used and have been able to use ON p% GOSUB for the corresponding shape, I was hoping I would have been able to do something to that large summary of IF statements (340..410), though as each shape has it's own personal traits, the conditions need to remain (unless there's another way around it!):


10 ' ------------------------------------------------------------------
20 ' Attack of the Moving Shapes #2!
30 '
40 ' Simulate the Movement of 3 Shapes using ORIGIN.
50 ' In this version the 3 Shapes positions are stored into 4 Arrays to
60 ' represent Current and Old positions. 1,2 & 3 represent each Shape.
70 ' The p% variable is used to point to the relevant position of the
80 ' array and print the relevant shape subroutine.
90 ' ------------------------------------------------------------------
100 MODE 0:BORDER 11:INK 0,11:INK 1,26
110 DIM x%(3),y%(3),ox%(3),oy%(3)
120 PRINT CHR$(23)+CHR$(1); ' XOR Mode
130 a%=4:b%=4:c%=8:d%=2
140 x%(1)=100:y%(1)=100
150 x%(2)=296:y%(2)=300
160 x%(3)=304:y%(3)=12
170 FOR p%=1 TO 3
180   ORIGIN x%(p%),y%(p%)
190   ON p% GOSUB 1010,1110,1210
200 NEXT p%
210 WHILE INKEY(47)=-1
220   FOR p%=1 TO 3
230    ox%(p%)=x%(p%):oy%(p%)=y%(p%)
240   NEXT p%
250   x%(1)=x%(1)+a%:y%(1)=y%(1)+b%
260   x%(2)=x%(2)+c%
270   y%(3)=y%(3)+d%
280   FOR p%=1 TO 3
290     ORIGIN ox%(p%),oy%(p%)
300     ON p% GOSUB 1010,1110,1210
310     ORIGIN x%(p%),y%(p%)
320     ON p% GOSUB 1010,1110,1210
330   NEXT p%
340   IF x%(1)=200 THEN a%=-4
350   IF y%(1)=200 THEN b%=-4
360   IF x%(1)=0 THEN a%=4
370   IF y%(1)=0  THEN b%=4
380   IF x%(2)=600 THEN c%=-8
390   IF x%(2)=0 THEN c%=8
400   IF y%(3)>370 THEN d%=-INT(RND*7)+2
410   IF y%(3)<10 THEN d%=INT(RND*7)+2
420 WEND:WHILE INKEY$<>"":WEND:MODE 2:END
1000 ' Draw Box
1010 PLOT 0,0,1
1020 DRAW 25,0
1030 DRAW 25,25
1040 DRAW 0,25
1050 DRAW 0,0
1060 RETURN
1100 ' Draw Triangle
1110 PLOT 0,0,2
1120 DRAW 25,0
1130 MOVE 25,2:DRAW 12,25
1140 MOVE 10,18:DRAW 0,0
1150 RETURN
1200 ' Draw Rectangle
1210 PLOT 0,0,3
1220 DRAW 50,0
1230 DRAW 50,25
1240 DRAW 0,25
1250 DRAW 0,2
1260 RETURN


The result for the second program is something which is slower than the 1st, though offers much less flicker.  :D
Title: Re: Silly Programming Ideas - Turning Text into Graphics
Post by: AMSDOS on 08:34, 10 September 17
I'd made some adjustments to that condensed character set program above to produce a short Multicoloured Character demonstration program.


Initially my program looked like this:




10 SYMBOL 255,48,80,136,136,132,132,132,132
20 SYMBOL 254,0,32,80,32,80,40,80,40
30 SYMBOL 253,0,4,8,8,16,32,32,16
40 SYMBOL 252,0,0,4,4,12,28,28,0
50 SYMBOL 251,0,0,2,2,2,2,2,12
60 SYMBOL 250,0,56,72,68,100,56,0,0
70 SYMBOL 249,0,0,48,56,24,0,0,0
80 mode 0:ink 0,11:ink 1,26:ink 2,12:ink 3,9:ink 5,20:ink 6,23:ink 7,9:ink 8,10:ink 9,18
90 print chr$(22);chr$(1);
100 locate 1,1:pen 2:print chr$(255);:locate 1,1:pen 3:print chr$(254);
110 locate 3,1:pen 7:print chr$(253);:locate 3,1:pen 9:print chr$(252);:locate 3,1:pen 8:print chr$(251);
120 locate 5,1:pen 6:print chr$(250);:locate 5,1:pen 5:print chr$(249);
130 print chr$(22);chr$(0);



with some adjustments I'm able to have the character set as data within a string and use ASC to return it's value into an array.


[attachimg=1]


with the character data that SYMBOL uses in the 1st program, I just used CHR(<num>) to get the appropriate characters. If the character is a control code (which fall in the range of 0..31), CHR(1);CHR(<num>) needs to be used to display it, otherwise the manual documents how to access the control code through the CTRL+<key> method. I just then used CTRL+Arrow Keys to select the characters required for the string. The only limitation I had was not being able to access CHR(0) which is not accessible through Cursor Copy, as a result I picked another character which was not being used (255 seemed a good start!), though because of that, I've had to write an conditional "IF" for it. So this program could be improved if all 8 lines are used to avoid having any 0's in the SYMBOL data. The rest of my program just demonstrates randomly selecting from the 3 characters available and randomly position them onscreen, this code is using the transparent mode and the characters are positioned based on text coordinate positions, overall this looks quite quick and could be used instead of Ariom Sprites for the 10-Liners Compo.


[attachimg=2]
Title: Re: Silly Programming Ideas - Turning Text into Graphics
Post by: AMSDOS on 11:32, 21 October 17
I've been working on another approach for redefining the symbol data, this is what I came up with, which is just an example of the program above:


1000 DEFINT a-z:DIM g(18),d(8):p=1:READ a$:FOR z=1 TO 18:g(z)=VAL("&"+MID$(a$,p,2)):p=p+2:NEXT z:woff$=CHR$(22)+CHR$(0):b$="AAKLGAAAALNMPLAAAABBBBBEAACCEHHAACDDFIIFAIOIOJOJKORRQQQQ":DATA 000204080C10181C20283038444850648488
1010 p=1:FOR c=249 TO 255:FOR q=1 TO 8:y=ASC(MID$(b$,p,1))-64:d(q)=g(y):p=p+1:NEXT q:SYMBOL c,d(1),d(2),d(3),d(4),d(5),d(6),d(7),d(8):NEXT c:MODE 0:INK 0,0:INK 1,26:INK 2,12:INK 3,9:INK 5,23:INK 6,20:INK 7,9:INK 8,18:INK 9,10:won$=CHR$(22)+CHR$(1)
1020 PRINT won$;:FOR z=1 TO 50:x=INT(RND*20)+1:y=INT(RND*25)+1:s=INT(RND*3)+1:ON s GOSUB 1030,1040,1050:NEXT z:PRINT woff$;:LOCATE 1,1:PEN 1:CALL &BB18:END
1030 i=3:FOR c=254 TO 255:LOCATE x,y:PEN i:PRINT CHR$(c);:i=i-1:NEXT c:RETURN
1040 i=6:FOR c=249 TO 250:LOCATE x,y:PEN i:PRINT CHR$(c);:i=i-1:NEXT c:RETURN
1050 i=9:FOR c=251 TO 253:LOCATE x,y:PEN i:PRINT CHR$(c);:i=i-1:NEXT c:RETURN


Lines 1000 & 1010 do all the hard work of preparing the data and redefining accordingly. The DATA line in 1000 contains the figures (in Hexadecimal format) which gets stored in the g array. The b$ string is also data, since there are more than 10 combinations due to the amount of data values, I've used an alphabetical approach, which is converted into a value using ASC and subtracted by 64 to return a pointer type position that's stored into the "y" variable which in turn is then used to get the correct value from within the g array.

I made this routine because the game I'm working on now has quite a few redefined symbols, this example from the program above however, shows that I was able to simply redefine the symbols within 1 line, this approach obviously needs 2 lines. What I have here maybe the same as having the symbol data in 2 lines, maybe one advantage with this routine might be the ability of having DATA on any line filling in any gaps where necessary or just making it harder to decipher the code (though it doesn't help explaining the process here!)  ???
Title: Multicoloured Text Scroller in BASIC
Post by: AMSDOS on 10:25, 11 December 19
A while ago I wondered if it were possible to use one of those BASIC Message Scrollers to have each letter in a different colour as it Scrolls Right to Left. I wasn't successful earlier, though my 2nd attempt I had of it was good enough to create this version. I don't know if it could be improved, though the code is compatible in Locomotive BASIC and CPC BASIC 3.




100 MODE 1:BORDER 0:INK 0,11:INK 1,26:p=1
110 READ a$,col$
120 a$=a$+MID$(a$,1,1):a$=RIGHT$(a$,LEN(a$)-1)
130 col$=col$+MID$(col$,1,1):col$=RIGHT$(col$,LEN(col$)-1)
140 LOCATE 10,10
150 FOR p2=1 TO 20
160   PEN VAL(MID$(col$,p,1))
170   PRINT MID$(a$,p2,1);
180   p=p+1
190   IF p=len(a$) THEN p=1
200 NEXT p2
210 IF p>20 THEN p=p-20
220 GOTO 120
230 DATA " Multicoloured Text Scrolling in BASIC...."
240 DATA "132231123123212321231212321231322123212321"
Title: Re: Multicoloured Text Scroller in BASIC
Post by: mv on 22:23, 13 January 20
Quote from: AMSDOS on 10:25, 11 December 19
A while ago I wondered if it were possible to use one of those BASIC Message Scrollers to have each letter in a different colour as it Scrolls Right to Left. I wasn't successful earlier, though my 2nd attempt I had of it was good enough to create this version. I don't know if it could be improved, though the code is compatible in Locomotive BASIC and CPC BASIC 3.

Hmm, improve? Staying with Locomotive BASIC, I just checked that using chr$(15) to set the PEN and printing it as a single string will speeds up the scroller by a factor of 3:


100 MODE 1:BORDER 0:INK 0,11:INK 1,26:p=1
110 READ a$,col$
120 a$=a$+MID$(a$,1,1):a$=RIGHT$(a$,LEN(a$)-1)
130 col$=col$+MID$(col$,1,1):col$=RIGHT$(col$,LEN(col$)-1)
140 'LOCATE 10,10
150 FOR p2=1 TO len(a$)
160   'PEN VAL(MID$(col$,p,1))
170   'PRINT MID$(a$,p2,1);
175   s$=s$+chr$(15)+chr$(VAL(MID$(col$,p,1))) +  MID$(a$,p2,1)
180   p=p+1
190   IF p=len(a$) THEN p=1
200 NEXT p2
205 p=1
210 'IF p>20 THEN p=p-20
213 t$=mid$(s$,p,20*3)
214 if len(t$)<20*3 then t$=t$+left$(s$,20*3-len(t$))
215 locate 10,10:?t$;
216 p=p+3:if p>len(s$) then p=1
220 GOTO 213
230 DATA " Multicoloured Text Scrolling in BASIC...."
240 DATA "132231123123212321231212321231322123212321"
Title: Re: Silly Programming Ideas - Turning Text into Graphics
Post by: Fessor on 00:09, 14 January 20
Dunno how much it saves, AFAIK converting of the values wasn't needed.

175   s$=s$+chr$(15)+MID$(col$,p,1) +  MID$(a$,p2,1)
Title: Re: Silly Programming Ideas - Turning Text into Graphics
Post by: Z|G on 10:01, 29 May 21
Not as one nice as the above ones.

(https://i.postimg.cc/QxrLF3mf/Capture.png)

10 CLS
20 MODE 2
30 a$="Hello CPC Wiki... Greetings to all members... Found a scroller and thought it worthy of posting...."
50 startatpos=40
60 amt=LEN(a$):a$=STRING$(startatpos," ")+a$:a$=a$+" "
80 FOR txt=1 TO LEN(a$)-1
90 LOCATE 20,10:PRINT MID$(a$,txt,startatpos);   
100 FOR delay=1 TO 50:NEXT delay     
110 NEXT txt
120 GOTO 80
Powered by SMFPacks Menu Editor Mod