Guess what is almost ready to become a playable demo?
(http://cngsoft.no-ip.org/PS4CPC_G-20130301D.PNG) (http://cngsoft.no-ip.org/PS4CPC_G-20130301D.PNG)
Just one thing is missing: I'm going to need the assistance of tastefulmrship, who adapted the Amiga songs of "Parasol Stars" to a CPC friendly format (http://www.cpcwiki.eu/forum/games/bubble-bobble/msg51747/#msg51747), because I need the scores of the main song so this playable demo does more than "beep", "boing" and "crash"...
Sweeeeeeet! :D
Oh cool !!!!!!!!!!!!
Really nice graphics ! 128kb release with no flickering ?
Quote from: cngsoft on 20:27, 01 March 13
Guess what is almost ready to become a playable demo?
Nice! Is the demo going to be ready in time for RetroMadrid 2013?
TomEtJerry: Flickerless double hardware buffer... in 64kb! :-D Multiload, however: each world and big boss will be loaded separately.
Nich: If nothing goes wrong, yes, it is, albeit fairly limited (just the first six stages), after all it's both a demo and a proof of concept.
Can we have a thumbs up smiley? I want to fill a whole post with them.
I can't like a post more than once :(
8) 8) 8) 8) 8) 8) 8) 8) 8) 8) 8) 8) 8) 8) 8) 8) 8) 8) 8) 8) 8) 8) 8) 8) 8) 8) 8) 8) 8) 8)
Quote from: cngsoft on 20:27, 01 March 13
Just one thing is missing: I'm going to need the assistance of tastefulmrship, who adapted the Amiga songs of "Parasol Stars" to a CPC friendly format (http://www.cpcwiki.eu/forum/games/bubble-bobble/msg51747/#msg51747), because I need the scores of the main song so this playable demo does more than "beep", "boing" and "crash"...
Oops, sorry! I've been busy and haven't been reading any threads (MaV pointed me to this request)... do you need the original .SKS or the .BIN file?
EDIT1: Here's the original .SKS file... use |GS to assign an address... or I can do it for you! Actually, sod it, here are ALL 6 .SKS files. Just load into Arkos & export as .YM
EDIT2:
Quote from: arnoldemu on 15:22, 03 March 13
Can we have a thumbs up smiley? I want to fill a whole post with them.
(http://4.bp.blogspot.com/_wzoyLdWZIOA/TMBWlwZztCI/AAAAAAAABeQ/CiJCPRwCxiA/s1600/01360916thumbs_up_smiley.gif)
This looks soooo nice!
(Lynwen, where are you?)
How do you get these to work? What files are SKS ?
Quote from: Puresox on 20:37, 05 March 13
How do you get these to work? What files are SKS ?
Either load into STarkos on CPC or Arkos on PC.
Quote from: tastefulmrship on 21:49, 04 March 13Oops, sorry! I've been busy and haven't been reading any threads [...] here are ALL 6 .SKS files. Just load into Arkos & export as .YM
Thank you very much!!! However, I'm afraid it's a bit too late, because I'm riding the bus to Madrid tomorrow morning :-( As soon as I'm back from the event I'll try integrating the music into the game and make a video of the playable demo.
Bad news: the PS4CPC playable demo won't be ready for tomorrow's RetroMadrid 2013. Good news: http://cngsoft.no-ip.org/cng_zip_lz3.htm (http://cngsoft.no-ip.org/cng_zip_lz3.htm) already features "Invasion of the Zombie Monsters" :-)
Hail César !!!!
;)
I still hope for hidden MLP:FiM bosses...
Ok, I made a slight palette edit, please don't use orange for the cheeks, orange on pink if really not ... good...
I turned the Yellow into pastel yellow, so it mix betterly with pink and is less saturated too (lots of saturated colours already...)
Player sprites' Cheeks are now Magenta (the red-purple crossbreed, not sure about the name)
Another thing is to try the different sort of bright green so it gives the whole set a slightly different ambiance/feeling/mood.
the seaGreen is quite good IMO, but here i put the lime green (yellowish) so it goes better won the fruits tiles (orange and yellow are used on them).
More yellow in the green and less in the yellow (it is pastel now) is somewhat a way to unsaturate a bit anyway.
Also, getting this setting enables you to go with an additionnal "green" gradiant...
Black-DarkGreen-Lime-pastelYellow-white.
Gives a sunny feeling too.
Same thing may be done with Cyan actually... As Sea green is a mix aof green+Cyan indeed. good to give an Icy feeling.
Hey! These two big sprites, located over the two umbrellas, at the right side of the picture, they look like.... MacDeath's avatar! :laugh:
Looking forward to play a first demo of the game! :)
After the disappointment of bringing a terribly incomplete double-buffer non-playable demo of PS4CPC to RetroMadrid 2013 I pretty much dug the project down and chose to focus instead on my own attempt at resuming the computer science degree I failed to complete twelve years ago. But now that exams are over (and I already know one score: 10/10! yay!) it's about time I resume developing this game, and talking about it too.
I finally settled on the pre-processed sprite engine we discussed a while ago. Empty bytes aren't stored; instead, a couple of nibbles tell the engine how many bytes to skip, and how many to draw. A couple of extra bits help the engine know whether it has to mask (rather than just copy) the first and last bytes of the block. The performance has improved over BB4CPC, but sprites are now 20% heavier on average, for most of them didn't really have many empty areas to begin with. Sure, the goal was speed rather than compression, but still...
I also ran into something that applies to BB4CPC as well and could justify yet another version. Do you notice something new in this sequence?
(http://cngsoft.no-ip.org/BB4CPC-20130618Z.PNG)
A lot of letter bubbles on screen?
Quote from: TFM/FS on 19:00, 21 June 13A lot of letter bubbles on screen?
No, no, although it's true I could have popped the green E bubble and scored an EXTEND. Look at the water stream: it's now as long as in the arcade game (10 rather than 8 tiles) and
it's dragging the drowned enemies instead of catapulting them away. How could I forget to do this back in the day?
Glad to hear your keeping this project alive and I really do hope you pass all those exams.
Regarding the project - are you attempting to squeeze this into 64kb or will it be 128kb with multiload?
Hi, Cesar.
If you release a new version of BB4CPC please read carefully the keyboard problem I've outlined in this thread of Amstrad miarroba forum.
Amstrad CPC - Cintas Bubble Bobble 4 CPC - Amstrad CPC (http://amstradcpc.mforos.com/305097/10861542-cintas-bubble-bobble-4-cpc/)
Quote from: 6128 on 09:16, 22 June 13Hi, Cesar.
If you release a new version of BB4CPC please read carefully the keyboard problem I've outlined in this thread of Amstrad miarroba forum.
Amstrad CPC - Cintas Bubble Bobble 4 CPC - Amstrad CPC (http://amstradcpc.mforos.com/305097/10861542-cintas-bubble-bobble-4-cpc/)
Quote...If you redefine the keys as Q-I-O-SPACE (jump,left,right,shoot) [...and...] you press at once I+O+Q [...] the game jumps back to the main menu [...] Truth be said, I didn't test other key combinations...
Ah, the good old CPC keyboard matrix clash. The solution is simple: choose other keys. When I want to play BB4CPC I always redefine the eight keys as ZXCVNM+comma+point and I never get any unexpected keypresses even in the few times I got a friend to come here and play the game together with me.
EDIT: for those who don't know yet about the keyboard matrix hardware glitch, here's a brief explanation. The scan codes of the keys I, O, Q and Escape are 35, 34, 67 and 66 respectively, and whenever we examine the keyboard hardware we get 10 bytes, each one stating whether eight keys are up or down. If we thus plot a 8x10 table and check the locations of the aforementioned keys we get this:
0 1 2 3 4 5 6 7
00 - - - - - - - -
08 - - - - - - - -
16 - - - - - - - -
24 - - - - - - - -
32 - - O I - - - -
40 - - - - - - - -
48 - - - - - - - -
56 - - - - - - - -
64 - - ? Q - - - -
72 - - - - - - - -
They define a perfect rectangle. That's indeed what happens: whenever three keys are pressed at once and the first one shares the horizontal coordinate with the second one and the vertical coordinate with the third one, a "ghost" fourth keypress is generated to complete the rectangle. Hence I+O+Q being the perfect recipe for a "ghost" Escape keypress.
Quote from: cngsoft on 11:29, 22 June 13
Ah, the good old CPC keyboard matrix clash.
I remember having it when playing two players games with my brother...
When we were kids a looooong time ago !
;)
Yes, it is a hardware problem. The only solution is to use another keyboard. One of my CPCs has a Siemens keyboard, which does not has the problem.
Quote from: TFM/FS on 18:51, 25 June 13
Yes, it is a hardware problem. The only solution is to use another keyboard. One of my CPCs has a Siemens keyboard, which does not has the problem.
Is this an original CPC keyboard or a modification?
If it's original how can you determine the difference?
I have a 664 which doesn't seem to suffer from keyboard clash.
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.
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.
(http://cngsoft.no-ip.org/BB4CPC-20130629Z.PNG) (http://cngsoft.no-ip.org/BB4CPC-20130629Z.PNG)
Because RTFM is more economic than LMGTFY, and because I still had several spare bytes too.
Hahaha :D a waste of bytes...
Quote from: Gryzor on 19:14, 29 June 13Hahaha :D 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:
(http://cngsoft.no-ip.org/bublbobl-tutorial.png) (http://cngsoft.no-ip.org/bublbobl-tutorial.png)
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.
Next level of authenticity: ship a cabinet with it!
Quote from: Gryzor on 15:26, 30 June 13Next 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.
Hey, where can I get a tape? :)
As for the exam, aw rats, hope you manage to find a way out of it :(
Quote from: cngsoft on 12:51, 02 July 13
...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!
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 (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.
Oh gawd, the cuteness... :D 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 :)
Quote from: cngsoft on 15:28, 07 July 13
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!
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.
Just bumping this and hoping for some exciting news...
Also wanting an update. :)
:) Hi guys, there are news for PARASOL STARS REMAKE for CPC?
Hope of see something this year :( .
(http://cngsoft.no-ip.org/PS4CPC_LOGO2K.PNG)
... 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.
(http://cngsoft.no-ip.org/PS4CPC_MOCKUPS_D7-32X.PNG)
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):
(http://cngsoft.no-ip.org/PS4CPC_JESTER-STUNNED-SPRITE.PNG) (http://cngsoft.no-ip.org/PS4CPC_JESTER-STUNNED-SPRITE_MASK.PNG)
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?
That sounds pretty good! :)
Some other nice game never get attention..
www.youtube.com/watch?v=GjNYtAJOCOA (http://www.youtube.com/watch?v=GjNYtAJOCOA#ws)
:(
(http://www.arcade-museum.com/images/118/118124215428.png)
The resolution looks quite Amstrad Friendly...
That looks like it would make one awesome plus cart.
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]
Quote from: cngsoft on 14:38, 02 October 14
... 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
;D :o 8) :P :-* ;)
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.
@beaker (http://www.cpcwiki.eu/forum/index.php?action=profile;u=497): Buuuuu, piracy!!!! :-\
Who's a pirate?
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.. :laugh:
[attach=2]
Where possible I always like to buy the real thing and support jobs and the community... :D
[attach=3]
If you want, I'll try and find the game in mu pile this weekend if I have time ;)
[attach=4]
Quote from: MacDeath on 20:12, 02 October 14
Some other nice game never get attention..
(http://www.arcade-museum.com/images/118/118124215428.png)
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).
Quote from: MacDeath on 20:12, 02 October 14Some 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!!!
(http://cngsoft.no-ip.org/PSYCHIC5-CPC-GRANDFATHER_CLOCK.PNG)
Quote from: cngsoft on 23:18, 02 October 14
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!
:laugh: :laugh: :laugh: Got me :laugh: :laugh: :laugh:
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 :-[
Yeah but don't resist too much nor too long... :laugh:
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 (http://cdecas.free.fr/arcade/maps/psychic1.php)
PCB Repair Logs Psychic 5 Bootleg - Aussie Arcade Wiki (http://wiki.aussiearcade.com.au/index.php/PCB_Repair_Logs_Psychic_5_Bootleg)
MAME | src/mame/drivers/psychic5.c (http://mamedev.org/source/src/mame/drivers/psychic5.c.html)
psychic 5 [coin-op] arcade video game, jaleco co., ltd. (1987) (http://www.arcade-history.com/?n=psychic-5&page=detail&id=2057)
Arcade: Psychic 5 (Jaleco, 1987) | Program : Bytes : 48k (http://programbytes48k.wordpress.com/2011/01/08/arcade-psychic-5-jaleco-1987/)
this one seems very interesting :
http://mamedev.org/source/src/mame/drivers/psychic5.c (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... :laugh:
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. ;D
the horizontal scrolling may be not the easiest part to port.
Quote from: cngsoft on 23:18, 02 October 14
Must ... resist ... temptation ... to delay ... PS4CPC ... even more ... because of ... of ... a new project that got in the way!!!
(http://cngsoft.no-ip.org/PSYCHIC5-CPC-GRANDFATHER_CLOCK.PNG)
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.
Quote from: cngsoft on 14:38, 02 October 14
(http://cngsoft.no-ip.org/PS4CPC_LOGO2K.PNG)
... 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.
(http://cngsoft.no-ip.org/PS4CPC_MOCKUPS_D7-32X.PNG)
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):
(http://cngsoft.no-ip.org/PS4CPC_JESTER-STUNNED-SPRITE.PNG) (http://cngsoft.no-ip.org/PS4CPC_JESTER-STUNNED-SPRITE_MASK.PNG)
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?
It would be slower
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! ::)
Quote from: Mr. DVG on 23:46, 15 January 21P.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! :'(
Quote from: Skunkfish on 13:50, 16 January 21
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? ::)
That not, but what we got is already very good.
@cngsoft any update at all / plans to continue with this? ;) Just got my ULIfAC so have been playing BB4CPC - awesome game!