rensoup

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.

That's not JP quality but that's a clear example. I can see PM01 affecting PF01 and going over PF23 and PM23 affecting PF23 while going under PF01

You seem to think that game technology reached its peak 30 years ago and can't be improved upon. Your beatem up mockup is an example of that, you were really conservative on the graphics side for fear of wasting too many cycles. If I was doing these tests developing on a real Atari with floppies and using Atari basic to create my tools. i'd have thrown it all out the window, ...daily! With better dev environments we should be able to push game tech further. I see so many great mockups in the forums, and they seem to be within reach. Just saw Mr.Fish's Pole position mockup which looks great. Alright I digress too much...

I think he meant preshifting the tiles? It was discussed earlier in the thread, right? I guess you just need to change the character map every frame to scroll the whole screen so that's less than 1KB to update. Then software sprite aren't as messy because you don't need to select which shifted version you're going to display for each parallax zone they cross (you might still cross character sets though) I feel like I'm explaining something really obvious to you... maybe we're not on the same page...

Sure but PMGs look poor... Callisto is a good example of that. I don't know why he didn't use soft sprites, perhaps too much hassle, perhaps it would have been impossible in char mode to move such large softsprites. All the CPU cycles are wasted on those raster colors for the PMGs to make them less ugly (really... just WSYNC and Color updates every scanline) ? I actually considered it. Subhunter uses less than 64 chars for the whole screen so everything preshifted 4 times would fit in 256 tiles on the C64. I wonder if they did it like that... but then again they have decent HW sprites. On the A8, yes you'd be splitting that into a bunch of charsets and back with softsprites... still might have made it faster than using HSCROL but perhaps not fast enough to display 8 sprites.

Thanks for the english lesson 😏 (not a native english speaker) God damnit... I didn't even know that. That's ridiculous. Why couldn't they just give us 8 players ? Does anyone know the actual reason ? Was it 8 originally and they just decided to cut the transistor count ?

Well, again I'm not sure what your point is. If you're saying that moving PMGs at a faster framerate than the background and/or soft sprites is a good technique, I fully agree! It's a good compromise if the game can't maintain 50fps. I guess that Callisto uses 25fps because 1 pixel at 50fps would scroll too fast and make the game unplayable (because we can't scroll at half a clock on A8 or something like that)

Great explanation! Must be fun designing around those 😲

Cool! That simple 1943 test looks nicer than any of the games you mentioned earlier (that plane looks great even though it's half width). Even the 25hz framerate version looks fine.

I like your tests, good choice of tune too 😀 I'm doing some software sprites in modeE and the results are encouraging enough that I think you'll ditch mode4!