Parasol Star Remake ? (PS4CPC)

[TFM]

The Siemens keyboard is no original keyboard. It looks very different, the keyboard is in this case external and the PCB in a bigger case (space for some expansions). However it's more or less directly connected IIRC.
That may not help us that much, but since you have the special 664, we at least know that there must be a way to omit the keyboard clash - using a hardware mod.

[cngsoft]

After being asked for 1234th time how to beat yet another seemingly impossible round I've decided to give BB4CPC a little thing to be shown in attract mode.



Because RTFM is more economic than LMGTFY, and because I still had several spare bytes too.

[Gryzor]

Hahaha a waste of bytes...

[cngsoft]

Hahaha a waste of bytes...

Well, the upside is that it also makes BB4CPC even more faithful to the arcade game, for I copied the text straight from its built-in tutorial:



As verbatim as in other parts of the game, because Engrish is adorable. Who doesn't remember the opening line? :-)
NOW,IT IS BEGINNING OF A FANTASTIC STORY!!  LET'S MAKE A JOURNEY TO THE CAVE OF MONSTERS! GOOD LUCK!

Regrettably, "Parasol Stars" didn't have any live tutorial, you were down to learning the gameplay from the demos that played during attract mode, and from guessing how to do with the joystick and the two buttons the things you saw in the demos.

[Gryzor]

Next level of authenticity: ship a cabinet with it!

[cngsoft]

Next level of authenticity: ship a cabinet with it!

That's a bit unfeasible, but it's good that you say that, because I should write somewhere that everyone who got tapes of the very first BB4CPC at RetroMadrid 2012 can send them to me so I record them with an updated (and working, because that batch of tapes was flakey!) version of the game and send them back.

By the way, I got all the exams' scores: I passed everything but Data Structures, where I was given a big round zero. Why? Because my mandatory practical exercise (in few words, a robotised pastry described as a "black box" we had to reverse-engineer and recreate in Java) hasn't been corrected yet (despite giving it to my professor 50 days ago) so the examiners assumed the lack of score meant I had flunked the exercise. I've already written a formal complaint to my professor and her department, although I'm already seeing that at least twenty students have suffered the same accident.

[Gryzor]

Hey, where can I get a tape?


As for the exam, aw rats, hope you manage to find a way out of it

[sigh]

...everyone who got tapes of the very first BB4CPC at RetroMadrid.....

I would also like to enquire about getting a tape!
The amount of love you have dedicated to Bubble Bobble is absolutely stunning!

[cngsoft]

Alright, now that I got the missing exam's score at last (I passed it, although I expected a better score; either way, thanks, Gryzor) and a bunch of things have been solved as well, it's about time to release the ninth version of BB4CPC at http://cngsoft.no-ip.org/bb4cpc.htm and start working for serious on PS4CPC! After all I already have all the sprites needed to make a fully playable first world and the songs written by TastefulMrShip, even if I have yet to adapt them to my music-and-SFX engine.

About the tapes... well, truth be said, it wasn't really my idea to begin with; my CPC fellows at RetroMadrid thought that it was a neat thing we could make for ourselves and our friends. Sadly, the recording was less than perfect (why did I make a custom turbo loader inspired by Bleepload WITHOUT amending its flaws, why?) and I'll never forget it. Hence my interest in getting them back and recording them again. Recording new tapes, on the other hand... well, it's a different thing.

EDIT: the changelog is as follows: 07/07/2013: ninth public release. New overscan intro screen, new in-game tutorial (128k only), fixed water streams (ten blocks rather than just eight) and drowned enemies (water carries them now), minor changes in title screen and sprites, minor scoring overflow bugfixes, minor size and speed optimizations.

[Gryzor]

Oh gawd, the cuteness... Even after all this time, I'm playing this right now (with my girl playing Extreme Pinball in DOSbox right next to me, unfortunately her laptop has more powerful speakers than mine), and can't put it down

[Nich]

EDIT: the changelog is as follows: 07/07/2013: ninth public release. New overscan intro screen, new in-game tutorial (128k only), fixed water streams (ten blocks rather than just eight) and drowned enemies (water carries them now), minor changes in title screen and sprites, minor scoring overflow bugfixes, minor size and speed optimizations.

I didn't see any new intro screen or title screen in the version that I have just downloaded from your site. Also, when I insert the DSK file, no filenames are listed when the user types CAT.

Congratulations on passing all your exams! It's been 11 years since I sat my last exams at university and I don't want to sit any more of them again!

[cngsoft]

Cripes, I posted on my website a DSK without the intro  I just replaced it, please download it again!

EDIT: well, at least Nich noticed it too! This is what I get for forgetting to edit the automated MAKEFILE and turn all the instances of BB4CPC_L into BB4CPC-L... And yes, I don't mind the low scores as long as they're high enough to keep me from taking the same exams ever again. University ain't fun!

EDIT again: the wrong BB4CPC.ZIP release is 75241 bytes long, the right one is 79054.

[romppainen]

Just bumping this and hoping for some exciting news...

[Carnivius]

Also wanting an update.

[DARKGATE]

  Hi guys, there are news for PARASOL STARS REMAKE for CPC?
Hope of see something this year  .

[cngsoft]

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

[TFM]

That sounds pretty good! 

[MacDeath]

Some other nice game never get attention..


www.youtube.com/watch?v=GjNYtAJOCOA





The resolution looks quite Amstrad Friendly...

[CraigsBar]

That looks like it would make one awesome plus cart.

[beaker]

I know there's a hell of a lot going on with the PC Engine version. sometimes the screen is filled with sprites of water droplets, fruit and enemies, and you can get close to it will be amazing!!! I can't wait to see the results. Good luck!

[attach=2]

[Carnivius]

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

This...

Meaning I don't understand any of those things and I'm just here for the pretty pictures which make me go


Am not usually that much of a CPC bragger ( i mean more than when is totally justified)  but I really can't see the Spectrum or C64 reproducing the graphics as accurately and so charmingly vibrant too.

[TotO]

@beaker: Buuuuu, piracy!!!!   

[beaker]

Who's a pirate?

[beaker]

So because I am using an Everdrive I am immediately a pirate?   
Actually I am using it as I don't want to wear out my cartridge port by constantly changing over games on a fairly rare and expensive PC Engine LT - it's already cost be one kidney and I don't think I can afford to sell the second..

[attach=2]

Where possible I always like to buy the real thing and support jobs and the community... 

[attach=3]

If you want, I'll try and find the game in mu pile this weekend if I have time 

[attach=4]

[mahlemiut]

Some other nice game never get attention..


The resolution looks quite Amstrad Friendly...

This is one game that I think would have worked better on home computers/consoles, as opposed to arcade.

There is an Famicom port, Japan only I think, but like many NES arcade ports, it's not a lot like the arcade was (ie: it's quite a different game).