Camoto Windows version

Discuss classic and favorite computer or console games here.
User avatar
Paramultart
VBB's Partner in Crime
Posts: 3004
Joined: Mon Jul 26, 2010 8:36

Post by Paramultart »

Malvineous wrote: An internal patch database would be interesting too, but at the speed most patches are produced I'm not sure distributing them with Camoto would be the best way - I'm thinking an online system might be better for that sort of thing, so (like the wiki) people can add and update patches easily. Again, I'm open to suggestions!
Perhaps just bare-minimum patches should be included; things that are absolutely essential to any comprehensive mod, such as text strings to edit dialog that is strangely not included in the .DAT file?
"Father Mabeuf was surveying his plants"
User avatar
Malvineous
Shikadi Webmaster
Posts: 382
Joined: Wed Oct 31, 2007 21:48
Location: Brisbane, Australia
Contact:

Post by Malvineous »

I had actually planned to allow text strings to be edited, but it's kind of a grey area as to where you actually stop. Crystal Caves requires the .exe to be patched to change the background tiles in the level, so do you do that in the level editor or a CKPatch type patch? Do you add text strings to the patch file or change them through the GUI? What happens when advanced patches change so much stuff that some of the offsets are no longer valid, and the GUI presents bad data?

My current thoughts are along the lines of self-contained data in the .exe (like a game level) can be edited, but everything else - text strings and code changes - belong in a patch database.

@Levellass: Resizing individual sprite frames will eventually be ok. The Camoto libraries can handle this for sprites and tilesets (if the file format supports it), I just haven't had a chance to make this functionality available through the GUI. But perhaps a more important issue is what happens if you patch the game to allow different sized sprites/tiles, for those file formats that don't store the size internally? Camoto will assume the old size which means it won't write the file out correctly.

@Lemm: I see now. The sprite format can hold more frames without a problem (again the libraries and command-line tools support adding more frames to the file but the GUI doesn't expose a way to do this yet) so I guess you'll then need to patch the game to actually use these extra frames. On this note, a number of sprites have frames made up of only a 1x1 white pixel - do you have any idea what these are for?
User avatar
Paramultart
VBB's Partner in Crime
Posts: 3004
Joined: Mon Jul 26, 2010 8:36

Post by Paramultart »

In the case of par-times being stored in the executable and not in the .DAT file, another essential patch for modding would be the respective "PAR TIMES". We don't currently know where this information is stored, or if it is entered as minutes, seconds or tics, but that is definitely something worth figuring.
"Father Mabeuf was surveying his plants"
User avatar
lemm
Blorb
Posts: 696
Joined: Fri Jul 03, 2009 10:18
Location: canada lol

Post by lemm »

Malvineous wrote:
@Lemm: I see now. The sprite format can hold more frames without a problem (again the libraries and command-line tools support adding more frames to the file but the GUI doesn't expose a way to do this yet) so I guess you'll then need to patch the game to actually use these extra frames. On this note, a number of sprites have frames made up of only a 1x1 white pixel - do you have any idea what these are for?

I would guess that they are remnants of frames that were removed during development.
User avatar
Levellass
S-Triazine
Posts: 5265
Joined: Tue Sep 23, 2008 6:40

Post by Levellass »

It's remarkable what dummy graphics get left in.
What you really need, not what you think you ought to want.
User avatar
Roobar
Vorticon Elite
Posts: 3263
Joined: Tue Jan 08, 2008 16:12
Contact:

Post by Roobar »

Recently, I've felt like wanting to make Dangerous Dave levels. I found that there's a newer version of Camoto, which Malvineous didn't post here.

But anyway, can someone please help me getting Dangerous Dave working? Levellass? Malvenious?

I've unlzexe the dave.exe, but when I start a new project and tried to open a level, it says:

Image

Image

There's no help for Dangerous Dave modding. A step by step tutorial on how to be able to edit it will be greatly appreciated.! thanx
spikey
Vortininja
Posts: 86
Joined: Sun Jan 20, 2013 21:30
Location: Miragia
Contact:

Post by spikey »

Information on Camoto and if the music tools will be included would be appreciated also. :)
User avatar
Levellass
S-Triazine
Posts: 5265
Joined: Tue Sep 23, 2008 6:40

Post by Levellass »

Wait, which Dave is this for? Dave 2 can be edited in a lot of Keen Vorticons editors; Dave 3 and 4 can be fiddled with in things like TOM and Abiathar.
What you really need, not what you think you ought to want.
User avatar
Roobar
Vorticon Elite
Posts: 3263
Joined: Tue Jan 08, 2008 16:12
Contact:

Post by Roobar »

Dave 1 of course.
User avatar
Roobar
Vorticon Elite
Posts: 3263
Joined: Tue Jan 08, 2008 16:12
Contact:

Re: Camoto Windows version

Post by Roobar »

Hey there. Malveineous seems busy and he suggested asking in the forums. So I need to ask here: is anyone interested in a little Dave modding?

I've been making a few graphics for a Dangerous Dave 1 mod. Just experimenting. I've used Camoto to extract the graphics. Then I made some modifications to them and then import them back. When I import a new file that's bigger than the original, I get the "'data is too big" error. So I compress the PNG and I don't get an error, but then something weird is happening. The game is glitching. It still works, but glitches every time a player collects an item etc.. I've recorded a video showing what's happening:

https://youtu.be/swWtpKywB7s

Can you help with this? Here's the edited graphics file so far, if you would like to check:

https://i.postimg.cc/hvh0Fp5m/davevga-edited.png

According to Malveineous, he thinks that if the tile data from that PNG is too small there's a risk the decompressor will read the junk at the end of the tile data and overwrite too much memory. So perhaps someone can figure out where the game stores the size of the compressed and decompressed data?

He also suggested that I'll probably have to poke around with the pixel data until it ends up exactly the same size as the original. In order to do that, I added some more pixels until I get the 19.3 kb size (that's the size of the original extracted PNG graphics). I tried that and some variations, but I still bump into the same issue. Maybe it needs to be the same size as the last byte, but I'm not sure anymore. When I export the original PNG graphics (which is 19.3kb), make no changes to them and then import them back, Camto still says "data is too big". So now I'm not sure what is the exact size I'm supposed to compress the PNG as well. And even if I manage to compress it to the exact same size, it's still no guarantee if it will work.

Anyone can help with this? Thanks.

On another Dave related thing, about editing Dave 1 start position, he said:
I think the player start points have been reverse engineered (check the ModdingWiki) so you should be able to adjust those with a hex editor (I don't think there are any tools yet that do it) but no idea about the enemies, I suspect they are fixed in number. Again someone will have to reverse engineer it before we know whether it's possible or not.
User avatar
K1n9_Duk3
Vorticon Elite
Posts: 779
Joined: Mon Aug 25, 2008 9:30
Location: Germany
Contact:

Re: Camoto Windows version

Post by K1n9_Duk3 »

Could you explain what you mean here:
Roobar wrote: Sat Aug 15, 2020 18:23So I compress the PNG
Do you mean compressing the PNG image into another PNG or do you mean converting the PNG image into the Dave Tileset Format and then applying the RLE compression?

What I can say right now is that the RLE-compressed tileset files always store the size of the decompressed data at the beginning, as it is documented on the ModdingWiki page, and that the game does in fact use that value to decompress the data. Once the RLE algorithm has written this many bytes, the decompression stops.

What you have to keep in mind is that the VGA tileset is stored inside the main executable, so if your new RLE-compressed VGA tileset is bigger than the old one, it will cause memory corruption (the compressed VGA tiles overwrite the sound effects). But there shouldn't be any issues if the new compressed VGA tileset is smaller than the original.

For any further assistance on this, I would need to take a look at the tileset files (and/or the modified executable) that Camoto has created, not the PNG images. I really don't want to go though the trouble of setting up Camoto myself.
Hail to the K1n9, baby!
http://k1n9duk3.shikadi.net
User avatar
Roobar
Vorticon Elite
Posts: 3263
Joined: Tue Jan 08, 2008 16:12
Contact:

Re: Camoto Windows version

Post by Roobar »

I mean compression of the PNG itself. Camoto can export and import the VGA tileset in a PNG file. It doesn't matter how small in size I make the PNG and import it, it still doesn't work.

Image
Calvero
Vortininja
Posts: 98
Joined: Tue Jan 29, 2008 15:31

Re: Camoto Windows version

Post by Calvero »

The file size of the PNG is not important.
User avatar
K1n9_Duk3
Vorticon Elite
Posts: 779
Joined: Mon Aug 25, 2008 9:30
Location: Germany
Contact:

Re: Camoto Windows version

Post by K1n9_Duk3 »

Did you check if the palette of the PNG image stayed intact after compression? Some compressors may move the palette entries around to achieve better compression. The image still looks the same after the palette is applied, but the pixels may have been assigned different palette index numbers. It's possible that Camoto ignores the actual color values of the pixels and only uses the palette index of each pixel when importing the PNG image. If Camoto also expects certain color index values to represent certain things (transparency etc.) then a modfied palette will totally mess things up.
Hail to the K1n9, baby!
http://k1n9duk3.shikadi.net
User avatar
Malvineous
Shikadi Webmaster
Posts: 382
Joined: Wed Oct 31, 2007 21:48
Location: Brisbane, Australia
Contact:

Re: Camoto Windows version

Post by Malvineous »

I just looked at this again for the web-based version of Camoto I am working on, and I managed to work out what the problem was.

It wasn't actually due to the RLE decompressor after all, but rather a mistake in the reverse engineering of the file format. It was thought that the game added an extra byte by mistake every 65,536 bytes, but actually it adds it every 65,281 bytes instead. Fixing this allows the graphics to be imported again without any corruption. The game also respects the decompressed-size field, which means the size of the replacement graphics don't have to exactly match the original, they just can't be any larger.

This means it's much easier to hit an allowed file size, because you only need to get under a maximum size. This is easily done by changing some pixels in the tiles so there are longer runs of horizontal pixels the same colour, which the RLE compressor can better compress to fit in the available space.

I haven't yet got a nice way of importing and exporting the graphics but gameinfo.js can do the basic tiles (haven't added the rest yet). It's a bit involved in getting it installed if you're not a Javascript programmer so I recommend waiting until I can get it all up and running in a web browser so you don't have to install anything at all.

Here's a screenshot (link if you can't see it)
Image
Post Reply