I am currently attempting to change the palette in Super Wonder Boy in Monster Land.
Any advice would be appreciated as to what to look for in the DSK image.
I am also curious to know what tile editors (if any) are available for editing sprite tiles in DSK images. I am using Tile Layer Pro which shows up the background tiles and menu tiles, but I am unable to find the sprite tiles.
The game is using Mode 1.
I am experienced in hacking SMS and NES roms, but the CPC is a new ball game and any advice would be appreciated.
Ooh! Can't help you any, but I want to wish you good luck... will be following this closely if it takes off :)
Thanks for the encouragement :)
There is some more info on the hack here: http://cpcwiki.eu/forum/index.php/topic,2093.0.html (http://cpcwiki.eu/forum/index.php/topic,2093.0.html)
A bit of info on myself. I am a Wonder Boy fan of many years, and have been involved in quite a few rom hacks on the SMS, NES and Mega Drive, and recently have turned my attention to the CPC version of Super Wonder Boy in Monster Land.
Hacking a CPC dsk image is on a whole different level, as there doesn't seem to be the same amount of info and applications available as there is for console rom hacks. This one has caught my interest though, as the CPC is capable of much more than a simple Spectrum port.
Any input or information will be much appreciated ;)
A game like Super Wonderboy in Monster Land won't have any Firmware in it (unless your extremely unlucky), so the routine that maybe in it will most likely be setting the Hardware Inks to set the colours. Hardware Inks differ from the standard palette the Amstrad has when setting them from BASIC or using the Firmware for setting the Inks (&BC32). So you maybe able to find them with a decent Disk Editor program and if the code is exceptionally nice you maybe able to do a search in a sequence for those Hardware Inks. Unfortunately I don't have on hand what they are and I'm not quite sure what maybe the best Disk Editor program to do the job, perhaps Xexor since it pretty much does everything one could want (not sure if it will search a disk for a series of bytes).
Others will probably have a better idea where and what to look for.
Quote from: Camm on 18:55, 26 March 11
Thanks for the encouragement :)
There is some more info on the hack here: http://cpcwiki.eu/forum/index.php/topic,2093.0.html (http://cpcwiki.eu/forum/index.php/topic,2093.0.html)
A bit of info on myself. I am a Wonder Boy fan of many years, and have been involved in quite a few rom hacks on the SMS, NES and Mega Drive, and recently have turned my attention to the CPC version of Super Wonder Boy in Monster Land.
Hacking a CPC dsk image is on a whole different level, as there doesn't seem to be the same amount of info and applications available as there is for console rom hacks. This one has caught my interest though, as the CPC is capable of much more than a simple Spectrum port.
Any input or information will be much appreciated ;)
You'll need to know Z80, but I'm assuming you know this already.
Colours:
The colours are access through the Z80's OUT (C),C style instruction.
(includes OUT (C),E, OUT (C),D etc). This performs a write to the hardware "an I/O operation".
BC is normally loaded with the I/O port to write to. and the OUT (C),reg is the value to write to it.
The colours are normally done like this:
LD BC,&7f00+pen
out (c),c
ld bc,&7f00+colour
out (c),c
e.g.
LD BC,&7f01
out (c),c
ld bc,&7f54
out (c),c
which will change pen 1 to black.
The "hardware colour numbers" are listed on www.cpctech.org.uk (http://www.cpctech.org.uk). Look for "Gate-Array".
Take the hardware colour number, turn it to hex, add &40 to it and you got the number.
You should be able to see these in the code. Sometimes, the screen shows more than the mode normally allows (e.g. 4 for mode 1), so to do this the colours are changed through an interrupt function.
Normally the interrupt function is called through &0038, normally a JP instruction here to the actual interrupt handler.
You can then see what it does, including OUTs just like these.
If you see an out like this:
ld bc,&7f89
out (c),c
then it's changing mode.
Generally read the gate-array document to get a handle on how to change modes, colours etc.
As for graphics.
You can use the graphics viewing tool in Winape emulator. On cpc there is no fixed tile width, height. It's all done through software functions, so you can have any size and data form as you need.
So use winape, adjust width and height until you see something sensible.
Winape also allows you to edit the graphics in place, but you can equally save out a snapshot, and work on this.
Most hardware documentation is here on cpcwiki, but also on www.cpctech.org.uk (http://www.cpctech.org.uk).
I hope this gives you a step in the right direction, feel free to ask more questions, I'll be happy to help.
EDIT: My advice is to first edit a snapshot to get a feel of how the code is doing the colours and graphics.
When you're happy with that, writing it back to a disk image is a bit more work.
(involves writing files using cpcxfs or similar tool, and if the game is a hack, the fun of possibly repacking the file, or if it's an original the fun of either re-cracking it, or trying to write the data direct to the sectors in a way that still works with the protection ;) None are impossible, but they vary in their complexity. ).
Thanks for the info CP/M User and arnoldemu, it has helped put some of the pieces together ;)
Ok so I have managed to find the palette data on disk 2, using a hex editor. The reason I couldn't find it before was because I was looking for the value with 40 already added, and on the disk it stores that number before the 40 is added. So black is stored as 14 not 54 on the disk (for example). Fortunately the 4 colors where actually stored in sequence! Which made it quite easy to find in the end, once I knew what I was looking for.
Still can't find the sprite info on the disk, but progress is being made.
More info soon and thanks again!
Quote from: Camm on 05:43, 28 March 11
Thanks for the info CP/M User and arnoldemu, it has helped put some of the pieces together ;)
Ok so I have managed to find the palette data on disk 2, using a hex editor. The reason I couldn't find it before was because I was looking for the value with 40 already added, and on the disk it stores that number before the 40 is added. So black is stored as 14 not 54 on the disk (for example). Fortunately the 4 colors where actually stored in sequence! Which made it quite easy to find in the end, once I knew what I was looking for.
Still can't find the sprite info on the disk, but progress is being made.
More info soon and thanks again!
Why not run the game in the emulator and find the sprites/tiles/colours through the emulator?
Much easier to find, but then the problem is then how to translate the data from it's memory form to it's disk form.
Could you extract the files using cpcxfs or another dsk tool (dsk-manager)?
Then you can look at the graphics?
How are you searching for the gfx?
it is possible that the coder chose to store the sprites/tiles in a mode 2 form (2 colour, 8 pixels per byte) and then translate them to mode 1 at runtime....
I am pleased you are making progress.
I have been using Tile Layer Pro to look for and edit the tiles. The background tiles are viewable/editable and are stored as 1BPP, but as mentioned the sprite tiles aren't showing up and would need to be stored as 2BPP as they have a 3rd color used for masking/transparency (I would assume).
I can view the sprites in Winape, but using a DSK editor/manager is something that I have no idea about, let alone using one to get my edits from Winape onto the disk. Guess I need to do some fast learning :)
WinApe's DSK editor is quite simple!
Press CTRL + SHIFT + F1 to access DSK in drive 0 or CTRL + SHIFT + F2 to access drive 1.
There you can drag & frop files from DSK to any explorer window or from windows to DSK.
Make sure, that the files have an AMSDOS header!
You can select "Add/Remove AMSDOS header" to add a pseudo header to each file you put on your DSK.
I also coded a little AMSDOS header tool, which allows you to add or remove an AMSDOS header to every file you find.
I'll attach it here...
If you are confused, how to run it:
You need Java on your PC.
Then you can run it by double click or use a .BAT file with this content:
java -jar AMSDOS.jar
Ok thanks for the info.
I think the part that I am confused about is if I edit the sprites in ram in Winape, how does that help put them on the disk.
Quote from: Camm on 11:07, 28 March 11
Ok thanks for the info.
I think the part that I am confused about is if I edit the sprites in ram in Winape, how does that help put them on the disk.
Well, you could load each file into Amstrad's ram.
then you can edit them (via Winape) and save them back to disk.
it would be something along these lines:
in basic:
load"<file>",&4000
edit the file
back to basic:
save"<file>",b,&4000,<length>
knowing the length of the file is important, and the dsk editor can help.
If the file is long, loading to &4000 will not be low enough, and you may need to load it lower.
But it's another possible way to edit the graphics.
JavaCPC's GFX editor also allows you to store the binary direct to your harddrive.
It works almost like WinApe's.
But you can select a range of sprites and store them. (Incl. AMSDOS header of course)
These you could edit and after merge them back into your program.
E.g.: Game's binary is from &4000 to &7fff, sprites are located between &5000 and &5fff.
Then you edit the sprites, save them to your PC and move the .bin on your DSK.
Then you would load the game like this:
MEMORY &3FFF:LOAD"GAMEDATA",&4000:LOAD"SPRITES",&5000:CALL gamestart
Info about JavaCPC's GFX-viewer:
http://cpcwiki.eu/forum/index.php/topic,484.msg15088.html#msg15088
You can find it in my latest beta:
http://cpc-live.com/data/list.php?dir=-beta
Your doing some very nice work there Devilmarkus ;)
I have managed to find the sprite data on the disk image, and have also discovered why I can't see it in Tile Layer Pro, or any of the other rom hacking tile editors (I have tried a pile of them). It is to do with the width of the tiles. When the tiles are viewed in Winape the width has to be altered in order to see the sprites. Also in Winape, if I actually load in the disk image directly to the debugger (see attached image), I can still see the sprites, I just can't save any changes back to the disk image.
Ironically, in Tile Layer Pro I can see and edit the 1bpp background tiles, which don't show up in Winape's editor.
I think all this has really exposed the need for a tile editing tool, with settings specific for the Amstrad, that edits the disk, tape or rom directly, with features like variable width tile viewing like in Winape. I think something like this would really open up the hacking/mod potential of the Amstrad community. So if any of you tool makers out there are feeling inspired, this is something that I think would be really worth while for the amstrad community.
With this feature in WinApe's debugger you just loaded a DSK image into CPC's ram!
It's not for editing disks!
It's meant to load binaries into ram...
You can basically edit sprites in my GFX-Editor, too... (well, no fill function, but you can zoom them and change all pixels)
Quote from: Devilmarkus on 12:31, 29 March 11
With this feature in WinApe's debugger you just loaded a DSK image into CPC's ram!
It's not for editing disks!
It's meant to load binaries into ram...
Yes, I was just pointing out, that when I did that (not the intention of the tool), I was able to see the sprites, which means the raw sprite data is on the disk, it is just the tile editors that don't have the ability to view it because of the abnormal tile size, or the way in which the data is laid out.
The idea would be to have a tile editor, that loads the disk data directly, displays it graphically, then you just edit that data and re-save the disk file. There are a pile of them out there, with Tile Layer Pro being the most popular, but nothing that I am able to find that allows to vary the width of viewed tiles like in Winape. I think something like this would be really great for the amstrad community.
Quote from: Camm on 12:41, 29 March 11
The idea would be to have a tile editor, that loads the disk data directly, displays it graphically, then you just edit that data and re-save the disk file. There are a pile of them out there, with Tile Layer Pro being the most popular, but nothing that I am able to find that allows to vary the width of viewed tiles like in Winape. I think something like this would be really great for the amstrad community.
My idea is:
I will use CPCInAJar as base (It contains all necessary functions)
and code a GFX-editor around it. It will look like the GFX editor in JavaCPC.
But the difference will be that you can select the files from your DSK to edit them.
You would have to setup the palette then manually! Also the screenmode.
But the editor could write directly the edited files back to your dsk. (I will use CPCXFS to make it possible)
Perhaps I will also show the CPC screen as small display and so you could do like this:
- Load and run your game
- So you get screenmode and palette
- Now select a file from your dsk and edit it.
- Save the file back to dsk, when edited and reset the tool and check your game
Sounds awesome.
Now understand that I am an amstrad noob, and am not used to dealing with dsk images that contain individual files. What I am used to is SMS and NES roms.
From what I can see though, the dsk image has all the data from it's contained files clearly readable and unaltered. So it should just be possible to read in the dsk directly and display the whole disk image as it is. Any tile data should show up regardless of whether the individual files have been separated or not ... Is this actually the case, or is there something that I am missing here?
With other systems, quite often an emulator will be able to save the palette of the game to a file, then this file is readable by various tile editors. Quite often though, it is enough just to muck around with the palette in the tile editor (with a color selection type tool in the editor) and put together a palette that allows you to see enough to work with.
I think it would probably be simpler to not add any emulation to the tool itself, but maybe have something like a palette file that is dumped by the emulator and readable in the editor.
Just some thoughts, forgive me if I sound a bit noobish when it comes to Amstrads ;)
No worries about that!
Well, I already begun coding it...
Working on the GUI and then I will implement all features ;)
(http://cpc-live.com/firstscreenshot.png)
In this panel you can use the CPC emulator as it should be used.
(Load games, play them etc...)
In the other panel the GFX-editor will take place.
Well, still lots of work ;)
Edit: Perhaps I should use double screensize here, what do you think?
Then also MODE 2 would fit properly...
Quote from: Camm on 13:22, 29 March 11
From what I can see though, the dsk image has all the data from it's contained files clearly readable and unaltered. So it should just be possible to read in the dsk directly and display the whole disk image as it is. Any tile data should show up regardless of whether the individual files have been separated or not ... Is this actually the case, or is there something that I am missing here?
The disk is generally 40 tracks, with 9 sectors (512 bytes size) for each track. This is the disk's formatted and base structure.
On top of this is the AMSDOS/CPM based filesystem (similar to how a PC stores files and how the IDE/SATA drive is structured - same concepts).
The files are then organized, as multiple blocks of data (2K each) which are potentially spread anywhere on the disc (similar to pc). So the data is not necessarily continuous.
The dsk is a dump of a real disk, with added structures defining the raw disc format, in a way that an emulator can read it, and a tool such as CPCdiskxp can write it back to a real disk to use on a real computer.
So you can load a disk image into memory (well not so easy since it is 178k and Amstrad's base ram is 64k), and edit it this way, or edit it in a hex editor, but then viewing it may result in finding half a sprite in one part of memory, and half in another, and in addition you risk destroying some important headers and then it can't be read in an emulator.
There is added complication in that the data on disk could be encrypted or compressed, or even not stored as files, but there are plenty of hacks where the protection has been removed, so I think this is not so much of an issue.
Generally I think roms (sms etc) are stored in continous blocks, and are often uncompressed and not encrypted, so hacking them is much easier, and in additiont the hardware of these consoles have hardware and fixed format tiles and sprites.
Hacking, for example, a Amstrad Plus cart would be much more familiar to you after it has been converted to raw binary.
(e.g. to hack a + cart, convert cpr to bin, edit it, convert bin back to cp and test it).
An editor as Devilmarkus suggests, which allows you to focus on individual files within a dsk, although a slightly different way of working, will probably yield a better result, because the data you will edit and see will be continuous (it will also take care of ensuring the appropiate file headers are correct for the Amstrad's filesystem, and that it is written correctly onto the dsk).
Some games come in 2 parts (loader and then main binary), some come in more, but I think this way could be the best.
I think mostly the editing issue is down to the structure of the emulator file, and how the data is structured within in, and the way to edit this in a way which is easy.
Please try the tool when it is ready, please give feedback, and hopefully it is heading in a direction that makes editing games like this much easier for a new Amstrad user such as yourself.
Very nice project, Markus.
That will be a useful tool, go on!
I think that what you are doing is a good thing, because I think many CPC games could be improved with some hacking, some require graphics changes, some require recoding.
And because you're new to it on CPC, you can highlight more easily for us, the problems and the way it can be done.
I already read in the other thread that you found something with the other black colour, which is interesting, something I wasn't really aware of.
Thanks for that info arnoldemu, it certainly makes things much clearer :)
Looks great Devil, and I agree with the idea of making it bigger.
QuoteAnd because you're new to it on CPC, you can highlight more easily for us, the problems and the way it can be done.
It is exciting for me to provide an outsider perspective, for what appears to be a very worthy and much loved machine :)
Also noobs inspire me for new ideas :D
So, noobs from all countries, unite! :D ;)
lol I am glad we have a use for something ;D
Making progress...
Need to embed CPCXFS and a suitable filechooser...
But the most important things already work!
Looking great :)
I am astounded at how quickly this has all come about and the progress that has been made already. All I can say is nice work, and keep going.
Well it goes quick because I use existing classes from JavaCPC and CPCInAJar and combine them.
The CPCXFS embedding and the "file-mode" I will code extra.
File editing is a hard nut... But I'll make it ;)
Here you go: CPCgfxEd 1.0 is ready to use!
It can edit sprites from RAM or also from DSK images!
Download (http://cpc-live.com/data/download.php?type=-tool&fichier=CPCgfxEd.zip)
Please handle with care ;) (Always use copies of your to-edit-dsk)
How to edit sprites now from files?
Simple follow these steps:
- Startup CPCgfxEd
- Insert a dsk into drive (F2 or the button)
- Load your game and run it (Only if you need colour palette)
- Switch to GFX Editor view
- There in the upper right area you see 2 radio buttons: RAM mode or DSK mode. Select DSK mode here.
- This will show you a selector with all found files from your DSK. Select one now.
- Search and edit graphics in this file. Use mousewheel to scroll, or change address by + and - buttons.
- Edit a sprite cell by double click with your right mousebutton into the sprite you want to change.
- Important: Select the pencil icon here in the Cell-Editor!
- Pixel around as you wish
- Edit as many sprites as you wish in the loaded file
- When done, click the "Save" button right to the file selector.
- Thats all! Have fun!
- Always remember: keep your original DSKs in a safe place!
- When done editing, you can delete "temp.dsk" and "temp.bin" (In the same folder where this app. is in)
- Never delete the folder "tools" or its contents! (Contains CPCXFS)
Are you Speedy Gonzales?
Pretty damn quick!
Yep...
Well I had nothing other to do... ;) You are not here... So all is sad :'(
Incredible!!
I was able to test and edit the sprites, using the version of super wonder boy that has loading problems later in the game, which I believe was a tape to disk conversion (as it asks in the game to rewind side 2 and press play). I also found some information that said that the cassette tape version of the game had loading problems and was a known bug.
Strangely enough, the 2 different disk versions that I have found that load correctly, don't have any individual files on disk 2, which is where the sprites are, so I couldn't use the tool with them. You can download these versions here:
http://cpc-power.com/pages/download.php?fiche=2150&dsk=4 (http://cpc-power.com/pages/download.php?fiche=2150&dsk=4)
http://museo8bits.es/cpc/games/arcade/superwon.zip (http://museo8bits.es/cpc/games/arcade/superwon.zip)
I am not sure if this is common with CPC games or not?
Anyway, I am testing the application with the version that has loading problems and will report any bugs that I discover, and any suggestions that come to mind.
Brilliant work and very encouraging ;D
In my testing so far I have been able to confirm that the sprites can have the 3rd color added to them. The attached images show this with a quick test that I did.
Ok I have been testing more and have some feedback:
- Something to look at, is when the screen is zoomed out, ie. zoom 1 and sometimes 2, and there is a lot of data on the screen, if you press - or +, sometimes only the top part of the data moves and the bottom part does not move. Also when doing this, sometimes strange colors appear that are not part of the palette. In order to replicate this possible bug, it must be a large file.
- similarly when scrolling with the mouse wheel, I have seen some strange colors appear that are not part of the palette. Edit: when scrolling or moving at all these colors seem to appear occasionally. All seems to be related to the first mentioned bug.
- After a new disk is loaded, or if changing between ram and disk, the data displayed does not update to the new data until you scroll.
- A suggestion would be some way to edit the colors of the palette manually, of course they don't need to be saved but just for the purposes of working with the graphics. For example, with super wonder boy, there are 2 blacks, 1 of which is used as a transparency mask for the sprites. In this situation it is useful to to change one of the black colors in the palette, so you can see what is being masked and what is actually black. Some sort of color selector tool would do the trick.
- Along with the mouse wheel, and -/+ controls(and check boxes), possibly use Page Up and Page Down to skip pages of data. Home and End to skip to the start or end of the data. Could also make use the up, down, left, right arrow keys to for quick key based movement, just a thought.
- The ability to load, view, edit, any file, including whole disk images, cartridges/roms etc. could be useful in certain situations, such as the problem I have encountered with the super wonder boy disks. Mind you this is an area I know nothing about, so you may a solution up your sleeve for that one ;)
This tool is shaping up to be totally awesome! (Yes I was well and truly alive in the 1980s lol)
Edit: When selecting a file in a disk, after clicking the dsk mode, with multiple files you can't see the data for the first file on the list until you have clicked on the second file and then clicked back on the first.
Quote from: Camm on 04:04, 30 March 11
Incredible!!
I was able to test and edit the sprites, using the version of super wonder boy that has loading problems later in the game, which I believe was a tape to disk conversion (as it asks in the game to rewind side 2 and press play). I also found some information that said that the cassette tape version of the game had loading problems and was a known bug.
I did do a tape to disc conversion at one time of this game. So this bad one might be mine.
Quote from: Camm on 04:04, 30 March 11
Strangely enough, the 2 different disk versions that I have found that load correctly, don't have any individual files on disk 2, which is where the sprites are, so I couldn't use the tool with them. You can download these versions here:
http://cpc-power.com/pages/download.php?fiche=2150&dsk=4 (http://cpc-power.com/pages/download.php?fiche=2150&dsk=4)
http://museo8bits.es/cpc/games/arcade/superwon.zip (http://museo8bits.es/cpc/games/arcade/superwon.zip)
I am not sure if this is common with CPC games or not?
Anyway, I am testing the application with the version that has loading problems and will report any bugs that I discover, and any suggestions that come to mind.
Brilliant work and very encouraging ;D
In my testing so far I have been able to confirm that the sprites can have the 3rd color added to them. The attached images show this with a quick test that I did.
Excellent!
As for the disk version, a version that does direct sector editing could be good for this, but it may be better to work with a working cracked version.
Quote from: Camm on 04:04, 30 March 11
Incredible!!
I was able to test and edit the sprites, using the version of super wonder boy that has loading problems later in the game, which I believe was a tape to disk conversion (as it asks in the game to rewind side 2 and press play). I also found some information that said that the cassette tape version of the game had loading problems and was a known bug.
Strangely enough, the 2 different disk versions that I have found that load correctly, don't have any individual files on disk 2, which is where the sprites are, so I couldn't use the tool with them. You can download these versions here:
http://cpc-power.com/pages/download.php?fiche=2150&dsk=4 (http://cpc-power.com/pages/download.php?fiche=2150&dsk=4)
http://museo8bits.es/cpc/games/arcade/superwon.zip (http://museo8bits.es/cpc/games/arcade/superwon.zip)
I am not sure if this is common with CPC games or not?
Anyway, I am testing the application with the version that has loading problems and will report any bugs that I discover, and any suggestions that come to mind.
Brilliant work and very encouraging ;D
In my testing so far I have been able to confirm that the sprites can have the 3rd color added to them. The attached images show this with a quick test that I did.
In the part where you added the colour, is this treated as transparent now?
Quote from: Camm on 04:59, 30 March 11
Ok I have been testing more and have some feedback:
- Something to look at, is when the screen is zoomed out, ie. zoom 1 and sometimes 2, and there is a lot of data on the screen, if you press - or +, sometimes only the top part of the data moves and the bottom part does not move. Also when doing this, sometimes strange colors appear that are not part of the palette. In order to replicate this possible bug, it must be a large file.
- similarly when scrolling with the mouse wheel, I have seen some strange colors appear that are not part of the palette. Edit: when scrolling or moving at all these colors seem to appear occasionally. All seems to be related to the first mentioned bug.
That's strange. I did not encounter this problem.
Perhaps your Java is outdated / your PC too slow?
Quote- After a new disk is loaded, or if changing between ram and disk, the data displayed does not update to the new data until you scroll.
True... I could blank the editor. A file should only be loaded when the user wants it.
But I think you can live with that ;)
Quote- A suggestion would be some way to edit the colors of the palette manually, of course they don't need to be saved but just for the purposes of working with the graphics. For example, with super wonder boy, there are 2 blacks, 1 of which is used as a transparency mask for the sprites. In this situation it is useful to to change one of the black colors in the palette, so you can see what is being masked and what is actually black. Some sort of color selector tool would do the trick.
Well, that would be impossible while the game is running. The game code or the CPC itself would overwrite a changed palette.
But you can do this:
- Don't run your game
- Select the file you want to edit as you already did in the selector
- Define the inks from BASIC manually. (INK 0,w:INK 1,x:INK 2,y:INK 3,z)
Quote- Along with the mouse wheel, and -/+ controls(and check boxes), possibly use Page Up and Page Down to skip pages of data. Home and End to skip to the start or end of the data. Could also make use the up, down, left, right arrow keys to for quick key based movement, just a thought.
My "playfield" (The area, where you see the sprites) is a rude hack :D
I will try to add "page up - page down" keys. But I am not sure if it works.
Also mouse scrolling is not always accurate.
Quote- The ability to load, view, edit, any file, including whole disk images, cartridges/roms etc. could be useful in certain situations, such as the problem I have encountered with the super wonder boy disks. Mind you this is an area I know nothing about, so you may a solution up your sleeve for that one ;)
As larger a file is, as more problematic is to show it.
So, @ the moment it's for files on DSKs only.
QuoteThis tool is shaping up to be totally awesome! (Yes I was well and truly alive in the 1980s lol)
Thank you! :)
QuoteEdit: When selecting a file in a disk, after clicking the dsk mode, with multiple files you can't see the data for the first file on the list until you have clicked on the second file and then clicked back on the first.
True.
But I don't want to load the first file automatically. Perhaps I should add the entry "none" @ first field and this cleans the editor.
You can hit the "Step field" checkbox. This will step each sprite cell when you click + or - on the address field.
"Step line" steps the field linewise.
I looked at the code.
The sprites seem to be drawn using a standard method (AND screen with a mask, and then OR the data on).
This implies, the potential that you can use 3 or possible 4 colours for each sprite (depending on masking method).
You can use 4 colours if you can find mask data in there (look for it in mode 2), but more likely they use a mask table, and you can only use 3 colours + transparent.
As for the backgrounds, I think I see something related to them, but it looks like the code is forced to 1-bit.
Does the scroll move a minimum of 4 pixels at a time? I see RLD and RRD opcodes being used. (RLD and RRD can be used for 4-pixel rate scrolling in mode 2).
But I also see big blocks of LDI being used, which also imply 4 pixel scrolling, but normal scroll.
So without furthur investigation, I can't tell if the tile drawing code is actually full colour in disguise, or forced for 1 bit.
I'd need to look at the code a bit more to give a full and final answer to the possibilities, but I know already you have opened up some without me looking closer.
QuoteSo, @ the moment it's for files on DSKs only.
The only versions that I have found that doesn't have loading problems later in the game, I can't edit disk 2 with the new tool because it doesn't have any amstrad files on it, just data. Is there some sort of way that it can be done?
This is one of them from CPC-Power and looks like an official disk release for the game:
http://cpc-power.com/pages/download.php?fiche=2150&dsk=4 (http://cpc-power.com/pages/download.php?fiche=2150&dsk=4)
Can you have a look at it with the tool devil and let me know if there is a solution?
QuoteThat's strange. I did not encounter this problem.
Perhaps your Java is outdated / your PC too slow?
I updated Java yesterday, and my computer is quite reasonable. The bug was occurring when large amounts of data where scrolling or moving with zoom on 1 or 2. The easiest way to replicate it is when viewing ram. It would be good if someone else could have a look and see if they encounter the same problem.
QuoteIn the part where you added the colour, is this treated as transparent now?
I can see that it might look that way from the image, but no it is solid color :)
The original DSKs are not editable in this way.
They use copy protections / unreadable formats for CPCXFS.
Perhaps I add DSK-edit feature, too. So you can edit directly on the DSK.
But first I must find the pixel problem... :o
Ok thanks Devil.
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 (http://cpc-live.com/data/download.php?type=-tool&fichier=CPCgfxEd.zip)
Just select "File mode" and then open or save your file.
But: as larger a file is, as slower does the display react!
Brilliant!
I successfully managed to load the DSK file, edit the sprite graphics, saved directly to the DSK file using the new file mode, and then tested in the emulator with the changes visible.
I played around for a while and thought that I could not get the zoomed out/scrolling bug to replicate, but eventually I did get it to happen, after I went into mode 0, was also in Ram mode and there was a lot of data. So it didn't actually happen for a while until I went into mode 0. I didn't see any weird colors appear though, just the top part of the data moved and the bottom part of the data was stationary when the -/+ feature was used.
I think that the Page Up/Page down feature would be a real improvement for larger files, as I did a lot of scrolling with the scroll wheel lol.
All in all excellent work and I think this is going to be a favorite, must use tool for amstrad modders and hackers :)
A couple of new questions that I would appreciate some thoughts on.
The below screen shot is an info hack where I have edited any mainly 1 color tiles so that they have numbers/letters, to show where they are being used. I have also changed 1 of the 2 black colors, the sprite transparent mask color, from black to blue. Just ignore the horrible color scheme, it is just a hack to gather info.
(http://cpcwiki.eu/forum/index.php?action=dlattach;topic=2115.0;attach=1423;image)
As you can see in the screen shot, the transparent mask color is also being used in the play area, and there are 2 vertical columns of blue on the edges of the playing field that would normally be black and therefore not noticeable.
I have not been able to find a tile that is being used where the blue columns appear, so is this just empty space and blue is the background color?
Does anyone have any ideas about how to make those blue columns black?
Any thoughts would be most appreciated :)
Version 1.2 is out.
You find it under the same Download link (http://cpc-live.com/data/download.php?type=-tool&fichier=CPCgfxEd.zip)
New:
- Page up/down buttons scroll though the cells now. (Accelerated)
Click into address field to enable them.
- Bug fix: DSK files are loaded properly now. (1.1 only handled the first 64k)
- Palette override: Click on a colour @ the bottom palette field. There you can lock and override the colour.
- Added a Hex editor to edit files.
This tool is a powerhouse ... That is all I have to say!
Quote from: Camm on 14:51, 31 March 11
This tool is a powerhouse ... That is all I have to say!
:) Thank you!
I hope you find it useful ;)
Really nice, like JavaCPC!
I'm starting to hate my netbook... it's sooo slow!
Well it has been a crazy couple of days of hacking, where after working out how to change the palette, and adding the extra color, I embarked on the impossible mission of finding where the pens were assigned to the task of drawing the tiles. This would give me some control over what color was being used for what. As you can imagine this was much harder than finding the palette data, because the pen values are 00, 01, 02 and 03 ... very common values. I bit the bullet and entered 01 in to the search bar and spent the best part of a day and a half finding 01 and changing it to 00, then starting the game and looking for the desired change, then going through the whole process again ... not particularly enjoyable, but all part of being a hacker. After almost giving up all hope, having tested a ridiculous number of times, I finally found it, and the rest of the pens were assigned in the same area.
However, I wouldn't be writing such a long spiel as this, if that was all I found!!! After all I was searching for 01 and changing it to 00, and it turned up something very interesting along the way. I found the value on the disk that controls the mode of the game and managed to change it into mode 0 with 16 colors.
Oh that's nice, I hear you say, but it isn't really going to be of much use. The graphics won't be in the right format, their won't be enough pen data on the disk to support it etc, etc.
Well, I wouldn't be writing such a long spiel as this, if that was all I found!!! When I first fired the game up in mode 0, first of all it worked which was a surprise, but as expected it only had 4 colors and looked like a garbled mess, plus the sprites were invisible. BUT! I remembered that directly after the palette data there was a pile of 14s (black) and so on a whim I decided to replace all the 14s with random color values. I fired the game up and BANG the screen exploded in a mess of color. Rather 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. The game is using 16 colors and it plays properly. I don't know exactly how, but the graphics themselves actually look ... well ... right? This one is even bending my brain I have spent days looking at these tiles in tile editors and I was certain that the menu and background tiles were 1bpp and the sprites were 2bpp, but there is 4 colors on each background tile, 4 different colors on each menu tile and 8 colors (7 + mask) on the sprites (some shared with the menu tiles). This one is bending my brain I can tell you, but it is all there and working. All I can think of is it must be some sort of layered effect, where there are actually more tiles that layer over the top. In mode 1, the palette for these extra tiles must have been those values that were set to 14, which is the transparent black, and was effectively hiding those tiles??
As a mad keen Wonder Boy fan, I am well aware of the other activision ports of the game, and I immediately thought this might actually be an Atari ST port, or perhaps even commodore 64 or Amiga, but as I fired up each emulator and had a look at those versions it was apparent that the graphics had not been ripped from those versions. They had indeed come from the spectrum.
So my theory is, that they indeed ported it from the Spectrum, and had the intention of a full blown "proper" port, but as the deadline drew closer they decided to take a short cut in order to meet that deadline and put it into mode 1. Or it may even have been for the benefit of the green screen. What ever the reason, one thing is for sure, this game is not limited to 4 colors and this hack just got a whole lot more exciting!
I now have control over the palette/ink, the assignment of the pens and mode 0 with 16 colors! I also discovered that part of the play area is actually covered up with black tiles, and it actually loads the play area tiles underneath them, but they don't scroll. Not sure what I can do with that yet, but it is something else worth a mention.
I haven't got a screen shot to post at this time, because I am trying to get the palette right. I am attempting to use the Atari ST version as a reference as it may have been influenced by that version. If not I will just go with an extended version of the original look.
More info soon.
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 ;) ).
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 (http://www.cpcwiki.eu/index.php/Speccy_Port)
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)
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.
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
(http://cpcrulez.fr/img/754.jpg)
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.
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.
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.
(http://www.cpc-power.com/images/ecran_titre/2150.png)
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.
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.
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.
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.
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 (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) :
(http://cpcrulez.fr/im3/CPC_MemoireGraphique_02.png)
ex: 01010101
is turned when displayed in mode 1 on screen into er...
mmm...
(http://cpcrulez.fr/im3/CPC_MemoireGraphique_04.png)
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...
(http://cpcrulez.fr/im3/CPC_MemoireGraphique_03.png)
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...
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.
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 ?
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 (http://cpc-live.com/data/download.php?type=-tool&fichier=CPCgfxEd.zip)
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'
CPCgfxEdLink doesn't work nowadays... It's implemented on JavaCPC emu??? other software/util allow it?
Something like that...
(https://i.postimg.cc/KzgLqxqm/thanatos-new-palette.png)