Cybernoid WIP

[popmilo]

You were close
it's 44 max with 6 sets. And that's on image with those eyes in background.

 

8 Charsets looks fun too

[José Pereira]

Please try with your new/actual extractor all the map (with and without eyes) for 6 and 8charsets.

Also post here the .png of the C64 CharPad tiles (with all the level gfxs). 

Thanks.

 

P.s.- Talking of double buffering means that on C64 bitmap mode is screen ~8KBs is also 2x so it's using 16KBs?

 

Edited September 18, 2022 by José Pereira

[rensoup]

14 hours ago, popmilo said:

You were close
it's 44 max with 6 sets. And that's on image with those eyes in background.

Nice... The blue turret partially animates I think so it wouldn't be part of the background, so that'd be 2 chars less for some charsets...

 

6 charsets = 6KB + 2 charmaps = 8KB for double buffered empty space, that's really good actually! Even 8 charsets is good.

 

Of course there would need to be an intermediate map required to generate those charsets costing a bit of space too.

 

53 minutes ago, José Pereira said:

P.s.- Talking of double buffering means that on C64 bitmap mode is screen ~8KBs is also 2x so it's using 16KBs?

Potentially no. Like you said, static sprites are charsets until they move and then use hardware sprites which don't require double buffering. It's hard to say for sure.

 

On the A8, all moving objects would require software sprites.

 

 

[+JAC!]

1 hour ago, José Pereira said:

Talking of double buffering means that on C64 bitmap mode is screen ~8KBs is also 2x so it's using 16KBs?

 

There's no double buffering on the C64, it would consume too much space and conflict with the EOR software sprites. And while it's nice to read all this, you also need to know that many (even large) screen elements are animated, too. Therefore using static screen maps to the do char count will never be fully correct.

[rensoup]

2 hours ago, JAC! said:

There's no double buffering on the C64, it would consume too much space and conflict with the EOR software sprites. And while it's nice to read all this, you also need to know that many (even large) screen elements are animated, too. Therefore using static screen maps to the do char count will never be fully correct.

The idea is that anything moving would go into the unassigned charset pool, so once destroyed it would free its space allowing it to be replaced with explosion debris for instance.

[popmilo]

Jac is correct, no double buffer on c64 (or any other version is my guess). Eor sprites are nice in that way, they don't need double buffer. You just avoid changing part of screen where raster beam is at that point. Even if you don't manage to reach 50fps it still looks ok.

 

Rensoup is also correct  Animated stuff belongs to rest of charset that can be dynamically alocated.

[popmilo]

José, can't easily remove all "eyes", so here's info with entire level1:

 

6 charsets full level:

 

8 charsets, full level:

[popmilo]

9 hours ago, José Pereira said:

Also post here the .png of the C64 CharPad tiles (with all the level gfxs). 

Here are tiles 2x2 that Charpad detected in first level:

Damn, I like those 3 colors per char of c64

 

[xxl]

Cybernoid 1 tiles:

 

 

 

Cybernoid 2 tiles:

 

 

 

---

Note that the c64 version is poorer in details and it is not about low resolution but the lack of elements such as displaying score after smashing rockets or large objects.

Edited September 19, 2022 by xxl

[mariuszw]

I did some planning for Cybernoid 2 by myself, so here are my random thoughts:

 

C64 runs this game in bitmap mode, simply graphics is too complicated to fit within a charset (even with 256 chars). Bitmap mode also allows more colors on C64. As far as I remember, shots are also drawn on screen, so they would consume additional chars.

 

Personally I would go into direction of using ZX Spectrum version as a base, but with graphics in lores mode, more or less these already presented in this thread, with PMG overlays for more colour. Spectrum version (which was basis for other versions) runs its in 25fps and does all movements in two hires pixel resolution (=1 lores pixel). I am pretty sure that Atari can do the same in 25fps as well. Of course game slows down when there are lots of enemies and/or bullets on the screen, but I guess nobody complains.

 

ZX Spectrum version does eor drawing and there is no backbuffer. Also, game sprites are kind of preshifted - actually each sprite frame has fixed horizontal offset and the game logic is designed so that given sprite frame appears only on fixed horizontal position (within byte). In general, game is designed with performance in mind.

 

I think mode E is an option here. But since Spectrum version is 256 pixels wide, a "hybrid" mode could be used to allow 5th color for playfield, at the expense of slightly awkward screen addressing.  I am thinking of having characters 0-$1f in first line, $20-$3f in second line, $40-$5f in third line and $60-$7f in fourth line. in next line, character generator is pointed to +$400, and whole thing repeats down the screen. So actual bitmap to draw on is character generator memory, while characters can will be used to implement one bit color map (to enable 5th color). In this more drawing can be done even faster, when we draw column by column - up to 8 bytes can be written without adjustment of pointers and also pointers adjusted by increasing high byte of screen pointer. The drawback is ANTIC bad lines and interrupts to change character generator address.

 

I actually have 95% completed disassembly of ZX Spectrum Cybernoid 2.

 

Mariusz.

[popmilo]

Sounds like what also Jose suggested. Btmap emulation with charsets. Makes sense.

Difference to interelaved charsets method is that you need more time to erase stuff...
Xor sprites neutralize it in some sense... (no need to restore/store charcodes for each softsprite).

 

If you have code, I would say go for it Give Jose gfx to convert and we'll have multicolor Cybernoid in no time

PM coloring can come in at the end once everything else works.

 

[José Pereira]

4 hours ago, popmilo said:

If you have code, I would say go for it Give Jose gfx to convert and we'll have multicolor Cybernoid in no time

PM coloring can come in at the end once everything else works.

 

So following this with this:

7 hours ago, xxl said:

Cybernoid 2 tiles:

 

@xxl please post me this screen in real size pixels .png so that I can rework it to 2:1 following the same order...

Thanks.

[José Pereira]

54 minutes ago, José Pereira said:

Cybernoid 2 tiles:

 

Know these are all game gfxs (including logo (less text letters)) but counting 932 (some less for 'empty' ones but sure seems better the 'mimic bitmap.

Following a ZX screen that is 32Bytes wide go for 1charset per 2charlines is playing area 20charlines = 10charsets (1charset for status area is for sure enough).

64chars +1char for border gives 63chars left seems enough...

[popmilo]

This starts to sound like a good example for somebody to test drawing xor-sprites on simulated bitmap mode screen

 

@José Pereira I'm thinking, better to just use 5 charsets as bitmap. There's no masking needed, xor sprites don't have to achieve 50fps, should look good without even too much optimization of draw routine.

 

[rensoup]

16 hours ago, mariuszw said:

I did some planning for Cybernoid 2 by myself, so here are my random thoughts:

Interesting stuff but why would you choose the ZX version since it's a much bigger job even with a complete disassembly ?

 

17 hours ago, popmilo said:

Here are tiles 2x2 that Charpad detected in first level:

Aren't there duplicates there ? just on that first line ?

 

8 hours ago, popmilo said:

This starts to sound like a good example for somebody to test drawing xor-sprites on simulated bitmap mode screen

XOR looks ok but I think regular masked sprites are doable on the A8.

 

I'm guessing that's why the palette for software sprites is a gradient on the C64, so that the XOR plot doesn't look too messed up.

[popmilo]

6 hours ago, rensoup said:

Interesting stuff but why would you choose the ZX version since it's a much bigger job even with a complete disassembly ?

 

Aren't there duplicates there ? just on that first line ?

 

XOR looks ok but I think regular masked sprites are doable on the A8.

 

I'm guessing that's why the palette for software sprites is a gradient on the C64, so that the XOR plot doesn't look too messed up.

My guess speccy version is easier because you avoid messing with entire multicolor bitmap system + hw sprites...
It's enough to "just transcribe z80->6502"

 

Yes there are kind of duplicates, but they really have single or two pixels different. Must be leftovers after I cleaned png from sprites of enemies and player ship. Doesn't change much in tile count imho.

 

[mariuszw]

1 hour ago, popmilo said:

My guess speccy version is easier because you avoid messing with entire multicolor bitmap system + hw sprites...
It's enough to "just transcribe z80->6502"

 

 

Yes, exactly. z80->6502 conversion is semi-automatic with my tools. C64 version code looks is less clean, with rendering code tied to game logic. Spectrum version has these clearly separated.

 

Regarding graphics design: even with PMG overlays and 5th colour, we will end up with 3 colors (+ black background) for action area, where player ship and and enemies move. How to distinguish player bullets from enemy bullets?

[popmilo]

1 hour ago, mariuszw said:

Regarding graphics design: even with PMG overlays and 5th colour, we will end up with 3 colors (+ black background) for action area, where player ship and and enemies move. How to distinguish player bullets from enemy bullets?

Use 5th color for some bullets, ignore eventual color clash ?

ps. I've never noticed that they are different colors

 

 

 

Edited September 20, 2022 by popmilo

[Yautja]

Who needs so many colors, anyway...?

 

 

[José Pereira]

7 hours ago, mariuszw said:

Regarding graphics design: even with PMG overlays and 5th colour, we will end up with 3 colors (+ black background) for action area, where player ship and and enemies move. How to distinguish player bullets from enemy bullets?

Start replacing ZX -> C64 next will C64 -> A8 (using the 5th colour, of course):

By now (from my past experiences) the colours should be similar to these so that PM2&PM3 using Prior_0 (oring with PF2 & PF3 works on grounds and other gfxs:
 (PM2 is pale green colour E and gun P3 blue green colour 9)

 (PM2 & PM3 distributed pale green colour E, brown colour F and green colour B)

So the PFs colours by now are:

BAK: blue (88);

PF0: darkest gray / black (02);

PF1: white (0E);

PF2: light blue (8A);

PF3: dark blue (84);

These to be similar (allmost 100%) to C64 pixels but if PF2 light blue on the horizontal and vertical lines walls be a light gray for mines, diamonds and shots. something like this (mine there):

But if removing the gray from the horizontal and vertical lines (the PM2 and PM3 is oring PF3 on the gfxs it'll also reduce possible clash (PF2&PF3) on the moving things like explosions, the moving * add-on gun(s),.... Here's with and without:

 -> 

This way the mines and other things will 'shine'/distinguish more.

 

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

 

 

 

 

Edited September 20, 2022 by José Pereira

[José Pereira]

20 hours ago, 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...

Ok. no need to answer, at least by now  because have something to show that think it'll pleases all and your usually PMGs using when porting ZX games ...

Here's the, can call it a Master screen (status more or less like this in 2:1 C64 but in 32Bytes wide to then use ZXs playing area):

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);

 

Hope to come back with 'that more' on the afternoon (here time)...

 

Edited September 21, 2022 by José Pereira

[José Pereira]

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

-> PFs only:    

-> PMGs only:   

 

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

Tomorrow will add our ship and start discussing moving enemys and PF3 colour that isn't already here.

The colours still are:

5 hours ago, José Pereira said:

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);

 

Edited September 21, 2022 by José Pereira

[José Pereira]

Missing screen with eyes gfxs on top (status screen 32Bytes):

though .xex file was ok.

[José Pereira]

Also that on the top, the status area PMGs are static/dizer so are allways the same shapes and that's changing are the the chars and numbers and , gfxs and energy bars PFs pixels/chars:

@mariuszw is used to this from me 😁...

 

Edited September 21, 2022 by José Pereira

[Heaven/TQA]

On 9/16/2022 at 1:08 PM, Steril707 said:

Haha, thanks...

Makes sense...

it is simpler than it first might look... C64 bitmap mode adressing is more headache  and more is Apple 2   

 

Edited September 22, 2022 by Heaven/TQA