quote:Originally posted by RiscaI've updated my too to allow selecting sub palettes. I also added a zoom slider. Code is on GitHub

It'll likely be difficult to come up with a general purpose solution without reversing the scene display code from the actual games, which I'll get around to eventually. But in the interim, every little bit you find out will help me eventually. So thanks

Wed Jun 07, 2017 3:17 am

Risca

Joined: 07 May 2012
Posts: 10

I've come back to this issue tonight to dig for some more information, but I can't wrap my head around it.
I added extra log outputs to dosbox-0.74 so that it would print out the palette when it's changed:

There is much more in the log but I thought it best to keep it short. There is also a fading effect going on after the intro. This seems to be done with palette cycling; a lot of new palettes are getting applied while after the intro is done and the first scene fades in.

I've setup dosbox to automatically run the game and I hit the ESC button to skip any intro, which takes me directly to the first interactive screen. This is how that screen looks like:

By inspecting the log, and using my tool to open the resource files, I can see that the game extracts a few different images and layer them on top of each other. For example, DGATE019.PIC contains this image at offset 0x0001EA98

Notice how the right lamp post, Xar, and the Nexus seal piece above his head are missing. These are all also located in the DGATE019.PIC resource file, at the offsets indicated by the log file. However, and this is what really bothers me, if I take the exact palette that dosbox dumped in the log for me and apply it to those overlayed images, it shows the completely wrong colors (the "big" picture is fine). For example, here's what I believe is the lamp post and the nexus seal piece:

I feel like I'm missing something crucial in understanding either how palettes work or how death gate is handling these overlayed images. Maybe there is some kind of index translation going on?
There might be some clues in the DGATE019.RGN file that is opened just before DGATE019.PIC.

EDIT:
I feel that figuring out how the scene display code works is the major blocker for allowing me (and others) to work on an actual game engine for Death Gate. I'm running out of ideas and that's when the progress slows down. If only I could figure this out, it would be so much easier to start hacking away at getting an actual game running. It would definitely feel like it's progressing faster once you can actually interact with the game.

Sun Nov 05, 2017 11:15 pm

dreammasterScummVM Developer

Joined: 04 Nov 2005
Posts: 322
Location: Boston, Massachusetts, USA

A bit of good news. Barring any other bugs turning up, I've finished development on the Starship Titanic engine, which now supports both the English and German versions. I'm now returning to work finishing up the Xeen engine, with the anticipation that I'll spend some more solid time working on the Legend games when I've done with it.

Mon Nov 06, 2017 3:43 pm

Dark-Star

Joined: 30 Oct 2005
Posts: 128
Location: Reutlingen, GERMANY

quote:Originally posted by dreammasterA bit of good news [...] I'm now returning to work finishing up the Xeen engine...

Cool! Looking forward to saving Crodo once again

Tue Nov 07, 2017 10:20 pm

Risca

Joined: 07 May 2012
Posts: 10

Okay, I updated my resource manage to visually show me the palette of the "big" images. I also fixed a bug where the transparency of overlayed images where not working properly.

From what I can see, it seems quite common for the palette at index 17-80 to be all green and not used. It's only the smaller images that references that part of the palette, and they only reference index 17 (see attached picture).

Okay, so I solved some indexing bugs in my code and I was wrong when I said that smaller images only use index 17 for green; that was a conversion error in my code because I was doing image conversions and alpha blending. I rewrote the code to do the image overlay manually and it turned out to be much simpler than converting the images to RGBA for alpha blending. Now I get correct indexes for all the green pixels. I haven't pushed it to GitHub yet, but I will do that soon.

Talking about green pixels, I figured out what that part of the palette is from: it's the menu interface! That part of the palette can be read from DGATE000.PIC. It still looks like crap (as before), but I made some progress at least.

I still haven't figured out how pixel indexes of smaller images are translated. I've made some experiments with the dosbox ability to capture video. It turns out that you can actually dump the whole screen in palette+image by activating video capture. Dosbox saves it in Zip Motion Blocks Video (ZMBV) format and it was fairly simple to extract stuff from it using dd and zlib-flate. The first frame of a video always contains the palette and an image. I'll do some more experiments and maybe write an extractor that I can put on github.

EDIT2:
By comparing a dump from dosbox with an actual image+overlay, I can conclude that the very same pixel value in a smaller image might actually be translated to different pixel values in the dosbox dump. This might indicate some kind of translation based on offset, or it might just be some kind of fading effect by the game engine.