Parasol Star Remake ? (PS4CPC)

[cngsoft]

Some other nice game never get attention..

Must ... resist ... temptation ... to delay ... PS4CPC ... even more ... because of ... of ... a new project that got in the way!!!

[tastefulmrship]

Must ... resist ... temptation ... to delay ... PS4CPC ... even more ... because of ... of ... a new project that got in the way!!!

Please! Really, please! Resist! I bought a 6128 just to play PS4CPC!

[TotO]

Who's a pirate?

I'm joking. 

[beaker]

  Got me 

Sorry, a little on edge at the moment, Mum got rushed to Limerick hospital on Monday (a few days after getting back from Australia) after visiting the local GP as she wasn't feeling well and they've been running a bunch of tests, x-rays and an MRI scan over the last few days trying to work out what's wrong; and I am suffering from a sense of humour failure 

[MacDeath]

Yeah but don't resist too much nor too long...


Sorry for the Out of topic...

I failed to find infos about the hardware from Psychic5.
No info at the excellent System16 website.

It is always interesting to find good infos about the Arcade Hardware.
Many older Arcade games don't have really impressive specs. Many are really nothing more than 2 amstrad CPC equivalents overlayed...
And many actually used Z80... (well, Z80 wasn't the msot used, still some classics...)
The PacMan arcade emulator was an interesting case.

Those arcade games like Psychic5 is really amstrad Compliant on the paper :

=vertical display : 224x256... on CPC we may use "256x256". The whole map is something like 512x1024 so this would be 2 screens horizontally and 4 screens vertically.
=Multiscrolling : may not need to have very smooth one.
=small sprites : well there may be quite some of them perhaps.

but yeah... quite sure some arrangments may be possible to run quite well on CPC anyway.

Some infos
http://cdecas.free.fr/arcade/maps/psychic1.php
PCB Repair Logs Psychic 5 Bootleg - Aussie Arcade Wiki
MAME | src/mame/drivers/psychic5.c
psychic 5 [coin-op] arcade video game, jaleco co., ltd. (1987)
Arcade: Psychic 5 (Jaleco, 1987) | Program : Bytes : 48k

this one seems very interesting :
http://mamedev.org/source/src/mame/drivers/psychic5.c

seems it runs on Z80s..
as often the main may be 6mhz and the second (the sound co-CPU) would be 4mhz, perhaps even less (ok, actually both are at 6mhz)

ok sorry if this wastes the topic, may be interesting to open/split into a new topic on this game if some are interested.


Psychic 5 was one of the games that I remember quite dearly from when I lurked in arcades during my youth...
Very elegant game.

To actually  emulate it on CPC would be something like 4 or 8 times slowlier... 
And would require a plAYcity and megaRAM/ROM cards...

Could work better on PLUS as usual.


Psychic 5 quite reminds me of Bombjack in many ways...




Back to topic :

Wasn't Parasol Star a PCengine original game (then ported on 16biters of course).

Well it's not like PCengine is not more powerfull than all 8bit arcade boards anyway.
the horizontal scrolling may be not the easiest part to port.

[CraigsBar]

Must ... resist ... temptation ... to delay ... PS4CPC ... even more ... because of ... of ... a new project that got in the way!!!

oh, now! If these happen the Cpc will become the must have retro format. ps4cpc looks awesome I really am looking forward to playing it.

[sigh]

... Now that I got your attention, it's time for some low-level talk.

The typical stage of "Parasol Stars" needs to handle 64 sprites, divided in 48 16x16 px sprites (well, it's MODE 0, technically speaking we should say 8x16) spanning the droplets, shots, fruits, powerups... and 16 sprites of variable sizes (the heroes are 24x24 px, the bigger baddies are 48x48 px, etc.). And since we're talking of software sprites, this is going to be a lot of work for the CPC.



Unlike BB4CPC, where memory was a huge constraint and a single buffer was the only feasible approach, PS4CPC is going to read blocks (from disc or tape) with some regularity, so it will be able to benefit from a hardware double buffer: there won't be any time penalty (software double) or sprite flickering (single buffer). Setting the screen width to 32 tiles (256 px) also allows a further optimisation where the 256-byte memory boundary happens always at the same horizontal point, and thus making easy to detect when a sprite can simplify all 16-bit pointer mathematics to 8-bit or not.

BB4CPC already used the stack and Gray encoding to draw 8x8 px tiles on the screen, and PS4CPC will keep that method as well:

; SP=^SOURCE,HL=^TARGET
3 pop bc
2 ld (hl),c
1 inc l
2 ld (hl),b
2 set 3,h
3 pop bc
2 ld (hl),b
1 dec l
2 ld (hl),c
2 set 4,h
Repeat 4 times with matching SET/RES X,H operations to follow the Gray sequence 000 001 011 010 110 111 101 100:
(3+2+1+2+2+3+2+1+2+2)*4= 80 NOPs/tile

Good sprite blitting boils down to good byte blitting. The shortest method is as follows, where MASK is a 256-byte aligned table of precalculated sprite bit masks:

; BC=^SPRITE,DE=^TARGET,H=HI ^MASK
2 ld a,(bc)
1 ld l,a
2 ld a,(de)
2 and (hl)
1 xor l
2 ld (de),a
*2 inc hl
*2 inc de
2+1+2+2+1+2+2+2= 14 NOPs/byte; if aligned: 14-2= 12 NOPs/byte

However, if we can disable interrupts while we blit bytes, we can use the stack:

; SP=^SPRITE,DE=^TARGET,H=HI ^MASK
3 pop bc
1 ld l,c
2 ld a,(de)
2 and (hl)
1 xor l
2 ld (de),a
*2 inc hl
*2 inc de
1 ld l,b
2 ld a,(de)
2 and (hl)
1 xor l
2 ld (de),a
*2 inc hl
*2 inc de
3+1+2+2+1+2+2+2+1+2+2+1+2+2+2= 27 NOPs/word; 27/2= 13,5 NOPs/byte; if aligned: 13,5-2= 11,5 NOPs/byte

Where we save half a NOP per byte. Both methods work very well with unrolled loops and macros, and are easily modified to support horizontal flipping as well. However, they handle all bytes regardless of their degree of transparency, and this becomes a serious issue as sprites grow bigger: there should be a way to skip the fully transparent bytes, copy the fully opaque ones, and blit those that are neither.

My suggested solution is to preprocess sprite scanlines into "chunks" that measure the lengths of transparent and opaque strings of bytes. For example, the string 00 00 55 FF FF FF FF AA (00 fully transparent, FF fully opaque, 55 and AA half-transparent half-opaque) would become 02 55 04 FF FF FF FF AA. Said graphically, here's the 48x48 sprite of the stunned jester puppet and its internal nature (white = transparent, black = opaque, green = half-transparent, red = half-opaque):



For the method to stay consistent, some redundancy is needed: all chunks need to have a partially transparent byte at the beginning and at the end, resulting in size-unoptimal storage: the blue bytes are fully opaque, but they're stored in places reserved for semi-transparent bytes. However, this makes writing the code handling these chunks relatively straightforward, especially if we can store the MASK table in $0100:

; HL=^SPRITE,DE=^TARGET,B=0; ^MASK=0100
blit_a_line:

; skip N bytes, or exit if end of scanline (N=$FF)
2 ld a,(hl)
1 inc a
2 jr z,end_of_line
1 dec a
1 add e
1 ld e,a
*1 adc d
*1 sub e
*1 ld d,a
2+1+2+1+1+1+1+1+1= 11 NOPs; if aligned: 11-3= 8 NOPs

; blit one partially transparent byte
1 inc b
2 ld c,(hl)
2 ld a,(bc)
1 ex de,hl
2 and (hl)
1 xor c
2 ld (hl),a
1 ex de,hl
*2 inc hl
*2 inc de
1 dec b
1+2+2+1+2+1+2+1+2+2+1= 17 NOPs; if aligned: 17-2= 15 NOPs

; copy a string of fully opaque bytes
1 ld a,(hl)
1 and a
2 jr z,$+6
*2 inc hl
1 ld c,a
+6 ldir
1+1+2+2+1+6n= 7+6n NOPs; if aligned: 7+6n-1= 6+6n NOPs

; blit another partially transparent byte
1 inc b
2 ld c,(hl)
2 ld a,(bc)
1 ex de,hl
2 and (hl)
1 xor c
2 ld (hl),a
1 ex de,hl
*2 inc hl
*2 inc de
1 dec b
1+2+2+1+2+1+2+1+2+2+1= 17 NOPs; if aligned: 17-2= 15 NOPs

*3 jr blit_a_line
end_of_line:
11+17+7+6n+17+3= 55+6n NOPs/chunk; if aligned: 55+6n-8= 47+6n NOPs/chunk

This method can be further simplified (removing "inc a: jr z,end_of_blit: dec a" at the beginning and "jr blit_a_line" and the end, and never storing a $FF marker at the end of each chunk) if we can guarantee that every scanline is exactly one chunk.

Either way, a quick histogrammatical analysis of the postprocessed sprite returns 26,4% white, 4,8% green, 4,8% red, 11,6% blue and 52,4% black in 60 chunks. The "worst" default sprite blitting method (misaligned, stackless) would spend (48/4)*48*14= 8064 NOPs in the byte blitting only, while the "worst" (misaligned, variable chunks per scanline) postprocessed method would spend (48/4)*48*0,524*6+60*55= 1812+3300= 5112 NOPs instead: almost 40% less time.

... So what do you think of all these things?

Instead of using masking for the stunned jester example, wouldn't it be more easier to use colour changes by using bytes?
For instance, you could create a table for the jester sprite that has unique byte combinations stored in its register that has info about what colours you want and do not want changed. The storage would be smaller than creating a mask for that character.

Or am I missing something?

[TFM]

It would be slower

[Mr. DVG]

I know, I'm a nostalgic, but every year I pass I dream of playing Parasol Stars for Amstrad CPC tomorrow!

Will it remain a dream forever?
P.S. - Sorry if I dug up such an old thread!

[Skunkfish]

P.S. - Sorry if I dug up such an old thread!

Ah, you got me excited that there was an update on this! I was scrolling down, hoping to find a DSK image at the end! 

[Mr. DVG]

Ah, you got me excited that there was an update on this! I was scrolling down, hoping to find a DSK image at the end! 

Well at least let's rekindle hope ...

I know that CNG Soft was working seriously on this project, but I don't know why it was shelved in the end ... maybe too difficult to manage such a game on CPC?

[GUNHED]

That not, but what we got is already very good.

[pollito]

@cngsoft any update at all / plans to continue with this? Just got my ULIfAC so have been playing BB4CPC - awesome game!