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

[Heaven/TQA]

At plus4world.powerweb.com/forum you have the coders explaining some of the tech.

 

in German RETURN magazine is interview of one of the coder.

 

coder Bubis find a trick to fool TED to position screen horizontal so similar maybe to VSP on the C64 (mayhem in Monsterland tech) so they don’t need to move all data with the cpu and esp color ram, too while scrolling.

 

its single buffer (not double buffering) has some 17 software sprites on screen and largest level is 25 screens in x and 4 screens high... level is depacked on the fly.

[emkay]

7 minutes ago, Heaven/TQA said:

At plus4world.powerweb.com/forum you have the coders explaining some of the tech.

 

in German RETURN magazine is interview of one of the coder.

 

coder Bubis find a trick to fool TED to position screen horizontal so similar maybe to VSP on the C64 (mayhem in Monsterland tech) so they don’t need to move all data with the cpu and esp color ram, too while scrolling.

 

its single buffer (not double buffering) has some 17 software sprites on screen and largest level is 25 screens in x and 4 screens high... level is depacked on the fly.

On the Atari this equals somehow with LMS plus charset rotation. 

[+Stephen]

Would it have been more clear if I stated it looks like much of it is "do pixel, move pixel"?

[emkay]

6 minutes ago, Stephen said:

Would it have been more clear if I stated it looks like much of it is "do pixel, move pixel"?

Just some lesson...

 

free movement:

 

 

 

Do a Pixel , move a pixel:

 

 

 

You get the difference in the controls.

[+Stephen]

Picture's worth a thousand words.  Got it - thanks.

 

Reminds me - need to play Atari Blast, it's been a while.

[rensoup]

6 hours ago, Heaven/TQA said:

At plus4world.powerweb.com/forum you have the coders explaining some of the tech.

 

in German RETURN magazine is interview of one of the coder.

 

coder Bubis find a trick to fool TED to position screen horizontal so similar maybe to VSP on the C64 (mayhem in Monsterland tech) so they don’t need to move all data with the cpu and esp color ram, too while scrolling.

 

its single buffer (not double buffering) has some 17 software sprites on screen and largest level is 25 screens in x and 4 screens high... level is depacked on the fly.

 

Looks very nice... I thought it was 320 res but it's still 160

 

I found a bit of info here: http://plus4world.powweb.com/forum/38581 

 

Quote

It's bitmap mode.

 

The sprites can be painted in a slower way.. (ranges from 2nd to 5th frame most time more like 25 fps to 12fps..) So the scrolling is done with 50 Hz and the sprites are painted slower..

Btw.. From my view the biggest achivement which made this game possible is the singlebuffer

And yes we mask the sprites if needed.

He says he uses bitmap mode (but he doesn't remember why)

 

Some sprites update at 12fps which is too slow, it's painful to watch and play sometimes. And not all sprites are masked.

 

I find the most impressive aspect is the amount of colors.

 

 

[TheNameOfTheGame]

18 minutes ago, rensoup said:

 

Some sprites update at 12fps which is too slow, it's painful to watch and play sometimes. And not all sprites are masked.

 

I find the most impressive aspect is the amount of colors.

 

 

Yes, I find 25 fps acceptable, but when it gets down to 12 fps that's too low for me.  Colors are good and that's what intrigues me about your project. There is a lot of potential here with your enthusiasm and coding skill and José's imagination and infectious optimism.  Please don't get dragged down and discouraged by the naysayers.  Keep true to your vision and see where it goes.

[rensoup]

20 minutes ago, TheNameOfTheGame said:

Yes, I find 25 fps acceptable, but when it gets down to 12 fps that's too low for me.  Colors are good and that's what intrigues me about your project. There is a lot of potential here with your enthusiasm and coding skill and José's imagination and infectious optimism.  Please don't get dragged down and discouraged by the naysayers.  Keep true to your vision and see where it goes.

Yes it looks good enough that it fooled me into thinking it was higher res! So the only thing that makes it stand out is it use of colors (and nice art) because it terms of pixel pushing power it seems fairly average.

 

I'm not bothered by people arguing around me ?. What's discouraging is when I optimize some piece of code and the setup code for the optimization wastes all the gains which happens a lot because the 6502 is unfortunately a piece crap.

 

Still the results are semi encouraging... so hopefully a semi update will be on the way soon ?

 

 

[Heaven/TQA]

6502 piece of crap...  it’s our RISC.... compared to bloatware like intel x86 or 68k haha  but yeah sometimes 6502 is hard... no pain no gain...

Edited August 22, 2019 by Heaven/TQA

[emkay]

3 hours ago, TheNameOfTheGame said:

Yes, I find 25 fps acceptable, but when it gets down to 12 fps that's too low for me.  Colors are good and that's what intrigues me about your project. There is a lot of potential here with your enthusiasm and coding skill and José's imagination and infectious optimism.  Please don't get dragged down and discouraged by the naysayers.  Keep true to your vision and see where it goes.

Two people on an Airplane:

 

Hey, what you are doing ?

 

- I want to jump outside

 

I'd propose to use a Parachute then

 

- No need. I can jump without one.

 

Believe me, you need one, if you want to survive. It don't work without one.

 

…. man is jumping without a parachute. 1m before hitting the ground…

 

- Haha... It still works. Who cares about Naysayers

 

…. a harsh sound following... 

 

...Man on the Airplane : " Someone wants a Parachute? " 

Edited August 22, 2019 by emkay

[popmilo]

3 hours ago, rensoup said:

Yes it looks good enough that it fooled me into thinking it was higher res! So the only thing that makes it stand out is it use of colors (and nice art) because it terms of pixel pushing power it seems fairly average.

I'm not bothered by people arguing around me ?. What's discouraging is when I optimize some piece of code and the setup code for the optimization wastes all the gains which happens a lot because the 6502 is unfortunately a piece crap.

Still the results are semi encouraging... so hopefully a semi update will be on the way soon

 

Would love to hear about what sort of optimization you tried. And to see new update

That plus4 game has one interesting tech. That char based marking system with bits for "sprite exists" in last, current frame... That's something that could help drawing soft sprites...

[Rybags]

It looks like the player's shots are character boundary aligned which would save some rendering time - and collisions appear to take place on char boundaries too.

But the game does look impressive - even the music isn't bad for TED (which essentially is like running 2 Pokey 16-bit voices except without anything other than square or noise and with less frequency range).

[TheNameOfTheGame]

5 hours ago, Rybags said:

It looks like the player's shots are character boundary aligned which would save some rendering time - and collisions appear to take place on char boundaries too.

But the game does look impressive - even the music isn't bad for TED (which essentially is like running 2 Pokey 16-bit voices except without anything other than square or noise and with less frequency range).

Yeah, it looks like the shots are char aligned.  That was the one thing that was a bit jarring to me.  The movement was a little too chunky.  But I agree it's an impressive game for using soft sprites.

[Faicuai]

On ‎8‎/‎18‎/‎2019 at 11:48 AM, popmilo said:

I think we agree that mode D is good for some things. Zybex shows how much can atari move around. Go to mode E and you'll be able to move that much with less speed, or just reduce number of objects... Zybex is just an example of game on atari with soft sprites.

What does it matter that plus4 came later than a8 ?
CPU speed is almost the same, gfx mode is simplest possible char mode with 4 colors.
No mention of using plus4 palette. 128 vs 256 chars is pointless as we do now have interleaved char mode lines tech, invented by yours truly Jose (Yes, by actually doing something all the time he does push boundaries on a8 coding no matter what you say...).

 

"Scrolling don't waste cycles" ? And on atari it does ? With hscroll and lms it's ultra easy.
Maybe you thought of hires pixel scroll, but nobody is even trying to do that here...

 

Xeo3 has nothing miraculous about it. Charmode, 8x16 soft sprites, char bullets, scrolling screen.... It can be done on atari with 95% same code, just replace screen layout from simple to 4 interleaved chars.

 

Here are examples of similar sprite engine on atari. These are even better then xeo3 routines as they work with full masking and background.

1942_50fps_6sprites.xex 19.36 kB · 17 downloads 1942_25fps_12sprites.xex 19.37 kB · 19 downloads

Just a big favor (if possible):

 

I have been very closely looking at these two tests, as well as the Char_Sprites one.

 

In turns out that the choice of "abstract" background pattern with moving sprites, and scrolling background (as in Char_Sprites test) turns out to be a FANTASTIC test for any de-interlacer / scaler / video-processor attempting to properly lock and decode 240p signal (from Atari).

 

Would it be possible to have "Char_Sprites" (first test) background scrolling (AND stopping, periodically) from right-to-left, and also alternating from left-to-right and diagonally as well? (either 25 or 50 fps, whatever is easier)

 

This would be AWESOME

 

 

 

Edited August 22, 2019 by Faicuai

[emkay]

16 hours ago, rensoup said:

 

Looks very nice... I thought it was 320 res but it's still 160

 

I found a bit of info here: http://plus4world.powweb.com/forum/38581 

 

 

Color dithering helps a lot there. In many circumstances solid colors help more than higher resolution.

You're not satisfied with the Atari's  abilities? Just keep in mind that the hardware is from the late 70s. The C16 HW is from 1984. So , OFCOURSE, it can look better there. 

 

Quote

He says he uses bitmap mode (but he doesn't remember why)

 

Some sprites update at 12fps which is too slow, it's painful to watch and play sometimes. And not all sprites are masked.

 

I find the most impressive aspect is the amount of colors.

 

 

 

Actually, I didn't find yet, how that "bitmap" mode is working. On the C64 and the CPC they talk about bitmap mode, but in real it is a remapped character mode. 

 

Edited August 22, 2019 by emkay

[popmilo]

5 hours ago, Faicuai said:

Would it be possible to have "Char_Sprites" (first test) background scrolling (AND stopping, periodically) from right-to-left, and also alternating from left-to-right and diagonally as well? (either 25 or 50 fps, whatever is easier)



This would be AWESOME

Something like this ?

 

char_sprites.xex

[Faicuai]

1 hour ago, popmilo said:

Something like this ?

 

char_sprites.xex 19.8 kB · 5 downloads

 

Mhmm... this file is binary the same as the first version... they are identical (no changes)...

 

What I meant is the for background (blue abstract pattern) for scrolling right-to-left, but left-to-right and up-down... with periodical (fixed) stops (no scrolling) along the way or simply stopping upon pressing a key, and then resuming scrolling upon pressing any key as well.

 

This would be a KICK-ASS 240p decoding / scaling test (!!!)

 

[rensoup]

On 8/22/2019 at 7:23 AM, Heaven/TQA said:

6502 piece of crap...  it’s our RISC.... compared to bloatware like intel x86 or 68k haha  but yeah sometimes 6502 is hard... no pain no gain...

MOS 6502, the 1 register RISC processor ?

 

But seriously when you'd rather make a table than do a 16bit shift/add operation, it gets a little silly.

[rensoup]

On 8/22/2019 at 9:07 AM, popmilo said:

Would love to hear about what sort of optimization you tried. And to see new update

That plus4 game has one interesting tech. That char based marking system with bits for "sprite exists" in last, current frame... That's something that could help drawing soft sprites...

 

Well, I digressed again so here's your very own update ?

 

 

I managed to get 13 planes at 50hz but the screen is only 184 lines... not as good as I hoped...

 

(they can all be different sprites of course)

 

Back to our regular schedule ?

 

spr1943.obx

[rensoup]

On 8/22/2019 at 2:37 PM, TheNameOfTheGame said:

Yeah, it looks like the shots are char aligned.  That was the one thing that was a bit jarring to me.  The movement was a little too chunky.  But I agree it's an impressive game for using soft sprites.

The main sprite actually jitters left and right... very glitchy but the wow factor prevails.

[rensoup]

 

And here's that semi update ?

 

 

I just focused on the ModeE precompiled sprites so there's NO SCROLLING YET

 

Managed to get 10 12x13... probably not where it needs to be because I'm expecting a big drop in performance once I get the scrolling going. Plus it's going to take massive amounts of memory...hopefully it'll still fit in 64KB

 

The precompiled sprites are fairly standard I guess:

-Immediate mode AND/OR for regular sprite data

-skip everything if no sprite data

-immediate mode LDA for full sprite data

 

The one thing I'm not sure others do, is to store the screen pointers (one per sprite line) in the ZP so when I draw a sprite I don't need to draw each line individually, I just jump to the code and return once everything is drawn.

Of course updating these ZP pointers is costly (and needs to be done when clearing too) but still the performance is decent.

 

The background restore is a bit more problematic and I think slower than the actual drawing!!  There's no precompiled code for this part and I'm not sure if it would work that well.

 

For the 1943 update I draw vertical slices which is about 10-15% faster than horizontal drawing and takes less memory. It should work for vertical/horizontal scrollers but it's probably not very good if there is parallax.

This subhunter update draws horizontally which will work better with all these parallaxes.

 

I'm going to focus on the scrolling and perhaps revisit the sprite restore later.

 

subh2_0824.obx

[emkay]

6 hours ago, rensoup said:

 

And here's that semi update ?

 

 

I just focused on the ModeE precompiled sprites so there's NO SCROLLING YET

 

 

Sorry for sounding harsh, but "no scrolling yet" means there is still no demonstration of what's needed. 

There is still no animation in the objects and they all look the same, they move in the same direction. And so on. 

There are 5 or 6 character mode lines missing for the complete screen. 

Then: If you want to use GPRIOR 0 or generally color enhancements, using PMg , you should exchange the black color and the background.  

 

Btw: Have you ever tried to fold a sheet of paper more than 8 times per hand?

[emkay]

You know this one?

 

Some Scrolling, more than 30 animated sprites, but even this one didn't evolve in a game yet. 

 

To make it short: If you want to show an engine that allows to have 20 real moving objects, the engine should handle even more , because it doesn't handle the game "yet" . 

 

 

[gorgh]

rensoup: that looks awesome, is this your own software sprites routine?

[rensoup]

1 hour ago, gorgh said:

rensoup: that looks awesome, is this your own software sprites routine?

Thanks, yes it's modeE though, because from my first test with mode4, precompiled sprites and parallax don't mix well.