KeenGraph 2.2

KeenGraph is a ModKeen alternative with extra features for Keen:Vorticons.
User avatar
CommanderSpleen
Posts: 1017
Joined: Sun Aug 31, 2003 12:11 pm
Location: The Land of Sparkly Things
Contact:

Post by CommanderSpleen »

The problem with programs that save 256-colour bitmaps is that some of them make up their own minds about how the palette should be arranged, instead of preserving the one they were given to begin with.

++24-bit support
Draik
Posts: 117
Joined: Sat Jul 26, 2008 8:52 am
Contact:

Post by Draik »

heh, I remember trying to mod with Photoshop. It kept mangling the palette, I had to open them in Paint and save them differently. :P
levellass
Posts: 3001
Joined: Wed Oct 11, 2006 12:03 pm
Location: Ngaruawahia New Zealand

Post by levellass »

Added multi-tileset export, it even extracts the tileinfo files!

So, does anyone have any examples of mangled palettes? The big problem would be if it rearranged the palette not by a simple fixed rule, but rather by say, which color had the most blue in it.
However, I think it would be handy to have a text file where you can specify colour x in your 256 colour bitmap maps to the 4 bit RGBL in the egalatch file. So I would say yes to #2.
I'm sorry? I don't understand what you mean. It should be easy enough to add an option say -palette to KG to get it to pick out what colors in a 256 color bitmap are to be used, is that what you mean?

Other options are:

* Automatically read a bitmap's palette and look for entries that match the 16 color EGA palette
* Checking a bitmap to see what program (ma have) produced it and automatically using the colors that work.

For 24 bit bitmap support KG will probably build a palette from the first 24 bit bitmap it encounters then use that to guess the colors of any others it finds. (Hopefully they'd all be the same colors, but if not I can have it 'round' to the nearest color match.)
User avatar
CommanderSpleen
Posts: 1017
Joined: Sun Aug 31, 2003 12:11 pm
Location: The Land of Sparkly Things
Contact:

Post by CommanderSpleen »

Here are some examples of the graphics after KolourPaint has mangled them, from both ModKeen and KeenGgraph.

KeenGraph
http://www.planetkeen.com/projects/keen ... nt-256.bmp
http://www.planetkeen.com/projects/keen ... nt-256.bmp

ModKeen
http://www.planetkeen.com/projects/keen ... nt-256.bmp
http://www.planetkeen.com/projects/keen ... nt-256.bmp
levellass wrote:Automatically read a bitmap's palette and look for entries that match the 16 color EGA palette
I think this is the best plan. Assuming by "a bitmap's palette" you mean a copy of one of the original extracted bitmaps from which to retrieve the 16 relevant colours. Or you could perhaps have it generate a 24-bit bitmap containing 16 pixels that will be read again upon import.

You just need to figure out how to handle the possibility of a 24-bit bitmap containing colours that do not adhere to the 16-colour palette; whether you'll make it guess based on the nearest colour or just skip over it and leave a black pixel or something.

Maybe you could even try your hand at supporting PNG or GIF? I'm not sure if we might encounter similar trouble with programs shuffling the palette around though.

This is really a complicated situation. Stupid palettes.
levellass
Posts: 3001
Joined: Wed Oct 11, 2006 12:03 pm
Location: Ngaruawahia New Zealand

Post by levellass »

I'd first need to know the formats of PNG and GIF in simple language that I can understand. My biggest problem with PNG et al is the compression they use, so far I haven't been able to find something that explains it nice and neat so I can get to grips with it. (Heck, some PNGs can't even be opened by paint!)

I have a good 'approximation' subroutine for analyzing 24-bit bitmaps, but the biggest problem will simply be converting from one form to another.


As for what kolorpaint does, it's worse than I feared. It creates a palette by 'converting' the image into 24 bit, then scanning it to see what colors it comes across first, then building the palette in that order. 'spare' color entries are given values inbetween 'filled' ones. The only way to get the 16 colors in (scrambled) form is to have an image such as the tileset that has all 16 colors in it. WHO WROTE THIS PROGRAM?! Heck, it even changes the palette type (16, 256, 24-bit) depending on how many unique colors appear in the image.

I suppose I could include a conversion subroutine that would scan each bitmap separately and build a lookup table. Of course the problem would arise with modified palette patches; the patch file would need to be specified for KeenGraph to accurately identify 'valid' palette values. I shall spend time thinking about the best strategy for this.
lemm
Posts: 554
Joined: Sun Jul 05, 2009 12:32 pm

Post by lemm »

Of course the problem would arise with modified palette patches; the patch file would need to be specified for KeenGraph to accurately identify 'valid' palette values. I shall spend time thinking about the best strategy for this.
This is what I meant earlier. Every colour in EGALATCH is represented by RGBI = xxxx. So if the user was able to supply a text file where each line is 24 bit bitmap RGB --> keen RGBI, then they could just pick the 16 24-bit colours in their image editing program and use that to create the text file.

Originally I thought you could do the same for 256 colour palettes as well, but if the palette is swapped around every time you save with a different program, I guess this wouldn't be very convenient.
levellass
Posts: 3001
Joined: Wed Oct 11, 2006 12:03 pm
Location: Ngaruawahia New Zealand

Post by levellass »

Whelp as I do it currently the default Keen palette is loading on import and export unless the patchfile has a palette patch, which then loads the modified palette.

So as it is currently I should be able to scan and convert 24-bit bitmaps as long as the colors aren't too similar.

The big problem will be the sheer amount of time it will take to convert rearranged palette bitmaps, since Modkeen and KeenGraph use a logical manner to set out their palettes (Given the value of a pixel yo can tell what EGA planes are occupied.) This could double the import time.
User avatar
CommanderSpleen
Posts: 1017
Joined: Sun Aug 31, 2003 12:11 pm
Location: The Land of Sparkly Things
Contact:

Post by CommanderSpleen »

As long as it skips the conversion process for already-compliant bitmaps, extra import time is preferable to the hassle of manual one-by-one conversion.

Though maybe you could save some time by keeping the indexed and RGB graphics side-by-side and only converting the RGB if its timestamp indicates it is newer than the indexed. That way you don't have to re-convert every single image if only one or two have been edited.
lemm
Posts: 554
Joined: Sun Jul 05, 2009 12:32 pm

Post by lemm »

Levellass, is it possible to make this program create EGALATCH and EGAHEAD for any size tile bitmap, even over 689 entries? Could it just emit a warning instead of halting?
levellass
Posts: 3001
Joined: Wed Oct 11, 2006 12:03 pm
Location: Ngaruawahia New Zealand

Post by levellass »

As it is, Keengraph should do that for any number of tiles LESS than 689 if you resize the tile bitmap. (It should also in theory work with any bitmap with a width divisible by 16 (1 tile) I am not sure if I added safety warnings later on, but I shouldn't have.

I'd allow 689+, but the problem there is that the game doesn't like to load that many tiles, so I thought it best to not let people do that. (You'd be amazed at what people will do in ignorance.) If there was a patch I could use to safely load that many tiles I'd have it automatically output that and import the tiles.

Why? What are you wanting to do?
lemm
Posts: 554
Joined: Sun Jul 05, 2009 12:32 pm

Post by lemm »

You're back!!

It's a monster patch that will allow slopes, as many tile graphics as you want, 8 animation frames, slopes etc etc, it's all in that thread in the CKCM forum... basically all the big patches I did over the last few months. I was going to attempt making a graphical tileinfo like program to actually make the .tls files, however, Dr Kylstein suddenly released the Tileset Tool, and he said he would support constructing it.

Anyways, for the patch to allow indefinitely large tile bitmaps, EGALATCH needs to be big enough as the biggest 1TIL00xx.bmp used in the particular mod, because video memory space is reserved depending on how big EGALATCH/EGAHEAD is. So there needs to be a way to make egalatch large, and I think the best way to do it is during loading, because it means less patching, and you have that nifty graphics space calculator.



PS: THANK YOU for making keengraph put stuff in the correct order; it really irritated me the way modkeen did it :p
levellass
Posts: 3001
Joined: Wed Oct 11, 2006 12:03 pm
Location: Ngaruawahia New Zealand

Post by levellass »

No problem!

I can make Keengraph set the EGALATCH size from the largest tile bitmap, though it would be easier just to have a set (Large) tileset size. I do have a few questions:

* Will the tileinfo be a variable size, depending on how many tiles are in the bitmap, or will it have a set plane size?
* If Dr Kylstein's utility is made, should I bother with TLS stuff with Keengraph or would people prefer to use his utility?


I can work on Keengraph this week, I've been trying to speed up its import/export speed, (24 bit support is annoyingly slow otherwise.) but my laptop's battery is not charging, which has caused my reccent blackouts.
lemm
Posts: 554
Joined: Sun Jul 05, 2009 12:32 pm

Post by lemm »

Thanks levellass.

It would be better if KeenGraph could fit the tile portion of EGALATCH exactly to 1TIL0000.bmp, otherwise it will waste video memory.

You don't have to bother with TLS creation; Dr. Kylstein's utility will cover it all.

The tileinfo plane size will always be 910.
levellass
Posts: 3001
Joined: Wed Oct 11, 2006 12:03 pm
Location: Ngaruawahia New Zealand

Post by levellass »

Then the largest tileset will be 910 tiles. I could just set the EGALATCH to that, but I'm trying for setting it exactly to the largest tileset encountered. (This will mean extra tilesets are imported before unmasked bitmaps.)

I'm also going to keep TLS creation, just to have everything in one neat package. Will the good doctor's utility use bitmaps, or raw EGA data like we did in the early days?
lemm
Posts: 554
Joined: Sun Jul 05, 2009 12:32 pm

Post by lemm »

The number of tile graphics COULD be larger than 910 as well, not just smaller. In theory, you could have the frames of a tile point to 566, 911, 912, 913 and so forth. Therefore, the number of tile graphics could be TileCount*AnimationFrameCount = 910*8 = whatever. Unlikely, but someone COULD have a monster tileset with lots of animation that won't fit into 910 16x16 graphics
but I'm trying for setting it exactly to the largest tileset encountered.
Yep, I agree, that's what I meant. My (admittedly less elegant) solution was to make the user pick the largest 1TIL0000.bmp he/she would use in the entire mod, and then use KeenGraph to build EGALATCH, using that .bmp. So in that scheme, keengraph would not even need to know that this whole multiple tilesheet business is going on; it would purely be used to make space for tiles.

Also, to accommodate slopes, the TLS format has been expanded a bit.

Here:

Code: Select all

This is (incomplete) readme for the patch portion of the tiletool.  We'll make a nicer html version later ;-)


The header file contains a list of filenames of the individual tilesheets used by a mod.  Thus, 
a mod will have one tilehead, and up to one tilesheet per level, all contained within the same folder
as the executible.


TILEHEAD:
0    16*91    TS_File      Contains an ASCII zero terminated filename of a tilesheet.
                           The patch looks at byte 16*current_level for a filename.
                           Therefore, all levels (including levels 80, 81 and 90) must
                           reference a tilesheet file.  Currently we can do up to 32 levels,
                           but one day a patch may be made to allow more.

                           
                           
                           
The tilesheet file is loaded at the start of each level (during the fade in and fade out).
It contains information for tile info, animation, and graphics in that order.                          
                           
                           
TILESHEET:

0        2    TileCount    Number of tiles in tilesheet (keen1: TC = 910; keen2,3 = ?)
2        2    FrameCount   Number of frames in tilesheet.  (keen1: FC = 8, keen2,3 = ?)
4        2    GfxLength    Length of one plane of tile graphics.  (keen1,2,3: GL = as much as desired/will fit)
6        4    InfoLoc      Offset from beginning of file of tileinfo
10       4    AnimLoc      Offset from beginning of file of animinfo
14       4    GfxLoc       Offset from beginning of file of graphics
18      46    buffer       left empty

64    TC*6    TileInfo     TileInfo*
?   TC*8*2    AnimInfo     AnimInfo**
?     GL*4    GfxLoc	   Tile Graphics***


*TileInfo

Similar to the unmodded tileinfo.  Contains 5 planes.  The first plane (plane 0) is 910 words for the behaviour of the tiles.
The values are unchanged from keen 1-3.  Planes 1 thru 4 are blocking top, right, bottom, and left edges, respectively,
and are only one byte per tile.  In addition, the byte can signify axis-normal blocking, or sloped blocking.  Slope values
are negative and defined in the PDF file.  There is no animation plane, as this has been replaced by animation data.


TILEINFO:
0     TC*2    Behaviour    Unchanged from Keen1-3
TC*2    TC    Top Blocking Values 0 thru 3 unchaged from Keen1-3.  Negative values indicate various slopes.
TC*3    TC    Right         ""
TC*4    TC    Bottom        ""
TC*5    TC    Left          ""



**AnimInfo

In the unmodded keen1-3.exe, the game goes through the animation plane and processes each tile.  The data in the
animation plane is converted into offsets in video memory, which are stored in four arrays of words in main memory (one
per animation frame).  The AnimInfo is in the format of these arrays.  Because offsets can be arbitrary, one tile
can have ANY four GRAPHICS for a given frame.  For "non-animating" tiles, this graphic is the same for each
frame.  By using empty space in the executable, the patch stores animation information for 4 extra arrays,
for a total of 8 frames!  


ANIMINFO:
0     TC*2    Frame 0      Offset data for frame 0
TC*2  TC*2    Frame 1      Offset data for frame 1 
TC*4  TC*2    Frame 2      Offset data for frame 2
...
TC*14 TC*2    Frame 7      Offset data for frame 7 



***Graphics info is simply tile EGALATCH data.  It is loaded into video memory.  The patch makes use of a pointer
to the start of tile graphics that is defined during game loading.

GFXINFO:
0       GL    Blue         Data for the BLUE  plane (8 pixels per byte)
GL      GL    Green        Data for the GREEN plane (8 pixels per byte)
GL*2    GL    Red          Data for the RED   plane (8 pixels per byte)
GL*3    GL    Light        Data for the LIGHT plane (8 pixels per byte)

Not quite sure exactly what Dr. Kylstein is up to... I still haven't seen the new program, but it sounds like it will be done shortly. It will use a bitmap (I don't know what colour depth is required) and spit out the TileSet file, (but not the tileheader, he said that was "best left for a level editor").
Post Reply