Cybernoid WIP

[José Pereira]

16 hours ago, rensoup said:

Seems a little wasteful to use PM0/1 just for those red mines (and borders). perhaps it would be possible to make the red part smaller ? 

 

like this ? (just make the inner part red)

On C64 it's using same colours and we could go this way but we can't because the ball(s) go over the gfxs (it'll then clash PF2/PF3):

To prevent this we have it using P0 (2nd P1) that is red then Oring PF0 (2nd red) and PF1 white (or a pink if Oring this).

Having the two same red gives the 2Missiles for free to cover the sides borders.

 

You probably don't know why the reason on C64 all moving things have exactly the same 3colours, don't you?

Is was clever decision from the coder (don't know if anybody else or any other game on C64 or other Machines with hardware sprites uses it):

The game is in C64 Bitmap Multicolour mode so is black then 3 own colours per char but moving things chars are always white, lilac and dark blue because sometimes they're software sprites/chars (you can have lots of them on screen >8 of the c64 hardware sprites) but when one/some start moving then turn to hardware sprites (when these and always there's only 8 at a time on the screen) but if explosions (diiferent colours are always hardware sprites) occurs/exceed 8 they can return to be software ones.

This was discouvered and said to me by @JAC! while we're talking and getting these things and ways to a possible A8 version of the game (that is indeed Cybernoid 2 though it could be also 1).

If @JAC! gets here he for sure will explain you better this approach...

[Gunstar]

I was just playing the Atari ST version of Cybernoid that was ported to the Atari Jaguar last night. I was actually pleasantly impressed with the graphics and animation of that version, and for the Atari 8-bit, this impresses me equally and if the animation is near as smooth, more so...it's looking very Amiga jr.-esque!

[rensoup]

8 hours ago, José Pereira said:

To prevent this we have it using P0 (2nd P1) that is red then Oring PF0 (2nd red) and PF1 white (or a pink if Oring this).

Ah right...

 

8 hours ago, José Pereira said:

The game is in C64 Bitmap Multicolour mode

I didn't remember much of the game (played it on the ST) so I checked it and there's a lot of sprites when there are explosions... not sure Mode4 can cope with that (CPU and Memory). Probably better suited for ModeE

 

[Steril707]

My problem with the "interleaved softsprite charset" approach is, that with 127 chars at disposal you barely have any room to wiggle.

 

The way I understand it, you have to have a copy of all chars used in that screen in each of the individual charsets, isn't it?

That plus all the objects and animations seem to make a tight space in there.

[rensoup]

18 hours ago, Steril707 said:

The way I understand it, you have to have a copy of all chars used in that screen in each of the individual charsets, isn't it?

That plus all the objects and animations seem to make a tight space in there.

I've not used it myself, I prefer modeE but I would think you'd only copy the chars needed for each line where the charset is used on the screen,

 

so 

 

line0: charset0

line1: charset1

line2: charset2

line3: charset0

...

 

charset0 would only contain the chars used on line 0/3/... which could be the whole charset indeed if you're unlucky. Plus some empty space for the soft sprites... 

 

soft sprites worst case would be space ship + 8 explosions + missiles, 2 mines + mine trails + enemies + projectiles, potentially 3 + 8*2 + ?*3 + 2*3 +  ?*2  + ?*3 + ?*2 = a lot! potentially half of the charset ? 

[Steril707]

Hmmmmm.

 

but then you cannot smooth move the soft sprites vertically, can you?

But you could write new chars into the charset for animating. But then every object of that type would need to be animated on that line.

 

Damn; I am too stupid for this ...

[popmilo]

Imho "plus" side of interleaved charsets is:

- You get 5th color which is really nice.

For example with 3x3 chars large sprites:
- 4 different charsets are enough
- You shift gfx data inside 4x4 char matrix 0..7 pixels depending on lower three bits of coord (or 2bits for horizontal axis when using multicolor mode with 2x1 pixel size).

- in each of those charsets you only use "sprite_width +1" chars for each sprite. So three chars wide sprite needs only 4 chars per screen charline.

 

Something like 8 large sprites (3x3) and ten smaller sprites (2x2) would need 8x4=32 + 10x3=30, total = 62 chars per charset.
66 left for background in a screen flip game sounds pretty good to me.

 

On the negative side:

- it's f....ing complex
- you need interrupt each character line to change charset.

- screen layout is crazy complex. Combining shifting data vertically with 8 by 8 bytes layout with different offsets for each charline is a headache.

- you need to restore background char codes on position where soft sprite used to be.

- have to draw new charcodes where sprite will be

- draw shifted gfx into those chars.

 

Still it can be really nice and something different on Atari that we haven't seen before if I'm not mistaken.

Here is how 14 x 2x2 sprites look like in 25fps (on a real atari it's really fluent, sorry for bad video).

 

 

[popmilo]

Here are two examples using interleaved charset method.

char_sprites.xex char_sprites2.xex

[Steril707]

Okay, thanks for trying to explain this to me...

 

Does this mean, you keep your soft sprite data in some kind of buffer for each object, ROR these (or have them preshifted in memory), and then "blit" these into the screen at those reserved charset positions each and every frame then?

 

And the number of charsets you need is the height of the biggest soft sprite+1?

 

How about objects that are on different Y positions at like one charline difference? Would you need to change the charset midline for that? 

I still cannot wrap my head around this at the moment... 

Edited September 16, 2022 by Steril707

[Steril707]

After using some paper and a pen, I think I understand it.

Sounds like it needs a sorting algorithm out of hell, though.

 

It's basically this, isn't it?

 

(edit: Not, that doesn't work... lol. the second 0-row would show the chars of the first one then, means the first object's bottom would show the thirds object's top)

 

 

Edited September 16, 2022 by Steril707

[Steril707]

This is it.

 

 

Positions of the numbers are arbitrary here.

These "chars" in the charset are just placeholders, not your asset data.

You need to calc (probably with a modulo operation, or better use a LUT) which charset to copy your data to, whether it's preshifted or ROR/ROLed in real time.

 

(mumbling to myself here, sorry if this stuff is obvious to you guys... )

 

Edited September 16, 2022 by Steril707

[popmilo]

Love your hand written notes

You got it right. Each sprite uses 3 chars in each charset.
You get address of each char with some simple math and yeah you can use modulo etc for it.
Think I've made lut for charset base for each screen row.
Then when going down in single sprite I add offset to next row also from table.

 

For each character on screen where ever it is, based on screen row:

0 offset to next char is 1024 (size of first charset)

1 offset to next char is 1024

2 offset to next char is 1024

3 offset to next char is -3072

4 offset to next char is 1024 (size of first charset)

5 offset to next char is 1024

...

..

etc. till last row 24

 

My routines above work with preshifted data, no way you can get away with lsr+ror etc... My guess with modern Atari games is that we shouldn't avoid using cartridges with large size etc...

 

[Steril707]

9 minutes ago, popmilo said:

Love your hand written notes

Haha, thanks...

9 minutes ago, popmilo said:

My routines above work with preshifted data, no way you can get away with lsr+ror etc... My guess with modern Atari games is that we shouldn't avoid using cartridges with large size etc...

Makes sense...

[José Pereira]

For Cybernoid the interleaved charsets will not work because there's too too much chars.

Static/gfxs things are in [2x2]chars tiles and a screen is 20chars high so 2,4,5,10,20charsets would go but no way (but 5 isn't a multiple of the tiles 2chars high).

Even with others numbers have a look for Cybernoid_2 level_1 map cleaned/just with the gfxs (the gfxs are the same on all levels):

     

So the only way to build the game levels is going into 'mimic bitmap mode' that is (a single/charset_0 is more than enough for the status panel):

-> charline_1  /  charset_1;

-> charline_2  /  charset_1;

-> charline_3  /  charset_2;

-> charline_4  /  charset_2;

->       ...        /       ...      ;

->       ...        /       ...      ;

-> charline_19 / charset_10;

-> charline_20 / charset_10;

 

The chars on each charset are 0 (black left and right) as the playing area is in 38chars wide then for the 2 charlines will be:

-> 0 / 01 -> 38 / 0;

-> 0 / 39 -> 76 / 0;

77chars;

Our ship is [3x2]chars so with moving/shifting needs a total of [4x3]chars = 12chars but only in 2charlines  = 8chars;

The 2 stars around our ship [2x2]chars so with moving/shifting needs a total of [3x3]chars x 2 = 18chars but only on 2charlines (when 2 at the same ones) = 12chars;

 

77 + 8 + 12 = 97chars;

31chars free per charset / per 2charlines maybe enough...

 

A screen [40x25]chars in bitmap mode on C64 (same if on A8) = 40Bytes x 200scanlines = 8000Bytes (a bit less than 8KBs).

On A8 we would have:

-> 1KB (1charset on A8) for the status panel;

-> 10KBs (10charsets on A8) for the playing area;

A total of 11charsets = 11KBs so more 3KBs than on C64 maybe go though we have lots more KBs 'wasted' on the large PMGs PM2 & PM3 colouring the gfxs.

 

 

 

Edited September 16, 2022 by José Pereira

[popmilo]

@José Pereira you calculated number of needed chars as if it's a scrolling map and not screen by screen game ?

 

If we look at each screen as a separate, I feel like there isn't many different chars on each ?
On the other hand why aim for total 100% copy of c64 gfx ? Just draw nice gfx, new levels, new enemies ? Make a Cybernoid 3 exclusive for Atari

 

[zbyti]

@popmilo no more old games in XXI 

Edited September 16, 2022 by zbyti

[José Pereira]

39 minutes ago, popmilo said:

@José Pereira you calculated number of needed chars as if it's a scrolling map and not screen by screen game ?

 

If we look at each screen as a separate, I feel like there isn't many different chars on each ?
OnA da qA the other hand why aim for total 100% copy of c64 gfx ? Just draw nice gfx, new levels, new enemies ? Make a Cybernoid 3 exclusive for AqqãZSda Av ftari

 

Other than some outside ground, like the large plant or tiver, almost all are allways present.

Whatever be if 3 there"ll be allways Number of chata problem.

The 'mimic bitmap mode' is the only possible 

You and your quick so easy solutions 😉😁... 

 

 

 

 

[rensoup]

16 hours ago, popmilo said:

Imho "plus" side of interleaved charsets is:

- You get 5th color which is really nice.

5th color has nothing to with interleaved charsets though ?

 

8 hours ago, José Pereira said:

For Cybernoid the interleaved charsets will not work because there's too too much chars.

Static/gfxs things are in [2x2]chars tiles and a screen is 20chars high so 2,4,5,10,20charsets would go but no way (but 5 isn't a multiple of the tiles 2chars high).

Interesting examples but can you post a screenshot with a single charset ? It seems really odd that this game would have more than 256 chars... 

 

Perhaps a bug, either with the tool or with the source picture which contains the same chars but with slightly different colors thus counting them as different chars ?

 

Can you post a few screenshots with a single charset where the source picture is one single screen of the game (like the start screen, the screen with the big plant, and the screen with the tall monster on the left wall ) ?

 

8 hours ago, José Pereira said:

77 + 8 + 12 = 97chars;

31chars free per charset / per 2charlines maybe enough...

Now just add double buffer requirements

 

The problem is that you have to keep an awful lot of free space which isn't used most of the time. Really wasteful and would probably push the mem requirements above 64KB

 

Mode4 is a letdown again...

Edited September 16, 2022 by rensoup

[José Pereira]

No computer on weekend to post that but is no bug. It's using bitmap mode on C64 (and on all other versions) so is easy to undertstand for them the number of chars wasn't a problem. 

Just download a screen from www.lemon64.com or ready64.com and take it to an extraction program...

 

 

[popmilo]

10 hours ago, zbyti said:

@popmilo no more old games in XXI 

Yeah

Honestly, I'm all for conversion of unique, complex games like Elite or Stunt car racer ... Math, physics, procedural generation, that's hard to write again from scratch...

 

But why would we try to convert 1:1 "simple 2d flip screen shooter" ?
Ok if it's easy, go for it, but if original game (like Cybernoid) uses bitmap with 3 colors per tile, soft sprites for effects and weapons, plus hw sprites, I say (gently) "avoid it"

 

Take the main idea about gameplay, but execute it with A8 methods. Make sprites 8 pixels wide (2 chars) so players can be used for them, use dli to change colors per scanline, make some enemies move more vertically to reuse same player for multiple enemies arranged in vertical direction etc... Don't take this as a gospel, I'm just brainstorming with morning coffee next to me. Have fun

 

ps. And now I'm going to analyse c64 Cybernoid game maps to see if number of chars is really that high

Edited September 17, 2022 by popmilo

[popmilo]

11 hours ago, rensoup said:

5th color has nothing to with interleaved charsets though ?

No connection. "Interleaved charset sprites" can work in hires mode for example.

 

Soooo..... I've downloaded Cybernoid 2 map files from vgmaps website, cleaned first level from enemy and player sprites.
This is what is left:

 

Didn't use converter that José used (I wrote that one years ago, and original python script doesn't run today on my new system because some libs were updated in the meantime)...

So I've used Charpad pro (c64 tool) to get char count in range of 470 or something like that... There are 134 tiles (16x16 pixels).
Game is using bitmap mode, so in c64 version there's no "char count". Everything is done with 8x16 tiles.

 

So I took first game screen and tried that. This is the result.

43 tiles, 147 chars.

Then I've figured those "eyes" around play area have no real purpose, so I've cleaned them, filled with black and got this:



Which produces this, 34 tiles made out of 113 chars.

[popmilo]

Ok. So I've fixed python script and it says this for first screen:

 

[popmilo]

Another screen:

[popmilo]

For entire level it counts like this.

So I don't see obstacle to use 4 charset inteleaved mode for separate screens, char count is bellow 64 which leaves plenty of space for >20 soft sprites. A8 can not draw more than that in any respectable framerate anyway

 

[rensoup]

16 hours ago, popmilo said:

But why would we try to convert 1:1 "simple 2d flip screen shooter" ?
Ok if it's easy, go for it, but if original game (like Cybernoid) uses bitmap with 3 colors per tile, soft sprites for effects and weapons, plus hw sprites, I say (gently) "avoid it"

 

I'm not working on Cybernoid, I was just answering Youxia in the PoP thread 

 

JP' mockup is very interesting and a good startup point for brainstorming. That said, it doesn't look impossible!

 

16 hours ago, popmilo said:

Take the main idea about gameplay, but execute it with A8 methods. Make sprites 8 pixels wide (2 chars) so players can be used for them, use dli to change colors per scanline, make some enemies move more vertically to reuse same player for multiple enemies arranged in vertical direction etc... Don't take this as a gospel, I'm just brainstorming with morning coffee next to me. Have fun

I doubt that it would be less work in the end... It would be less time spent on pushing the hardware though. 

 

Perhaps I'll try a graphics test in the future 

 

11 hours ago, popmilo said:

Ok. So I've fixed python script and it says this for first screen:

 

That's actually lower than I thought...

 

11 hours ago, popmilo said:

So I don't see obstacle to use 4 charset inteleaved mode for separate screens, char count is bellow 64 which leaves plenty of space for >20 soft sprites. A8 can not draw more than that in any respectable framerate anyway

Indeed!

 

4 charsets + 1 charmap = 5KB if I recall, x2 for double buffer. That's actually really low... I'm wondering if there would be even more savings if you used a few more charsets and only double buffered the empty space ?

 

Could you try to run that first pic with 6 charsets and see if it goes down to about 40 for each ?

 

Perhaps mode4 isn't that useless...