SUB HUNTER on C64, now ported to CPC... When A8 version?

[emkay]

7 minutes ago, dmsc said:

 

 

Certainly, it is simpler to use mode E if you need many soft-sprites - but compensating for the scrolling regions would be difficult.

 

 

Haven't you realized yet that it is impossible to handle the "Softwaresprites" in Mode E with Scrolling?

It is easier to Mock things, but, if you had a closer look at the latest "Demo" by "rensoup" , there are "No" moving objects, just some Lines that jump from "here to there" ...

 

 

How about implementing more than one of those subs on your "Engine" ?

Edited September 1, 2019 by emkay

[popmilo]

19 minutes ago, emkay said:

Haven't you realized yet that it is impossible to handle the "Softwaresprites" in Mode E with Scrolling?

Thanks, you made me laugh

 

[Heaven/TQA]

3 minutes ago, popmilo said:

Thanks, you made me laugh

 

“Impossible” seems to be his ego...

Edited September 1, 2019 by Heaven/TQA

[emkay]

5 minutes ago, Heaven/TQA said:

“Impossible” seems to be his ego...

No, yours. 

[emkay]

It's still the question , if somedays the missing software will reach the Atari.

But, as it seem, it will be a never ending story.

As Long as those people only love their own, things won't change.

After all those Years my Ideas for changing that , ran out of Ressources. There is simply too much ignorance.

The defiance for reality is not something to battle with.  

Luckily not all of them were that narcissistic, so some good stuff still is approaching.  

[rensoup]

1 hour ago, dmsc said:

Hi!

You need to move all background characters, so 87 chars with current background - there is one "empty" char that does not need movement.

 

But, a few chars move by 1.5 pixels (4 bits one frame, 2 bits the other) others by 0.5, so I alternate movements to use less CPU.

 

Main problem is not CPU (it can be fixed y using pre-shifted chars) but number of chars available for the soft-sprites. As I said before, this could only work with a simpler background that would reduce both, the used characters and the CPU usage by shifting.

 

If you want 8 "enemies", and each uses 12 chars (so the maximum size is 13x17), you have 32 chars left for the background... using repeating patterns in the lines it could work. I always miss having 256 chars in the Atari  .

 

Certainly, it is simpler to use mode E if you need many soft-sprites - but compensating for the scrolling regions would be difficult.

 

Have Fun!

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 ?

[rensoup]

1 hour ago, emkay said:

Haven't you realized yet that it is impossible to handle the "Softwaresprites" in Mode E with Scrolling?

It is easier to Mock things, but, if you had a closer look at the latest "Demo" by "rensoup" , there are "No" moving objects, just some Lines that jump from "here to there" ...

 

17 years a troll ?

[emkay]

9 minutes ago, rensoup said:

17 years a troll ?

A troll who did real stuff on the Atari. 

[+Stephen]

1 hour ago, emkay said:

It's still the question , if somedays the missing software will reach the Atari.

But, as it seem, it will be a never ending story.

As Long as those people only love their own, things won't change.

After all those Years my Ideas for changing that , ran out of Ressources. There is simply too much ignorance.

The defiance for reality is not something to battle with.  

Luckily not all of them were that narcissistic, so some good stuff still is approaching.  

Well, we all know nothing will come our way from you since all you do is spout bullshit words and no code.  At this point, you are a nothing but a useless troll.

[+Stephen]

38 minutes ago, emkay said:

A troll who did real stuff on the Atari. 

Ear bleeding out of tune compositions and you can't understand why nobody used your cat claws down a chalkboard sounds?  Your level of mis-comprehension knows no bounds.  Never ending amusement for me, that's for sure.

[dmsc]

Hi!

1 hour ago, rensoup said:

Nice to see others getting involved ?

Only for a little test. I'm not good at making full games . Full source was included, so you can take a look to the techniques. For example, I used a macro for the sprite expansion, IMHO it is a lot clearer than the full expanded code.

 

1 hour ago, rensoup said:

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.

Yes, but I just watched the CPC version (didn't watch the game before) and there the backgrounds are even more repetitive, you could base your version on that. And in the C64 version there are just 5 scrolling regions, not 8 like the current demo.

 

So, IMHO, limiting the game could work.

 

1 hour ago, rensoup said:

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.

Yes, probably ROM usage was a constrain, and number of flip-flops inside ANTIC.

 

1 hour ago, rensoup said:

Why not use 2 charsets btw ?

 

Because then you have the same problem as the scrolling regions in mode E, you need to test for sprites crossing the charset regions and copy from/to different fonts. It complicates the code a lot.

 

Have Fun!

 

[solo/ng]

looks very impressve so far.

 

works ok on altirra

Edited September 2, 2019 by solo/ng

[rensoup]

2 hours ago, dmsc said:

Only for a little test. I'm not good at making full games . Full source was included, so you can take a look to the techniques. For example, I used a macro for the sprite expansion, IMHO it is a lot clearer than the full expanded code.

 

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

3 hours ago, dmsc said:

Yes, but I just watched the CPC version (didn't watch the game before) and there the backgrounds are even more repetitive, you could base your version on that. And in the C64 version there are just 5 scrolling regions, not 8 like the current demo.

 

So, IMHO, limiting the game could work.

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?

 

3 hours ago, dmsc said:

Because then you have the same problem as the scrolling regions in mode E, you need to test for sprites crossing the charset regions and copy from/to different fonts. It complicates the code a lot.

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

 

[rensoup]

1 hour ago, solo/ng said:

looks very impressve so far.

 

works ok on altirra

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 ?

 

[_The Doctor__]

shoot us the latest greatest and we'll give it a whirl

[dmsc]

Hi!

1 hour ago, rensoup said:

We're not making games in here, just unicorn demos ?

Well, that i the part that I like  

 

1 hour ago, rensoup said:

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

It is on purpose, because I need to copy from the original charset to the output charset even in the blank regions, to allow the see-through background. Yes, using mode E is easier because you don't need to restore the full 8 bytes char.

 

1 hour ago, rensoup said:

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?

Ok! 

1 hour ago, rensoup said:

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

So, we agree  

 

This is a new version using a smaller (more repetitive) background, I managed 6 sprites of 3x3 chars before there was too few cycles left (in PAL). Again, optimizing the scrolling code more CPU would be available.

 

 

 

subfnt.xex subfont.zip

[dmsc]

Hi!

1 hour ago, rensoup said:

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

Oh, I misread, you are right of course!

 

Attached fixed version, speed should be a little faster.

 

subfnt.xex subfont.zip

[emkay]

7 hours ago, Stephen said:

Ear bleeding out of tune compositions and you can't understand why nobody used your cat claws down a chalkboard sounds?  Your level of mis-comprehension knows no bounds.  Never ending amusement for me, that's for sure.

 

Our honest Troll , again. Nothing to contribute to the thread but attacking others from nowhere. 

[emkay]

2 hours ago, dmsc said:

Hi!

Oh, I misread, you are right of course!

 

Attached fixed version, speed should be a little faster.

 

subfnt.xex 3.96 kB · 6 downloads subfont.zip 3.68 kB · 3 downloads

 

Have you checked how Extirpator works? It is also build on pure software with some exception in the range, the moving objects won't go.  

Seeing the "Subs", I have some questions.

You also set the background to the Subs ?

Could you do a version without that ?

And just move 12 of the "Subs" in character resolution? Up, down, diagonal (all directions, bouncing) ? 

 

If you want, you could also move some of them still in the "software Sprite" Resolution. 

 

 

[+skr]

5 hours ago, rensoup said:

Having not heard back from @skr I would guess it does ?

Hi rensoup,

 

I was not able to compile and run it yet, there was too much distraction at the Fujiama meeting. Will take another look into it later today.

[Lastic]

11 minutes ago, skr said:

Hi rensoup,

 

I was not able to compile and run it yet, there was too much distraction at the Fujiama meeting. Will take another look into it later today.

 

@rensoup I ran your compiled obx from this post 

 on a stock PAL 130XE at Fujiama and it worked.

[rensoup]

10 hours ago, _The Doctor__ said:

shoot us the latest greatest and we'll give it a whirl

 

5 hours ago, skr said:

Hi rensoup,

 

I was not able to compile and run it yet, there was too much distraction at the Fujiama meeting. Will take another look into it later today.

 

5 hours ago, Lastic said:

 

@rensoup I ran your compiled obx from this post 

 on a stock PAL 130XE at Fujiama and it worked.

 

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 )

[rensoup]

10 hours ago, dmsc said:

Hi!

Well, that i the part that I like  

 

It is on purpose, because I need to copy from the original charset to the output charset even in the blank regions, to allow the see-through background. Yes, using mode E is easier because you don't need to restore the full 8 bytes char.

 

Ok! 

So, we agree  

 

This is a new version using a smaller (more repetitive) background, I managed 6 sprites of 3x3 chars before there was too few cycles left (in PAL). Again, optimizing the scrolling code more CPU would be available.

 

 

 

subfnt.xex 3.99 kB · 8 downloads subfont.zip 3.68 kB · 3 downloads

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

 

?

 

 

[NRV]

I have done some old experiments with software sprites and I'm also a "macro lover", for precompiled sprites x)

From what I remember there were different ideas used, but sadly neither of the examples used a scrolling background.

 

A more recent one, for char software sprites (also with source):

https://atariage.com/forums/topic/282434-char-based-software-sprites

 

One interesting thing in the macros of the last one, is that the "write byte" part was "aware" of the previous byte, so it can generate consecutive "sta" if writing the same byte:

 

.macro MACRO_DRAW_BYTE

    .if (([%%1%%3] == 0) && (:?DRAW_STA_OPT_FLAG == 1) && (:?DRAW_STA_OPT_VALUE == [%%2%%3]))
        sta (m_newCharFontAddress),y
    .elseif ([%%1%%3] == 0)                // mask byte == 0 ? (only new byte then)
        lda #[%%2%%3]
        sta (m_newCharFontAddress),y
.def :?DRAW_STA_OPT_FLAG = 1
.def :?DRAW_STA_OPT_VALUE = [%%2%%3]
    .elseif ([%%1%%3] == $FF)        // mask byte == $FF ? (only old byte then)
        lda (m_oldCharFontAddress),y
        sta (m_newCharFontAddress),y
.def :?DRAW_STA_OPT_FLAG = 0
    .else
        lda (m_oldCharFontAddress),y
        and #[%%1%%3]                // invert the mask here? (in another place is better)
        ora #[%%2%%3]
        sta (m_newCharFontAddress),y
.def :?DRAW_STA_OPT_FLAG = 0
    .endif

    .if (:4 == 0)
        iny
    .endif
    
    .endm

 

Anyway, I still think is better to write an external tool to generate the precompiled sprite code

 

[dmsc]

Hi!

7 hours ago, NRV said:

I have done some old experiments with software sprites and I'm also a "macro lover", for precompiled sprites x)

Thanks for the pointers!

 

I don't have as much code as that examples, as I only store horizontal shifts of the sprites, and at runtime adjust the Y position to do the copy. This is slower than using the full 4*8 pre-shifted images, but uses much less memory.

 

7 hours ago, NRV said:

From what I remember there were different ideas used, but sadly neither of the examples used a scrolling background.

A more recent one, for char software sprites (also with source):

https://atariage.com/forums/topic/282434-char-based-software-sprites

 

One interesting thing in the macros of the last one, is that the "write byte" part was "aware" of the previous byte, so it can generate consecutive "sta" if writing the same byte:

I added this to my code, and a few optimizations, like if (data OR mask) == $FF, don't need to apply the mask.

 

7 hours ago, NRV said:

Anyway, I still think is better to write an external tool to generate the precompiled sprite code

Yes, but writing macros is fun

 

Attached is new code, I commented all the sprite procs and rewrote the macro to use the full sprite as argument, now the code looks like this:

        ;            -------  MASK  ---------  --------- DATA ---------
        sprite_line %111111111100111111111111 %000000000010000000000000 ;  0
        sprite_line %111111111100111111111111 %000000000011000000000000 ;  1
        sprite_line %111111111100111111111111 %000000000011000000000000 ;  2
        sprite_line %111111110000001111111111 %000000001110100000000000 ;  3
        sprite_line %111111110000000011111111 %000000001110101100000000 ;  4
        sprite_line %111111000000000011111100 %000000111111111100000011 ;  5
        sprite_line %111100000000000000000000 %000011111111111111111010 ;  6
        sprite_line %110000000000000000000000 %001111101110111011101111 ;  7
        sprite_line %000000000000000000000000 %111110101010101010101011 ;  8
        sprite_line %000000000000000000000000 %111011101010111011101111 ;  9
        sprite_line %110000000000000000000000 %001110111011101111111111 ; 10
        sprite_line %110000000000000000110000 %001111101110111111001010 ; 11
        sprite_line %111100000000000011111100 %000011111111111100000011 ; 12

Also, I added another sprite shape and an example of a sprite that changes shape as it moves. I think that you can do pretty good games with only 6 2 color sprites, plus the P/M graphics.

 

Have Fun!

 

subfnt.xex subfont.zip