| |
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?
|
|
| |
Oswald
Registered: Apr 2002
Posts: 5094 |
in the better games bullets are usually made of software sprites ie. characters, which only move in the char grid.
its meaningless to ask whats the record, as the number of achievable soft sprites will vary with definiton. (size, number of color, etc, etc).
As we luckily have sprites, software sprites are rarely used, check my first line for the most cases.
Anyway, your questions are not specifyc enough for good answers. ("Does anybody have any experience with XXXX? YYYY?" Lets assume I do, so what? what do you want to know?) |
| |
Cruzer
Registered: Dec 2001
Posts: 1048 |
Bubble Bobble for bubbles.
Software sprites are also known as bobs.
|
| |
enthusi
Registered: May 2004
Posts: 677 |
personally I always felt like X-Out features ALOT of them |
| |
T.M.R
Account closed
Registered: Dec 2001
Posts: 749 |
Well, Boulder Dash is the obvious first one to mention (everything is soft sprites, showing it's Atari 8-bit heritage there...) and there's some big character-based bullets in Salamander or the Turrican series, the green attackers and men in Dropzone (again, it's from the Atari) are all soft sprites. The nasties in Extreme are char sprites too, but the they only step a char at a time so it's a little rough. One of the IK+ fighters is chars as well (the original International Karate on the Atari uses a mixture of char sprites with hardware sprite underlays to get the colours up).
The short answer is don't use 'em unless you're really desperate and, if at all possible, keep them fast-moving to avoid having to do sub character steps. If you need to go smooth, precalculate the horizontal shifts and preferably the vertical too as far as y'can, that'll help a bit. Oh, and it's a total fucker for CPU overhead! =-) |
| |
Monte Carlos
Registered: Jun 2004
Posts: 359 |
My opinion is, that bobs moving only quantized with the chargrid don't count.
|
| |
T.M.R
Account closed
Registered: Dec 2001
Posts: 749 |
Quote: My opinion is, that bobs moving only quantized with the chargrid don't count.
Well, strictly speaking a "BOB" is a Blitter OBject so the C64 doesn't have 'em at all since there's no blitter. Software sprites can be anything from char-stepping bullets to fully rendered and masked objects on the bitmap. |
| |
pernod
Account closed
Registered: Nov 2004
Posts: 25 |
I could be wrong, but if I remember it correctly Goonies was all multicolor bitmap.
|
| |
cadaver
Registered: Feb 2002
Posts: 1160 |
Also Conan (by Datasoft too), and Karateka. Wings of Fury relies heavily on software sprites too, though not exclusively. |
| |
Graham
Account closed
Registered: Dec 2002
Posts: 990 |
If you are looking for software sprites, look at all the games ported from ZX Spectrum. For example "Fairlight", "Underwurlde" etc etc, there are so many of them. |
| |
cadaver
Registered: Feb 2002
Posts: 1160 |
Underwurlde is interesting. If I remember, it uses sprites for the enemies, and bitmap for the bubbles & rope in the caves, but manages to retain quite high framerate. |
| |
T.M.R
Account closed
Registered: Dec 2001
Posts: 749 |
Doesn't Barbarian write to bitmap as well...? i seem to remember it leaving objects behind sometimes. |
| |
cadaver
Registered: Feb 2002
Posts: 1160 |
Yes, the body (pink & black) of the combatants is bitmap. |
| |
Zyron
Registered: Jan 2002
Posts: 2381 |
Underwurlde is a really good game. |
| |
PopMilo
Registered: Mar 2004
Posts: 146 |
Let me be more specific:
I am not asking about "char sprites" as I would call them - chars put at any of x(0-39),y(0-24) at char screen.
I am interested in real bitmap sprites plotted at any screen coords, 320x200 in hires or 160x200 in multi color.
This can be done in two ways in my opinion:
1. "Spectrum way" - Hires screen, take sprite definition from mem, shift right by (x and 7) in some way, and put it on screen. I know you can optimize this by using pre-shifted data or some other technic like that, and that is what interests me.
2. "Commodore Charset way" - Char screen. Two ways:
- Regular 40x25 char screen, reserve for example 3x3=9 chars for one 2x2 char sprite, in every frame copy appropriate background from screen into this 9char buffer, plot sprite in these 9chars, and put those 9 chars on screen.
- Virtual hires screen made out of chars arranged in vertical columns - this is just a different "Spectrum way", adress calculation is simpler than in normal hires...(but less colors...)
So... Were there any demos that used this kind of software sprites ?
Maybe some sort of dxycp ? Many small 8x8 pixel sprites? |
| |
tecM0
Registered: Jan 2002
Posts: 40 |
i think lemmings on c64 have the most "bobs" :)
T. |
| |
T.M.R
Account closed
Registered: Dec 2001
Posts: 749 |
Quote: i think lemmings on c64 have the most "bobs" :)
T.
Did they claim 50 or 100 i forget...? There are demos pulling more objects at a better speed but Lemmings has a metric fuckload of other considerations it needs to take into account (is the lemming standing on something, should it drop, is it dead). Burglar did about fourty soft sprites in Troddlers too, that's got a very good frame rate.
For demos, DXYCPs are essentially soft sprite routines so they can hammer quite a bit around... i can't think of any "speed record" parts that write to bitmap though, most work into 32x8 or sometimes 40x6 character areas for speed. Fastest way possible is to have all the objects the same, that means they can swap around to do each other's jobs and similar tricks. |
| |
PopMilo
Registered: Mar 2004
Posts: 146 |
Yes Lemmings is good example. I remember reading developers diary. Ill have to check it out.
Screen was pretty narrow as I remember. He used sprites overlayed with char screen or something like that...
|
| |
T.M.R
Account closed
Registered: Dec 2001
Posts: 749 |
Quote: Yes Lemmings is good example. I remember reading developers diary. Ill have to check it out.
Screen was pretty narrow as I remember. He used sprites overlayed with char screen or something like that...
The lemmings themselves are written to a block of character data if memory serves (either that or it's bitmap, been a long time since i looked) and the landscape to sprites. |
| |
Inge
Registered: Nov 2003
Posts: 144 |
Quote: If you are looking for software sprites, look at all the games ported from ZX Spectrum. For example "Fairlight", "Underwurlde" etc etc, there are so many of them.
Dynamite Dan comes to mind, all the monsters are software-sprites. |
| |
tecM0
Registered: Jan 2002
Posts: 40 |
Quote: Yes Lemmings is good example. I remember reading developers diary. Ill have to check it out.
Screen was pretty narrow as I remember. He used sprites overlayed with char screen or something like that...
where can i find the developers diary? wnever seen it before anna read it too! thx a lot!
T.
|
| |
T.M.R
Account closed
Registered: Dec 2001
Posts: 749 |
Quote: where can i find the developers diary? wnever seen it before anna read it too! thx a lot!
T.
http://www.zzap64.co.uk/zzap99/lemmingsdiary1.html |
| |
Burglar
Registered: Dec 2004
Posts: 1101 |
Quote: Did they claim 50 or 100 i forget...? There are demos pulling more objects at a better speed but Lemmings has a metric fuckload of other considerations it needs to take into account (is the lemming standing on something, should it drop, is it dead). Burglar did about fourty soft sprites in Troddlers too, that's got a very good frame rate.
For demos, DXYCPs are essentially soft sprite routines so they can hammer quite a bit around... i can't think of any "speed record" parts that write to bitmap though, most work into 32x8 or sometimes 40x6 character areas for speed. Fastest way possible is to have all the objects the same, that means they can swap around to do each other's jobs and similar tricks.
correct, Troddlers Preview V2, featuring 40 troddlers troddling around on a multicolor hires background, includes proper masking and the like. but the way I wrote it, it's kinda hogging up memory (needs 3 bitmaps in memory, one to remove troddlers from screen and 2 for bankswitching).
lemmings is different, theres no masking, the background is done in sprites, and the lemmings are chars/hires... dont like the spritebackground restriction that much... |
| |
T.M.R
Account closed
Registered: Dec 2001
Posts: 749 |
Well, there's not many ways to do it better than the three bitmaps i'd have thought... although i've only really done soft sprites to character screens m'self (for the Commodore 264 series and Atari 8-bit). i think that, in the case of Lemmings the only other real option would've been to single screen the levels; personally, i'd have preferred that with bitmapping rather than the limited window scrolling but it would've taken a lot more work to re-mangle the levels down i s'pose...
And when did "troddle" become a verb? [Troddles off, looking ponderous... =-] |
| |
PopMilo
Registered: Mar 2004
Posts: 146 |
I know Hires screen is obvious but its slow... Scrolling is very cpu intensive and stuff like that...
Im leaning towards sprites made out of chars, as you said on commodore 264 series..
I know there are games using 5-10 of this kind of sprites on commodore+4, even with scrolling ...
Would not make layers out of hardware sprites like lemmings did ... its to restrictive...
I guess one could make better looking graphics with black monochrome hardware sprite over multicolor software one? As long as they are far enough from each other and background they would be fine... Speed is problem...
I can not fight with the amount of data needeed to be put on screen, so only optimization as I see is in shifting:
1. slowest way is:
sprite to buffer
shift
buffer to screen
2. fastest way:
one out of 8 or 4 (depends if its multicolor) preshifted sprite definitions to screen.
But it eats to much mem...
One could use some sort of cache... ?
3. experiment:
if I make 3 or 4 tables called "left part of shifted byte" with corresponding "right part of shifted byte" that are 256 bytes long tables with values of index shifted 2,4 or 6 pixels. For shift 0 table is not needed but maybe would complicate stuff to much.
so:
put byte from sprite def.first column to x
put byte from sprite def. second column to y
take byte from tableLeft,index1
put on screen
take byte from tableRight,index1
ora with byte from tableleft,index2
put on screen
...?????
This just got to my mind... :) maybe its all bollocks :)
Will check troddlers and dinamite dan... |
| |
Oswald
Registered: Apr 2002
Posts: 5094 |
Burglar, you write: "multicolor hires" hmm what screenmode is multicolor lowres then ?:D |
| |
Steppe
Registered: Jan 2002
Posts: 1510 |
Oswald, are you talking about 8x8 FLI? Blocky, yet colourful! :D |
| |
Burglar
Registered: Dec 2004
Posts: 1101 |
Quote: Burglar, you write: "multicolor hires" hmm what screenmode is multicolor lowres then ?:D
errr, multicolor bitmap ;) |
| |
TDJ
Registered: Dec 2001
Posts: 1879 |
Quote: errr, multicolor bitmap ;)
Used to make the same mistake: always called bitmap screens 'hires pictures', even did a 'flashing hires scroll' once (which was actually a flashing bitmap scroll, ugly as hell and replaced by a version Compyx did for Not Worthy, but who cares). |
| |
PopMilo
Registered: Mar 2004
Posts: 146 |
So:
Does anyone know fastest way to plot an 8x8 or 16x16 pixel sprite anywhere on some sort of "bitmap" screen ? (colors are not important right now) without 4 preshifted definitions for multicolor sprite... |
| |
cadaver
Registered: Feb 2002
Posts: 1160 |
You could use a generic lookuptable for all possible shifts of all 256 possible data bytes? That'll waste initially more memory, but wins once you have a lot of animation frames..
If that's not OK, then shift manually.. |
| |
Cruzer
Registered: Dec 2001
Posts: 1048 |
There's no way of plotting bobs fast if they're not pre-shifted. So choose some small objects with not too many anim frames for bobs, and use sprites for the ones with many frames. |
| |
Oswald
Registered: Apr 2002
Posts: 5094 |
cadaver, a 256 byte table would only work for 8 pixel wide objects.
popmillo there's no ultimate fastest way, it all depends on what you want to do.
check tower power / camelot which has IMHO the best done hires 8x8 bobs. (maybe not the fastest but hundreds of bobs without music in a sine to make a world record is boring).
anyhow the fastest way is to have predefined speedcodes for each shifted version of the object, and use hires mode, so u only have to do ORAs, multicolor is atleast twice as slow.
fastest one should look like:
lda #preshiftedshape
ora screen,y
sta screem,y
where Y holds your Y coord. Also its a good idea not to clear the entire screen, but only the bobs which were drawn. |
| |
cadaver
Registered: Feb 2002
Posts: 1160 |
Oswald: naturally results from adjacent data bytes would have to be combined. In addition with masking, this would not be so hot either, yes :) |
| |
PopMilo
Registered: Mar 2004
Posts: 146 |
If:
Sprite is defined in two columns (16 bytes a column) (where address of spr1= spr0+16) like this:
spr0 spr1
---------
xxxx xxxx
xxxx xxxx
xxxx xxxx
xxxx xxxx
...
And Character buffer 3x3 chars is in three columns (24 bytes each) like this
ch0 ch1 ch2
---------------
xxxx xxxx xxxx
...
which is:
char0 char3 char6
char1 char4 char7
char2 char5 char8
And there are two tables of 256 bytes. Each is representing left part (table "shl") and right part ("shr") of shifted byte
example:
for index 255, and case where desired shift is 2 bits
(shl+255) (shl+255)
00111111 11000000
(there would be 3 tables for each shift, for shift 2,4,6...) shift zero is special case, and I think it would be good to make separate routine for those cases... Its simple copy in that case.
-----------------
Would this be ok?
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
offcourse, ch0,1,2 would be address of char0,1,2 +(sprite.y and 7) before calling this routine |
| |
Oswald
Registered: Apr 2002
Posts: 5094 |
looks correct.
is this for some game project? |
| |
PopMilo
Registered: Mar 2004
Posts: 146 |
Well... I'm thinking how to improve graphics a bit...
I thought if I combine software and hardware sprites, I can make pretty nice graphics...
Always wanted to do some cool platform game. Imagine game like creatures but if every sprite was with additional black hires layer. Something like Rick in Rick dangerous...
p.s. And then make a game like Turrican with this graphic :)
or some shooter.... |
| |
cadaver
Registered: Feb 2002
Posts: 1160 |
Hmm, would this require bitmap mode and AGSP scrolling to be usable? I mean, Bubble Bobble gets away with the bubbles, because each level's graphics require only a couple of different chars. But for something Turrican-like you need a fairly large charset. Even taking away 64 chars can make the charset too simplistic/crap looking (I know for doing it in MW1 & 4 :)) |
| |
T.M.R
Account closed
Registered: Dec 2001
Posts: 749 |
Don't forget the CPU overhead of hammering in all those software sprites, Turrican moves a lot of stuff around! |
| |
PopMilo
Registered: Mar 2004
Posts: 146 |
Quote: Don't forget the CPU overhead of hammering in all those software sprites, Turrican moves a lot of stuff around!
Ok :)
I'm know I can not even come close to Turrican when level size, speed and bunch of stuff its doing is considered...
If I would make a hero jump around, shoot some bulletts at some nicely drawn nasties, and if they are little harder to kill then in Turrican maybe it would be interesting enough to play for a while...
And maybe its just because nobody done this before.. (correct me if I'm wrong)
I havent tought about scrolling yet. I know it would be nice.
If I try these software sprites in char mode:
They are faster, scrolling is easyer but less colors, less background details...
If I try these software sprites in bitmap mode:
Slower, tough scrolling (I know Stormlord and Fred's back did it) but much more color, and so, so many more details...
Hope Ill have time next few days to come up with some demo...
|
| |
PopMilo
Registered: Mar 2004
Posts: 146 |
@ T.M.R.
By the way, I think I red your posts on Atari forum about scrolling and sprites ?
Maybe there is some interesting stuff in those Atari routines ?
I just found this thread:
http://www.atariage.com/forums/index.php?showtopic=66811&hl=spr..
looks interesting... |
| |
T.M.R
Account closed
Registered: Dec 2001
Posts: 749 |
i've been involved in a few discussions on Atari Age yeah; a lot of the time it's been me saying "it's not possible to do X and Y at the same time" and everyone else saying it can be done but not producing sample code... =-)
|
| |
Oswald
Registered: Apr 2002
Posts: 5094 |
what platformers never really did good on c64 IMHO:
pixel based height handling: the main character should be able to run up / slide down on slopes, instead of having to jump to get over a 1 pixel high obstacle, because its "one char" higher.
GOOD physics, accelerating - slowing down/sliding down on slopes, speed decreases when running up on a slope, _really_ smooth jump acc/decc.
ability to jump up to walls (zool/amiga)
really good controllable character instead of the usual feeling of 2 bit accuracy at speed/collision handling.
If I would have plenty of time, and mad coding mood, I would make a platformer like zool on amiga. I'd go for a char screen and AGSP. So I dont loose out speed with screen scrolling, but still have the advantage of a character screen:bullets/powerups/changing scenery/etc made of chars.
popmillo: IMHO you should rather concentrate on gameplay than gfx, check the best platformers on 16 bit machines, and adapt the good ideas. |
| |
T.M.R
Account closed
Registered: Dec 2001
Posts: 749 |
Mayhem In Monsterland does a lot of what you said, Oswald - except it's a VSP scroller since it's only bi-directional.
Totally agreed about the playability issue of course, there's zero point in having a nice looking game that doesn't play well and there never will be... that's where some of the discussions on Atari Age have fallen down, people wanting to cripple the game's overall design to put more colours in or use some new trick for the graphics. |
| |
Oswald
Registered: Apr 2002
Posts: 5094 |
tmr: I know, but only sideways scrolling ahem... :P also the gameplay is boring.
I repeat, check platformers on 16 bitters from the 90s, with todays knowledge we could copy most of that stuff. |
| |
cadaver
Registered: Feb 2002
Posts: 1160 |
What would you do to the sprite frame pointers becoming visible in char mode & AGSP scrolling? In bitmap mode you'd just get some flashing, but now we're talking about actual garbage..
(If there was no multiplexing and sprite pointers would always be the same, for example 248-255 [when copying/depacking sprites in realtime], it would be trivial to copy the correct chars to that place in the charset, but the question is would you settle for no multiplexing?) |
| |
Oswald
Registered: Apr 2002
Posts: 5094 |
make the chars same color as the background. |
| |
T.M.R
Account closed
Registered: Dec 2001
Posts: 749 |
Personally, i like MiM but i'm the first to admit i'm not a platform game fan as such... |
| |
PopMilo
Registered: Mar 2004
Posts: 146 |
If I would sum up good values from all platform games I played, this is what would be most interesting in my opinion:
1. Turrican
- Big levels
- Big bosses
- different weapons, powerups
2. Creatures
- Cute graphics
- Funny jokes
- different weapons
3. Flimbo's quest
- Dual plane scroll
- different weapons
- cute graphics
4. Rick Dangerous
- Big levels
- Cute graphics
5. Cyberdine warrior
- Big levels
- graphics
.... and many more
So, if I would take the best out of these games:
different weapons, power ups, cute graphics (including dual plane scroll), big levels, big bosses, jokes...
What is a must for a good game then?
I must say this. I have been reading routines for software sprites on ZX and Amstrad for decades, and never saw it done properly on C64. I want to try it. Want to see, is it possible on c64. I think graphics would benefit from it enough.
So, I want to use software sprites to make hero and monsters look better. I dont think I can do dual plane scroll... Its just too much...
Big levels can be done even with non-scrolling screen (take dizzy, draconus, impossible mission for example)
Jokes are not hardware hungry :)
Weapons and power ups? Massive, multi bullet style weapons are demanding...(char screen comes handy). Maybe make some clever weapons that are simple to animate but interesting enough. I love cyberdine warriors rifle.. Its great, you have feeling of acctually shooting a good gun, and it requires almost no animation at all (kinda like a rifle in Alien Breed on Amiga).
Big Bosses? Easier in charmode. Maybe can be done in bitmap too... Not so important now...
I think best is to try and see. Ill make a demo with char mode sprites, and one with bitmap mode sprites... Test it and then, celebrate or cry :)
p.s. And the best platform game in my opinion: "Ruff'n'tumbble" Amiga... :) Something like that would be fun...
|
| |
T.M.R
Account closed
Registered: Dec 2001
Posts: 749 |
"What is a must for a good game then?"
It has to be playable. Doesn't matter how that's achieved, how technically advanced or otherwise the code, how unusual the tricks used or how good the graphics...
|
| |
PopMilo
Registered: Mar 2004
Posts: 146 |
Ok. I'll try to make a playable game that uses some sort of software sprites :)
|
| |
T.M.R
Account closed
Registered: Dec 2001
Posts: 749 |
To be honest, you should only be using software sprites if they're a necessity to the game and the hardware is going to struggle; something like Lemmings or Troddlers being a prime example of that. Writing a game is a major undertaking (more major than many people believe) so deliberately going in and making things difficult for yourself by using software sprites in a situation where the hardware could do it perfectly well isn't the best approach to things.
i made that mistake when porting my game Reaxion to the Atari 8-bit, a relatively simple puzzler had a nine month development cycle because i didn't want to take the obvious route of having four hardware sprites for the player and only four colours on the rest of the graphics... the result was three character sets used for the background and a software/hardware sprite combination that had to work over those three character sets and therefore ate large chunks of available CPU power up! |
| |
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 :)
|
| |
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... |
| |
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. |
| |
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! |
| |
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. |
| |
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. |
| |
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........ |
| |
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. |
| |
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?
|
| |
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. |
| |
Cruzer
Registered: Dec 2001
Posts: 1048 |
IC, hadn't thought of the clipping. |
| |
PopMilo
Registered: Mar 2004
Posts: 146 |
@ WVL: "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?"
I have that dev package... Have already looked in there but its huge. Maybe you could give me some pointers where to look ? |
| |
WVL
Registered: Mar 2002
Posts: 902 |
Quote: @ WVL: "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?"
I have that dev package... Have already looked in there but its huge. Maybe you could give me some pointers where to look ?
the routine you need is called 'calcclippedsprite' and is inside MAIN.txt in the /sources/ directory.
the first bit of the routine fetches pointers to the chars containing the mask data (which is rle-ed in the memory), from 'clipoffset' is the loop that does the ANDing.. i've chosen for some smart way i only need to AND with the mask data once (my sprite data is set up in such a way, check it out)
clipoffset ldx #0
cliploop
spritea1 lda $1000,y //fetch correct sprite byte
char1 and $1000,x //mask data!
point1a sta spriteimage,y //store 1st byte sprite0
spriteb1 and $1000,y //and with 2nd spriteimg
point2a sta spriteimage2,y //store 1st byte sprite2
spritec1 and $1000,y //and with 3rd spriteimg
point3a sta spriteimage3,y //store 1st byte sprite3
dey
spritea2 lda $1000,y //the same, but for
char2 and $1000,x //the 2nd byte in the
point1b sta spriteimage,y //sprites
spriteb2 and $1000,y
point2b sta spriteimage2,y
spritec2 and $1000,y
point3b sta spriteimage3,y
dey
spritea3 lda $1000,y //3rd byte
char3 and $1000,x
point1c sta spriteimage,y
spriteb3 and $1000,y
point2c sta spriteimage2,y
beq point3c
spritec3 and $1000,y
point3c sta spriteimage3,y
after this is the loop condition, which is a bit awkward. It checks for all rows done (15 of them) and if the maskdata goes past any 8-pixel boundarys (if so, the char1/char2/char3 pointers get an update!)
|
| |
PopMilo
Registered: Mar 2004
Posts: 146 |
thanks! will take some time to analyse it...
First I want to finish kind of a framework for my test app... making lookup tables, sinuses, double buffering stuff like that... so I could test different aproaches more easily... |
| |
PopMilo
Registered: Mar 2004
Posts: 146 |
Am making progress but nothing to show yet.... will be soon...
But. I found this:
http://plus4.emucamp.com/forum.php?postid=10459
A game for plus4 with software sprites, with masking and speed...
It looks very interesting:
Quote: "...It only generates the sprite in that rotation when its about to draw it. So if a sprite is animating, and moving, theres a good chance that some frames won't ever be rotated.
Also the cache allows sprites that are used a lot to stay inside the cache, while ones that aren't drift to the top of the list.
So yes. Rotate on demand, but demand is mesured per-rotation and no per-sprite. (i.e. I dont do 4 rotations for a sprite, just the one it needs right now)..."
Cache for mostly used rotations? Excellent idea!
|
| |
T.M.R
Account closed
Registered: Dec 2001
Posts: 749 |
Things to remember about Xeo3:
1) Mike Dailly used to work for DMA Design, wrote Blood Money on the C64 and seriously knows what he's doing.
2) The 264 series have a higher overall clock speed than the C64, at least 1.5 times the grunt to shift stuff around if memory serves. |
| |
PopMilo
Registered: Mar 2004
Posts: 146 |
Quote: Things to remember about Xeo3:
1) Mike Dailly used to work for DMA Design, wrote Blood Money on the C64 and seriously knows what he's doing.
2) The 264 series have a higher overall clock speed than the C64, at least 1.5 times the grunt to shift stuff around if memory serves.
I know he is pro... :)
I didnt like blood money that much :)
I know he knows what he's doing :)
I know I began programming 6510 back in 1986. Never stopped since. I make programs for living. Have done some pretty intensive shit on DSP's and microcontrollers. I want to take c64 to its limits :)
And I love software sprites :)
Next week Im releasing my demo with software sprites, I hope... :) |
| |
Honesty
Registered: Jan 2003
Posts: 121 |
Good luck then... :))
|
| |
T.M.R
Account closed
Registered: Dec 2001
Posts: 749 |
"Next week Im releasing my demo with software sprites, I hope..."
That's a very long week...? |
| |
PopMilo
Registered: Mar 2004
Posts: 146 |
Sorry man.... :(
My parents got ill ... I wasnt able to work on it as much as I thought...
But I'm Ok and am working on it as much as I can!
I got seven 24x21 pixel software sprites moving around at 50 fps! Its murphys law I guess :) Why isnt it 8 ? I miss just a few raster lines to make it 8 sprites... But I think it can be optimized enough to squeeze in 1 more....
But it will be difficult to do anything else in the few remaining lines... :(
But! since this is all without preshifted sprite definitions I am prety satisfied... :)
Ill try to put something together for this evening for you to see it in all of its glory! :) |
| |
PopMilo
Registered: Mar 2004
Posts: 146 |
http://noname.c64.org/csdb/release/index.php?id=34110
There it is... :)
Not much... just a basic v0.1 routine rapped up with setup and loop...
No doublebuffering therefore the flickering... will be repaired in v0.2 :)
|
| |
Burglar
Registered: Dec 2004
Posts: 1101 |
question is, does it ORA or not? |
| |
Oswald
Registered: Apr 2002
Posts: 5094 |
does not, it plots characters onto the screen, then copyes the sprite image into the chars. (from what I've seen).
looks slow to me. :-| Consider using the cache idea I've read on the plus4 forum mentioned here, might save you in the game if you have no memory to preshift. if you have memory you should preshift the shit outta it. |
| |
Bizzmo
Account closed
Registered: Mar 2005
Posts: 82 |
Talking about "preshifting the shit outta it" - this is something that I was playing with a long long time ago...
http://www.dougroberts.co.uk/bizzmo/demos/rotation_bizz.prg |
| |
WVL
Registered: Mar 2002
Posts: 902 |
Quote: Talking about "preshifting the shit outta it" - this is something that I was playing with a long long time ago...
http://www.dougroberts.co.uk/bizzmo/demos/rotation_bizz.prg
another good reason you should not do software sprites :D (in multicolor mode anyway) yuck!!! 2-pixel res in the x-movement looks really sucky here, the only way to disguise it is to move faster!
popmilo : your example is a good example why NOT to do software sprites.. 7 lousy sprites eating up all the rastertime... maybe you can do 1 behind the main character or something else, like the bullets, but this simple is not the way to go IMO.. |
| |
Bizzmo
Account closed
Registered: Mar 2005
Posts: 82 |
WVL: Yep, the 2x resolution issue is nasty! :-)
Personally, I feel that software sprite are not going to bethat practical for anthing more than bullets and missiles... |
| |
cadaver
Registered: Feb 2002
Posts: 1160 |
Most Ocean games got along fine with 2-pixel sprite move X-resolution (it was embedded in the multiplexer code, to represent X-position with one byte only)
Also in MW4 :) |
| |
Bizzmo
Account closed
Registered: Mar 2005
Posts: 82 |
(I must also confess that some of the jerky movement could be put down to my sin tables.... ahem) |
| |
cadaver
Registered: Feb 2002
Posts: 1160 |
Yes.. pure sinus movement will likely be ugly with 2x resolution, so you're right there, but often in games you're trying to frantically stay alive and not think of that :) |
| |
Graham
Account closed
Registered: Dec 2002
Posts: 990 |
Most Ocean games were crap :P |
| |
Oswald
Registered: Apr 2002
Posts: 5094 |
wvl, imho the prob is rather with the sines as bizz puts it.
I'm still against the general scene idea that beauty is in hires pixels and 50hz, no, the beauty is in your creativity :P :) |
| |
PopMilo
Registered: Mar 2004
Posts: 146 |
Ok guys... You do realize this is just an experiment to practice rusty grey cells :)
But... after this experiment it looks like I should try the cache thing with preshifted sprites...
And there is still bitmap screen sprites to test...
|
| |
MikeD
Account closed
Registered: Jan 2006
Posts: 19 |
I know it was a while back now... but how did you get on with this? Software sprites have their place - even if its to allow you to stop HW sprite glitching by doing an offending one in software.... |
| |
Radiant
Registered: Sep 2004
Posts: 639 |
I can't believe nobody has mentioned the noter to Irrational yet. :-) |
| |
MikeD
Account closed
Registered: Jan 2006
Posts: 19 |
Nice subtle effect. I have to say if someone managed to make say 7 or 8 extra sprites using software, it could change the nature of a (say) a shoot-em-up. You might not need a multiplexor. Being able to have 15-16 sprites in a row would change how a game flowed... Even if they were only 16x16's, could be interesting....
|
| |
Oswald
Registered: Apr 2002
Posts: 5094 |
multiplexers are and will always be much cheaper than software sprites. one of the key elements to the c64's success were the hardware sprites, overlooking their importance is unforgiveable. |
| |
Danzig
Registered: Jun 2002
Posts: 440 |
@Oswald: reminds me of some software-sprite-routine on pc i faced at the party 94 that, after running stable for some minutes, started NOT to clear and replace the background... *lol*
fun to watch, looked little like unlimited bobs :D
on actual windows pcs, sprites are done with GPU power! (what makes it kindalike hardware ;) ) dont forget!
|
| |
chatGPZ
Registered: Dec 2001
Posts: 11386 |
Quote:on actual windows pcs, sprites are done with GPU power! (what makes it kindalike hardware ;) ) dont forget!
many VGA cards actually have one "real" sprite - typically used for the mousepointer =) |
| |
MikeD
Account closed
Registered: Jan 2006
Posts: 19 |
Oswald: I didn't say they weren't important, I just said that using software sprites on top of the normal ones gives games a certain advantage. And if you have 16 "objects" running around, you might not need it - depending on the game.
No matter how good you are, your not going to get 16 sprites in a line without using some sort of software sprite, and in games being able to do that would help a great deal. I'm all for using hardware to get the best from a machine, but depending on the game you might need a different approach. You shouldn't fixate on using hardware sprites only, or you miss all kinds of opportunities.
|
| |
Sasq
Registered: Apr 2004
Posts: 156 |
As far as I can tell noone has mentioned the classic trick for making really fast software sprites; converting the bitmap to machine code.
You basically RLE-pack your graphics into code that draws itself. It's faster than any other soloution but clipping is tricky.
EDIT:
... hmm but that is probably not so good on the 6502 since you need relative adressing for that to work... |
| |
Oswald
Registered: Apr 2002
Posts: 5094 |
code that draws itself? huh? :) |
| |
T.M.R
Account closed
Registered: Dec 2001
Posts: 749 |
Yeah, fairly common on the Z80-based platforms - seen that called "compiled sprites" before now. |
| |
Radiant
Registered: Sep 2004
Posts: 639 |
@T.M.R: It's generally the way to go for software "blitting" on more modern platforms as well. Not on 6502 though. |
| |
Oswald
Registered: Apr 2002
Posts: 5094 |
well lda sta lda sta lda sta code is not a new innovation. |
| |
PopMilo
Registered: Mar 2004
Posts: 146 |
Quote: I can't believe nobody has mentioned the noter to Irrational yet. :-)
Why "Irrational" ?
Because of the name? :)
|
| |
PopMilo
Registered: Mar 2004
Posts: 146 |
@Miked
Yes I made some more experiments but nothing great...
Im thinking about two aproaches:
1. To use software sprites made out of black chars for overlaying multicolor hardware sprites to get that "hires look" with colors... (They would have to be over blank areas of screen, rest of the background would be multicolor chars, scroll is easy to acomplish in this aproach)
or
2. To use multicolor soft sprites in graphic mode, overlayed on top with black hires hard sprites... but...but no scrolling because of the amount of data that would need to be moved.
I plan to try them and see what comes out of this...
Since Im planing a platform game, Im thinking maybe charmode sprites wouldnt be bad for a spray of bullets and some spectacular weapons made out of many small 2x2 char soft sprites (I really disslike those 8 pixel moving bulletts in many commodore games (even in my favourite "Turrican")
p.s. Great work on Xeo3, your blog is first thing to look at during morning coffe :) |
| |
T.M.R
Account closed
Registered: Dec 2001
Posts: 749 |
Quote: Why "Irrational" ?
Because of the name? :)
Count the sprites on the note part... =-) |
| |
MikeD
Account closed
Registered: Jan 2006
Posts: 19 |
popmilo: I would also consider just adding more sprites so you can get rid of the the 8 sprites in a row limit - but this would depend on the game. I do like the idea of using them along with normal sprites to get a HIRES colour effect though.
You could use that delayed DMA thing to scroll the bitmap if you really wanted to - although I've heard its a bit unstable.
How many have you managed to get running?
|
| |
Cruzer
Registered: Dec 2001
Posts: 1048 |
Bubble Bobble is a good example of software sprites that are not just the usual shots moving 8 pixels per frame. This clearly would have been no success with only a multiplexor. |
| |
algorithm
Registered: May 2002
Posts: 705 |
many methods of speeding up the software sprite plotting. precalculated pixel shifts of the main character, etc, then only something such as ora opcodes, etc |
| |
PopMilo
Registered: Mar 2004
Posts: 146 |
@MikeD: I mannaged to get 7 x 24x21 freely movable sprites with no predefined rotations in 50 fps (but with only 10 raster lines left free... :( ). And then I tried sprites with preshifted definitions (4 of them for every sprite) (aproximately 33% faster routine) and 8 is easy doable in this way.
Since Im planning platform game Im thinking to use this method because game objects would mainly walk on platforms or such. So I have to make animation frames for them anyway - and I can limit the movements to "steps". enemy robot similar to some kind of "walker" on two legs could walk in steps, and guess what? Those steps would be 4 pixels each :)
Same goes for flying objects and any other - they all need animation to look nice, so I just have to make those animations compatible with char boundaries...
p.s. Here is a draft of my main character :)
|
| |
HCL
Registered: Feb 2003
Posts: 728 |
COol. He's got a big.. whatever. |
| |
Cruzer
Registered: Dec 2001
Posts: 1048 |
Starts to sound/look promising. Please add a preview soon. |
| |
MikeD
Account closed
Registered: Jan 2006
Posts: 19 |
Sounding pretty cool! When your not pre-shifting them, how do you go about rotating them?
Are they hires or multicolour? |
| |
PopMilo
Registered: Mar 2004
Posts: 146 |
@MikeD:
I use tables for each rotation, 256 bytes each (3 tables, no need for table if shift=0)
its all in previous post (35#)
Im using black hires software sprites over multicolor hardware sprites (this way I get to choose from 16 colors for each sprite, if I used chars for multicolored sprites I would have only first 8 colors...)
|
| |
MikeD
Account closed
Registered: Jan 2006
Posts: 19 |
Ah...cool. That also means you just ORA the data in I guess, which would help quite a bit. Good idea.
Oh...I see, a table for each rotation. Mmm..I guess I have that too, I have a barrel shifter which rotates "X" pixels...so yeah. Just a slightly different way of looking at it.
Good though, nice and big as well. |
| |
Hein
Registered: Apr 2004
Posts: 954 |
Zone Ranger has some cool software sprites, not too smooth, but very fast.. Zone Ranger |
| |
PopMilo
Registered: Mar 2004
Posts: 146 |
Quote: Ah...cool. That also means you just ORA the data in I guess, which would help quite a bit. Good idea.
Oh...I see, a table for each rotation. Mmm..I guess I have that too, I have a barrel shifter which rotates "X" pixels...so yeah. Just a slightly different way of looking at it.
Good though, nice and big as well.
Well... :) I dont even ora with back :) I just sta.
All the backgrounds are empty... Light blue for outside spaces, and black for underground. And if there are details in the background like colums and wall sections, they are infront of sprites (like in DanDare), or some kind of fence wich is black also appears infront of sprites. This ofcourse needs masking so not much of this on one screen because its cpu intensive...
Mike: what do you mean with "barrelshifter"? I know how they work in hardware but wouldnt they be slow in software? Do you have a routine to ror part of mem? is it faster than my method? Hmmm.... Ill have to do some calculations... :) |
| |
JackAsser
Registered: Jun 2002
Posts: 2014 |
Any previews popmilo? |
| |
tlr
Registered: Sep 2003
Posts: 1790 |
Quote: Zone Ranger has some cool software sprites, not too smooth, but very fast.. Zone Ranger
Hadn't seen that one. Great! |
| |
MikeD
Account closed
Registered: Jan 2006
Posts: 19 |
Err....but what happens when 2 sprites cross? If you just STA, then you lose the sprite underneath?!?! I don't quite follow you - unless you're masking some other way perhaps?
Yes, the barrel shifter is a small routine that will rotate any sprite by "N" pixels. Its pretty much the same as your tables. I have 8 tables for MCM and 16 for Hires. 1 is the remainer, and 1 overflow, and then have this "n" times. Although yes, I could do a "0" special case.
All this does is rotate one column into the next and then stores the remainer in the overflow column. here it is...
ldy #15
RotateALL
SrcColumn1 lax $0101,y
BarrelShift1 lda Table1,x
DataDest1 sta $0101,y
BarrelShiftO1 lda Table1+256,x
sta Column2+1
; Now do Column 2
SrcColumn2 lax $0101,y
BarrelShift2 lda Table1,x
Column2 ora #$00
DataDest2 sta $0101,y
BarrelShiftO2 lda Table1+256,x
DataDest3 sta $0101,y
dey
bpl RotateALL
A barrel shifter is simply a function (of hardware or software) that takes the same time to rotate 1 as it does any other number. This routine does that - probably exactly the same way as yours does. More effort actually goes into caching the thing rather than rotating it!
|
| |
Oswald
Registered: Apr 2002
Posts: 5094 |
why dont you use good ol' brute force ?
lda screen,x
and #spritemask
ora #spritedaza
sta screen,x |
| |
MikeD
Account closed
Registered: Jan 2006
Posts: 19 |
Because this isn't from a demo, its game code. And the game has 167 16x16 sprites. Demo's can afford the space for a couple of sprite shapes - games can't :) |
| |
Oswald
Registered: Apr 2002
Posts: 5094 |
167 is a lot :) |
| |
Luca
Registered: Apr 2002
Posts: 178 |
Boooo-hooo! :_(
Months ago, I tried myself to have a nice softprites routine too, with animated bubbles that run in vertical+sin(x). Due to the amount of the bubbles (5) I used doublebuffering, but bubbles #4 and #5 disappear before they reach the top of the screen, although I'm quite sure the dblbuffer works good! Frustrated, I paused that stuff...and I'm soooooo saaaaaad cause of that! |
| |
Cruzer
Registered: Dec 2001
Posts: 1048 |
@Luca: Definitely sounds like it's not safe to conclude that your double buffer works. Testing all the things you're 100% sure works is the way to debug when you can't find the error. |
| |
Luca
Registered: Apr 2002
Posts: 178 |
Quote: @Luca: Definitely sounds like it's not safe to conclude that your double buffer works. Testing all the things you're 100% sure works is the way to debug when you can't find the error.
Yes, you're right. I had a long debugging time, then I lost hopes, also because of the bad ordered code I wrote. Probably it's time to get back to it, after a period of calm. |
| |
PopMilo
Registered: Mar 2004
Posts: 146 |
@MikeD:
Sprites do not cross :)
Its supposed to be arcade game, if you touch some object it can explode, dissapear, you picked it up, or it just blocks your movement...
Since my frontal layer is hires black there are no color clashes even if two sprites overlap (In that case I just have to use simple masking routine).
Char sprites -> hires black->masking routine
Hardware sprites -> multicolor (3 colors) -> dont have to do masking, they have priorities-just have to synchronize hardware priorities with software routine.
Offcourse I need mask definition for each frame, so it takes more memory, and more cputime, so I think Ill try to avoid overlaping.
And also chars in front (scenary) will have rectangular shapes (like chars) to make masking simple (dont draw char on screen if there is something infront, and mask hardware sprites if nececery with simple "erase 8x8 pixel block" in sprite.
And to answer JackAsser "Any previews popmilo?":
Currently Im busy with my own pc "hires over multi sprite editor" with keyboard controls (like in c128 built in sprdef)- old habbits die hard :)
So when I make at least one complete animation of my hero walking, Ill let it out :)
So far, I have only sprites flying around, and there is so much more in a game that needs a lot of thinking...
Ill take it step by step...
Ohhh... I just realized how big this post is :) Maybe I should make a blog out of this :)
|
| |
MikeD
Account closed
Registered: Jan 2006
Posts: 19 |
Err... What about baddie to baddie? Dont you get that at all? If its Hires only, do you really need a MASK?
Is it hires in MCM? I use an automask so I dont need to store one.
lax (Temp+18),y ; 5*
lda (Temp+2),y ; 5
and MCMAutoMask,x ; 4
ora (Temp+18),y ; 5*
sta (Addr),y ; 6
dey ; 2 = 27 (with 7 sprites=14,616 cycles)
Little longer, but saves loads of memory - and rotation time. |
| |
PopMilo
Registered: Mar 2004
Posts: 146 |
They say one picture describes more than a thousand words:
Here is two sprites decomposed to its hires-char part and its multicolor-hardware-sprite (background is black just to see those grey colors clearly):
Here are those two overlaped:
The multicolored part is simply two hardware sprites and there is no problem moving them around, one over each other.
The hires part looks like this:
These are two black hires sprites made out of dedicated characters, so if they overlap I have to use masking for them (at least for one that comes on top).
I draw the bottom one, then I draw the top one using data from the first one as the background, mask it with sprite mask, and ora it with sprite data...
Automask is a great idea, and I would use it if the multicolored sprites would be software ones (in case I use bitmap and not charmode screen, but because of speed, Im sticking to a charmode sprites for now) |
