News:

Printed Amstrad Addict magazine announced, check it out here!

Main Menu
avatar_Camm

Editing the Palette of an existing game?

Started by Camm, 07:15, 26 March 11

Previous topic - Next topic

0 Members and 1 Guest are viewing this topic.

arnoldemu

The tiles on the sides may be to help scrolling, or perhaps used to help with cutting the sprite to the display area.

I think to make it work fully in mode 0, you *may* need to change the masking table (if it has one), so that pen 0 is correctly masked for mode 0.

I am interested to know how well the scrolling works for mode 0, and how the tiles are converted.

So I look forward to your screenshot.

As for the mask table needed for mode 1, I can't remember what it would look like.
But I'll try and help next week (if you need it ;) ).

My games. My Games
My website with coding examples: Unofficial Amstrad WWW Resource

MacDeath

#51
For a CPC, to manage Mode0,1 or 2 is quite the same...
it's just that Graphics are coded differently...
But for the same "surface" you have the same Weight in RAM/Bytes...

1byte in Mode2 is 1 character... (8x8...)
The same in mode1 would be half a character... (4x8) and in mode0 1/4 of a char (2x8...).


In Wonderboy's case, messing with the modes may bring a problem mostly concerning the background.
Sprites are already in Mode1 as I told, because on spectrum (the source code... it is a Speccy port you know ?) the sprites are masked, hence they have a second set of sprite for the mask... totaling 2bpp per sprites.
But concerning the Background's tiles, they have no "mask" so are still in 1bpp.

The portage was done by adding some routine to convert directly the tiles stored in RAM from the still used (for storage purpose) 1bpp into the 2bpp needed for the screenRAM (VRAM...sort of... ) and the GA-CRTC to read them in Mode1.

1bpp code on CPC is Mode2.but the resolution doesn't match Spectrum's one...

Imagine your fuly 1bpp game would be half as large on screen... ouch...

Ok Spectrum also use some character attributes (not a lot concerning those kind of monochrome games, yet a bit too)


So if you want :
=to get your game in Mode0.
or
=to have more tan 2 colours (1bpp originally) for the background tiles...

You'ld have to :
=edit heavily the routines used to convert the tiles from 1bpp to 2bpp mode 1 (despite those still only use 2 colours instead of 4...)
=Edit heavily the full tile-set... so it is actually in 2bpp/4 colours (or even Mode0...)

The problem is here.

=The RAM is already quite well filled (full ?).
=Getting Mode1 character surface (=2 Mode2 characters = 1/2 Mode0 character) would at best use twice the same RAM weight.
=So you should re-address the full tileset for the engine.

This implies :
=Re-code the Levels-Map so they use half a tile-set but display twice number of tiles. (why not... after all more colours is also a gain and this game have "simple" graphics..)...
or
=yeah... re-address the tiles differently and re-code the "search-tiles" function so the engine know where to search.

But you may have not enough RAM left for the 64K RAM configuration.

So the loading system/RAM management may have to be re-written.
Or the "6128" config have to be used...

And so on.


so yeah, if your want the simplest way, just get the sprites to use 3 colours instead of 2.
And get a slightly better ink Choice for the 2colours background.
Not a lot yet more than nothing.


Or else your mod is like what was done for RickDangerous 128PLUS.




Anyway, this kind of topic teached me a lot in the way Speccyports were done.
And gave me some hints and tools suggestions to learn more about codes and those stuffs.


As I told you, we have a french topic which is quite the same at CPCrulez.

A game such as HeroQuest per exemple could get a good improuvment too and easierly.. because the Graphics are already fully 2bpp coded (not only the srpites...).


QuoteSo my theory is, that they indeed ported it from the Spectrum
Thx mister obvious. ;)
Many English games (mostly Arcade games... but not only) were ported on ZX Spectrum from...say... AtariST.
And there ported (= vaguely emulated) on CPC from the spectrum.

a Native CPC code would never use 1bpp graphics in mode1...

This is a shame and what made the CPC quite infamous around the world.

Many people see the CPC as some sort of a Speccy Clone, which it is not at all.

:'(

http://www.cpcwiki.eu/index.php/Speccy_Port

Camm

#52
I added a bit of extra info in my last post, but basically what I think is going on is there are extra tiles that are layered over the top (raster?), that only use colors from pens 4 to 15 (all of those pens were set to 14 which is the transparent black color, but that may not be relevant). These tiles would not have been recognizable in a tile editor because they just had bits of the sprite on them, where the extra colors was needed for mode 0. Not really sure, but that is all I can come up with at this stage, as the graphics data is definitely 1bpp for the tiles and 2bpp for the sprites.

There is a problem with the mask table in mode 0, so any help there will be appreciated (it does use a mask table)

Camm

Yeah I read that speccy port article today and it was very informative   ;)

I guess what I am saying is, that the game is already coded for mode 0, and for some reason they changed their mind and decided to make it mode 1. Perhaps there were plans to have an option for both modes in the menu, to cater for green screen users, with the option for color, but they abandoned the mode 0 option for some reason.

I will get a screen shot up when I get the palette right.


MacDeath

#54
QuoteNot really sure, but that is all I can come up with at this stage, as   the graphics data is definitely 1bpp for the tiles and 2bpp for the   sprites.
Exactly.
This explains a bit why the game is so laggy and slow.
To get the CPC "translate" "Mode2" graphics into Mode1 os quite intensive.
And this is added to Software sprite routine...

The major aim in speccyport was to have the game to use almost the exact same amount of RAM (to fit the 64K config) and
with minimum extraCoding time because a coder is an expensive worker for a company.

So to use the more Speccy code as possible, which is simply un-CPC friendly.

A Spectrum "VRAM" is something like less than Half the VRAM used by a CPC.

=Spectrum = 256x192x2(+attributed characters) = 7Ko (perhaps even 6k or 8k, don't know...)
just the 256x192x1bpp = 49152bits.

=CPC ? mode1 is 320x200x4 (non attributed, 2bpp)
320x200x2bpp = 16Ko...ouch.
And one character of graphics is twice the Bits as a speccy one (basically).

Graphic Datas are heavier.
To get original Speccy Graphic Datas (1bpp...) translated directly when used by a routine is more RAM friendly but not CPU friendly.
But is faster to programm than redesigning entireley the Game's engine.

Screen size on CPC can be reduced...
in theory, this can reduce the "weight" from the VRAM or even ease scrollings on a CPC dedicated code...
But actually it was just done to simply fit the speccy code, code which can't get a proper scrolling on CPC most of time.

Post edition :
Because we are writting at the same time... ;D

QuoteI guess what I am saying is, that the game is already coded for mode 0,   and for some reason they changed their mind and decided to make it mode   1. Perhaps there were plans to have an option for both modes in the   menu, to cater for green screen users, with the option for color, but   they abandoned the mode 0 option for some reason.
I don't get why you tell the game was coded for Mode0.
to get something in mode0 is not a big deal actually.
It just need to get the full Graphics Data re-written.

So 8x8 in mode1 become 4x8 pixels (same amount of bits) in mode0... covering the same screen surface actually.
Quote
Perhaps there were plans to have an option for both modes in the   menu
:laugh:
I'm afraid no.
To have 2 set of graphic Datas is not something the Speccyporters were doing.
Even to try to make good game was none of their concern. ::)

There was an asshole biznessBoss in each "Speccyport company" to demand the coder to do this for pure money purpose.

If the game was to be in mode0... the "convert 1bpp into monocolour 2bpp" part wouldn't be there.
It would be a fully 2bpp engine.

QuoteRather peculiar that the disk had data for all 16 pens, but it gets   better, the colors were actually specifically placed, it wasn't just a   random mess. Of course the colors were randomly chosen by me, but they   were actually placed properly ... where they had been designed to go, on   the background and on the sprites.
Do you have some screenshot ?


ok.
1byte is 8 bits.

1bpp code is something like :

10001000.

in mode2... 1bpp... so you have
1 pixel ink1... 3 pixels ink0...1 pixel ink1...3 pixels ink0.
8 pixels (those are "half pixels...)
(perhaps in reversed order)

Mode1...
still 1byte to display.
10001000

From right to left... yeah is it like Arabic or Hebrew... ;)

so you have 3 pixels in ink0... and 1 pixel in ink3.
4 pixels (square ones...)

For a mode0.
10001000.

I'm not exactly sure (couldn't find the same schematic) but this is only 2 pixels in 4bpp...

So 1st pixel is  0000 (ink0) and second pixel is 0101... (ink5...)



Inks ? if you are in Mode2 or 1... of cxourse you don't use the extra ink slots that are used for Mode0.
But those are of course set on something (be it by default or last used setting)...

To set on mode0 from mode1 doesn't mean that you have to set all the inks. especially (better if you want a certain control...)


And any byte/sequences of bits can be read as Graphics... in any mode... it will display something, be it a blob of ranom pixels and colours.
The colours depending on the ink set inside the CPC.






Camm

#55
Dude what I am trying to tell you (which is very exciting), is the  game was ported for mode 0.

There is ink data on the disk for 16 pens, pens 4 to 15 were set to the transparent mask value 14.

When I set the game into mode 0 (maybe easier with a ram hack/poke, but not easy to find on a disk hack!), and set random colors to pens 4 to 15, the game is in full 16 color.

The 1bpp background tiles and 2bpp sprite tiles, have got layered tiles on top of them, that were hidden, but when you change the mode to 0 and the ink for pens 4 to 15, those tiles display over the top of the 1bpp tiles and 2bpp sprites.

This isn't a case of trying to change a mode 1 speccy port to to mode 0, this is a case of they coded it for mode 0, and then changed it to mode 1.

This is all very exciting, and a rare discovery by the sound of it  :)

Edit: The Tile theory turned out to be incorrect. I just discovered that in ram the sprites are viewable as 4bpp in mode 0.

MacDeath

#56
No problem, i didn't wanted to sound aggressive or stupid or disapointing or anything, it's just i don't really understand what this looks like... ;D

I'm french you know... English is definitely not what my mama told me. :laugh:



The engine seems to convert the few 1bpp graphics into 2bpp graphics when it displays/use them (numbers and letters, the HUD (score, inventory and so on...)

So in Mode0... the CPC displays this Mode1 screen in mode0.

of course you get the "screen shape" as the bytes are still displayed in the same order at the same place...
Because the tile mapping on the displayed screen is the same...

So it may be possible to actually trick on this.

The 1bpp into 2bppp part is obviously designed to turn the 1bpp characters into 2 colours Mode1 characters, respecting the pixel setting.

This turns 1byte from the "Data RAM" into 2 bytes in the "VRAM" ...

With a clever calculation... you can get a result of 4x8 pixels characters in Mode0...

So redesign the 1bpp character cleaverly so the Mode1 result would be read in Mode0 as something that mean what you want...

Have to test this and check betterly how pixels are coded/read by CPC.
Would certainly be a bit like the trick used on good old PC CGA to get composite mode...(sort of...)

The same with sprite, perhaps even easier as you have one less conversion...


Also got to check the Mask-colour stuff...

is it ink0 used for the Mask ?

So the bytes in sprites are cleverly redrawn (recoded) so the bits can be read in Mode0 to display...what you want.
(also got to cleverly set the 16inks...)

QuoteThe 1bpp background tiles and 2bpp sprite tiles, have got layered tiles   on top of them, that were hidden, but when you change the mode to 0 and   the ink for pens 4 to 15, those tiles display over the top of the 1bpp   tiles and 2bpp sprites.
Ok... what are those tiles lookingl ike ?
Remember that the game actually use mode0 for the intro page.


Perhaps this page remains in RAM...
Which would be a shame as I don't think it is re-used once the game starts... and this weights like 16ko...
But hey, speccyporters were not know for the ingenious way of Gamedesign on CPC... ;D

Anyway, I don't have a lot of time thses days to check all this...
But it is rather cool to see you working on it.

Camm

No problems bud  :)

It does use Ink 0 for the mask color, and the sprites have a problem with the mask table with a bit of flickering over certain colors, but that may change when I get the palette right (not sure).

Edit: The Tile theory turned out to be incorrect. I just discovered that in ram the sprites are viewable as 4bpp in mode 0.

arnoldemu

Quote from: Camm on 15:53, 01 April 11
No problems bud  :)

It does use Ink 0 for the mask color, and the sprites have a problem with the mask table with a bit of flickering over certain colors, but that may change when I get the palette right (not sure).

Edit: The Tile theory turned out to be incorrect. I just discovered that in ram the sprites are viewable as 4bpp in mode 0.
It *may* be possible to use mode 0 sprites, with a modified mask table.
Of course, they would be half the horizontal resolution. If you wanted to make them larger then you will be in trouble.
The code for the tiles is probably fixed for converting 1 bpp to 2bpp.
Without looking into it furthur, you may not be able to do anything, so you may be forced to mode 1.

The code may be against you... and to realise the full potential some code may need to be modified.
My games. My Games
My website with coding examples: Unofficial Amstrad WWW Resource

Sykobee (Briggsy)

Quote from: MacDeath on 15:02, 01 April 11
Exactly.
This explains a bit why the game is so laggy and slow.
To get the CPC "translate" "Mode2" graphics into Mode1 os quite intensive.


Indeed - although if you have 512 bytes spare in memory you can just have a table of mappings, one for each potential 1bpp bit pattern (mapping to two bytes of screen data), and use that table lookup in your rendering routine (but it's still a slowdown). At a push you could have a 16 byte table for mapping nybbles of 1-bit data to bytes of screen data, but you'll be ANDing and shifting your 1-bit data then. However a crude Spectrum 48K port such as this should have a few KB free.



QuoteSo 8x8 in mode1 become 4x8 pixels (same amount of bits) in mode0... covering the same screen surface actually. :laugh:


Very true.  If the game is using 1bpp data in MODE 1, and you switch the game to MODE 0, you have a chance to redraw the tiles as 2bpp at half the resolution, but you will probably need to adjust the rendering code to cope. Generally the best option is to find the background rendering routine, scrap it, and write your own routine that best matches what you are aiming for.


Note that storing 2bpp graphics for MODE 0 games isn't too bad if your routine can select whether those graphics render in colours 0..3, 4..7, 8..11 or 12..15 - maybe using the tile# as a guide. E.g., if your game has 128 tiles, then tiles 0..31 can be colours 0..3, 32 .. 63 can be colours 4..7, etc. Each range could have tiles for different parts of the screen, e.g., palette 0..3 is blue, green, red, white - sky with trees and clouds, palette 4..7 is blue, grey, black, cyan - bricks, ground, etc (with sky blue showing through), palette 8..11 is blue, yellow, red, black - lava or something, and the final palette could have other splash colours.


I don't know about the speed slowdown for such a method though - it would be fine for static backgrounds on non-scrolling games.

MacDeath

#60
Well well well...
What I suggested...
you don't have to consider the graphics as pixels but as bytes... when displayed in "VRAM".

http://cpcrulez.fr/coding_ANTIBUG-01-struct_memoire_ecran.htm
(french article...)


So you convert eack bytes for the sprites... and if the game is patched to be set set in mode0... it reads the bytes as mode0...
then for your sprites, you only have to keep the sprites templates...

A Mode1 16x16pix sprite becomes a Mode0 8x16pix...
This is exactly the same amount of bits/Bytes...

Just got to check if the masking system stil work (stil use 1 ink, the same slot...) and calculate all this/redrawn/convert by hand...


For the 1bpp graphics used by the game, this is a bit trickier...
Displayed in Mode1 because proibably converted by the software.
So to get the Mode0 graphics, you have to consider the source 1bpp characters/tiles...that are then converted into 2bpp... with only 2 inks.

This result is then read in Mode0... so you design it accordingly...if possible.

But this may be enough to get some interesting result.
And would need a lot of trial and tries.

Also gotta see whether the Scrolling or animation works well too.



So, there :
the picture I posted...

the letters are stored in RAM in "mode2"... 8x8 pixels in 1bpp...
But are displayed on screen at 8x8 x 2bpp...
So it would be displayed in mode0 in 4x8 pixels (4bpp...mode0 wide pixels) which il enough to display letters... sort of.



So...

exemple :

1bpp data (=mode2... sort of, gotta check if the Datas here are "mode2 or speccy specific format) :



ex: 01010101

is turned when displayed in mode 1 on screen into er...
mmm...



0000000000001111... or 0000111100000000...(not sure if you read left-right or right left...)

so it displays the same pixels (but widened) pattern...


Then in Mode0...

Argl...
Well i don't have time to calculate a proper exemple ...lol...
But it may be possible to get something ok at display in Mode0...or not.

I would need  time to do some tries and schematic on paper ;D ...

Is anyopne good at conversions ?

what would it look to get a "A" character displayed on screen though such system ?

The "trick" is to start from what you want in Mode0 and go too the 1bpp code through reversed "convertion" as used by this game...


Camm

#61
After spending time experimenting with the palette, It has been disappointing considering the initial excitement of the find.

The menu tiles and sprites are just a mess, however the background tiles do actually work correctly in mode 0, and have 4 pens assigned.

In the screen shots I have set the menu tiles and sprites to black and white because they are just a mess, and have selected 4 inks for the background tile pens. You can see from the screen shots, that the color placement for the background tiles is deliberate and they have done something to make them work in mode 0, although it doesn't look particularly good.

MacDeath

QuoteThe menu tiles and sprites are just a mess, however the background tiles   do actually work correctly in mode 0, and have 4 pens assigned.
Being recoded from 1bpp into Mode1's 2bpp...
The pixels have 2 bits that alternates... (see diagram I posted)

If you read Mode1 datas in mode0... you may actually see the basic patterns of your graphics...

Sometimes it displays well, sometimes not.

exemple :chzaracter "1"

1bpp :
00011000
00111000
00011000
00011000
00011000
00011000
01111110
00000000

translated in Mode1's 2bpp... from 1 byte to 2 bytes.
1byte = 4 pixels.

0001-1000
  0011-1000
  0001-1000
  0001-1000
  0001-1000
  0001-1000
  0111-1110
  0000-0000
this becomes :
00010000-10000000
00110000-10000000
    00010000-10000000
    00010000-10000000
    00010000-10000000
    00010000-10000000
    01110000-11100000
    00000000-00000000

Just adding 4bits in 0... this give the colours 0 remaining colur 0... and Colour 1 bocomes colour 2 ("10" in binary = 2...)


Then if you read this in Mode0...

each byte bocomes only 2 pixels.

1rts Byte per exemple :
00010000 =
1st pixel : 0000... ink0
2nd pixel = 0100...ink 4.

2nd byte :
10000000
1st pixel : 1000... ink7
2nd pixel : 0000... ink 0.

2nd line :
00110000-10000000

00110000= 0100 pixel 1 and 0100 pixel2.
10000000= 1000 pixel3 and 0000pixel4.

And so on.


Can anyone confirm this interpretation ?

RockRiver

#63
Quote from: Devilmarkus on 12:48, 30 March 11
Version 1.1 is out.
You can now also edit all files you want (DSK, SNA etc...)
You find it under the same Download link

Just select "File mode" and then open or save your file.

But: as larger a file is, as slower does the display react!


Hi mates!!
Working now on palette changing for PCWcolor, comes to my mind this old topic... (sorry for bring it up)


My intention is an easy Palette Changing for Thanatos on CPC (Speccy port, you know) maybe with Devilmarkus' CPCgfxEd


Link doesn't work nowadays... It's implemented on JavaCPC emu??? other software/util allow it?

RockRiver


Powered by SMFPacks Menu Editor Mod