News:

Printed Amstrad Addict magazine announced, check it out here!

Main Menu

Jumping Jack Sinclair Zx Spectrum Emulator for Amstrad CPC

Started by 40Crisis, 13:41, 30 January 16

Previous topic - Next topic

0 Members and 1 Guest are viewing this topic.

40Crisis

You can download here the very first release of Jumping Jack Sinclair Zx Spectrum Emulator for Amstrad/Schneider CPC range.

Jumping Jack is a game for Sinclair Zx Spectrum 16/48K created by by Albert Ball and Stuart C. Ball and released in 1983 by Imagine Software

It's one of this early simple 16K ZX Spectrum game with awesome gameplay.
This game is very addictive.

Special care has been used to reproduce as many colors as possible in cpc mode 1. Hopefully much more than 4 !

For copyright reasons, you need to provide a snapshot of Jumping Jack original tape for Zx Spectrum to play Jumping Jack in emulator.

Please read the "Jumping_Jack_Sinclair_Zx_Spectrum_Emulator_For_Amstrad_CPC_v1.0.txt" file for details.

Enjoy.

Joseman

@40crisis

This emulator that you're using to emulate spectrum games... is possible to download the source code?

or can you explain how do you implement the graphic routines and the increment of colours?

I'm pretty sure that a lot of people will find this very useful for a lot of things!!  ;)


Thankyou!

40Crisis

Quote from: Joseman on 13:56, 30 January 16
@40crisis

This emulator that you're using to emulate spectrum games... is possible to download the source code?

or can you explain how do you implement the graphic routines and the increment of colours?

I'm pretty sure that a lot of people will find this very useful for a lot of things!!  ;)


Thankyou!

        Hello Joseman,

I see that you have interest in converting Sinclair ZX Spectrum games.
you converted Skkol Daze with pugnacity and many thanks for that.

When you try to emulate zx spectrum graphics, every game uses his own routines,
so each time you have to emulate them with specific code.


For speed reasons, I always first convert graphics from ZX 8 pixels/byte to native 4 pixels by byte CPC format.
But you need to find extra ram for that as size is doubled.

On the zx to cpc on the fly pixel convertion is not likely to work in realtime.
But as I understood, you managed to do it in Skool Daze.


Speaking of displaying more than 4 colors in CPC mode 1:

In the jumping jack I use two things:

1) Dithering existing sprites using two colors pixels combinaison which enhanced 4 colors to 10 possibles colors.
Color combinaisons are:
0,0
0,1
0,2
0,3
1,1
1,2
1,3
2,2
2,3
3,3

You applied it to replace foreground pixels on even lines.
On odd lines you replace them whith the "rotated" color configuration:
0,0
1,0
2,0
3,0
1,1
2,1
3,1
2,2
3,2
3,3

You first convert zx spectrum byte to 2 bytes format (color 0 et color 3);
to apply dithering you just do an and operation with the dithering pattern every two bytes,
changing pattern between odd and even lines.
You can do it on the fly or once to match you needs.

2) I use palette change every 300 th of seconds corresponding to 52 vertical pixels among a total of 312 lines.
This is done using interrupt handler.

In Jumping Jack I need to keep 3 fixed hardware colors: white, red, black.

Luckily, I realise that combining the fact that under each red line in the game there's a 8 pixels vertical gape with no display.
Each red lines are separated with 24 pixels.

So be using a 200 pixels vertical resolution and moving display down by 8 pixels + 4 pixels down using CRTC register 5 (12 pixels down),
I could change the remaining color four times on a vertical zone of 52 pixels without affecting display of sprites and red line.
Without this, the risk would have ben to part a displayed  sprite in two different colors.

This means that combining dithering with multicolor I can get up to 13 colors (I decided to not use white color for dithering because of the awful result).

Here's a screenshot with border change enabled to illustrate this:

Gryzor

I have read about this game but never actually played it. Anyone can comment on how it compares to running it on a ZX?


Thanks for this nice treat, man!

40Crisis

                Hello All,

version 1.01 (31/01/2016):
Fix a bug in sound: bit 6 of PSG muxer register 7 was incorrectly set to 1.This led to CPC reset
in emulators like Arnold, CPCE, Java CPC Deskop and of course real CPC's because keyboard output was wrong (response was all keys pressed when none !)


Morality, always check on the real hardware (that's what I did today) as good and faithful an emulator can be.

This example of bit 6 of PSG muxer register 7 which must always have value 0 on CPC according to documentation, shows how far CPC emulation can minic a real CPC.

in this case I saw the following emulators ignoring bit 6 set to 1:
Winape
SugarBox
Reloaded

Many Thanks to Nich for pointing out to me this problem

ivarf

It looks like Home Runner, but I guess it plays much better

Puresox

Look forward to checking this out . I have a question that is slightly related but not exactly. In relation to emulators--Are there any good threads on here that go into details on how emulator's are put together ? In layman's terms preferably . It amazes me how these programmes can simulate machines and would love to know how they are done . If I can get my head round them. I have heard that they are not that difficult to build? (Not to belittle the task , as I know I couldn't do it , as it is not my field) .
Anyway do not wish to hyjack the thread , so only a quick pointer will be great . Thanks

ivarf

The latest Retro Gamer had a long article about this game

Gryzor

Quote from: ivarf on 22:25, 31 January 16
The latest Retro Gamer had a long article about this game


...the first one I won't get since I didn't renew my sub...

Joseman

Quote from: 40Crisis on 15:38, 30 January 16
       
For speed reasons, I always first convert graphics from ZX 8 pixels/byte to native 4 pixels by byte CPC format.
But you need to find extra ram for that as size is doubled.

On the zx to cpc on the fly pixel convertion is not likely to work in realtime.
But as I understood, you managed to do it in Skool Daze.

Yes, the conversion 8px to 4+4px is the best option, but in a lot of games you don't have virtually ram to make that, and the tile routines needs to be recoded, a hard job without a doubt...

A lot of posts here are about to improve the graphics of a game but, they really don't know how HARD is to do that, virtually is more easy to start the game from scratch instead of upgrade the graphics of a compiled game!!.

And yes, I do pixel conversion on the fly on the skool daze port, but the tile routines and the draw system on skool daze are very primitives (8px scroll), yes i lost time doing the conversion but there is no big impact on the already slow ZX routines.

I suppose that on more recent games with pixel movement the on the fly conversion is impossible and the routine needs to be completely rewriten...

Thanks for the information about the multicolor mode 1 that you're using, i suspected about the dithering and the graphics redone... good job @40Crisis




Nich

Quote from: ivarf on 22:25, 31 January 16
The latest Retro Gamer had a long article about this game

'Latest' in this case being issue 146. ;)

For me, the latest issue is 151 (which I received towards the end of last week), but of course, it depends where in the world you live...

ivarf

Quote from: Nich on 20:30, 01 February 16
'Latest' in this case being issue 146. ;)

For me, the latest issue is 151 (which I received towards the end of last week), but of course, it depends where in the world you live...
LOL

I must have picked an older one from the stack, I wrongly assumed a LIFO stack   8)

ivarf

Quote from: Joseman on 20:19, 01 February 16
Yes, the conversion 8px to 4+4px is the best option, but in a lot of games you don't have virtually ram to make that, and the tile routines needs to be recoded, a hard job without a doubt...

A lot of posts here are about to improve the graphics of a game but, they really don't know how HARD is to do that, virtually is more easy to start the game from scratch instead of upgrade the graphics of a compiled game!!.

And yes, I do pixel conversion on the fly on the skool daze port, but the tile routines and the draw system on skool daze are very primitives (8px scroll), yes i lost time doing the conversion but there is no big impact on the already slow ZX routines.

I suppose that on more recent games with pixel movement the on the fly conversion is impossible and the routine needs to be completely rewriten...

Thanks for the information about the multicolor mode 1 that you're using, i suspected about the dithering and the graphics redone... good job @40Crisis

How did they manage to change the graphics when porting games from the Spectrum in the old days?

Joseman

Quote from: ivarf on 10:28, 02 February 16
How did they manage to change the graphics when porting games from the Spectrum in the old days?

Well, hard question, but i think that they have 3 advantages:

1- have the source code and important too, know how it works (it's not the same that read 2000 lines of code that you not coded).

2- Have another person for the graphics that do the job of convert them.

3- And the most important thing: it was his Job, they were paid for convert the game!!!  ;D

There are games that upset me to the end, it was a terrible lazy job, the graphics are 1bpp and some indicator on the scoreboard is missing!!! they even don't bother to change the color in it!!

Ex:

Smaily by Zigurat (see videos on youtube for a big example of lazy lazy lazy port):

the are 2 bars on the side of the screen that indicates the energy: a red bar that is emptying as you lose energy (you can see it on the spectrum version).

But in the Amstrad version on the same game.. the bars are there but only decorative, they don't change the color!!, on the amstrad version you have to "sense" that you are going to lost one live  :laugh:

even the graphics are pure 1bpp, hence only 2 colors,  and the presentation screens, c'mon!! you can't recolour them??? you're being paid for it!!

and the slowness that demostrate the for sure emulation of the spectrum screen!!


This type of conversion is nearly a fraud for me and us the amstrad user were very very lucky, go and ask the MSX users! nearly the 90% of their catalogue is with ports like this (spanish games nearly the 100%), we have less of the 50% of this ports for sure... perhaps a 20-30%, spanish games perhaps only a 5% or less.








Powered by SMFPacks Menu Editor Mod