rensoup

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.

they're very close, can't get any c64 emu to play at 50fps (micro64 and vice)... not sure if they're slow or the game is slower on c64

masters of time, such a peculiar tune...

Well... I'm doing my bit 😀 Every Atari gamer knows Archer Mclean 😁 I'm surprised that it uses char mode though since there's pretty much no background to restore... It was an awesome game and technical prowess back then... Nowadays, with better dev tools and all that, it's not that impressive technically... still an awesome game though!

Because of the scroller, it will actually take 159 x (40+48) = +-14KB if you want to scroll infinitely. Then you have to double buffer that because sprite sorting is not going to help with flickering... so 28KB, still doable. I'm going to try some real sprites instead of snow 😀, (my goal is still to test mode4) so yeah perhaps someone will take over after that and turn it into a proper game. I checked out what good looking shooters are available on A8... it's pretty much Dropzone... a shame really.

Thanks! C64 sprites are 21*24 3 cols right? 25fps on an A8 is a little depressing... Not only is char mode slower to setup, but even fast restore is debatable, since you have to save 8 more lines most of time just for vertical alignment. I wouldn't rule out char mode completely, there are things that are impossible in bitmap mode (like a parallax scroller with overlapping zones, ie R-Type). But the savings it seems to give you for frame buffer memory it takes back by requiring sprite preshifting. Depends on your use case I guess...

José kindly provided a cleaned up GF2, so here's a new version! Also: -More DLIs for more colors changes and more parallaxes (9 vs 5 in the original) -wide playfield -sprite test (30 tiny 1x1 white pixels) Could anyone test in on a real machine and let me know if it works ? I'm having an issue with WSYNC and setting HSCROL: I have to have NOPs between the 2 otherwise the display goes mad in Altirra... is that expected ? Juste a note regarding perf of sprites in mode4... it's not very good 🤨 The code's not optimized at all but it would be at best a close call to have the same amount of sprites as the C64, the code to set the sprite drawing up is slower than the actual drawing. My gut feeling tells me it may be as fast in bitmap mode. subh_190805.zip

Well I'm doing tests with Antic4 and I figured I could use some nice graphics so I gave it a shot. It's just the parallax effect, there aren't any sprites even though it looks like there are some. I'm just using the g2f that José posted 8 years ago :) I plan on adding sprites but will not turn it into a game or anything... I added the 7 gates of jambala conversion tune by Miker and I'm using dmsc' SAPR player for extra punchiness! obx+ source included subh190731.zip

The RMT player source is available from the original package http://raster.infos.cz/atari/rmt/rmt.htm , there are newer versions in the forums though. You could also look into dmsc's SAPR player. It only supports 50/60hz mono tunes but that's most of them. How to integrate that with basic, I have no idea. It uses some ZP but you can move it out except for a 2 byte pointer. It will be slightly slower but it's much faster than RMT anyway. Storage wise it requires less than 2.5KB for code+buffers (mostly buffers), and whatever tune you use which may actually be smaller than the original RMT. Yeah, it's pretty great!

Thanks again, I'm still unsure which way to go but I'll definitely investigate OS switching.