Jump to content
José Pereira

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

Recommended Posts

1 hour ago, dmsc said:

 

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.

 

 

 

subfnt.xex 5.35 kB · 2 downloads subfont.zip 5.02 kB · 1 download

Thanx. This is great. That's the way to go. :)

 

 

Share this post


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

Hi!

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.

 

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

 

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 5.35 kB · 4 downloads subfont.zip 5.02 kB · 2 downloads

Nice example !
How much memory does this precompiled sprite take ?

 

  • Like 1

Share this post


Link to post
Share on other sites
13 hours ago, NRV said:

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:

 

 

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

 

 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.

Share this post


Link to post
Share on other sites

Hi!

20 hours ago, popmilo said:

Nice example !
How much memory does this precompiled sprite take ?

 

Thanks!

 

Looking at the listing file, in that demo, the "sub" is one frame of 356 bytes, and the "squid" is 4 frames at 1306 bytes total (so about 327 bytes per frame).

 

I could reduce it by 25 bytes per frame with a little optimization, but not much more than that. An option for a longer game would be generating the sprite code on load, or simply storing the sprite code compressed.

 

Have Fun!

Share this post


Link to post
Share on other sites
2 hours ago, dmsc said:

Hi!

Thanks!

 

Looking at the listing file, in that demo, the "sub" is one frame of 356 bytes, and the "squid" is 4 frames at 1306 bytes total (so about 327 bytes per frame).

 

I could reduce it by 25 bytes per frame with a little optimization, but not much more than that. An option for a longer game would be generating the sprite code on load, or simply storing the sprite code compressed.

 

Have Fun!

 

Not sure , if such need optimizations. If you mix them with "high" speed elements. 

Slow moving objects move in software Sprite resolution steps, fast moving objects move in character mode steps.

Character mode movement should be used for anything that moves diagonal....

 

In that solution PMg is really fitting to the protagonist , and use the characters for shots, and other needed elements, the game demo is already there. On machines with more than 64K it could be useful pre-roll all moving elements. Interrupts, for controls and game logics can be placed almost everywhere, because there are enough cycles free on every scanline, to do something.  

 

The impression of a fluid gameplay is given by the nice scrolling effect, and if the main "enemy element (wich is moving vertically) is doing that on a pixel exact level. The PMg is allowed to do that without restriction. 

Plain horizontal or vertical shots could be done with Missiles, while more complex shots should take use of Characters ...

 

If you put that together, you have the same type of hardware usage as in Drop Zone, btw.  . The difference is that those character clusters not just move "software Sprites" , it also resembles parallax scrolling. 

 

 

 

 

Share this post


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

Hi!

Thanks!

 

Looking at the listing file, in that demo, the "sub" is one frame of 356 bytes, and the "squid" is 4 frames at 1306 bytes total (so about 327 bytes per frame).

 

I could reduce it by 25 bytes per frame with a little optimization, but not much more than that. An option for a longer game would be generating the sprite code on load, or simply storing the sprite code compressed.

 

Have Fun!

Is 356 bytes for sub with 4 different left-right shifts ?

How many lines vertically is a sub sprite ?
If it's similar to 3 wide x16 high x4 shifts = 192 bytes (~1:2 ratio compared to unrolled code), then it's not that bad if speed is of importance.

 

Share this post


Link to post
Share on other sites

Hi!

4 hours ago, popmilo said:

Is 356 bytes for sub with 4 different left-right shifts ?

No, the sub has only one shift, that's why it does not move horizontally in the demo. I think that having sprites without shifts is valid in this scenario where the background is shifting.

 

4 hours ago, popmilo said:

How many lines vertically is a sub sprite ?

It's 13 lines, exactly 12x13 pixels, 39 bytes. Including mask, you could store it in 78 bytes. So, the code expands about 4.5 times the data.

4 hours ago, popmilo said:

If it's similar to 3 wide x16 high x4 shifts = 192 bytes (~1:2 ratio compared to unrolled code), then it's not that bad if speed is of importance.

Yes!

 

Have Fun!

Share this post


Link to post
Share on other sites

@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 😶

Edited by rensoup

Share this post


Link to post
Share on other sites
44 minutes ago, rensoup said:

@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 😶

Possibly you had a look at your version again ?

 

That "Jitter" imagination could result from the same color  "white" in the lower part and the moving objects. 

Share this post


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

@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 like there is some bug in scrolling or just raster catching up to on-screen changes.


Take a look at yellow arrows pointing towards pixel columns.

 

image.png.8a32ee26396070ab567ce18b48b391ed.png

Share this post


Link to post
Share on other sites
13 minutes ago, popmilo said:

Looks like there is some bug in scrolling or just raster catching up to on-screen changes.


Take a look at yellow arrows pointing towards pixel columns.

 

image.png.8a32ee26396070ab567ce18b48b391ed.png

 

Isn't it ridiculous ? Some Pixel irregularity , compared to … nothing ? 

The Routine isn't 100% working, needs some fixing. Is there a definition available? Something like Nitpicking on a drug level?

 

 

 

Share this post


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

 

Isn't it ridiculous ? Some Pixel irregularity , compared to … nothing ? 

The Routine isn't 100% working, needs some fixing. Is there a definition available? Something like Nitpicking on a drug level?

Man.... I don't know what is that "nothing" you mention...

I'm just commenting on rensoup's comment about possible jitter in bottom and pointing dmsc what it could be.

 

You yourself said "Jitter imagination could result from the same color  "white" in the lower part and the moving objects."

 

Well it's not imagination. It's real. I've had errors like that happen to me when coding and checking in debugger cycle by cycle. Something you maybe haven't done in a while ;)

 

Imho it's most probably as I said - raster beam going over parts of screen that are drawn over at that moment. If it's not, no harm, just move on.

 

  • Like 2
  • Thanks 1

Share this post


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

 

Isn't it ridiculous ? Some Pixel irregularity , compared to … nothing ? 

The Routine isn't 100% working, needs some fixing. Is there a definition available? Something like Nitpicking on a drug level?

 

 

 

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.

  • Like 4

Share this post


Link to post
Share on other sites
30 minutes ago, popmilo said:

Man.... I don't know what is that "nothing" you mention...

I'm just commenting on rensoup's comment about possible jitter in bottom and pointing dmsc what it could be.

 

You yourself said "Jitter imagination could result from the same color  "white" in the lower part and the moving objects."

 

Well it's not imagination. It's real. I've had errors like that happen to me when coding and checking in debugger cycle by cycle. Something you maybe haven't done in a while ;)

 

Imho it's most probably as I said - raster beam going over parts of screen that are drawn over at that moment. If it's not, no harm, just move on.

 

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.

Share this post


Link to post
Share on other sites

Hi!

3 hours ago, popmilo said:

Looks like there is some bug in scrolling or just raster catching up to on-screen changes.


Take a look at yellow arrows pointing towards pixel columns.

 

image.png.8a32ee26396070ab567ce18b48b391ed.png

Yes, this is because I'm racing the beam to draw all the screen without double-buffering, and in this part the font was scrolled before displaying the line.

 

Attached is a version fixed to always wait for scrolling the charset just after the line is displayed. I also fixed the "horrible mountains" 😛 :) 

 

 

 

subfnt.xex subfont.zip

  • Like 7

Share this post


Link to post
Share on other sites
8 hours ago, rensoup said:

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.

Nice , how you distract from your own position ;) 

dsmc's version shows something real. Just some "off" Dots (seems also fixed now) . Your version showed full Jitter on everything (not seen any fixed version yet) , but seeing you picking other's nits ;)

 

The real ridiculous part is that things weren't allowed on the Atari. While other Platforms have "Doom" "Wolf 3d" , Games that originally couldn't be there  caused by the given specs. Well, they all have some issues, some flaws, just like low update speeds, color clash, jitter, … whatever …  But they work as games and using the playable content of the Original.

 

On the Atari ?

 

"OMG... there is no full fps, it's not worth to port.. "

"HAHA... Me seen some weird pixel, the whole game would be crap.. "

"GRRR... I'm the best, even if nothing else works, I broke the weirdness record. "

 

poor little Atari 

 

 

Share this post


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

If racing the beam is on edge at PAL you run into troubles on NTSC.

Not at that screen height . You know: VBI Time and stuff. 

Share this post


Link to post
Share on other sites
16 hours ago, rensoup said:

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.

In his 35+ history "codng" all he did is an image with a scroll:

https://demozoo.org/sceners/35955/

 

I have to say its quite technological achievement. All other 8-bit platforms cant keep up and envy us.

 

Generally it can be two ways: he is a persisent troll or mentally ill person.

 

pure lamer - thats for sure.

 

just ignore him, its the best you can do.

  • Like 2

Share this post


Link to post
Share on other sites
56 minutes ago, solo/ng said:

In his 35+ history "codng" all he did is an image with a scroll:

https://demozoo.org/sceners/35955/

 

I have to say its quite technological achievement. All other 8-bit platforms cant keep up and envy us.

 

Generally it can be two ways: he is a persisent troll or mentally ill person.

 

 

Is your world really that tiny.

I feel sorry for you. 

 

 

 

Share this post


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

Nope, nobody knows what you're talking about.

Of course you don't understand. That's why you don't listen. 

Heaven needs no explanation about Vertical Blank and then he mixes it up with racing the beam. 

Ever seen a Vertical Blank ? 

 

But a small hint: The CPU time per scanline is the same on PAL and NTSC. 

 

Edited by emkay

Share this post


Link to post
Share on other sites

I'd not reply to the troll or even quote him, he feeds off that...

 

But on a more interesting note, I'm loving the work on the game engine, most of its a bit too tech for me but its just fun to read and makes me want to try a bit of coding again. Nearest I got back then was a smooth scroll screen, a background and some awful sprites sat doing nothing on it....I liked it :)

 

Seeing it done properly is great...

  • Like 4

Share this post


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

I'd not reply to the troll or even quote him, he feeds off that...

 

But on a more interesting note, I'm loving the work on the game engine, most of its a bit too tech for me but its just fun to read and makes me want to try a bit of coding again. Nearest I got back then was a smooth scroll screen, a background and some awful sprites sat doing nothing on it....I liked it :)

 

Seeing it done properly is great...

 

How great is that ? He has no clue about what's inside the Atari. Forcing the wrong solution, as the Thread is about the game and not about narcissistic presentations.  The only common is the used graphics.

Is it caused just for trolling purposes, or is there some dark truth behind it ;) . Just like some C64 Freak don't want to have things done on the Atari, for some evil sake ;)

 

Edited by emkay

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...