im trying to understand what the graphics codes in inpaws mean

[777]

i would like to extract individual pictures from various adventures that are written in paw and paste them into my own. unfortunately i dont understand what the graphics codes in inpaws mean. i tried deleting one picture in an adventure and comparing it to one that i left alone but i couldnt see where the difference was. i have asked on various forums, etc and not had much luck really. apparently it messes with the image index if you start removing pictures in paw and thats why i cant make head nor tail of it. also apparently there is documentation on this subject but no one can seem to find it. any help would be appreciated.

[+3code]

i would like to extract individual pictures from various adventures that are written in paw and paste them into my own. unfortunately i dont understand what the graphics codes in inpaws mean. i tried deleting one picture in an adventure and comparing it to one that i left alone but i couldnt see where the difference was. i have asked on various forums, etc and not had much luck really. apparently it messes with the image index if you start removing pictures in paw and thats why i cant make head nor tail of it. also apparently there is documentation on this subject but no one can seem to find it. any help would be appreciated.

https://intfiction.org/t/extracting-ind ... paws/55360

The graphics are chains of "vectorial commands", like in the Logo's turtle.

[777]

i know but if you remove one or more picture they get corrupted

[8BitAG]

i know but if you remove one or more picture they get corrupted

Setting aside the fact that I don't think you should be using other people's work without their permission...

One thing you will need to bear in mind is that individual location graphics might be dependent on other location graphics, or rather graphics subroutines that are stored in other location slots.

Most PAWed games with decent graphics will make use of the GOSUB command in the drawstring, which allow you to reuse (and rescale) graphics subroutines. This could be used for something like a location image border, a basic shape, or a specific detailed graphical element (such as a tree). It saves you memory, if you store commonly used shapes as a subroutine. And if you start using graphics in a game, you really do need to conserve memory wherever possible!

So for example, the graphic for location 1 might well use a subroutine stored in the (unused) location graphic space for location 50. If you don't transfer both across, and adjust the GOSUB calls accordingly then you won't get the complete picture... you will just get a garbled mess.

If you really want to decode how inPAWs converts the drawstring commands into the .paw source, then I would suggest starting from a blank database. Adding a simple picture in location 1. Looking at the code. Then add a picture in location 2, and compare the new .paw source. etc.

However, like I've indicated above, all the decent graphics will be created from some quite complicated, interdependent building blocks. There's also the added wrinkle that quite a few games used custom UDGs or additional character sets as part of the graphics. So those need to be looked at too.

To be honest it would be much easier to grab graphics in raster form and load them off disk instead. Or, to be perfectly blunt, much easier to just draw your own!

[8BitAG]

Compare, for example, the standard UDGs and Shades for PAWs...


...with the way they've been redefined for Jekyll and Hyde...


Using the default shades would make this J&H screen...


...turn out like this!


Quite a different result!



So you'd potentially encounter all sorts of issues if you were pulling graphics from different games where the UDGs and shaders were defined differently.

[8BitAG]

Another quick example, again from Jekyll and Hyde, to show that shades/UDG are important...

[bass-on]

It's been a while since I looked at this, but the graphics section in InPaws is made up of 4 separate elements, all concatenated together and comma-delimited:

1. The number of images in the game.
2. The size of each image in bytes.
3. The attributes of each image (so a single number for each image based on various bits set or unset representing the ink, paper, border and whether the image is a location or a subroutine. As a guide, empty, unused images all have the value of 7.)
4. Byte representation of the drawstring commands for each individual image. I vaguely recall that each image ends with a marker of 7.

For example, for Mirror Mirror, which has 4 locations and no graphics, it's:

Code: Select all

GRAPHICS
{
	4,		<number of images
	1,1,1,1,	<size of each of the four images
	7,7,7,7,	<attributes of each of the four images
	7,7,7,7		<7 denoting the end of each of the four images' drawstrings
}

So the problem will be that if you manually try and mess with the drawstring data in 4, as well as the obvious one of not knowing what you're deleting or changing, the drawstring length for that image will become out of sync with the image size for it at 2, and you'll corrupt all of the data, not just the image you changed. 8BitAG is also correct that you'll ideally need to bring in the UDG and shade data too. This is in the first 35 rows in the characters output of InPaws. Finally, in PAW, the number of actual locations needs to match the number of graphics locations. You can have more graphics than locations in The Quill, but not in PAW.

It should be possible, but a slight ball-ache to construct an InPaws file with the graphics and characters from another adventure blended with your own data.

• Add dummy locations to your own actual adventure so that the number of actual locations matches the number of image locations in your "donor" game,
• extract your original actual game using InPaws and then
• overwrite the graphics and character blocks from your game using the graphics and character blocks output from the "donor" game.