rensoup

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!

Not much, like emkay said, you save a little by switching Antic (or is it GTIA?) to a narrow playfield (128 pixels wide) but beyond that you only restore the areas where you display software sprites, and software sprites are by far the most taxing on the CPU.

Hell yeah... I started A8 coding a few months ago ?

Hmm... I didn't know those... interesting (but not convincing). If these are state of the art A8 shooters, I object ? Those pixels look really chunky in Zybex and Menace... I guess it's 160x100 res or something. Zybex is from 1988 so they've got an excuse I guess. Menace seems to update the player and scroll at 50hz but the rest is 25. Zybex seems to do something similar? There's no background to restore over enemies it seems... Did Zybex steal the Dropzone character ?? Xeo3 looks a lot slicker but I have no idea what kind of HW the C+4 has. If this can easily be ported to the A8 that would be a big step up. It looks like it runs at 25hz too.

Yes mode4 has the extra color but is it compatible with Prior 0 ? I was just saying that Prior 0 has no benefit in char mode vs bitmap mode... or is that not the case ?

3-4fps ? feeling generous eh ? 32 byte width is probably the original format anyway so nothing wrong with that... DKJr is a really nice looking game and I used to play it a lot. It's one of those games wouldn't really need a graphical overhaul so it looks like they made the right decision back then. I don't know about that, PRIOR and graphics mode are unrelated, you could do Reaxion in modeE and it would look just as good. I like José's example because you get a 4 color object with a software sprite and a single PMG

Of course! Again this is just a graphics test... The perception seems to be that the Atari can't do good looking shooter unlike other 8bit platforms. I don't know about that. The best looking one is probably Dropzone and it's got its own style but most of the screen has no background. Atari Blast is supposed to be a showcase of the A8 power but while it does have a lot on screen, those PMGs take me back right to VCS days.

Not sure what you mean.... I was just being facetious... José throws in a lot of ideas and it's not easy to keep up but he pushes boundaries and I certainly learned news tricks by looking at his examples. If you meant "too much in the foreground", I believe mode4 is the problem... modeE would probably better suited.

Oh Dear... ?

Well José already explained how he did it, and in the test I posted there aren't any clashes. I would say there is potential, I like what José did with it. Well yeah it's dead expensive, that's why I have barely 4 sprites moving across the screen ?. That's why I'm thinking mode4 is overrated... It was designed before 1979 after all when 16KB of mem was beyond your wildest dreams. I'm guessing it was purely a cost saving mode with an extra color thrown in, not to be used for fast animations. Never said the game was great, just potentially a good showcase of A8 power. The parallax scroll is much nicer that the other versions (not very CPU intensive either) and that was just a few days of work...

Thanks again! Btw this version has the sprite loop ORG in the ZP... not sure if loaders like that or not... the previous test with the snow had no code in the ZP, so you could also try that one if the latest one doesn't work. Regarding Prior 0, here's a screenshot with all 4 PMGs set to the same color ($E8), as you can see P0/P1 look different from P2/P3... that's what I don't understand. From the Altirra manual: Priority mode 0 Clearing all four priority bits PRIOR[3:0] causes the all of the cross-disable signals in the priority logic to turn off, enabling some combinations to mix. The reduced logic for this mode is as follows: SP0 = P0 SP1 = P1 * (/P0 + MULTI) SP2 = P2 * /P01 * /PF01 SP3 = P3 * /P01 * /PF01 * (/P2 + MULTI) SF0 = PF0 * /SF3 SF1 = PF1 * /SF3 SF2 = PF2 * /P01 SF3 = PF3 * /P01 I have no idea how to read this ? what is SPx ? why the '/' in front of Px ? Multi = multicolor ?? what is SFx ? The effect is to allow playfields 0 and 1 to mix with players 0 and 1, and playfields 2 and 3 to mix with players 2 and 3. The result of two colors mixing is the bitwise OR of their color register contents. PF0/PF1/P0/P1 still have priority over PF2/PF3/P2/P3. This is confusing too because it seems to imply that only pf color 0/1 can mix with PM 0/1 while that's clearly not the case

Well, here's another update... as I expected the performance isn't that great ( could be my fault ? ) After a week of messy optimizations I can get 6 12*16 sprites @50HZ but that's without vertical movement. With vertical movement, a 12*16 sprite becomes a 12*24 sprite... that an extra 50% area which translates into 4 sprites @50HZ... I could have optimized that part a little but I really got fed up fighting mode4. I didn't even bother with precompiled sprites but I guess I could get a good speed up and squeeze in an extra sprite or two. The setup/restore code is extremely slow, the obvious optimization would be to draw 4 pixels wide stripes but this is a worst case scenario: many different HSCROL zones and a change of character set midscreen... so I have to draw horizontally instead. I doubt I got any speed benefit from using mode4 vs modeE, probably the opposite actually and the code is also more complex. I'm convinced 8 sprites would be possible with ModeE (but I was interested in investigating mode4) I also added some rough PMGs to test priority 0. I don't fully understand how it works, the Altirra manual is a little confusing. There's some flickering on the sprites just to try to improve the gradient but it doesn't work that well sh6 is the 6 sprites version moving horizontally sh4 is the 4 sprites version moving in all directions but I had to cheat a little by drawing only 13 lines (which translate in an extra char line only half the time) source is attached as usual ( also contains a simple sprite converter in C# ) Could anyone test this on real HW ? sh4_0815.obx sh6_0815.obx subh_190815.zip

That doc is a little cryptic, not sure if it tells me I should expect a crash with specific HSCROL values but I the good news is I was able to get rid of the NOP by using a different range of values (5-8 instead of 9-12).

You mean HSCROLL, right ? I should mention that the problem occurs in wide and normal PF mode. But yes it seems the range of values I use for HSCROL affect the number of NOPs I need.

how is this in the middle of scanline ? (this is causing a crash) sta WSYNC sta HSCROL For this to work I need: sta WSYNC nop sta HSCROL I'm wondering if it is expected to have to put a nop or if there's a bug somewhere in my code

ouch that's a little rough ?. Still an interesting idea, I'd probably still have some limited char graphics behind the fighters, like the building edges,...

I thought he was creating new chars dynamically for overlapping sprites but perhaps he isn't in which case it's very fast indeed. For my test I will use preshifting and precompiled sprites. I was going for preshifting only but it's clearly not going to be good enough.