Cybernoid WIP

[José Pereira]

Going further with some more:

status screen 32Bytes wide.xex

Here you can see that there's no clash because is only PF2 now in-use.

For PF3 will talk later as is also not used PM0&PM1 waiting to answer(s)...:

23 hours ago, José Pereira said:

For PM0 and PM1 will see...:

On 9/20/2022 at 4:59 PM, José Pereira said:

P.s.- @mariuszw like all others we did on the past applying PMGs to get more colours you think to better use PMGs for colouring gfxs / static ones or can I use also on moving things (now I had on those add-ons *)?

You decide...

 

Depending on these is the solution for the * when going over the terrain pale green PMGs 2&3 there (is possible when our ship is right over the platform) that will or blue on them (here is my thoughts, one of, for the P0&P1)...

[popmilo]

Looking great José !

Can you please send g2f file of that latest xex ?

 

[José Pereira]

10 minutes ago, popmilo said:

Looking great José !

Can you please send g2f file of that latest xex ?

 

Tomorrow 😉...

 

[José Pereira]

Tomorrow is now  sohere's the screen with PF3 also in-use:

status screen 32Bytes wide.g2f

status screen 32Bytes wide.xex

 

-> PFs only:

-> PMGs only:

 

Regarding colours:

 

with the PMGs only (on those scanlines that we changed (all wide terrarin) BAK to pale green and PF2 to yellow pale need P2 and P3 red to cover the border sides):

 

Some little notes about PF3 gray:

-> makes different/distinctable mines and diamonds but also some other things (here those ships);

-> these ships similar to C64 (also use gray) and can be with no clash to the gfxs because they move in quadrangular movement (not go into other gfxs chars) on C64 and in all other versions including the ZX one.

Edited September 23, 2022 by José Pereira

[José Pereira]

Oops... forgot to add the back add-on weapon shots:

status screen 32Bytes wide.g2f

status screen 32Bytes wide.xex

status screen 32Bytes wide.g2f

Edited September 23, 2022 by José Pereira

[popmilo]

Well, that's what I was afraid of

Wanted to see in g2f how did you manage to get that many colors on screen at once. Of course it's possible, with almost each part of screen using different "trick".

Some parts have pm underlay, overlay, some parts you change colors using dli, etc...

Uf, kinda hard to code it in a game project. Each screen would have different routines, different data... You would maybe need kind of a script language to make nice data structures, that your realtime code could work from later on.

Hard, but not impossible.

 

[dhor]

C'mon... Game without scrolling? No matter how nice these screens are... We already have magic PoP, now... Time to use some scrolling. Don't get me wrong - cybernoid is a perfect game to be ported to atari (no scrolling, just screens). Fingers crossed!

[Steril707]

1 hour ago, dhor said:

C'mon... Game without scrolling? No matter how nice these screens are... We already have magic PoP, now... Time to use some scrolling. Don't get me wrong - cybernoid is a perfect game to be ported to atari (no scrolling, just screens). Fingers crossed!

What's your point, mate?

That nobody should port Cybernoid because it's not a scrolling game? 

[dhor]

3 minutes ago, Steril707 said:

What's your point, mate?

That nobody should port Cybernoid because it's not a scrolling game? 

You said that. I said - I would to see cybernoid on atari, screens are perfect. However, atari games don't use scrolling at all... Usually

[Steril707]

Just now, dhor said:

You said that. I said - I would to see cybernoid on atari, screens are perfect. However, atari games don't use scrolling at all... Usually

Mmh yeah. Which is weird. The Atari is extremely capable with its scrolling abilities actually.

[popmilo]

6 minutes ago, Steril707 said:

Mmh yeah. Which is weird. The Atari is extremely capable with its scrolling abilities actually.

Yeah, stick to 4 colors and scrolling is a no brainer

 

 

[José Pereira]

2 hours ago, popmilo said:

Well, that's what I was afraid of

Wanted to see in g2f how did you manage to get that many colors on screen at once. Of course it's possible, with almost each part of screen using different "trick".

Some parts have pm underlay, overlay, some parts you change colors using dli, etc...

Uf, kinda hard to code it in a game project. Each screen would have different routines, different data... You would maybe need kind of a script language to make nice data structures, that your realtime code could work from later on.

Hard, but not impossible.

 

No! that screen is an example.

It's nothing different than what we (@mariuszw and me) did on many others ZX ported games.

In Highway Encounter many types of PMGs ways and DLIs to get the screens coloured. ZX code ported 'straight-away' but had to get many different x and yPos for PMGs per screen/different type looking screens,... but in the end they're all coloured. There's 10, 20,.. don't remember because they're so much different that trying to remember and no head to try to get all that is inside (anyone with time and patience can unzip to see how the hell could we coloured the game screens but all have it):

Highway_screens.zip

 

I said there that on all the screens I'll colour gfxs using PMGs2 & 3 and only difference are mainly in top and bottom screens of the maps where all wide have the ground eyes gfxs so there it'll need the PFs (BAK and PF2 colours need to change but our ship or any other could not go there) instead of the PMGs.

Here's the maps (C64 each level and ZX all-in-one):

   

So for those marked with green (C64) and blue (ZX) squares the thing that you should do is just DLIs of 2colours while on middle screens of the map(s) can not be needed:

Quote

Here's a screen example:

status screen 32Bytes wide.xex

-> PFs only:    

-> PMGs only: 

(only using PM2&PM3 to colour gfxs in 32Bytes wide seems enough in most of the screens. In top and bottom screen has all its width the ground eyes plants gfxs so DLIs changing the BAK and PF2 colour and need to apply P2 and P3 there on where's that red)

 

When there's no all wide ground (that top start of playing area mess is no problem but no more time to fix it now):

status screen 32Bytes _2.xex4.92 kB · 11 downloads

-> PFs only:    

-> PMGs only:   

 

For PM0 and PM1 will see...

What's the problem in here/on this?

 

P.s.- Of course that can be, instead, the gfxs changed instead of those 'all wide eyes gfxs lines' then you can have it allways the same for all screens with these colours:

Quote

 

So playing area following these PFs colours like this:

-> BAK: dark blue (84);

-> PF0: allmost black/darkest gray (02);

-> PF1: white (0E);

-> PF2: light blue (88);

-> PF3: grays (status) /DLI/ gray or cyan (playing area);

 

On status area they're fixed, like I said,... on playing area you don't want to on certain screens change 2 PFs colours registers?

Do you need a script for what? screen_01/02/... set 2DLIs on top, screen_07/08/... all the same colours and no DLIs, screen 17/18/... set 2DLIs on bottom... so 3types of screen PFs colours distribution is what 1KB and a dozen or two of cycles cpu.

The code from ZX is the same, the game engine is the same, you're just adding LDA/STA 2colours on certain screens in A8 6502 inside the own/original Z80 code. Where's the problem and confusion here?

Edited September 26, 2022 by José Pereira

[popmilo]

Oho, slow down José

Don't worry, I didn't say it can't be done. I did say "Hard, but not impossible."

 

Sure, if you have everything else covered, if pm layout is fixed per screen, code each screen as separate part, it can be done, one by one. I admire your efforts, hope someone will take existing z80 code and make it work in multicolor mode.

 

[José Pereira]

1 hour ago, popmilo said:

code each screen as separate part, it can be done, one by one.

Not code each screen different, it comes from the ZX everytime.

'Behind this code' just set for each screen the colours for PFs (if needed) and PMGs. You have to do it anyway for the PMGs x and yPos per each screen...

For PMGs let's say that this is screen_01:

And this is other, like screen_31:

Other, screen_24 instead of the green creature have those C64 gray cannons (on A8 will be cyan metal blue colour_9 so PMG_2 or _3 needs a different pixels shape, colour and position.

Another, screen_32 have the grays towers on C64 that on A8 are another colour(s) so these PMGs colour(s), positions,... again change.

The game is static screen so each one PMGs and colours needs to change be in hi-res or in middle-res... certain cases also need a PF or two but nothing outstanding in my opinion.

 

Whatever gfxs are, for each screen they're all in different positions, colours, not the same gfxs,... that is why I refered Highway Encounter.

Usual @mariuszw work is after porting the Z80 code then he adds the A8 colours and PMGs to the correspondant needs, screen per screen.

Here I change the 1:1 into 2:1 ratio and only difference is that for the first time the bitmap ZX version will be turned into charmode but in a 'pseudo/mimic bitmap mode' on A8.

 

Want to start port the Z80 code? Ok. right after I change all the gfxs to 2:1 ratio you/him can (even can start using original 1:1 ZX ones).

Just use the 4+1colour after my rework. Put the things and the engine working using the Z80 code:

(only DLIs are in top PF3 grays and is for all the game because they're static and always there also are the inside things on the panel PMGs)

 

At the end Memory and cpu left I send you the PMGs and any PFs DLIs needing for the colourings ...

Edited September 26, 2022 by José Pereira

[mariuszw]

7 hours ago, popmilo said:

Well, that's what I was afraid of

Wanted to see in g2f how did you manage to get that many colors on screen at once. Of course it's possible, with almost each part of screen using different "trick".

Some parts have pm underlay, overlay, some parts you change colors using dli, etc...

Uf, kinda hard to code it in a game project. Each screen would have different routines, different data... You would maybe need kind of a script language to make nice data structures, that your realtime code could work from later on.

Hard, but not impossible.

 

I did something like that for Skool Daze 🙂 Every screen had its data for PMG (with simple RLE compression) and DLI (built like Copper lists and later expanded to 6502 code at runtime). The only problem with such approach is memory to fit data for all screens.

[José Pereira]

2 minutes ago, mariuszw said:

I did something like that for Skool Daze 🙂 Every screen had its data for PMG (with simple RLE compression) and DLI (built like Copper lists and later expanded to 6502 code at runtime). The only problem with such approach is memory to fit data for all screens.

Exactly. @popmilo isn't used to our tricks !...

[popmilo]

Ok, so we talk about the same thing, just using different words

All good, keep working on z80->6502 translation, drawing special pm layers for colors. In that time I'm coding a small sprite demo, just to see what can be done  Should be ready soon

 

[popmilo]

So, I think experiment is successful

 

Small demo of sprite routine on Atari 8bit. Bitmap simulated using 6 character sets to get one more potential color using 5th color in char mode. Sprites are drawn and erase using eor operation. This simplifies interaction with background with small artifacts where sprites go over background. Routine is not 50fps with anything more than 6 sprites, but even with 32 sprites it handles nicely, not even looking that slow because of all the objects moving on screen at once. There are 18 sprites on screen, 12x16 multicolor pixels large in 4 colors.

 

ps. This is char mode, so there could've been more colors using 5th color, I didn't bother with that. And don't forget PMs are available too

pps. Music is from c64 Cybernoid of course

 

Xex with nice placeholder name attached

cybernator.xex

 

 

 

[Synthpopalooza]

Gentlemen ...

 

This looks exquisite.  Please continue ... it's high time both of our 8-bit Atari platforms (counting the 7800 E.X.O. game) had a port of Cybernoid ...

 

Who needs scrolling?  Single screen stuff is just as well.  I'm ok with adhering to the source material.

 

 

[+Stephen]

8 hours ago, popmilo said:

So, I think experiment is successful

 

Small demo of sprite routine on Atari 8bit. Bitmap simulated using 6 character sets to get one more potential color using 5th color in char mode. Sprites are drawn and erase using eor operation. This simplifies interaction with background with small artifacts where sprites go over background. Routine is not 50fps with anything more than 6 sprites, but even with 32 sprites it handles nicely, not even looking that slow because of all the objects moving on screen at once. There are 18 sprites on screen, 12x16 multicolor pixels large in 4 colors.

 

ps. This is char mode, so there could've been more colors using 5th color, I didn't bother with that. And don't forget PMs are available too

pps. Music is from c64 Cybernoid of course

 

Xex with nice placeholder name attached

cybernator.xex 18.04 kB · 9 downloads

 

 

 

Holy shit dude - that's fantastic.  I haven't done that yet on VBXE!  I've spent too much time doing object oriented C# these past 15 years.  Trying to also squeeze every cycle from 6502 is too much for my pee brain at this point   I try to do baby steps at least.

[Beeblebrox]

3 hours ago, Synthpopalooza said:

 

This looks exquisite.  Please continue ... it's high time both of our 8-bit Atari platforms (counting the 7800 E.X.O. game) had a port of Cybernoid ...

I second this... Very cool work from all so far. 

@Synthpopaloozaperhapsyou wanna help with your musical and sound fx expertise if interested?

[Steril707]

13 hours ago, popmilo said:

 

 

That's seriously impressive, Popmilo... 😮

[Synthpopalooza]

7 hours ago, Beeblebrox said:

I second this... Very cool work from all so far. 

@Synthpopaloozaperhapsyou wanna help with your musical and sound fx expertise if interested?

I would if I didn't have so much on my plate now lol ... 3 projects running.  

[José Pereira]

On 9/26/2022 at 4:49 PM, mariuszw said:

I did something like that for Skool Daze 🙂 Every screen had its data for PMG (with simple RLE compression) and DLI (built like Copper lists and later expanded to 6502 code at runtime). The only problem with such approach is memory to fit data for all screens.

Skool Daze has less screens... Highway Encounter has more so I have to see how many has Cybernoid...

If ZX memory/game counting need is maximum 48KBs then how more KBs did you spent on our PMGs colourings in Highway Encounter?

 

[José Pereira]

23 minutes ago, José Pereira said:

Skool Daze has less screens... Highway Encounter has more so I have to see how many has Cybernoid...

If ZX memory/game counting need is maximum 48KBs then how more KBs did you spent on our PMGs colourings in Highway Encounter?

 

Just playing screens going to it again I counted 31screens.

Counting Cybernoid II from the Zx maps this is what I got: 

Quote

 

Level_1: 15
 Level_2: 12
 Level_3: 15
 Level_4: 16
_____________

  TOTAL = 58

 

So lets say 2x more is 62screens comparing to Highway Encounter is there memory enough for the PMGs if ZX 48Kbs still more 16KBs?