Log inRegister an accountBrowse CSDbHelp & documentationFacts & StatisticsThe forumsAvailable RSS-feeds on CSDbSupport CSDb Commodore 64 Scene Database
You are not logged in - nap
CSDb User Forums


Forums > C64 Coding > Software sprites....
2006-04-24 10:16
PopMilo

Registered: Mar 2004
Posts: 146
Software sprites....

Does anybody have any expirience with software sprites?
Bobs?

In hires or char mode?

Games I susspect have something to do with software sprites:

Cybernoid for bullets...
Last ninja for masking main character (its not a software sprite, only hardware one masked, to show visibility...)
karnov
Astromarine corps
..,

What is record for these?
 
... 111 posts hidden. Click here to view all posts....
 
2006-04-29 10:44
PopMilo

Registered: Mar 2004
Posts: 146
I know all this... Have made a strategy game once that had all the functions that it needed, but with simple graphics (simple chars...)... It never reached maturity (but will soon!) because it lacked graphics...

This year I made a promisse to make one game for our beloved c64 (last one I finished was in 1992...) and only two requests I set firmly for it are:

1. To be good.
2. To try to use software sprites in combination with hardware ones.

With this said I just can not give up on them. If there is going to be just enough cpu time to make it work with only few sprites, then I shall make a good game that requires only those sprites :) It may not be Turrican or Armalyte but hey... Im not Manfred Trenz and Im doing this out of pure joy :)


2006-04-29 11:20
PopMilo

Registered: Mar 2004
Posts: 146
Technical stuff:

My example

ldx spr0,y
lda shl,x
sta ch0,y
lda shr,x
ldx spr1,y
ora shl,x
sta ch1,y
lda shr,x
sta ch2,y

is OK if sprites are not overlaping with each other or background. But if they are... I need masking

If I want to use one more lookuptable (same as shl,shr, just for masking: like this:
sprite mask
00 11
01 00
10 00
11 00
) to avoid mask for each sprite it gets to complicated... One more index is needed and Im out of registers.. or not?... maybe this:

ldy #15
loop:
ldx spr0,y
lda maskl,x
and ch0,y
ora shl,x
sta ch0,y ;left byte

lda maskr,x
and ch1,y
ora shr,x
sta p ;p is on zero page for speed
ldx spr1,y
lda maskl,x
and p
ora shl,x
sta ch1,y ;middle byte

lda maskr,x
and ch2,y
ora shr,x
sta ch2,y ;right byte

dey
bpl loop

offcourse, background is copied to chars before this...
2006-04-29 14:26
Oswald

Registered: Apr 2002
Posts: 5094
popmilo, I agree with TMR, you're going into a totally wrong direction. Why dont you use the hires-on-multi tech for nicer sprites, and let the vic do the job ? You will never get color clashes right anyway, all you will have is a few sprites sucking up all the cpu power. You will have another of those zillion platformer games, but this time with soft sprites. No one will care.
2006-05-01 07:57
PopMilo

Registered: Mar 2004
Posts: 146
T.M.R. "...deliberately going in and making things difficult for yourself by using software sprites in a situation where the hardware could do it perfectly..."

That is only reason for me wanting to TRY (I just want to try them for god sake :) ).

I dont want to do easy stuff, all easy stuff has already been done...

Hardware can not do it for me perfectly... Maybe satisfactory but not perfectly...

If it is not possible I will use hardware...

It gives me 4 hires on multi sprites with not many colors but with good design it can look good...
Still I think it would be good to use software sprites for bullets and stuff like that... small sprites that dont need colors and are not that cpu or memory intensive...

I need to make a demo and then Ill tell you is it doable or not... and wich is the right path...

Thanks guys!
2006-05-01 09:08
T.M.R
Account closed

Registered: Dec 2001
Posts: 749
"perfectly" != "perfectly well"

That four sprite limit isn't a limit though, look at All Terrain Gardener or Microprose Soccer. Just need a good sprite multiplex.
2006-05-01 10:20
Cruzer

Registered: Dec 2001
Posts: 1048
@popmilo: If software sprites turn you on, go for it. Just beware that the C64 has less CPU power than most other 8-bit systems where software sprites are more common, e.g. Spectrum. So if you insist on the non-preshifted solution, the refresh rate will probably have to be less than each frame. That might look ok for some objects, e.g. an enemy walking slowly back and forth on a platform, but for fast moving stuff like a spaceship flying around it will look ugly.
2006-05-01 22:57
PopMilo

Registered: Mar 2004
Posts: 146
@Cruzer: "Turn me on..." :) You hit the spot... Maybe I do have some stupid affection for software sprites :)

I did a test just to see hom much time these sprites cost...

Eight 24x21 sprites, without masking,without preshifted definitions, using my previously mentioned method (wich means it could be faster) leave me with about 50 raster lines per frame for other stuff .........

Not much... Im not intending to make fastest game in the world so... If I drop animation speed to 25fps I have time for the rest of game code...

I guess I can use masking with same speed if I use preshifted definitions...

Have to expand my test app........
2006-05-02 07:45
WVL

Registered: Mar 2002
Posts: 902
Quote: @Cruzer: "Turn me on..." :) You hit the spot... Maybe I do have some stupid affection for software sprites :)

I did a test just to see hom much time these sprites cost...

Eight 24x21 sprites, without masking,without preshifted definitions, using my previously mentioned method (wich means it could be faster) leave me with about 50 raster lines per frame for other stuff .........

Not much... Im not intending to make fastest game in the world so... If I drop animation speed to 25fps I have time for the rest of game code...

I guess I can use masking with same speed if I use preshifted definitions...

Have to expand my test app........


pinball dreams also uses preshifted sprite definitions for the 3 ball sprites to make the masking quicker. The code is pretty well optimized, so maybe you would want to take a look?

if so, send me a mail and i can send you the more important items of it..

(oh yeah, the masking is based on 8x8 char blocks, and the sprite is max 17x15 pixels (which suited me just fine..)) I think the max width is 17 pixels, or else preshifting will not work. The height can be the max 21 though, if you change the routine a bit.
2006-05-02 09:16
Cruzer

Registered: Dec 2001
Posts: 1048
Isn't the ball in Pinball Dreams just some plain old layered hardware sprites? Any "software" involved in that?
2006-05-02 09:27
WVL

Registered: Mar 2002
Posts: 902
Quote: Isn't the ball in Pinball Dreams just some plain old layered hardware sprites? Any "software" involved in that?


lot of software involved in that! :)

the ball consists of 3 single colored sprites for each of the 3 colors. Sometimes the ball has to go behind objects, so i have to cut pieces out of the sprites. To do this the fastest, i use 24 pre-shifted spritedefinitions (8 images for every color of the ball) which i AND with the mask data. The sprites themselves only move by 8 pixel spacings in x, and every single pixel in y.
Previous - 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 | 13 - Next
RefreshSubscribe to this thread:

You need to be logged in to post in the forum.

Search the forum:
Search   for   in  
All times are CET.
Search CSDb
Advanced
Users Online
Conjuror
leonofsgr/Singular C..
New Design/Excess
ΛΛdZ
CreaMD/React
Andy/AEG
Didi/Laxity
Guests online: 136
Top Demos
1 Next Level  (9.7)
2 13:37  (9.7)
3 Mojo  (9.7)
4 Coma Light 13  (9.6)
5 The Demo Coder  (9.6)
6 Edge of Disgrace  (9.6)
7 What Is The Matrix 2  (9.6)
8 Uncensored  (9.6)
9 Comaland 100%  (9.6)
10 Wonderland XIV  (9.6)
Top onefile Demos
1 No Listen  (9.7)
2 Layers  (9.6)
3 Cubic Dream  (9.6)
4 Party Elk 2  (9.6)
5 Copper Booze  (9.6)
6 X-Mas Demo 2024  (9.5)
7 Dawnfall V1.1  (9.5)
8 Rainbow Connection  (9.5)
9 Onscreen 5k  (9.5)
10 Morph  (9.5)
Top Groups
1 Performers  (9.3)
2 Booze Design  (9.3)
3 Oxyron  (9.3)
4 Censor Design  (9.3)
5 Triad  (9.3)
Top Coders
1 Axis  (9.8)
2 Graham  (9.8)
3 Lft  (9.8)
4 Crossbow  (9.8)
5 HCL  (9.8)

Home - Disclaimer
Copyright © No Name 2001-2024
Page generated in: 0.173 sec.