Author Topic: SCI32 Templates  (Read 3526 times)

0 Members and 1 Guest are viewing this topic.

Offline Kawa

Re: SCI32 Templates
« Reply #15 on: January 11, 2022, 09:48:52 AM »
It seems like the reason the views tend to be garbled when edited may be related to SCICompanion not properly modifying RESOURCE.MAP.
That's interesting. The more details you can get me and/or Phil, the better.

Offline EricOakford

Re: SCI32 Templates
« Reply #16 on: January 11, 2022, 12:12:41 PM »
It seems like the reason the views tend to be garbled when edited may be related to SCICompanion not properly modifying RESOURCE.MAP.
That's interesting. The more details you can get me and/or Phil, the better.
Specifically, if the resource files are modified, SCICompanion later mistakenly detects the map format as SCI 1.0, when it should be SCI 2. The package format and actual resources are still detected correctly, however.

In SCI Viewer, the resources themselves display fine, so it appears the view editor is not causing the problem; modifying the map file is.
« Last Edit: January 11, 2022, 01:53:46 PM by EricOakford »
My SCI templates
SCI0 SCI0.1 SCI1.0 SCI1.1
SCI2.1 planned

Offline Dhel

Re: SCI32 Templates
« Reply #17 on: March 11, 2022, 04:47:36 PM »
I am in full support of getting sci32 implemented with proper view and pic editing support. I will look for ways I can contribute. What is currently in the works or in the que for working through these next steps?

Offline Kawa

Re: SCI32 Templates
« Reply #18 on: March 11, 2022, 04:54:59 PM »
* queue and uh... as far as I know, nothing is in it. I've looked into loading RESSCI volumes without having to rename them but the code scared me off. As far as picture editing goes, the main deal is that you can't change the position and priority of a given "draw image" command.

(Note that the position part of that sentence also applies to Jones in the Fast Lane because that is a strange, strange game.)

Anyway, I for one welcome any and all PRs about this.

Offline Dhel

Re: SCI32 Templates
« Reply #19 on: March 11, 2022, 10:09:06 PM »
* queue and uh... as far as I know, nothing is in it. I've looked into loading RESSCI volumes without having to rename them but the code scared me off. As far as picture editing goes, the main deal is that you can't change the position and priority of a given "draw image" command.

(Note that the position part of that sentence also applies to Jones in the Fast Lane because that is a strange, strange game.)

Anyway, I for one welcome any and all PRs about this.

Is priority mapping working in 1.0 / 1.1 scicompanion editing, or is it just the sci32 or higher resolution p56 files that are having issues? I can definitely see issues when loading a < 640x480 p56 file that the priority mapping seems off. I cant say I have tried editing any 1.x or 320x200 files.

Although this would be nice to have working, I do know how to use the OEM tools method to build p56 files with proper priority mapping already so there is at least an alternative out there. However, any thoughts on the condition of view files managing links and loops?

Offline Kawa

Re: SCI32 Templates
« Reply #20 on: March 12, 2022, 05:07:58 AM »
Far as I can tell, literally the only 16-bit game resource that uses an un-editable feature is the game board in Jones in the Fast Lane. There's nothing illegal about it, SCI Companion just assumes you have one "draw image" command, making it unclear how to add more and if you do have multiple you can't change their position like in Jones. Priorities seem to be fine, being drawn the old vector way in all 16-bit SCIs.

It's 32-bit SCI where the fun begins, since its priority screen isn't vectors at all -- you need a clear way to add multiple bitmap layers, and position and prioritize them. That this would let you reproduce the Jones game board is just a bonus. But from what I can tell, what it shows is basically correct. Not that it matters much if you can't edit it to check...

Of course, that's just pictures, and discounts any weird but obvious bugs like views coming out all black or obviously with the wrong stride.

Offline Dhel

Re: SCI32 Templates
« Reply #21 on: March 12, 2022, 10:19:43 AM »
Ok thank you for helping explain this. Trying to make sure we are on the same page with this and following you.

So sci companion has no issues rendering resource files for sci1 compatible games which use the vector based rendering and priorities. But for later sci1.1 and sci2 when sci starts using bmp style backgrounds, it has no way of saving the draw cells from the priority map? It seems that when I pull up resources from a game like QFG4 and pull up the pic file, the priority map is shown and recognized by sci companion. But when I export / save that resource as a patch file it is corrupted. My thoughts were maybe it was a conversion issue from p26 p56 but I was not sure.

View files seem to be a whole other thing I am finding in general. It seems there are many changes of how a view works between sci2 and the different variations of sci21 that I am hoping can be sorted through. A lot of these things were fixed and are now supported with the recent photoscihop update so it gives me hope. I have also had issues with the embedded palette saving v56 with sci companion, but that could also be to how I have things in sci companion palette config.



Offline Dhel

Re: SCI32 Templates
« Reply #22 on: March 12, 2022, 10:36:44 AM »
Ok I will just correct myself about saving the QFG4 p56 file. It seems to open fine in SCI Resource Viewer but not photoscihop. I have not tested it in game to see if it works in context or not yet. I am curious to see if I can open the original resource file in photoscihop and see compare the export with sci companion export.

Offline Kawa

Re: SCI32 Templates
« Reply #23 on: March 12, 2022, 11:41:01 AM »
So sci companion has no issues rendering resource files for sci1 compatible games which use the vector based rendering and priorities. But for later sci1.1 and sci2 when sci starts using bmp style backgrounds, it has no way of saving the draw cells from the priority map?
Considering how the priority and control maps work...

In the original SCI 0.0 and 0.1, you had three bitmaps (visual, priority, control), painted in by vector commands. These can be freely edited in SCI Companion.

SCI 1.0 added a "draw image" command which painted a bitmap in the same format as a single View cel to the visual bitmap, but you could still draw on the visual bitmap in the old style, just in 256 colors instead of 16, and there was no more dithering. Some SQ4 screens are entirely vector-drawn, and the Jones game board has its inside border drawn that way. All of this also goes for the 16-color SCI 1.0 games. This is why most SCI 1.0 Picture resources have one big "draw image" command and then draw the priority and control bitmaps the old way.

Around SCI 1.1, the control bitmap was deprecated -- you could still use it, but the later games used Polygon objects exclusively for both walkable areas and Feature hotspots.

In SCI 2.0, the control bitmap was removed, along with every single vector drawing command. You could no longer directly draw on the priority bitmap; instead each layer of the image would have its own "draw image" command, with a position and priority value:


So what SCI Companion needs to properly and fully support SCI 2.x Picture resources is a way to change these position and priority values.

Quote
It seems that when I pull up resources from a game like QFG4 and pull up the pic file, the priority map is shown and recognized by sci companion. But when I export / save that resource as a patch file it is corrupted. My thoughts were maybe it was a conversion issue from p26 p56 but I was not sure.
There was a bug involving exported pics that may be in play here. Past tense.

Offline Dhel

Re: SCI32 Templates
« Reply #24 on: March 12, 2022, 01:17:43 PM »
Ok I am following you and also experience it when trying to modify the priority locations. I will take a look at some of the code and see if I can think of any solutions. Although I have OEM tool to build these pic files, it would be nice to have something with a full on editor that supports modern os.

Offline Dhel

Re: SCI32 Templates
« Reply #25 on: April 07, 2022, 02:24:21 PM »
Just wanted to touch base and let you know that I have been working on a set of tools outside of sci companion to help aid in p56 and view file modifications. Some examples that are currently finished and / or in the works.

A tool that will take any image file (png, jpg, etc) and convert it into a p56 file with complete support for multi-cell and priority mapping. This tool can either map to a particular palette which is very important to matching to the sci palettes, as well as a palette quantizer which will limit the palette index for use in creating new pics with their own palettes. This is 100% sci32 compatible up until the latest sci version from what I can tell. I have been using this tool to create new rooms, as well as upscale previous p56 files to 1080p for an upscaling project I have been working on.

I have also been working a FotoScihop fork that is becoming pretty heavily modified. I have added a CLI support to allow to add support for direct modifications to view files as well as process in batches. This is useful for making changes to header files as well as positions / links in views. I have accompanied this modified fork with a set of tools that will batch upscale / swap images in views by whatever % of scale. It can process hundreds / thousands of view files in a matter of minutes. This again has 100% compatibility with the most recent versions of sci as far as I know.

I have many more ideas for tools in the works as well, but this is what I currently have working. I plan on releasing these tools to public as soon as they are a little more defined and established for casual use. I also plan on implementing the CLI modification tools to the FotoScihop GUI once they are finished as well. My forked version of Fotoscihop has a lot of the back end revamped to allow easier support for modifying things. Currently, I have added the ability to add / duplicate cells and loops to views which will also aid in creating new views for use in sci32. I have a pretty good understanding of how the view files are put together now, so I am hoping I can also start implementing support into sci companion.

I will keep everyone in touch as development continues.

Offline Collector

Re: SCI32 Templates
« Reply #26 on: April 07, 2022, 05:33:20 PM »
I would be interested your GIT repo as soon as you set it up. I would like to think that this could also be added to Companion to fully extend it to SCI32 support.
KQII Remake Pic

Offline Dhel

Re: SCI32 Templates
« Reply #27 on: April 09, 2022, 04:49:19 PM »
Sounds good I hope to have something released soon. Lots of work is going in to fotoscihop. I have been trying to organize it in a way that makes it easy as a reference to understand how a v56 file is working and is broken into parts. I think this could definitely be useful is helping implement support to sci companion, though its been while since I have looked at the sci companion code in these areas to verify how they relate. My thoughts is implementing the main parts may not be so trivial, but setting up the user interface with the editor and maintaining compatibility with earlier pic versions may take a little sorting out. But hopefully it can be done. I will try to find some time to start reading it over in sci companion to start getting some better ideas on how it might merge over.

Offline Collector

Re: SCI32 Templates
« Reply #28 on: April 09, 2022, 06:35:03 PM »
I tried going through FotoSCIhop's source, but my C++ skills are sorely lacking. I have not even recently looked to see if Enrico has a newer version of it. When I asked him about it quite a while back he seemed to be mostly done with any further development of it. Nice to see you take it up.
KQII Remake Pic

Offline Kawa

Re: SCI32 Templates
« Reply #29 on: April 09, 2022, 09:02:19 PM »
Maybe it's just me but for SCI32 Picture support, I think being able to change positions and depths from inside the Picture Editor itself would be preferable. Are we all just too intimidated by how hairy the source code is to make the point editor (fills, lines, polygons) also work on cels? Cos I know I am.


SMF 2.0.19 | SMF © 2021, Simple Machines
Simple Audio Video Embedder

Page created in 0.114 seconds with 24 queries.