Since i've been fiddling around with a custom dungeon engine for a while, i've been taking a look at how different Commodore 64 games uses different perspectives and sizes of the pseudo-3D window. The best looking ones are ofcourse some of the newer - Dragon Wars, Centauri Alliance and Advanced Newcomer. Today I examined Bard's Tale I and III, as i've been looking into BT I a lot lately.
At the moment i'm kind of surprised. As it seems, the ingame graphics might be 100% matching between the two versions. I wouldn't be surprised if you could replace the graphics for dungeons and monsters entirely between the two games. Could any of you verify this?
8 BIT BTCS - Matching wall and monster graphics?
Re: 8 BIT BTCS - Matching wall and monster graphics?
Not my forte', I'm afraid.Twoflower wrote:Since i've been fiddling around with a custom dungeon engine for a while, i've been taking a look at how different Commodore 64 games uses different perspectives and sizes of the pseudo-3D window. The best looking ones are ofcourse some of the newer - Dragon Wars, Centauri Alliance and Advanced Newcomer. Today I examined Bard's Tale I and III, as i've been looking into BT I a lot lately.
At the moment i'm kind of surprised. As it seems, the ingame graphics might be 100% matching between the two versions. I wouldn't be surprised if you could replace the graphics for dungeons and monsters entirely between the two games. Could any of you verify this?
BTIII has a redesigned engine so I have some doubt as to whether the graphics between them are interchangeable. Can you explain further?
@ Twoflowers
So you identified the gfx? Please name the files, and then it should be easy to exchange one file of BT1 by one of BT3 and see, if the gfx loads and displays well, same for bigger files with wall gfx.
As for your email to me, regarding the "trainer", the roster of characters is in the files NM00 and NM01 (if 00 is full). There is one C64 character editor out there, but the format is easy and we can, if you want to, completely decode the roster format. With level 511 and 65535 hit and spell points I really don't care about unlimted hp/sp, most monsters will anyway miss me at that level.
The BB00 address was very obvious, since one of the first JSR had to be the text output, and it always happens, that the x,y loaded is the same offset from the beginning of event file where the text in the event file is, just the base address is diff.
I like to check all events that are there for JSR's into the BT jump table and see, which are used for events. Also I like to check all levels, if there is any unused event file, i.e. if all addresses in the event index table (see the file I sent you for dungeon mem map) are used at least once.
There must be a similar logic for the city. Monster names unfortunately are coded in the main program, as well as item names and spell abbreviations, so editing these would be harder.
However we make progress.
So you identified the gfx? Please name the files, and then it should be easy to exchange one file of BT1 by one of BT3 and see, if the gfx loads and displays well, same for bigger files with wall gfx.
As for your email to me, regarding the "trainer", the roster of characters is in the files NM00 and NM01 (if 00 is full). There is one C64 character editor out there, but the format is easy and we can, if you want to, completely decode the roster format. With level 511 and 65535 hit and spell points I really don't care about unlimted hp/sp, most monsters will anyway miss me at that level.
The BB00 address was very obvious, since one of the first JSR had to be the text output, and it always happens, that the x,y loaded is the same offset from the beginning of event file where the text in the event file is, just the base address is diff.
I like to check all events that are there for JSR's into the BT jump table and see, which are used for events. Also I like to check all levels, if there is any unused event file, i.e. if all addresses in the event index table (see the file I sent you for dungeon mem map) are used at least once.
There must be a similar logic for the city. Monster names unfortunately are coded in the main program, as well as item names and spell abbreviations, so editing these would be harder.
However we make progress.
Indeed we do. When examining the BT3 / BT1 ingame tiles I did unfortunatly not work with files; I went through screen-mem and looked at the layout of the char-graphics. Even if the format differs somewhat, it'd be easy to force the graphics into the BT1 engine - the portraits and dungeons share the same size, graphic format (3-color chargraphics) and uses the same pseudo-3D perspective.
I will post some images which explains what I mean.
I will post some images which explains what I mean.
/Twoflower
Just for the sake of completeness - here we go:
Here we see an animation of the dungeon-graphics from BT 1 and BT3.
"Wizardry-outlines" have been added to show how well they align.
It is possible that the BT 3 graphics needs to be pinched up one pixel, but this example illustrates my theory pretty well. Let's go on:
This is an example of a portrait from BT 3 pasted into BT 1. They are exactly the same size, and use exactly the same limitations. It is possible that the BT3 engine enables more animationframes, though.
Here we see an animation of the dungeon-graphics from BT 1 and BT3.
"Wizardry-outlines" have been added to show how well they align.
It is possible that the BT 3 graphics needs to be pinched up one pixel, but this example illustrates my theory pretty well. Let's go on:
This is an example of a portrait from BT 3 pasted into BT 1. They are exactly the same size, and use exactly the same limitations. It is possible that the BT3 engine enables more animationframes, though.
/Twoflower
Ok, seems I have done a major breakthrough which might prove my theory right. After a lot of cursing on the trackloading BT II-engine, I finally managed to find out where in memory it buffered the images / animations after loading. After replacing some graphics in BT, I can proudly state the following:
- The animation / image-engines seems to be identical between (atleast) BT I and BT II.
- I have successfully managed to move two of the animations from BT II into an BT I event.
This means that all animations and images for BT II is potentially available for inclusion in BT I. Right now it is quite a big fuzz to rip them out since the loader hangs when you freeze. Ripping might be doable from VICE-mon though, or by tracking the files directly from disk.
- The animation / image-engines seems to be identical between (atleast) BT I and BT II.
- I have successfully managed to move two of the animations from BT II into an BT I event.
This means that all animations and images for BT II is potentially available for inclusion in BT I. Right now it is quite a big fuzz to rip them out since the loader hangs when you freeze. Ripping might be doable from VICE-mon though, or by tracking the files directly from disk.
/Twoflower
Yep. I will post both some screenshots and a .D64 with the frozen images later today along with some instructions. There are currently two problems which I would require assistance with though:
The first is the fact that it looks like the BT II original disks utilizes en early version of Kris Hatlelid's Pirateslayer protection. I guess that means that the data is trackloaded and all data EOR'ed (bitshifted).
The second is that I don't know how to determine where the loaded animations end - it starts buffering them at $BC00 in memory and it looks like the end is located around $C000-C300 but it is impossible to say exactly where without knowing more of the format. On the positive side - the animation packer (!) have been proved to be coded by Burgerbecky, who have shown up here at times.
I will look more into this later today...
The first is the fact that it looks like the BT II original disks utilizes en early version of Kris Hatlelid's Pirateslayer protection. I guess that means that the data is trackloaded and all data EOR'ed (bitshifted).
The second is that I don't know how to determine where the loaded animations end - it starts buffering them at $BC00 in memory and it looks like the end is located around $C000-C300 but it is impossible to say exactly where without knowing more of the format. On the positive side - the animation packer (!) have been proved to be coded by Burgerbecky, who have shown up here at times.
I will look more into this later today...
/Twoflower
Twoflower wrote:Yep. I will post both some screenshots and a .D64 with the frozen images later today along with some instructions. There are currently two problems which I would require assistance with though:
The first is the fact that it looks like the BT II original disks utilizes en early version of Kris Hatlelid's Pirateslayer protection. I guess that means that the data is trackloaded and all data EOR'ed (bitshifted).
The second is that I don't know how to determine where the loaded animations end - it starts buffering them at $BC00 in memory and it looks like the end is located around $C000-C300 but it is impossible to say exactly where without knowing more of the format. On the positive side - the animation packer (!) have been proved to be coded by Burgerbecky, who have shown up here at times.
I will look more into this later today...
Here is an example of an imported graphics from BT II to BT I:
http://ifile.it/pqg8n1m
The .VSF is a snapshot-file from VICE with a disk attached to it. When you start the snapshot, you should see the animation of the playing Bard as an illustration to the Kylearan-event. Pics are coming soon.
http://ifile.it/pqg8n1m
The .VSF is a snapshot-file from VICE with a disk attached to it. When you start the snapshot, you should see the animation of the playing Bard as an illustration to the Kylearan-event. Pics are coming soon.
/Twoflower
I'll have a look in the morning.Twoflower wrote:Here is an example of an imported graphics from BT II to BT I:
http://ifile.it/pqg8n1m
The .VSF is a snapshot-file from VICE with a disk attached to it. When you start the snapshot, you should see the animation of the playing Bard as an illustration to the Kylearan-event. Pics are coming soon.