RGB Classic Games Forum

I'm getting several troubles on Camoto, I collected a few errors so I could make a single thread rather than spam the whole forum with different threads with basically the same problem.

Let's start off with the first game I tried in Camoto, Dangerous Dave.
I tried 2 different installations of Dangerous Dave from 2 different directories, both gave me the same exact error when I double click any level or graphics tiles, which is this one:


When I click "Yes", I get the following error:


It happens with whatever Dangerous Dave installation I use and whatever directory I use, no levels and anything else I can get loaded into Camoto Studio, but I know for sure that D.D. is supported for 2 reasons: there's a mod in Shikadi wiki and there's a video of it on YouTube aswell.

Now for the next game I tried in Camoto Studio: the first Duke Nukem.

For Duke Nukem, I even tried to import the original game files directly from my Steam installation! (I bought the Apogee Anthology pack on Steam)
When I try to load any level, I get this error instead:


I click "Yes", another error pops up:


After a bunch of supposedly "conversions" it does, eventually the level gets loaded.... or doesn't it?



The tiles seem to look ok, but... what are all those grey rectangles ??? Are they supposed to be the sprites/actors ? How.... how do I work with this?
I don't see the sprites, all grey brick rectangles instead! And there's no info on this anywhere on Shikadi or the original thread here!!!

Well, I could go on for a while, I tested several other games, some of which kinda worked (Captain Comic, Duke Nukem 2, Monster Bash), others got similar errors as the above two (Raptor, Crystal Caves, Secret Agent).

Also, for the games I got to work, such as Captain Comic, or Duke Nukem 2, I have no idea how to get the "Tiles" window on the right to load any tile, I also have no idea how to show the sprites and actors in a window, ready to place them on the map, there's absolutely no information about this anywhere, thus I'm also taking the chance to ask "how does this program actually work at all?".

I hope we can get things sorted out, because as soon as I saw a program such as Camoto Studio, which supported all these games, but couldn't get to work properly a single one of them to comfortably edit... well, use your imagination.

What's the file size of back0.dn1?

It's 7.87 KB as "file size" and 8 KB as "size on disk"

I can't comment on your issue with Dangerous Dave, but I can try to explain your issues with Duke Nukem. I haven't tried Camoto myself, but I do know Duke's file formats inside out.

First of all, you can safely ignore the error messages for "back0.dn1" and so on. Judging by the screenshot of the level view, Camoto did read the file(s) correctly. "back0.dn1" should contain all the background graphics that are animated in the game, like the blue lights and the computer display (seen in the red square in the highlighted area).

The fact that Camoto says the file was supposed to be in Crystal Caves Tileset format probably explains why the error message pops up. The file format in Duke Nukem is very similar to the one used in Crystal Caves, but not identical. Crystal Caves stores multiple tileset blocks (each with its own 3-byte header) in one file, but Duke only has one single block in each file.

The other issue basically just shows that Camoto is incomplete. All the interactive level objects are stored as regular tiles in the level. What you see in Camoto is what the level looks like when you don't convert convert the tiles that represent the interactive objects and just treat them like regular tiles. Just have a look at the Duke 1 Level Format and you will see that the values 0x3000 to 0x3059 represent actor objects. But the range 0x3000 to 0x367F also indicate tiles from BORDER.DN? (the tiles that make up the border of the in-game screens as well as the blue and red menu windows). All those grey rectangles you see are actually tiles from the border area. The level display is obviously incomplete and shows only the level tiles, not the actual graphics for the interactive objects.

So at least as far as Duke Nukem is concerned, Camoto basically "works" correctly, it's just not finished.

I see, so should I stick with DN1EDIT 3.0 for Duke Nukem 1 modding?
Any way to import custom backgrounds and graphics yet ?

Malvineous created a command-line tool that can convert the tile graphics for Duke Nukem 1 (to .BMP format and back). That tool was released way back in 2002, probably long before he (Malvineous) started working on Camoto. You can find a download link here: http://dosclassics.com/duke/dl.php (or click here to download it directly).

Nice found!
Does it allow to convert them back into .DNx format too, to import custom graphics in the game ?
In the .txt file it says nothing about that...

This is what you see when you run DUKECONV without parameters:

Bit late to the party but would just like to confirm everthing K1n9_Duk3 has mentioned. Camoto is very much incomplete as a lot of the information just hasn't been reverse engineered yet. Much of the Duke stuff that K1n9_Duk3 figured out hasn't yet made it in just for lack of time. The rest of it was just guesses and approximations until we learned more about the file formats, which in hindsight were a mistake as many people get quite upset when it doesn't work perfectly. It would've been better to have completely disabled the functionality instead of having it work as only a level viewer.

I've pretty much given up on Camoto Studio now, in its current form. It turned out to be a huge pain and waste of time trying to get it to work under Windows because it's just so different to every other platform out there, and practically nobody runs Linux so keeping it going as a Linux-only GUI would be pointless. It's also difficult to find collaborators to help out with the code because hardly anyone knows C++, and this kind of project is really too big to do successfully on your own. Programming a decent GUI in C++ is also an exercise in frustration which is why the Camoto level editor is so awful.

So I'm thinking about shelving Camoto as it stands now and wondering whether it would be worth rewriting it in Javascript, so that it can run inside a web browser. I think this would solve so many issues: no special cases for Windows, nobody complaining that the installer was flagged as a virus by some obscure virus scanner, nobody having trouble compiling from source, nobody struggling with the command lines, nobody stuck with an old version, etc, etc. It seems to have so many upsides that I'm sure it would be a better solution than to keep going with it the way it is now!

The only thing would be whether JS would lower the barrier to entry enough that people would be willing to collaborate on the code, because that would be the biggest benefit of all.

I'm currently learning a bit of Lua, but that's certainly not a good programming language to make a whole application.

Otherwise you could release the old C++ version of Camoto as open source, so the community could try to make it better and "complete it", all while you work on a newer and better version in another (perhaps easier) programming language, such as Javascript, as you said you could implement it in the Shikadi website as an online tool, or Visual C# (which I know a bit of, using Visual Studio 2013/2017).

C# is way easier than C++ and more people will be more likely to wanna help to the project.

Camoto has been open source since the very beginning back in 2010 - all the code is up on GitHub. But only a couple of people have made small contributions in all those years.

Unfortunately C# would be even worse than C++ as it does not work very well under Linux or Mac, and every time I am forced to write code in C# it drives me crazy because it has been so poorly designed compared to C++. C# was very clearly designed by someone who didn't understand why C++ works the way it does, but thought they could do a better job anyway. Even the original creator of C# has distanced himself from it, perhaps because he has realised all the mistakes he made with it!

Although Lua, Python and Javascript are all similar scripting languages, Javascript is considerably more optimised and can achieve near-native speeds in some implementations, so it is really the only option if a program like this is to be developed in it. It's also the only language that can run in a browser on any platform so although it's far from a perfect language as well, it's really the only practical option in a situation like this.

It's also one of the most widely used languages because there are so many web developers out there, so if I go ahead with the rewrite it'll be interesting to see whether it lowers the barrier to entry and more people contribute.