Crazyace

That's very cool - looking forward to Warbirds even more though

I'd forgotten about Flak - it totally blew Xevious out of the water ( on the 8bit/5200 at least )

TI had the same chip as the coleco ... but there are lots of games on the 2600 that reuse the players... ( well, pretty much any game more complex than combat )

Wasn't sprite multiplexing in common use on the 2600 - way before any definition on the c64 ... ( I think also that the Colecovision or Intellivision had a sprite multiplexor in the OS rom... cant remember which )

How would the picture look on a normal machine?

Ah - makes sense ( also there's no animation ) - still seems quite expensive - I think that main sprite is 24 pixels high - so you need 24 copies for 1 line vertical movement - PMBASE has to be 2K aligned... so you've swallowed 48k of ram ( with 18k 'spare' in gaps ) and when you mirror the sprite you need to rewrite all the 24 PM definitions. I'd just use the old fashioned method

Btw, good example of the sprite system: A8: uses all players and all missiles for those 3 sprites. Cannot use 3rd OR color due to one color being black so bruce and the fat guy have to use 2 colors only. C64: sprite system is heavily underused. 3 of the 8 sprites are used, in those 3 sprites not even 3 colors or full size are used. But Atari could have used the 3rd OR color if they had slightly adjusted the luminance of the knight to say 2 or 4 instead of pitch black knight. Perhaps, they were porting from some other version or planning for another platform. I dont think that would have been possible for Bruce Lee - as the sprites were up to 16 pixels wide during kicks - if the players were multicolour then it might have shown more. Actually I think , with a little effort, that the ninja could have been improved - by changing the widths of the 4 missiles that made him. This is more a matter of semantics than anything; since what you're describing as a multicolour sprite istill isn't a single entity and has two X registers for the seperate parts, it's still two sprites as far as the hardware is concerned. ... That's your speculation. Ever heard of bitplanes vs. chunky mode. On amiga the bitplanes each have their separate addresses so you can have two X registers and still have one multicolor sprite. There's bit 5 of register 53275 which specifically states "Enable Mulitiple Color Players". >No, you've got to show that, in order to match the totally arbitary selection of colours the C64 has, you can do the same thing; otherwise the claim about three unique colours per multicolour sprite has a huge "but". Even if you give the ORed color less than 1.0 color value but greater than 0.0 (obviously), you still get more colors on two Atari multicolor sprites. Also, the fact that the two planes of the multicolor sprites have their own x-register gives you the option of slightly shifting them to increase their width. >At which point block copying kicks in yes? So in these worst cases, how much faster than my suggestion does your method go if you include the bounds checking to see when things need copying? You don't need to do the bounds check in the sprite renderer as that would be running at 16*60 Hz (for up to 32 multicolor sprites as in the current implementation). You can check the bounds when setting the virtualY position. Also copying does not necessarily have to be done in a zone conflict. You have several other options including (1) interleave it with VBLank so it renders at 30Hz [on NTSC], (2) Not to render it (so it disappears in that zone), (3) Use Grafn to fix DMAd data for 2nd sprite. Even if you copy data, it'll be done < 1/8 of the time [avg] as when doing normal Y positioning. >That's the thing... we weren't just moving things in Y, it was about matching facilities; yes, your method works ten times faster than mine but it apparently doesn't replicate the other features. I don't think your original post asked for animating it, but you can still use a similar solution-- either increase memory useage (if available) or decrease the PMBase table size so copying occurrence would increase but give you more memory. I'm still hazy on how cycling PMBASE helps to move multiple sprites - if I'm using paired sprites I have at least 2 objects moving independantly each frame. Cycling PMBASE only helps if they move in sync - which isn't a common game situation.

I'm using softsprites for my pacman demo - the aim is to have no flicker at all. ( I really hate flicker, even on 2600 games - where it's almost a staple diet for games )

That's why threads like this one always run out of fuel. Running 3D is nice - but games have already shown off some of the extra 'power' of the A8 ... look at Wayout , or Mercenary. The Numen engine is cool for a demo - but the Framerate is really low for a 'doom' game.. Although it would be quite cool for a Dungeon master style game.

At least it cost the initialization "routine" and the DMA Cycles for reading the colour RAM data. Not quite sure what you mean about initialisation - the only costs that matter really are per frame costs. I dont think it actually costs any extra cycles to read colour ram on the C64 because of the 12 bit bus to Vic.

The essential here is that this mode on the C64 cost cpu time, alike what is done to reach this40x50 resolution. Actually - if you implemented it the way I've just described, rather than the way you said, there is no cpu time cost at all Yes - the bitmap modes have a lot of flexibility for 3D - I'm not a big fan of the flickering in Space Harrier though - maybe it looks worse on the emulator

If I was trying to implement a 3D game I'd probally set up a hires multicolour screen with alternating 4 pixel high lines of colour 2 and colour 3. This would effectively give me a 40x50 grid of colours programable by the low nibble of the character ram and the colour ram. - So all the 3d stuff could act on the screen as a byte per pixel. That way, I wouldn't need any interupt hacks... but it would cost a 'dummy' high res screen I was reading about Mood that it does force a refresh of the colour Ram every 4 scanlines to have the independend colours. This would result in 50 Badlines, not only 25. Even if a "standard" mode is used. ok - you're probally right.. but this way would involve only the normal 25 'badlines' - and probally save a lot of processor cycles as no interupts would be needed ( I assume the refresh is via vscroll hacks to get more badlines ) and the cpu speed would be maximised

If I was trying to implement a 3D game I'd probally set up a hires multicolour screen with alternating 4 pixel high lines of colour 2 and colour 3. This would effectively give me a 40x50 grid of colours programable by the low nibble of the character ram and the colour ram. - So all the 3d stuff could act on the screen as a byte per pixel. That way, I wouldn't need any interupt hacks... but it would cost a 'dummy' high res screen

That's a really cool video - it's always interesting to hear engineers talking about their stuff - and interesting to see how Tramiel had 'the right idea' which was then 'lost'..

c64 sprites are 24 hires pixel wide (12 in multicolor) and 21 pixels high. in multicolor mode each sprite can have 1 own color, and they share 2 colors. so it can be made of 3 sprites. furthermore the ninja could have been hires... I always wondered why the ninja sprite is so ugly, well its because <emkay mode one> the atari turned the VICII's sprites into restricted a8 pmgs <emkay mode off> I dont think it works that way - 16 pixels at 160 needs 32 pixels at 320 res... so I'm still pretty certain that the characters are made up of 2 double width monochrome sprites.. although they could also be 2 double width multicolour sprites. It's easier with 2 mono sprites though as the X/Y coords stay the same. Bruce Lee isn't using the C64 sprites to their full potential though - it is just a conversion... they could have used 3 sprites for bruce and the green guy, and 2 for the ninja - and had hires animations (320pixel) rather than lores. I'd forgotten how much I enjoyed playing this game when I was younger

I think the plus 4 was actually more expensive than the C64 in the UK $50-$80 dollars for the machine makes more sense - ( though couldn't they release some varient of the Ultimax? )

That would be a better thing - make a Jag CD interface - the real JagCD is getting a bit expensive nowadays

The plus4 always seemed a bit strange - it didn't offer much over the C64, and it lost the sprites.... why not just release a C16 as a C64 with less memory instead of new machines, especially as the C64 seemed to be as cheap as the plus4

Just for comedy - here is the Apple II version of bruce lee... nominally the Apple is 6 colours in high res, relying on Artifacting - This was the machine that the original A800 was aimed at, the C64 came years after Edit: Added 2nd picture to match c64/atari ones earlier

I think it's more than 3 sprites on the C64.. Bruce and the green guy go to 16 pixels wide in 2 colours - seems to be 1 double width player, and 1 single width player.. That's too wide for a standard multicolour sprite, so I expect the game uses 2 sprites each in the C64 version It looks like the ninja is using the fifth player - when he stabs on the A8 version the sprite goes 'double res' only. The C64 would have 3 more sprites spare to improve his graphics Haven't we already decided that the C64 sprites are better? ( come on - it shows a certain blind devotion to argue otherwise... )

they do not Maybe colour clash is the wrong description - It was almost as if there was a mask problem.. ( Maybe it was a sprite flicker ) It was a long time ago

For game comparisions: Mr Robot and his robot factory seemed better on Atari - it lots the rainbow effect on the C64, and for some reason the enemies seemed to colour clash with the ladders. I remember some of the early Atari games being AppleII ports ( I like Bandits for example )

Different and cheaper, yes. Why not using a game for comparision where the C64 looks like the 4 years older computer? The name is Koronis Rift. http://www.mobygames.com/game/koronis-rift/screenshots The only picture that looks worse on the Atari is the title screen. But in game you see the clear difference. Around 50 colours (incl. 16 steps of one hue) on the Atari with a 3 layer depth of view and fading hills come into the scene softly. The C64 even shows not 16 colours, has only two layers of depth, and due to the missing palette the hills are hard popping into the scene... and so on. I looked at the MSX picture and was amazed - then realised it's a picture for the MSX2 , which has a 256 colour per pixel video mode

This picture gets better every time I look at it How anyone tried to convert it to an A8 format? ( I have no artistic talent - so any effort I made would look pitiful )

Masochist! Oh, that's a given otherwise i'd never have hung around here as long as i have... The Beeb is a bit like a prototype for the Amstrad CPC, but some of the display modes are more conservative for memory use; the 8 colour mode has totally arbitary placement of colours but needs about 20K for a screen but there is a four colour mode which is a lot lighter on the RAM. Actually if you're a masochist you'd be programming on the Acorn Electron rather than the BBC model B... I did enjoy programming the CPC - the colours were almost as nice as the Atari - but it sucked having rubbish scrolling and no sprites