rensoup

Well I see some good progression there ?

Nope, nobody knows what you're talking about.

Ha, you might be right about the single buffering. I generally don't use it because of the headaches it can cause so I totally forgot about that possibility.

I'm not gonna ask you to post any of your ? to prove how great you are, if that's what you were hoping for... So please don't post it in here.

@dmsc I noticed something weird with your latest version , I tried taking a screenshot but it's not obvious (more obvious when moving): There's some weird jitter around some of the sprites when they're near the bottom border ?

Looks nice! Don't forget 1943... still on your todo list right ? ?

I found that demo a while back, pretty good ! (damn chunky pixels though) The thread mentioned setting up the line pointers... Just wondering if you ever found an optimum solution for that. My screen width is 256 bytes so obviously I only have the high byte to set so I'm just doing LDA #.HI(lineAddr) STA ZP,x but the screenlines are not consecutive, hence I can't do a INC I can't read that macro ?, I prefer indeed writing an external tool... that's pretty much half the job on the A8: writing tools that output code or tables.

Ouch... those mountains ? Like Jimi Hendrix used to sing: Well, I stand up next to a mountain And I chop it down with the edge of my hand ?

finally ?, Excellent news... you could even try removing the NOPs in the DLIs just to see if it goes crazy in the same fashion as Altirra (it's just a .def at the top of DLI.asm )

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!