rensoup

My guess is they wanted as many colours as possible and at the time that turned out to be a very awkward amount: 32. Look at halfbrite mode: 64 colours with only 32 colour registers...

Of course, I've seen it (I played it and finished it back then) ? Like heaven said, probably 4 bit scrolling horizontally... which is too fast. Hence the simple trick they used: they never scroll continuously but rather shift from one screen to the next one when you reach a certain screen position. Impossible, I tell you ?

I'd say bitplane graphics never made sense... I don't know if any of the A8 multicolor mode are bitplanes. Mode E isn't and it's pretty fast and easy to use. Bitplanes are a problem they created on the Amiga and I guess solved with the blitter. On ST they just created the problem and let the developers deal with it. I don't know much about the CPC and I thought it was a piece of crap back then... but the stuff I see now is pretty impressive. I think it's due to the fact that the bits that make up a pixel are grouped. I'd say that if Atari had made a 320x200 16 color res with 4bit grouped together, you'd have seen faster games than on the Amiga. Removing bitplanes changes everything. On the ST, if you wanted to plot a sprite you had to shift it realtime which was extremely slow or you had to preshift it 16 times (with the mask) and an extra 16 pixels on the side for the shifted pixels. For a 32 pixels wide sprite, that increased your coverage by 50% and took massive amounts of memory. The ST didn't have a HW scroll built-in (people found a trick to shift the screen by 16 pixels but that's it) so if you wanted to have a 1 pixel scrolling (horizontally) game, you had to preshift the screen 16 times... I don't think any game ever did a horizontal 1 pixel scroll at 50fps Nedless to say most of the ST conversions were garbage... Just because of that single feature. If you group a pixel's bits together, all that crap goes away... mostly, you still need preshifting but a lot less... and it allows for precompiled sprites which can be several times faster than regular preshifted sprites. As for what Jay Miner says, I don't know... 16bit color/pixel on a consumer machine in 1985, that's not insight, that's fantasy. I'm thinking he meant grouping bits without necessarily having truecolor. After all VGA 256 colors cards came out in 1987. 1 byte per pixel, best mode ever! and it sure changed the gaming industry (castle wolfenstein). Perhaps he meant something like that.

3 cycles/line is fine by me... enabling HSCROL steals a lot more cycles. I couldn't notice any difference... so that's good news to me. Mode4 steals a lot more cycles too... it's slower to display a single Mode4 line than displaying the equivalent 8 ModeE lines. Make a prediction then... how many of those submarines will I be able to display with all the parallaxes ?

at around 19:40... Someone asked him what he would have done differently for the Amiga. Oh I'm not being clever about but I've only got 152 lines ?

Looks damn good... 25fps though. Close to 16bit indeed but that's because the CPC designers didn't go for bitplanes unlike the Atari ST and Amiga. That was a big mistake... Even Jay Miner said so in an interview.

Copying the whole bitmap every frame even if it's a repeat copy would, like you said, bring the whole thing down to 25fps. Sure you get a screen clear but there' aren't enough sprites to display in the first place. Yes bitmap + hscroll, is the way to go. I'm in the process of rebuilding the DLs and screens with an LMS every scanline, each scanline being 256 bytes(!), with 2 double buffers next to each other. The good news is: an LMS every scanline steals 0 CPU cycle... on top of that 256 bytes scanlines may allow further optimizations.

MrFish pointed me to this thread, so I'm just passing by... I must say that adding color0 outlines to PM is a pretty good idea... In theory with precompiled sprites, they would be very fast to display and not consume a lot of memory! (I quoted the wrong 1942 post where it's not color0) I'm amazed they didn't actually implement a software mask for QBert, it looks much much better. Maybe they used char mode?

Yes that's still the way I'm going. I still don't see how Heaven's solution would work in bitmap mode given that all the zones scroll in 1 pixel steps except for the 2 outer ones (which scroll in 2 pixel steps) I know I'm going to lose 1 sprite just by enabling HSCROL but I don't know about the LMS on each of the 152 lines, not sure what kind of speed hit I'm going to take for that.

You again ? Nice 1942 mockup... looks like you have/had a ton of ongoing projects...

Tests are useless then... Nice way of proving your point by showing me another test that didn't turn into a game ? I find tests to be valuable, much more than made up rules. So I'll keep testing... I wanted to do a real mode4 test based on something that already existed and that looked like an actual game and found José's thread. This test showed me how slow/messy mode4 really is... and probably not worth the hassle for an extra color and potential memory savings. Still the result was so bad with 3 1/2 sprites that I decided to do the same test with modeE. Like I said from the beginning I'm not trying to make a game (well not this one anyway) so if the A8 can't match the C64, be it. I'll still give it a good shot.

you want to preshift a 40*152 byte buffer 4 times ? *2 to allow for coarse scrolling (2 screens next to eachother ). that's 48KB and that's for a single buffer... Then I need another 40*152 *4 just as a restore buffer. Did I miss something here ? It works in char mode and like I said earlier I guess that's how they did it on the C64 but they don't have to deal with soft sprites. On the A8 you'd be drawing over several charsets which makes it a mess (but without the need to select the right preshifted sprite for each char line) I don't know anything about the CPC but preshifting a 16KB screen 4 times would take 64KB (I think the CPC version runs in 64KB). I'm going to guess there's a char mode on CPC (according to emkay there is) or a fine scroll every scanline ? otherwise I don't see how it would be possible

So why even bring that here? I'm testing a parallax with software sprites and you're showing me something that's completely irrelevant... you might as well have shown me Bubble Bobble and said "Here's what's possible" Yeah I don't get your point... someone's going to have to translate that for me ?

Like I said in the 1943 post: As for 5/6 missing lines, they're there (I promise!) but just empty because.... WIP!

Well that's the issue, they will cross parallax zones all the time because I have 9 (or 10?) zones over 152 lines. Because these sprites are 13 lines, they can only cross 1 zone at a time though but for taller sprites they could cross 2 at least. In mode4 that got really messy (I was switching sprites for each char line).. In modeE I'm hoping I can split the draws more simply.

Well I guess he was cleverer... ...at fooling you into thinking the machine can do more than what is actually possible ? Problem is you're not technical enough and you just make random comparisons... From what I can see in the video: 1) the pink/purple sprites aren't proper software sprites, because they overlap with nothing except the background, in fact I would bet they are PMGs multiplexed. 2 PMGs for pink sprites and 2 for purple ones. 2) The greenish sprites, don't restore any background. simple clear, much faster. 3) greenish sprites aren't proper sprites, you can see it when they overlap, they just OR, there's no masking. 4) greenish/purple/pink sprites are all double height (those chunky pixels are really obvious) which is faster to display of course. Lots of simple tricks but they definitely fooled you.

Thanks, yes it's modeE though, because from my first test with mode4, precompiled sprites and parallax don't mix well.

I think the double and triple copy as well as mirroring features being removed was a wrong move. double and triple copies would have been great for prior 0 but not so much for multiplexing because once you start abusing it you need to go 2600 kernel programming style and count your cycles which I'm not sure you can really do with Antic(/ Gtia ?) stealing cycles all over the shop.

Really it would have complicated prior and collision ? even if they'd kept the same number color registers ? (basically missiles with 8 bit width ) I 'm not sure about being good enough at design time ?, they must have had plenty of experience with the 2600 and their arcade division... It seems that every console maker does that mistake and cuts a feature that could literally have been a game changer. Just look at all these botched arcade/C64 conversions...

And here's that semi update ? I just focused on the ModeE precompiled sprites so there's NO SCROLLING YET Managed to get 10 12x13... probably not where it needs to be because I'm expecting a big drop in performance once I get the scrolling going. Plus it's going to take massive amounts of memory...hopefully it'll still fit in 64KB The precompiled sprites are fairly standard I guess: -Immediate mode AND/OR for regular sprite data -skip everything if no sprite data -immediate mode LDA for full sprite data The one thing I'm not sure others do, is to store the screen pointers (one per sprite line) in the ZP so when I draw a sprite I don't need to draw each line individually, I just jump to the code and return once everything is drawn. Of course updating these ZP pointers is costly (and needs to be done when clearing too) but still the performance is decent. The background restore is a bit more problematic and I think slower than the actual drawing!! There's no precompiled code for this part and I'm not sure if it would work that well. For the 1943 update I draw vertical slices which is about 10-15% faster than horizontal drawing and takes less memory. It should work for vertical/horizontal scrollers but it's probably not very good if there is parallax. This subhunter update draws horizontally which will work better with all these parallaxes. I'm going to focus on the scrolling and perhaps revisit the sprite restore later. subh2_0824.obx

The main sprite actually jitters left and right... very glitchy but the wow factor prevails.

Well, I digressed again so here's your very own update ? I managed to get 13 planes at 50hz but the screen is only 184 lines... not as good as I hoped... (they can all be different sprites of course) Back to our regular schedule ? spr1943.obx

MOS 6502, the 1 register RISC processor ? But seriously when you'd rather make a table than do a 16bit shift/add operation, it gets a little silly.

Yes it looks good enough that it fooled me into thinking it was higher res! So the only thing that makes it stand out is it use of colors (and nice art) because it terms of pixel pushing power it seems fairly average. I'm not bothered by people arguing around me ?. What's discouraging is when I optimize some piece of code and the setup code for the optimization wastes all the gains which happens a lot because the 6502 is unfortunately a piece crap. Still the results are semi encouraging... so hopefully a semi update will be on the way soon ?

Looks very nice... I thought it was 320 res but it's still 160 I found a bit of info here: http://plus4world.powweb.com/forum/38581 He says he uses bitmap mode (but he doesn't remember why) Some sprites update at 12fps which is too slow, it's painful to watch and play sometimes. And not all sprites are masked. I find the most impressive aspect is the amount of colors.