### Author Topic: Silly Programming Ideas - Turning Text into Graphics  (Read 24950 times)

0 Members and 1 Guest are viewing this topic.

#### AMSDOS

• Supporter
• 6128 Plus
• Posts: 3.893
• Country:
• Liked: 1104
• Likes Given: 1871
##### Re: Silly Programming Ideas - Turning Text into Graphics
« Reply #25 on: 11: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!  ), 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!

Code: [Select]
`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,1620 DIM col(242):GOSUB 1000:a=1:y=398:x=030 c1=0:c2=040 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 it80 c2=c2+1 ' increment loop (x coordinate) position by 190 WEND ' c2 trigger - works on x coordinate100 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 image130 c1=c1+1 ' increment loop (y coordinate) position by 1140 WEND ' c1 triggers back to first loop if total has not been reached, otherwise exits150 CALL &BB18160 MODE 2:CALL &BC02:END1000 ' Set up Colours1010 FOR a=1 TO 2411020 READ c1030 col(a)=c1040 NEXT a:RETURN1050 DATA 0,4,4,4,4,4,4,0,0,0,01060 DATA 0,4,4,4,4,4,4,4,4,4,01070 DATA 0,4,4,4,4,4,4,9,4,4,01080 DATA 4,4,4,4,4,4,4,9,4,4,01090 DATA 4,4,4,4,4,4,9,9,9,4,41100 DATA 4,4,4,4,1,0,9,0,1,4,41110 DATA 4,9,4,9,1,0,9,0,1,4,41120 DATA 0,9,4,9,1,0,9,0,1,4,41130 DATA 0,9,9,9,1,0,9,0,1,4,01140 DATA 0,4,9,9,1,1,9,1,9,9,01150 DATA 0,4,9,9,9,1,9,1,9,9,01160 DATA 0,4,9,9,9,9,9,9,9,9,01170 DATA 0,7,4,9,9,9,0,9,9,9,01180 DATA 7,7,7,9,9,9,9,9,9,8,01190 DATA 7,7,7,8,7,7,7,8,7,8,01200 DATA 7,7,9,8,7,7,7,8,9,9,01210 DATA 7,9,9,9,8,8,8,8,9,9,01220 DATA 0,9,9,8,6,1,6,1,8,9,01230 DATA 0,8,8,8,8,6,6,6,6,8,01240 DATA 0,8,8,8,8,8,8,8,8,8,81250 DATA 0,4,6,6,6,0,6,6,6,6,41260 DATA 0,4,4,4,4,0,4,4,4,4,4 `
* Using the old Amstrad Languages    * with the Firmware
* I also like to problem solve code in BASIC    * And type-in Type-Ins!

Home Computing Weekly Programs
Popular Computing Weekly Programs
Updated Other Program Links on Profile Page (Update April 16/15 phew!)
Programs for Turbo Pascal 3

#### SuTeKH/Epyteor

• 6128 Plus
• Posts: 1.379
• Country:
• Liked: 1286
• Likes Given: 2030
##### Re: Silly Programming Ideas - Turning Text into Graphics
« Reply #26 on: 11: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;
Code: [Select]
` 10 t=TIME20 FOR l=1 TO 500030 NEXT l40 PRINT (TIME-t)/30050 '60 t=TIME70 FOR l%=1 TO 500080 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...

#### AMSDOS

• Supporter
• 6128 Plus
• Posts: 3.893
• Country:
• Liked: 1104
• Likes Given: 1871
##### Re: Silly Programming Ideas - Turning Text into Graphics
« Reply #27 on: 00:55, 26 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!    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!
* Using the old Amstrad Languages    * with the Firmware
* I also like to problem solve code in BASIC    * And type-in Type-Ins!

Home Computing Weekly Programs
Popular Computing Weekly Programs
Updated Other Program Links on Profile Page (Update April 16/15 phew!)
Programs for Turbo Pascal 3

#### SuTeKH/Epyteor

• 6128 Plus
• Posts: 1.379
• Country:
• Liked: 1286
• Likes Given: 2030
##### Re: Silly Programming Ideas - Turning Text into Graphics
« Reply #28 on: 11:02, 26 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)

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)

« Last Edit: 11:06, 26 November 11 by tastefulmrship »

#### AMSDOS

• Supporter
• 6128 Plus
• Posts: 3.893
• Country:
• Liked: 1104
• Likes Given: 1871
##### Re: Silly Programming Ideas - Turning Text into Graphics
« Reply #29 on: 13: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.
* Using the old Amstrad Languages    * with the Firmware
* I also like to problem solve code in BASIC    * And type-in Type-Ins!

Home Computing Weekly Programs
Popular Computing Weekly Programs
Updated Other Program Links on Profile Page (Update April 16/15 phew!)
Programs for Turbo Pascal 3

#### SuTeKH/Epyteor

• 6128 Plus
• Posts: 1.379
• Country:
• Liked: 1286
• Likes Given: 2030
##### Re: Silly Programming Ideas - Turning Text into Graphics
« Reply #30 on: 13:59, 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.
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.

« Last Edit: 14:00, 26 November 11 by tastefulmrship »

#### AMSDOS

• Supporter
• 6128 Plus
• Posts: 3.893
• Country:
• Liked: 1104
• Likes Given: 1871
##### Re: Silly Programming Ideas - Turning Text into Graphics
« Reply #31 on: 03:40, 27 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!

UPDATED: All the BASIC stupid mistakes i&#39;ve made solved
All the BASIC stupid mistakes i've made solved.

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

Early Comments: "Hmm,some examples appear faster, others are harder to pick up speed wise when compared to the original programs."
« Last Edit: 09:08, 27 November 11 by CP/M User »
* Using the old Amstrad Languages    * with the Firmware
* I also like to problem solve code in BASIC    * And type-in Type-Ins!

Home Computing Weekly Programs
Popular Computing Weekly Programs
Updated Other Program Links on Profile Page (Update April 16/15 phew!)
Programs for Turbo Pascal 3

#### AMSDOS

• Supporter
• 6128 Plus
• Posts: 3.893
• Country:
• Liked: 1104
• Likes Given: 1871
##### Re: Perhaps More Unusual Programming Ideas - Smooth'ish Vertical Scrolling.
« Reply #32 on: 09:49, 25 July 12 »
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:

Code: [Select]
`;; 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:

Code: [Select]
`10 MODE 1:INK 1,26:INK 2,1320 WHILE INKEY\$<>" "30 PLOT (RND*240),396,INT(RND*2)+140 CALL &BD19:CALL &4000:CALL &BD1950 WEND`
« Last Edit: 10:38, 25 July 12 by CP/M User »
* Using the old Amstrad Languages    * with the Firmware
* I also like to problem solve code in BASIC    * And type-in Type-Ins!

Home Computing Weekly Programs
Popular Computing Weekly Programs
Updated Other Program Links on Profile Page (Update April 16/15 phew!)
Programs for Turbo Pascal 3

#### AMSDOS

• Supporter
• 6128 Plus
• Posts: 3.893
• Country:
• Liked: 1104
• Likes Given: 1871
##### Re: Silly Programming Ideas - Turning Text into Graphics
« Reply #33 on: 15: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.

[ Invalid Attachment ]

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.
* Using the old Amstrad Languages    * with the Firmware
* I also like to problem solve code in BASIC    * And type-in Type-Ins!

Home Computing Weekly Programs
Popular Computing Weekly Programs
Updated Other Program Links on Profile Page (Update April 16/15 phew!)
Programs for Turbo Pascal 3

#### AMSDOS

• Supporter
• 6128 Plus
• Posts: 3.893
• Country:
• Liked: 1104
• Likes Given: 1871
##### Re: Silly Programming Ideas - Turning Text into Graphics
« Reply #34 on: 11:50, 03 August 12 »
This is the CP/M 2.2 version of the previous attachment including the Turbo Pascal source.
* Using the old Amstrad Languages    * with the Firmware
* I also like to problem solve code in BASIC    * And type-in Type-Ins!

Home Computing Weekly Programs
Popular Computing Weekly Programs
Updated Other Program Links on Profile Page (Update April 16/15 phew!)
Programs for Turbo Pascal 3

#### AMSDOS

• Supporter
• 6128 Plus
• Posts: 3.893
• Country:
• Liked: 1104
• Likes Given: 1871
##### Re: Silly Programming Ideas - Turning Text into Graphics
« Reply #35 on: 11:14, 11 August 12 »

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

Code: [Select]
`10 MODE 1:BORDER 020 GOSUB 100030 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)=&F80040 GOSUB 10050 FOR p%=0 TO &4E:addr%=&4000:CALL &BD19:CALL &BD19:GOSUB 11060 addr%=&4010:CALL &BD19:CALL &BD19:GOSUB 110:NEXT p%70 CALL &BB18:END100 ' Poke Sprite to Screen110 FOR y%=1 TO 8120 a%=scr%(y%)+p%:POKE a%,PEEK(addr%):addr%=addr%+1130 b%=scr%(y%)+1+p%:POKE b%,PEEK(addr%):addr%=addr%+1140 NEXT y%150 RETURN1000 ' Poke Sprite Data to Memory1010 FOR addr%=&4000 TO &401F:READ a\$1020 POKE addr%,VAL("&"+a\$)1030 NEXT addr%:RETURN1040 DATA D0,60,77,CC,03,08,03,081050 DATA 03,08,03,08,03,08,10,001060 DATA 00,00,00,00,00,00,00,001070 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.
* Using the old Amstrad Languages    * with the Firmware
* I also like to problem solve code in BASIC    * And type-in Type-Ins!

Home Computing Weekly Programs
Popular Computing Weekly Programs
Updated Other Program Links on Profile Page (Update April 16/15 phew!)
Programs for Turbo Pascal 3

#### AMSDOS

• Supporter
• 6128 Plus
• Posts: 3.893
• Country:
• Liked: 1104
• Likes Given: 1871
##### Re: Silly Programming Ideas - Turning Text into Graphics
« Reply #36 on: 10: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.    I've attached a Disk Image (with Demonstration program) and Source file as well.

Code: [Select]
` ;; 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`
* Using the old Amstrad Languages    * with the Firmware
* I also like to problem solve code in BASIC    * And type-in Type-Ins!

Home Computing Weekly Programs
Popular Computing Weekly Programs
Updated Other Program Links on Profile Page (Update April 16/15 phew!)
Programs for Turbo Pascal 3

#### AMSDOS

• Supporter
• 6128 Plus
• Posts: 3.893
• Country:
• Liked: 1104
• Likes Given: 1871
##### Re: Silly Programming Ideas - Turning Text into Graphics
« Reply #37 on: 14: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.    And I've slipped in a Link in my Signature in case anyone can do something with it.
* Using the old Amstrad Languages    * with the Firmware
* I also like to problem solve code in BASIC    * And type-in Type-Ins!

Home Computing Weekly Programs
Popular Computing Weekly Programs
Updated Other Program Links on Profile Page (Update April 16/15 phew!)
Programs for Turbo Pascal 3

#### Gryzor

• 6128 Plus
• Posts: 15.967
• Country:
• CPC-Wiki maintainer
• Liked: 3426
• Likes Given: 6155
##### Re: Silly Programming Ideas - Turning Text into Graphics
« Reply #38 on: 14:22, 03 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.    And I've slipped in a Link in my Signature in case anyone can do something with it.

Ooh nice work mate!

#### AMSDOS

• Supporter
• 6128 Plus
• Posts: 3.893
• Country:
• Liked: 1104
• Likes Given: 1871
##### Re: Silly Programming Ideas - Turning Text into Graphics
« Reply #39 on: 06: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.

Code: [Select]
` ;; 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:

Code: [Select]
`10 MODE 1:FOR y%=0 TO 190:CALL &BD19:CALL &4000,&4094,100,y%:NEXT y%`
* Using the old Amstrad Languages    * with the Firmware
* I also like to problem solve code in BASIC    * And type-in Type-Ins!

Home Computing Weekly Programs
Popular Computing Weekly Programs
Updated Other Program Links on Profile Page (Update April 16/15 phew!)
Programs for Turbo Pascal 3

#### AMSDOS

• Supporter
• 6128 Plus
• Posts: 3.893
• Country:
• Liked: 1104
• Likes Given: 1871
##### Re: Silly Programming Ideas - Turning Text into Graphics
« Reply #40 on: 10: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.
* Using the old Amstrad Languages    * with the Firmware
* I also like to problem solve code in BASIC    * And type-in Type-Ins!

Home Computing Weekly Programs
Popular Computing Weekly Programs
Updated Other Program Links on Profile Page (Update April 16/15 phew!)
Programs for Turbo Pascal 3

#### AMSDOS

• Supporter
• 6128 Plus
• Posts: 3.893
• Country:
• Liked: 1104
• Likes Given: 1871
##### Re: Silly Programming Ideas - Turning Text into Graphics
« Reply #41 on: 14: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:

Code: [Select]
`plot 100,100draw 100,200draw 150,100draw 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.

Code: [Select]
`10 ' BASIC Graphics20 ' CP/M User - 200830 INK 0,0:INK 1,26:BORDER 1:MODE 1: WINDOW#1,1,14,25,25: WINDOW#2,20,40,25,2540 WHILE 150 LOCATE 1,25:INPUT#1,"Command:-";c\$:CLS#160 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#270 IF c\$="e" THEN MODE 2:END80 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#190 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.
* Using the old Amstrad Languages    * with the Firmware
* I also like to problem solve code in BASIC    * And type-in Type-Ins!

Home Computing Weekly Programs
Popular Computing Weekly Programs
Updated Other Program Links on Profile Page (Update April 16/15 phew!)
Programs for Turbo Pascal 3

#### AMSDOS

• Supporter
• 6128 Plus
• Posts: 3.893
• Country:
• Liked: 1104
• Likes Given: 1871
##### Re: Silly Programming Ideas - Turning Text into Graphics
« Reply #42 on: 09: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.

Code: [Select]
`10 EVERY 5,2 GOSUB 100020 x%=1:y%=100:dir%=1:num%=1:MODE 030 WHILE INKEY\$=""40 TAG:MOVE x%,y%:PEN num%:CALL &BD19:PRINT " ";CHR\$(224);" ";:TAGOFF50 x%=x%+dir%60 IF x%=320 THEN dir%=-170 IF x%=1 THEN dir%=180 WEND90 CALL &BC02:MODE 2:PEN 1:END1000 num%=num%+1:i%=(RND*26)1010 IF num%=15 THEN num%=11020 INK num%,i%1030 RETURN`
* Using the old Amstrad Languages    * with the Firmware
* I also like to problem solve code in BASIC    * And type-in Type-Ins!

Home Computing Weekly Programs
Popular Computing Weekly Programs
Updated Other Program Links on Profile Page (Update April 16/15 phew!)
Programs for Turbo Pascal 3

#### Gryzor

• 6128 Plus
• Posts: 15.967
• Country:
• CPC-Wiki maintainer
• Liked: 3426
• Likes Given: 6155
##### Re: Silly Programming Ideas - Turning Text into Graphics
« Reply #43 on: 12:09, 14 October 12 »
Man, it really tripped my girl out, I can tell you that

#### AMSDOS

• Supporter
• 6128 Plus
• Posts: 3.893
• Country:
• Liked: 1104
• Likes Given: 1871
##### Re: Silly Programming Ideas - Turning Text into Graphics
« Reply #44 on: 10:57, 15 October 12 »
Man, it really tripped my girl out, I can tell you that

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).
* Using the old Amstrad Languages    * with the Firmware
* I also like to problem solve code in BASIC    * And type-in Type-Ins!

Home Computing Weekly Programs
Popular Computing Weekly Programs
Updated Other Program Links on Profile Page (Update April 16/15 phew!)
Programs for Turbo Pascal 3

#### AMSDOS

• Supporter
• 6128 Plus
• Posts: 3.893
• Country:
• Liked: 1104
• Likes Given: 1871
##### Re: Silly Programming Ideas - Turning Text into Graphics
« Reply #45 on: 12:02, 20 October 12 »
I'm doing this rotating square the hard way from BASIC and this is what I came up with:

Code: [Select]
`5 MODE 1:p=0:GOSUB 200010 EVERY 10,1 GOSUB 100015 WHILE INKEY\$="":WEND:END20 MOVE 100,10030 DRAW 200,100,c40 DRAW 200,200,c50 DRAW 100,200,c60 DRAW 100,100,c65 RETURN70 MOVE 75,12580 DRAW 125,225,c90 DRAW 225,175,c100 DRAW 175,75,c110 DRAW 75,125,c115 RETURN120 MOVE 75,150130 DRAW 150,225,c140 DRAW 225,150,c150 DRAW 150,75,c160 DRAW 75,150,c165 RETURN170 MOVE 75,175180 DRAW 175,225,c190 DRAW 225,125,c200 DRAW 125,75,c210 DRAW 75,175,c220 RETURN1000 oldp=oldp+1:p=p+11020 c=1:IF p=1 THEN CALL &BD19:GOSUB 201021 c=0:IF oldp=1 THEN CALL &BD19:GOSUB 201030 c=1:IF p=2 THEN CALL &BD19:GOSUB 701031 c=0:IF oldp=2 THEN CALL &BD19:GOSUB 701040 c=1:IF p=3 THEN CALL &BD19:GOSUB 1201041 c=0:IF oldp=3 THEN CALL &BD19:GOSUB 1201050 c=1:IF p=4 THEN CALL &BD19:GOSUB 1701051 c=0:IF oldp=4 THEN CALL &BD19:GOSUB 1701060 IF p=5 THEN p=01065 IF oldp=5 THEN oldp=01070 RETURN2000 MOVE 50,502010 DRAW 250,50,22020 DRAW 250,250,22030 DRAW 50,250,22040 DRAW 50,50,22050 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.
* Using the old Amstrad Languages    * with the Firmware
* I also like to problem solve code in BASIC    * And type-in Type-Ins!

Home Computing Weekly Programs
Popular Computing Weekly Programs
Updated Other Program Links on Profile Page (Update April 16/15 phew!)
Programs for Turbo Pascal 3

#### HAL 6128

• 6128 Plus
• Posts: 514
• Country:
• Liked: 254
• Likes Given: 1333
##### Re: Silly Programming Ideas - Turning Text into Graphics
« Reply #46 on: 13: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.
Code: [Select]
` 10 GOSUB 130:' initialize20 :30 MOVE -100,-100:DRAWR 200,0:DRAWR 0,200:DRAWR -200,0:DRAWR 0,-20040 :50 ' ****** Main Loop55 GOSUB 29060 FOR rot=1 TO 565 GOSUB 29070 GOSUB 36080 GOSUB 290100 NEXT rot110 GOTO 60120 :130 '****** Initializing140 MODE 1150 DEFINT a-z:DEG:ORIGIN 100,100160 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 4190 READ x(i),y(i)200 NEXT i210 FOR i=1 TO 4220 READ a(i),b(i)230 NEXT i240 RETURN250 :260 DATA -50,-50,50,-50,50,50,-50,50270 DATA 1,2,2,3,3,4,4,1280 :290 ' ****** Draw & Delete300 FOR i=1 TO 4310 MOVE x(a(i)),y(a(i))320 DRAW x(b(i)),y(b(i)),1,1330 NEXT i340 RETURN350 :360 ' ****** Transformation370 FOR i=1 TO 4380 tmp(i)=x(i)*cosinus!-y(i)*sinus!390 y(i)=y(i)*cosinus!+x(i)*sinus!400 x(i)=tmp(i)410 NEXT i420 RETURN `
...proudly supported Schnapps Demo, Pentomino and NQ-Music-Disc with GFX

#### AMSDOS

• Supporter
• 6128 Plus
• Posts: 3.893
• Country:
• Liked: 1104
• Likes Given: 1871
##### Re: Silly Programming Ideas - Turning Text into Graphics
« Reply #47 on: 13:21, 23 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.
Code: [Select]
` 10 GOSUB 130:' initialize20 :30 MOVE -100,-100:DRAWR 200,0:DRAWR 0,200:DRAWR -200,0:DRAWR 0,-20040 :50 ' ****** Main Loop55 GOSUB 29060 FOR rot=1 TO 565 GOSUB 29070 GOSUB 36080 GOSUB 290100 NEXT rot110 GOTO 60120 :130 '****** Initializing140 MODE 1150 DEFINT a-z:DEG:ORIGIN 100,100160 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 4190 READ x(i),y(i)200 NEXT i210 FOR i=1 TO 4220 READ a(i),b(i)230 NEXT i240 RETURN250 :260 DATA -50,-50,50,-50,50,50,-50,50270 DATA 1,2,2,3,3,4,4,1280 :290 ' ****** Draw & Delete300 FOR i=1 TO 4310 MOVE x(a(i)),y(a(i))320 DRAW x(b(i)),y(b(i)),1,1330 NEXT i340 RETURN350 :360 ' ****** Transformation370 FOR i=1 TO 4380 tmp(i)=x(i)*cosinus!-y(i)*sinus!390 y(i)=y(i)*cosinus!+x(i)*sinus!400 x(i)=tmp(i)410 NEXT i420 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.
* Using the old Amstrad Languages    * with the Firmware
* I also like to problem solve code in BASIC    * And type-in Type-Ins!

Home Computing Weekly Programs
Popular Computing Weekly Programs
Updated Other Program Links on Profile Page (Update April 16/15 phew!)
Programs for Turbo Pascal 3

#### AMSDOS

• Supporter
• 6128 Plus
• Posts: 3.893
• Country:
• Liked: 1104
• Likes Given: 1871
##### Re: Silly Programming Ideas - Turning Text into Graphics
« Reply #48 on: 13: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.
* Using the old Amstrad Languages    * with the Firmware
* I also like to problem solve code in BASIC    * And type-in Type-Ins!

Home Computing Weekly Programs
Popular Computing Weekly Programs
Updated Other Program Links on Profile Page (Update April 16/15 phew!)
Programs for Turbo Pascal 3

#### Devilmarkus

• Vivid source of indefiniteness
• 6128 Plus
• Posts: 4.035
• Country:
• WebCPC / JavaCPC developer
• Liked: 1016
• Likes Given: 926
##### Re: Silly Programming Ideas - Turning Text into Graphics
« Reply #49 on: 01:41, 25 October 12 »
Indeed, DRAW and PLOT is very slow...

My example:
Code: [Select]
`10 MODE 120 DEG30 g=140 WINDOW #1,14,27,7,16:PAPER #1,0:INK 0,0:BORDER 0:INK 1,1350 A%=100:B%=5060 FOR p%=0 TO 88 STEP 270 MOVE 320+SIN(p%)*A%,200+COS(p%)*B%,g:DRAW 320,30080 MOVE 320+SIN(p%+90)*A%,200+COS(p%+90)*B%:DRAW 320,30090 MOVE 320+SIN(p%+180)*A%,200+COS(p%+180)*B%:DRAW 320,300100 MOVE 320+SIN(p%+270)*A%,200+COS(p%+270)*B%:DRAW 320,300110 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 #1160 NEXT170 GOTO 60`
Perhaps anybody can improve this?
« Last Edit: 01:48, 25 October 12 by Devilmarkus »
When you put your ear on a hot stove, you can smell how stupid you are ...