Jump to content
José Pereira

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

Recommended Posts

32 minutes ago, rensoup said:

They're software sprites so there can't be any compensation in the DLIs.

 

Well, well….

Of course you'd have to split the calculations for every depth layer. If you don't compensate that by calculations, it won't look correctly.

 

For the books: Doing such calculations in the DLI range can help to get more cpu speed, because the halt by Antic only stops read and write on the RAM, not what happens inside the Processor.     

Share this post


Link to post
Share on other sites
6 hours ago, skr said:

Just out of curiosity I wanted to see that on the real hardware, but I cannot get it to load and start there.

It looks like it loads to something like $800 which is too low. I have no skills to change that manually, so I would like to ask you if you can change it to some higher memory area? :)

If I come cross something like this I typically find it OK to pump it through a compression tool, e.g. exomizer, and get it to produce a self-extracting binary with a higher load base.

  • Like 3

Share this post


Link to post
Share on other sites

If the processor is executing instructions in a DLI or not, then it's affected by Antic DMA. The HALT by Antic from a WSYNC stops the processor but the DMA will steal cycles, not stop reading/writing from/to RAM, just delay.


By not using DLIs, this saves on the overhead of stack push/pulls but has advantage of knowing where you are.

A kernel type approach seems therefore better and actually you could use them within a fewer number of DLIs to keep better control of where you are and in the case where your code ends earlier.

But then you'd have to examine what the mainline code is doing in this case... mostly you'd be waiting for the 'out of display' areas to update gamestate / prepare the next frames graphics etc.

 

But I'd say this is only necessary where you aiming for a 50/60Hz framerate. If halving that then these considerations (mostly) go out of the window and your mainline code deals with things.

  • Like 1

Share this post


Link to post
Share on other sites
3 hours ago, Wrathchild said:

has advantage of knowing where you are

That should read "has the disadvantage of not knowing where you are" ;) 

Share this post


Link to post
Share on other sites
7 hours ago, Wrathchild said:

If the processor is executing instructions in a DLI or not, then it's affected by Antic DMA. The HALT by Antic from a WSYNC stops the processor but the DMA will steal cycles, not stop reading/writing from/to RAM, just delay.

 

I wonder about this post. 

It could be an answer to mine above. As the point is different, I just point it out ;) 

Rensoup could get confused there. 

 

7 hours ago, Wrathchild said:


By not using DLIs, this saves on the overhead of stack push/pulls but has advantage of knowing where you are.

A kernel type approach seems therefore better and actually you could use them within a fewer number of DLIs to keep better control of where you are and in the case where your code ends earlier.

But then you'd have to examine what the mainline code is doing in this case... mostly you'd be waiting for the 'out of display' areas to update gamestate / prepare the next frames graphics etc.

 

But I'd say this is only necessary where you aiming for a 50/60Hz framerate. If halving that then these considerations (mostly) go out of the window and your mainline code deals with things.

 

Kernel, well , a never ending "dream" on the Atari. Which game is using a kernel for real on the XL/XE?

A kernel means to do things at 1 frame every time. But people prefer still images that look like C64 ;)

If you aim 25fps, using the DLIs is just the better way, as you can place them exactly to the screen, where you want to change things.

DLI start and WSYNC grant the right timing , without complex preparations from the programming .  

Share this post


Link to post
Share on other sites

kernel is at least for me code interleaved into display code running in those “free” time while running across the screen. Must not be static as it can be parts of dynamic code (but coder must be experienced enough to let those code snippets fit in there). Standard on 2600 and other micros.

 

it’s just another way of balance out the cpu usage. Has nothing to do with static 1 frame thing.

 

compare eg. Numen Bump Mapper which is using a cycle exact “kernel” and is not “static”.

 

  • Like 1

Share this post


Link to post
Share on other sites
6 hours ago, emkay said:

Rensoup could get confused there.

All I see here is an attempt to rephrase what I have said as your own when at the same time employ some one-upmanship to assert your knowledge but in the process have ended up spreading more mis-information. You really need to resist the temptation to keep on doing that.

 

When we talk here about a 'kernel' it refers to a 'display kernel' (as opposed to an OS kernel). Yes, for a 2600 its architecture is such that the code is locked into servicing the full screen and so game state is then handled in the non-drawing/v-blank area.


For an A8, a (display) 'kernel' merely refers to code dedicated to affecting the display about to be rendered further on in the current frame, so like Heaven states, a 'snippet' suffices here.

 

It's not "to do things at 1 frame every time" - blimey, a VBI satisfies that definition!

 

 

 

  • Like 1

Share this post


Link to post
Share on other sites
1 hour ago, Wrathchild said:

All I see here is an attempt to rephrase what I have said as your own when at the same time employ some one-upmanship to assert your knowledge but in the process have ended up spreading more mis-information. You really need to resist the temptation to keep on doing that.

 

Why do you think we're on the same point ? I'm  exactly vice versa to your post. 

For a Demo your solution seems fine, but not for a game. 

 

Quote

When we talk here about a 'kernel' it refers to a 'display kernel' (as opposed to an OS kernel). Yes, for a 2600 its architecture is such that the code is locked into servicing the full screen and so game state is then handled in the non-drawing/v-blank area.


For an A8, a (display) 'kernel' merely refers to code dedicated to affecting the display about to be rendered further on in the current frame, so like Heaven states, a 'snippet' suffices here.

 

That is the nonsense part for games. If you use a Kernel for the Display, you'd have to do the changes every new VBI the same. 

Splitting it into several DLI (that actually can be handled like small Kernels) , this gets better in control for the game mechanics. 

 

Quote

It's not "to do things at 1 frame every time" - blimey, a VBI satisfies that definition!

 

Blimey , I'm not talking about the VB time.. ;)

Edited by emkay

Share this post


Link to post
Share on other sites
1 hour ago, Heaven/TQA said:

I love the Dilbert pic posted here ;)

Yes, it's very meaningful.

Particular this morning I thought about , what games could be really done on the Atari, but will never get real, because people claim they feel so correct in what they do... ;)

Share this post


Link to post
Share on other sites

And btw.: The Frame is the displayed screen. One Frame = One FPS in that term ...

The VB … Vertical Blank is the time, when the Cathode Ray moves from the bottom to the upper part of the CRTube to display the next Frame.  

So the VBI is the Interrupt that is made to do something in the time of the Vertical Blank.

 

Just for the books ;)

Share this post


Link to post
Share on other sites
9 minutes ago, Heaven/TQA said:

Not sure if we need a lesson what VBL etc is.... but well... as I said... Dilbert rules.

Indeed.

Share this post


Link to post
Share on other sites

Hi!

 

I tried to convert the demo to ANTIC mode 4, the idea is that instead of using hardware scrolling you can just shift the charset in software, taking advantage of the repetitions.

 

My modified screen uses 88 characters for the backgrounds, so you have 40 chars left for software sprites, for the big sub sprites this could make 4 sprites at most :( Perhaps simplifying the background It could be made to work.

 

subfnt.png.c7bee2012016a75caf5e0f2aa2af24dd.png

 

 

subfnt.xex subfont.zip

  • Like 4

Share this post


Link to post
Share on other sites
3 hours ago, Heaven/TQA said:

Not sure if we need a lesson what VBL etc is.... but well... as I said... Dilbert rules.

You know what else rules?  The Block User function.  I've only used it twice and this is the second time.  Way too much noise with that user.  I can't take him anymore.  Now the thread is much more enjoyable. 😁

  • Like 1

Share this post


Link to post
Share on other sites
9 minutes ago, dmsc said:

Hi!

 

I tried to convert the demo to ANTIC mode 4, the idea is that instead of using hardware scrolling you can just shift the charset in software, taking advantage of the repetitions.

 

My modified screen uses 88 characters for the backgrounds, so you have 40 chars left for software sprites, for the big sub sprites this could make 4 sprites at most :( Perhaps simplifying the background It could be made to work.

 

subfnt.png.c7bee2012016a75caf5e0f2aa2af24dd.png

 

 

subfnt.xex 3.71 kB · 1 download subfont.zip 3.3 kB · 1 download

That's something to work on. Nice work.

Share this post


Link to post
Share on other sites
18 minutes ago, TheNameOfTheGame said:

You know what else rules?  The Block User function.  I've only used it twice and this is the second time.  Way too much noise with that user.  I can't take him anymore.  Now the thread is much more enjoyable. 😁

Already in use ;)

Share this post


Link to post
Share on other sites
39 minutes ago, dmsc said:

I tried to convert the demo to ANTIC mode 4, the idea is that instead of using hardware scrolling you can just shift the charset in software, taking advantage of the repetitions.

 

My modified screen uses 88 characters for the backgrounds, so you have 40 chars left for software sprites, for the big sub sprites this could make 4 sprites at most :( Perhaps simplifying the background It could be made to work.

 

When you say "shift charset in software" do you mean actual LSR character definition bytes or similar tech each frame, or maybe 4 different character sets changed using chbase register ?

Share this post


Link to post
Share on other sites

Hi!

1 minute ago, popmilo said:

When you say "shift charset in software" do you mean actual LSR character definition bytes or similar tech each frame, or maybe 4 different character sets changed using chbase register ?

Yes, actual ROL instructions on each frame, for 4 characters it looks like this (see the subfnt.asm file in the ZIP above):

        ldx     #7
lp      lda     font + :1 * 8, x
        cmp     #$80
        rol     font + (:1+3) * 8, x
        rol     font + (:1+2) * 8, x
        rol     font + (:1+1) * 8, x
        rol
        cmp     #$80
        rol     font + (:1+3) * 8, x
        rol     font + (:1+2) * 8, x
        rol     font + (:1+1) * 8, x
        rol
        sta     font + :1 * 8, x
        dex
        bpl     lp

It should be faster by having the pre-shifted characters, but this was easier to write.

 

Have Fun!

  • Like 1

Share this post


Link to post
Share on other sites
35 minutes ago, Mclaneinc said:

Same here....Love the Dilbert, pretty spot on..

 

Loving the work on the game..

I miss being you

Share this post


Link to post
Share on other sites
22 minutes ago, dmsc said:

Hi!

Yes, actual ROL instructions on each frame, for 4 characters it looks like this (see the subfnt.asm file in the ZIP above):

        ldx     #7
lp      lda     font + :1 * 8, x
        cmp     #$80
        rol     font + (:1+3) * 8, x
        rol     font + (:1+2) * 8, x
        rol     font + (:1+1) * 8, x
        rol
        cmp     #$80
        rol     font + (:1+3) * 8, x
        rol     font + (:1+2) * 8, x
        rol     font + (:1+1) * 8, x
        rol
        sta     font + :1 * 8, x
        dex
        bpl     lp

It should be faster by having the pre-shifted characters, but this was easier to write.

 

Have Fun!

 

This solution prevents from endless rolling the moving objects through the different charsets.  Very well !

 

It also leaves a lot free CPU cycles. 

PMg is still available. 

 

Share this post


Link to post
Share on other sites
47 minutes ago, dmsc said:

Hi!

Yes, actual ROL instructions on each frame, for 4 characters it looks like this (see the subfnt.asm file in the ZIP above):

        ldx     #7
lp      lda     font + :1 * 8, x
        cmp     #$80
        rol     font + (:1+3) * 8, x
        rol     font + (:1+2) * 8, x
        rol     font + (:1+1) * 8, x
        rol
        cmp     #$80
        rol     font + (:1+3) * 8, x
        rol     font + (:1+2) * 8, x
        rol     font + (:1+1) * 8, x
        rol
        sta     font + :1 * 8, x
        dex
        bpl     lp

It should be faster by having the pre-shifted characters, but this was easier to write.

 

Have Fun!

Quite a cycle burner in itself. How many chars are needed actually for the parallax?

 

if it outpays the simpler soft sprite logic it’s ok but such stuff at some point might come into your way.

Edited by Heaven/TQA

Share this post


Link to post
Share on other sites
3 minutes ago, Heaven/TQA said:

Quite a cycle burner in itself. How many chars are needed actually for the parallax?

 

if it outpays the simpler soft sprite logic it’s ok but such stuff at some point might come into your way.

Unfinished imagination, as usual.

 

If the coder is building the ROLling ( ;) ) in dedicated DLIs, the CPU saving is obvious. 

Share this post


Link to post
Share on other sites

Hi!

8 minutes ago, Heaven/TQA said:

Quite a cycle burner in itself. How many chars are needed actually for the parallax?

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.

8 minutes ago, Heaven/TQA said:

if it outpays the simpler soft sprite logic it’s ok but such stuff at some point might come into your way.

 

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!

  • Like 1

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...

  • Recently Browsing   0 members

    No registered users viewing this page.

×
×
  • Create New...