sprites

[jamie]

I am looking to program on my 464. I have had a fair bit of experience with CBM Basic. To start with how do I poke sprites to screen? Example on the C64 you need pointers, activate VIC chip, set colour etc. I am guessing it is very different on the 464. Can anyone reccomend any good literature?

[arnoldemu]

I am looking to program on my 464. I have had a fair bit of experience with CBM Basic. To start with how do I poke sprites to screen? Example on the C64 you need pointers, activate VIC chip, set colour etc. I am guessing it is very different on the 464. Can anyone reccomend any good literature?

welcome jamie.

464 doesn't have hardware sprites so you can't poke them like you can on the c64.

My advice is to try with a program like "sprites alive" which gives sprite abilities to basic programs.
http://www.cpc-power.com/index.php?page=detail&num=4649

If you have access to a plus machine try B-ASIC:
http://www.cpc-power.com/index.php?page=detail&num=5184

With a 464 "shape and sound" may also be fun.
http://www.cpc-power.com/index.php?page=detail&num=5077

To use sprites on the 464 you really need to use assembler code. If you know a bit, take a look in the programming section and look at the sticky topic. It has a load of examples I wrote for drawing sprites, erasing them etc.

[arnoldemu]

AGD is also good.
Arcade Game Designer

[Trebmint]

Welcome. Yes the C64 and CPC are different beasts when it comes to Sprites. The CPC does not have hardware sprites like the C64, we have to draw our sprites onto the screen each displayed frame rather than saying "Hey Sprite appear here!" like on C64.


There are some advantages and some disadvantages. The main advantage is as its software its far more flexible so we can have any size, number, compressed or any other little trick. The real disadvantage is speed. Most CPC games are 90% CPU time drawing stuff to screen. This is why CPC games often appear to be slower than C64 games which have smooth sprites shifting at 50 frames a second, but obviously these have severe limitations of size and number.


The other thing is unless you are a Z80 coder you might as well forget Sprites, luckily there are programs that are around to help you overcome this. CPC basic is faster and better than the poor C64 version. I recommend you look at a thread on here called CPC BASIC 3. Its super quick... not just 2 or 3 times faster than C64 basic but x100 or so.

[arnoldemu]

Good point.

In BASIC you can redefine the char set using SYMBOL you can then use graphics coordinates to place them at any pixel position. So you could make simple sprites this way.

Also the CPC can use other languages such as Pascal and C. These may have libraries with them which you can use.

Or, if you can develop on PC, you can do more there using tools that exist on those and build for CPC and transfer. (e.g. sdcc and cpcrslib).

[AMSDOS]

The 1st Sprite Driver/Program I was using was David Hall's Ariom Sprites (or Axiom Sprites if you follow the ACU title), it's only a 10-Liner (well if you cut out the Instructions for use) which gives you a 8x8 Sprite Editor, the code can then easily be called to display the image. It only gives you simple Text Based Co-ordinates, but simple Multicoloured sprites can be incorporated to BASIC programs, this program will also let you Load or Save the Sprite Data (along with the Sprite Driver). It's kind of Fool proof. 

[dthrone]

To see David Hall's routine in action, try his type-in from Amstrad Action 104 "Helloween" - this is a great example of what can be achieved in BASIC with a simple machine code sprite routine! 

[TFM]

The most easy way of using the CPCs sprite is to redefine characters using the SYMBOL command in BASIC and the use the PRINT command to show them on screen. But don't forget to use the TAG mode. You find anything in the handbook.

[Morri]

Hi Jamie and welcome. Don't forget to register and update us on your new CPC adventures 

My advice is to try with a program like "sprites alive" which gives sprite abilities to basic programs.

I have used sprites alive, both the BASIC version and the compiler version, to make simple games which I called Eternal Light 1 & 2. The basic version is very easy to use as it is simply the locomotive basic with added RSX commands (e.g. |sput,1,x,y = put sprite 1 on screen at x & y co-ordinates).
The sprite designer is also very good and easy to use.

I have also been playing around with Sean McManus' "The Sprite Idea" which is in introduction to the world of CPC sprites. Very easy to follow and he made a simple sprite driver / definer to use. Again, just regular locomotive basic with RSX commands.

I recommend you look at a thread on here called CPC BASIC 3. Its super quick... not just 2 or 3 times faster than C64 basic but x100 or so.

I have only just started trying CPC BASIC 3 but this is a windows based compiler which takes basic programs and turns them into machine code, much like the sprites alive compiler version (which is CPC based). A bit harder to get to grips with but the results are very fast as Trebmint says.
You'll see at the end of the cpc basic 3 thread that we have been incorporating Sean's sprite routine to make fast code with sprites. This has been quite challenging for someone of my beginner coding levels but has been quite fun to learn.

[Morri]

The 1st Sprite Driver/Program I was using was David Hall's Ariom Sprites (or Axiom Sprites if you follow the ACU title), it's only a 10-Liner (well if you cut out the Instructions for use) which gives you a 8x8 Sprite Editor, the code can then easily be called to display the image. It only gives you simple Text Based Co-ordinates, but simple Multicoloured sprites can be incorporated to BASIC programs, this program will also let you Load or Save the Sprite Data (along with the Sprite Driver). It's kind of Fool proof. 

Haven't seen this one before. Will type this out on my 6128 and give it a go.

To see David Hall's routine in action, try his type-in from Amstrad Action 104 "Helloween" - this is a great example of what can be achieved in BASIC with a simple machine code sprite routine! 

Helloween is great! My favorite David Hall game is "Supersnake" from AA # 84. Play this one all the time but I can't beat his high score! 

[AMSDOS]

Haven't seen this one before. Will type this out on my 6128 and give it a go.

Very easy to use and if you don't mind 8x8 Sprites it can colour up some of those BASIC games which rely on SYMBOL, obviously though it won't give you Graphical Precision.


The other one I used which uses Text Based Co-ordinates is Michael Gledhill's Spritemaker
Michael Gledhill's Spritemaker which gives a small library of Tools for Sprite Handling, I guess it could be described as the poor mans Sprites Alive though.

[Morri]

The other one I used which uses Text Based Co-ordinates is Michael Gledhill's Spritemaker
Michael Gledhill's Spritemaker which gives a small library of Tools for Sprite Handling, I guess it could be described as the poor mans Sprites Alive though.

Ah, a horrible machine code type-in...  So many DATA statements...  Do I dare...  Tempted... 
I do like the fact that this one offers the ability to overlay sprites / go behind backgrounds but a shame it has no sprite editor (only data statements or a RSX that grabs one sprite only).

I also notice that within the machine code hex are values beginning with "r". Whats happening there? I see line 100 deals with it but why not just put the proper hex value and be done with it? 

[dthrone]

Ah, a horrible machine code type-in...  So many DATA statements...  Do I dare...  Tempted... 
I do like the fact that this one offers the ability to overlay sprites / go behind backgrounds but a shame it has no sprite editor (only data statements or a RSX that grabs one sprite only).

I also notice that within the machine code hex are values beginning with "r". Whats happening there? I see line 100 deals with it but why not just put the proper hex value and be done with it? 

I think the “r” is for relative.  He is counting 256 byte chunks from &8fxx.  Notice in line 1340 the rB is preceded by an ff, so he is referencing the address &8eff – his himem for the sprite blocks.  I’d guess he has probably written it this way to make the hex data a bit more readable.


or it could be for "register" 

[AMSDOS]

Ah, a horrible machine code type-in...  So many DATA statements...  Do I dare...  Tempted... 
I do like the fact that this one offers the ability to overlay sprites / go behind backgrounds but a shame it has no sprite editor (only data statements or a RSX that grabs one sprite only).

I also notice that within the machine code hex are values beginning with "r". Whats happening there? I see line 100 deals with it but why not just put the proper hex value and be done with it? 

Well I think there should be a Download of the Program here. And if I remember correctly the program saves a BIN file of the Suite. Bit of a letdown that it doesn't have a Sprite Editor, it's the only program I know of that takes the DATA from BASIC statements and compiles them into Sprites. I'm unsure what I was using to make the data, by the look of my notes it looks like I was just using Gpaint to draw the sprite and writing down the pen colours for the data.


But it really is a poor-mans Sprites Alive and just assumed you wouldn't be interested in this, the only advantage you'd probably get out of this is more memory to play with, though Ariom Sprites would also give the same result and I reckon if you're clever with Ariom Sprites the illusion of having a Background could be created, I think David did this with his Supersnake game.

[Morri]

Well I think there should be a Download of the Program here.

Tried the link already but doesn't seem to be uploaded yet. No problems, not going to type it in just yet. Still playing with ESD2.

But it really is a poor-mans Sprites Alive and just assumed you wouldn't be interested in this

Really just interested to see all the different drivers that are available and the effort the author put into making it user friendly / features / speed / sprite designers etc... I enjoy trying to then make a game using them (so far only 2 - currently working on my 3rd using ESD2) to see how powerful they are. So if you know of anything, please share as I'll always be interested! 
For example, I've tried looking at Laser Basic but that manual looks too complicated (user friendly is my #1 feature) and I'm waiting for the day that the Pandora manual ever pops up so I can have a look at that.

[AMSDOS]

Tried the link already but doesn't seem to be uploaded yet. No problems, not going to type it in just yet. Still playing with ESD2.

I've attached the disk image, along with the programs from that article and some of the ones I made with it. No games though, SMSBUBDEM.BAS gives you a bit of an idea of what can be produced.

Really just interested to see all the different drivers that are available and the effort the author put into making it user friendly / features / speed / sprite designers etc... I enjoy trying to then make a game using them (so far only 2 - currently working on my 3rd using ESD2) to see how powerful they are. So if you know of anything, please share as I'll always be interested! 
For example, I've tried looking at Laser Basic but that manual looks too complicated (user friendly is my #1 feature) and I'm waiting for the day that the Pandora manual ever pops up so I can have a look at that.

I've just produced a Buffer Screen which addresses the Flickering issue, though discovered that I had to modify ESD2. The example seems to work fine in Interpreted BASIC, but when I compile it under CPC BASIC 3, the program compiles fine, but the outcome is crashing. I cannot find any signs of the program being the flaw, so suspect my modified ESD2 is playing havoc with the registers, so might have preserve my registers.

[AMSDOS]

I've just produced a Buffer Screen which addresses the Flickering issue, though discovered that I had to modify ESD2. The example seems to work fine in Interpreted BASIC, but when I compile it under CPC BASIC 3, the program compiles fine, but the outcome is crashing. I cannot find any signs of the program being the flaw, so suspect my modified ESD2 is playing havoc with the registers, so might have preserve my registers.

Here's said program which works fine from BASIC. In this format if I take this program to CPC BASIC 3, program proceeds to exit & if I make it an Infinite Loop it doesn't display my ball sprite, just looks like it's crashing. I modified my ESD2 code see if that would change the situation by placing PUSH AF / POP AF around CALL &BC26, but still had the same outcome.

Code: [Select]

   org &9C40


.force   ld l,(ix+00)
   ld h,(ix+01)
   ld e,(ix+02)
   ld d,(ix+03)
   call &bc1d
   push hl
   ld e,(ix+04)
   ld d,(ix+05)
   ex de,hl
   ld c,(hl)
   inc hl
   ld b,(hl)
   inc hl
   ex de,hl
   pop hl
.loop1   push bc
   push hl
.loop2   ld a,(de)
   ld (hl),a
   inc hl
   inc de
   djnz loop2
   pop hl
;;   push af
   call &bc26
;;   pop af
;;   ld bc,&800
;;   add hl,bc
;;   jr nc,end
;;   ld bc,&c050
;;   add hl,bc
;; .end   
   pop bc
   dec c
   jr nz,loop1
   ret


.Overlay
   ld l,(ix+00)
   ld h,(ix+01)
   ld e,(ix+02)
   ld d,(ix+03)
   call &bc1d
   push hl
   ld e,(ix+04)
   ld d,(ix+05)
   ex de,hl
   ld c,(hl)
   inc hl
   ld b,(hl)
   inc hl
   ex de,hl
   pop hl
.ol1   push bc
   push hl
.ol2   ld a,(de)
   cp &00
   jr z,iszero   
   ld (hl),a
.iszero   inc hl
   inc de
   djnz ol2
   pop hl
;;   push af
   call &bc26
;;   pop af
   pop bc
   dec c
   jr nz,ol1
   ret


.grab
   ld l,(ix+04)
   ld h,(ix+05)
   ld e,(ix+06)
   ld d,(ix+07)
   call &bc1d
   ex de,hl
   ld l,(ix+08)
   ld h,(ix+09)
   ld c,(ix+00)
   ld b,(ix+02)
   ld (hl),c
   inc hl
   ld (hl),b
   inc hl
.gl1   push bc
   push de
.gl2   ld a,(de)
   ld (hl),a
   inc hl
   inc de
   djnz gl2
   pop de
   ex de,hl
;;   push af
   call &bc26
;;   pop af
   ex de,hl
   pop bc
   dec c
   jr nz,gl1
   ret


.sc1   ld a,&40
   call &bc08
   ret
.sc2   ld a,&c0
   call &bc08
   ret