rensoup

Thanks! I know it works on Altirra though, it's what I use to test it. What I'd like to know is if it works on real HW because I'm having to use the magic nop again in my DLis to prevent the screen from blowing up. Having not heard back from @skr I would guess it does ?

We're not making games in here, just unicorn demos 😃 Yes the macro is nifty, much cleaner, but it does prevent grouping lda #, which doesn't happen very often on most sprites, but for a few cases it can give good gains where the sprite is really repetitive. Also spotted this (Looks like you're loading the background even when the mask is empty) .macro mask :1 :2 :3 lda (ptr:1), y ift :2 = 0 lda #:3 els lda (ptr:1), y ift :2 <> $FF and #:2 ... .endm I'm really really not making that game, just pushing the limits to see what can be done on the A8, perhaps match or exceed the C64😶 Not sure if you've only been recently watching this thread but a couple of pages ago I posted my mode4 test with 2 charsets and hw scroll. Yes it was a mess... and the performance was crap and yes, agreed too about complexity shooting up

17 years a troll 😮

Nice to see others getting involved 😀 I tried to avoid relying on the background content being very similar because that may work for one level but not another one (not that I'm planning to try other levels...). I was testing mode4 and wanted to compare performance with the C64 as well so I tried a generic solution. José sent me different versions as well and the char count changed constantly. I was really interested in testing sprites, I didn't think the scroller would make everything so messy. A learning process with lots of answers which made me discard mode4 completely. I'm guessing a lot of those text modes were designed for the present time (in 1979) where the first batches of atari 400/800 shipped with 4 & 8 KB. It was the only way to get a complete screen to fit in memory. Bitmap modes would have then be designed for the future. Why not use 2 charsets btw ?

They're software sprites so there can't be any compensation in the DLIs. Still have to add the PMGs and different graphics for enemies that José sent me. So it should be very colorful and varied!

Thanks 😄 well it's a precompiled sprite so I have a table with a pointer to each code line. I will self modify the code for the splitting. (so not an auto generated mask) Parsing the list would be nice but I think it would be a luxury I can't afford as I would be writing back a lot of data. I want to avoid disabling too many sprites just for this as I still have to add the PMGs (with a bit of multiplexing! ) I'm think I'm going to split the sprite as I display then save the splits values for the restore. The sprite display can be horizontal (subhunter, slower but easier for splits) or vertical (1943, faster) but the clearing is always vertical

Yeah I'd like to know as well, right @popmilo 😀 Here's the source and an obx built at $1000. If you need to rebuild it, just use do.bat subh2s_190831.zip

Still thinking about the simplest way to do the splitting... The problem is that both the display and restore functions have to be modified and they both have to work otherwise it'll look like a mess. Here's what it looks like currently: 12 subs in case you can't count them! subh2_buggy.obx

Just one last test with the plane: plain screen clearing! Well... surprisingly I only managed to get 23 planes on screen. Looks like the code for setting up the restore/clear code is still taking a fair amount of time compared to the clearing itself. (it's pretty clean now though and isn't that long so there isn't any significant gains to be made anymore) 1943_3c.obx

Well, I'm done cleaning up the restore code at least and I was able to remove some unused tables and useless instructions. So I got 20! ...but I had to remove the last panel line as it was so close to going over a frame. Honestly... I'm surprised that I got that many 😅 I thought using mode4 was ok for static stuff... but I still think I'm losing cycles compared to modeE. I will probably not use it at all from now on, even for UI. Even the memory saving is not obvious when you factor in that 1KB alignment requirement. 1943_3.obx

damn... emkay would rather stick to his fantasy rules rather than face the reality in front of his eyes... 🙄

Thanks guys! Well I optimized the scroll update and was able to squeeze in an extra sub! I also optimized the restore background function a little and was able to squeeze in an extra plane. Wonder if it's possible to get to 20 😎 These optimizations actually helped clean up the restore function quite a bit which is now more or less readable again! This will make the splitting a little less messy.

So... Not the update you're expecting... still it's interesting enough that I decided to post it 😄 After switching the screen format to 256 bytes/line I was able to do some quick optimizations (which also simplify the code) and here's the result: 18 planes with a beautiful sinewave @50hz! I've already added the scrolling/widescreen back in the subhunter test and with the above optimizations. I can get 11 subs (that's one more than the previous one ). Last thing to do is the sprite plot splitting... hopefully I won't lose too many cycles on that one. 1943_2.obx

strange... works fine here (another umatrix user!)

still impressive... I'd like an explanation for any of your posts. You still haven't told me how many sprites I will be able to display.

True, I saw that... I'm not sure if the guy said it was stable on all STFs. There was another 4 pixel hw scroll by STConnexion... strange that nobody else used it 🤔 while this thread is derailing: damn!

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.