Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[Hungry Horace]

Hi again guys,

A new one for you if i may - hopefully some of you guys will have more experience in dealing with Atari ST data formats than i do (i have none!)

I have used some of my re-sourcing of the code to work out where some of the game's graphics are stored. I've identified a number of references and used their offsets to calculate block sizes and then extracted them into individual files.

i've attached one of the items that was extracted, which should be the small champion avatars, which i found when making modifications to the champion selection screen.

What i'd like to understand is how to translate (or 'draw') this data back into a graphic, which i will code another program for. I was once informed the data was in an Atari ST format (even on the amiga version!), and of course i know some basic info about the data block - it comprises of 16 repeated items (all 16 champions) which are $100 each. The champions graphics are 30x16 (although i am expecting them to be 32x16 with 1 blank pixel each side) and 16 colours.

Any help in working out how to convert this data into X,Y and Colour values would be gratefully received, as i confess this is a bit out of my field.

[Bit]

It is indeed Atari-format.
So, in Atari 320x200, 16 color, you always have one quadword for one pixelblock of 16 pixels. Each word describes one plane and got 16 bits for the 16 pixels. The lowest significant colorplane comes first, and the very first bit (so, the MSB of the first byte) stands for the lowest significant colorplane of the first pixel.
This piece of code looks confusing, but should give you the color of the selected pixel (0...15) pretty fast.
You always have to place the pointer at such a quadword margin.

Code: [Select]

// p = pointer to a quadword (one pixelblock of 16 pixels)
// n = selected pixelnumber
int get_atari_pixelcolor(char* p, int n)
{
  switch (n)
  {
    case  0: return ((p[6] & 0x80) >> 4) | ((p[4] & 0x80) >> 5) | ((p[2] & 0x80) >> 6) | ((p[0] & 0x80) >> 7);
    case  1: return ((p[6] & 0x40) >> 3) | ((p[4] & 0x40) >> 4) | ((p[2] & 0x40) >> 5) | ((p[0] & 0x40) >> 6);
    case  2: return ((p[6] & 0x20) >> 2) | ((p[4] & 0x20) >> 3) | ((p[2] & 0x20) >> 4) | ((p[0] & 0x20) >> 5);
    case  3: return ((p[6] & 0x10) >> 1) | ((p[4] & 0x10) >> 2) | ((p[2] & 0x10) >> 3) | ((p[0] & 0x10) >> 4);
    case  4: return ((p[6] &  0x8)     ) | ((p[4] &  0x8) >> 1) | ((p[2] &  0x8) >> 2) | ((p[0] &  0x8) >> 3);
    case  5: return ((p[6] &  0x4) << 1) | ((p[4] &  0x4)     ) | ((p[2] &  0x4) >> 1) | ((p[0] &  0x4) >> 2);
    case  6: return ((p[6] &  0x2) << 2) | ((p[4] &  0x2) << 1) | ((p[2] &  0x2)     ) | ((p[0] &  0x2) >> 1);
    case  7: return ((p[6] &  0x1) << 3) | ((p[4] &  0x1) << 2) | ((p[2] &  0x1) << 1) | ((p[0] &  0x1)     );
    case  8: return ((p[7] & 0x80) >> 4) | ((p[5] & 0x80) >> 5) | ((p[3] & 0x80) >> 6) | ((p[1] & 0x80) >> 7);
    case  9: return ((p[7] & 0x40) >> 3) | ((p[5] & 0x40) >> 4) | ((p[3] & 0x40) >> 5) | ((p[1] & 0x40) >> 6);
    case 10: return ((p[7] & 0x20) >> 2) | ((p[5] & 0x20) >> 3) | ((p[3] & 0x20) >> 4) | ((p[1] & 0x20) >> 5);
    case 11: return ((p[7] & 0x10) >> 1) | ((p[5] & 0x10) >> 2) | ((p[3] & 0x10) >> 3) | ((p[1] & 0x10) >> 4);
    case 12: return ((p[7] &  0x8)     ) | ((p[5] &  0x8) >> 1) | ((p[3] &  0x8) >> 2) | ((p[1] &  0x8) >> 3);
    case 13: return ((p[7] &  0x4) << 1) | ((p[5] &  0x4)     ) | ((p[3] &  0x4) >> 1) | ((p[1] &  0x4) >> 2);
    case 14: return ((p[7] &  0x2) << 2) | ((p[5] &  0x2) << 1) | ((p[3] &  0x2)     ) | ((p[1] &  0x2) >> 1);
    case 15: return ((p[7] &  0x1) << 3) | ((p[5] &  0x1) << 2) | ((p[3] &  0x1) << 1) | ((p[1] &  0x1)     );
  }
  return 0;
}

To read the Avatar's picture, load to char avatar[4096];
Then plot like that:

Code: [Select]

for (int c=0; c<16; c++)
  for (int y=0; y<16; y++)
    for (int x=0; x<32; x++)
    {
      int pixblock = x / 8; // 8 bytes per pixelblock
      if (x<16)
        putpixel_somewhere(c, x, y, get_ataripixelcolor(&avatar[256*c + 16*y + 8*pixblock], x));
      else
        putpixel_somewhere(c, x, y, get_ataripixelcolor(&avatar[256*c + 16*y + 8*pixblock], x-16));
    }

Hope you get the idea.
How does the Amiga organizes the 320x200x4 ?

btw: those graphics are the avatar graphics for the shield, see attachment. That one is the easiest bitmap-mode that is used, there are a lot more, and some pretty confusing, I'm at it to sort this out and have it easier. From a certain level on, Amiga-code is *absolutely* identical to Atari-code - can't say yet if this includes higher level bitmap-operations.

[Hungry Horace]

i knew you'd have the solution bit

however, i'm still confused, but i am re-reading your post a lot!  So.... this would explain why all the graphics are stored in multiples of 16 pixels wide! (i am sure some big monsters use 48px etc)

I dont really understand the C++ code you've posted, but i'm trying to work it all out from your description!

The first twp quadwords of the file i posted is this:

Code: [Select]

B0 00 7F F8 - 10 00 10 00 - 00 34 1F F8 - 00 20 00 20

you always have one quadword for one pixelblock of 16 pixels.

so what you are saying is this data is enough to generate the first 16 pixels of Blodwyn's Avatar.

Each word describes one plane and got 16 bits for the 16 pixels.

I assume therefore, that the planes would be broken up as follows: (hex and binary)

... edit...  removed for correction after realising my own mistake!

Code: [Select]

How does the Amiga organizes the 320x200x4?
how do you mean? in general? I am not sure, but ther is info. on amiga  RAW Interlaced formats here, from when i was doing something similar for Sensible Soccer.

http://eab.abime.net/showpost.php?p=391585&postcount=2

looking at this, the main difference is not worrying about 16 pixel wide sizes?

[Hungry Horace]

OK, after a brief moment of madness (see my edit above!) i think i have this.... (although I know my code wont perform as well as yours bit, you seem to understand 'efficient' logic very well!!)

Using the above mentioned data...

BPL0: B0 00   |  1011 0000 0000 0000
BPL1: 7F F8  |   0111 1111 1111 1000
BPL2: 10 00   |  0001 0000 0000 0000
BPL3: 10 00  |   0001 0000 0000 0000

second block...

BPL0: 00 34  | 0000 0000 0011 0100
BPL1: 1F F8  | 0001 1111 1111 1000
BPL2: 00 20  | 0000 0000 0010 0000
BPL3: 00 20  | 0000 0000 0010 0000

The lowest significant colorplane comes first, and the very first bit (so, the MSB of the first byte) stands for the lowest significant colorplane of the first pixel.

I admit, this is where you lose me, but assuming i've got the above correct, i'd be looking at pixels like this:

Px0: 0001   Px4: 0010  Px8: 0010   PxC: 0110
Px1: 0010   Px5: 0010  Px9: 0010   PxD: 0000
Px2: 0011   Px6: 0010   PxA: 0010   PxE: 0000
Px3: 1111   Px7: 0010   PxB: 0010   PxF: 0000

Colours Block 1: 1,2,3,F,2,2,2,2,2,2,2,2,2,0,0,0


Px0: 0000   Px4: 0010  Px8: 0010   PxC: 0010
Px1: 0000   Px5: 0010  Px9: 0010   PxD: 0001
Px2: 0000   Px6: 0010   PxA: 1111   PxE: 0000
Px3: 0010   Px7: 0010   PxB: 0011   PxF: 0000


Colours Block 2: 0,0,0,2,2,2,2,2,2,2,F,3,2,1,0,0

(now i am thinking i get some of what you meant, and that the bits should be in the reverse order)  ...  i am pretty sure this matches up with the blodwyn graphic!

[Bit]

Note: just finished this writing when you posted fresh. Didn't read the new one yet - we're out of sync

so what you are saying is this data is enough to generate the first 16 pixels of Blodwyn's Avatar.
 

Yes, that's it.
Let me explain it in a sample, reading the color of the first pixel.
You need four bits for the color, and speaking about the quadword and planes, it would be the leftmost bit of word 0, 1, 2 and 3 - or (in bytes) Byte 0, 2, 4 and 6.
The bytemask to get the leftmost (MSB) bit would be 0x80.

Of course you would then have to shift each one 7 to the right to get it as a bit. (or shift first and then mask it by AND 1 to kill the non-interesting bits).
 Now you got the four colorbits, and to get the total color index, you have to assemble those again:
 The most significant planebit has to be shifted 3 to the left, the next 2, the third 3 and the fourth stays.

When the most significant plane is the last, the least significant one is the first, so you have to shift
- byte 0 seven to the right and not to the left, (so - 7 to the right)
- byte 2 seven to the right and one to the left (so - 6 to the right)
- byte 4 seven to the right and two to the left (so - 5 to the right)
- byte 6 seven to the right and three to the left (so - 4 to the right)
Now the bits are in correct position.

now see my codeline for case n=0:

Code: [Select]

case  0: return ((p[6] & 0x80) >> 4) | ((p[4] & 0x80) >> 5) | ((p[2] & 0x80) >> 6) | ((p[0] & 0x80) >> 7);

Each component gets masked, then shifted into the right position and finally ORized (|). That gives the complete colorindex.
You could do it also with a mask-table-lookup, I quickly made this code from my fast atari-screen-to-pc-truecolor-screen translator.
Shouldn't be the worst one. After all, it is - and stays - confusing...

Will check the Amiga-infos later.

I made a side-by-side view from bruceeuncles Amiga-disassembly and my Atari-disassembly. Both files can be loaded into notepad++, then one gets placed in the second view and if you then lock vertical scrolling, you can scroll by simultaneously and get the impression. The code isn't original 68k-assembler anymore, but emulation code (calling C-emu-functions), but with a little bit of intuition, you can understand it.
What I have done with the Atari-code is close to happen with the Amiga-code too now. Still, I do need a memory image and the disassembly of the same one - and there I have problems with bruceuncles version. I can load other existing versions (into UAE), but they don't match bruceuncles disassembly then. Then again, bruceuncles code is no adf-file and will not load as I need it. Somehow the offsets don't really match. If I can make it that the lbl-Labels match the memory image, the $-adresses won't etc.
Hope I can solve this later, or would need that 439-version as adf.

[Bit]

I got this:

b0: b0 b1:  0 b2: 7f b3: f8 b4: 10 b5:  0 b6: 10 b7:  0
01 02 03 0f 02 02 02 02 02 02 02 02 02 00 00 00

b8:  0 b9: 34 b10: 1f b11: f8 b12:  0 b13: 20 b14:  0 b15: 20
00 00 00 02 02 02 02 02 02 02 0f 03 02 01 00 00

yup, fits with your last result

attached those atari/amiga-sync-view files,
you cannot run them, just have some ideas while watching them.

[Hungry Horace]

will have to comment more on this tomorrow, but the good news is i've got something working

watch this space!

[Bit]

I still can't say, but be prepared that the ATARI-format is kept in higher routines. If you take a look at Label 0A9C8 (in bruceuncles disassembly), then this routine is absolutely the same as in the Atari-code - and that one does some mirroroperation on a bitmap.

We can expect the routines that direct access the screen (and the framebuffer) to be different. Those are at least: draw horizontal line (what a mess in atari-code, you won't believe it!), draw vertical line, blit letter for text and some bitmap-things that I'm figuring out atm.

Sample for that: AC98 is the label for the subroutine to plot a character's class (card) symbol. Called only by AC2C. In fact both routines are identical to Atari-code. In that case, differences can be found on higher level. Haven't checked this deeper, but AC2C gets called from three different locations. At least it seems as if we also have some unified graphics formats that are treated same on low level.

[Hungry Horace]

cool - good to hear how it's being used!!

I confess, i'm not ikely to look into changing the calling routine so much, although it would be neat to know how to use them (the final entropy for the game completion still confuses me) ...  but i have managed to now create a small programme that can load my ripped files, and allow you to "switch" the width it draws at, so that you can see the graphics even if at first they dont appear right.

I dont sem to have an offset value from the resource to point to the Entropy graphic, so i wonder if it has accidently assumed a fixed long-word for the address elsewhere in the code.

I have used my viewer to 'clean up' my file rips, so i'm hopeful i should have some more to upload soon. (I have a few including some monsters, champion stuff and pockets at the momen)

[Bit]

As long it are the simple icons it's pretty  easy.
But I can assure you that it will drive you nuts if it comes to the party/class-dependend color-masking - combined with horizontal and vertical-mirroring including an alpha-channel for transparency.
Sometimes masking happens in combinations from mask/bitmap/screen to mask/bitmap/screen.
 You know I got one far developed branch - which - instead of making things more understable - even enhances the chaos.
Did I say that humanoids are treated a completely other way than i.e. spiders... 

[Bit]

One thing could be helpful when haven't done much with the graphics:

I'm sure you know the purpose of the adressregisters:
A6 - pointer for strings/stringtables/bitmaps/colorinfos, so basically datastructures at all
A5 - mainly points to the current player's datastructure
A4 - points to a champion or npc
A3 - used by link/unlk on this 32-byte-structure which has something to do with the viewport
A0 - goes usually to the current screenposition
A1/A2 - different temporary purposes, even sometimes used as backup for D-registers, or used as 2nd A4/A5.

Dataregisters have also their place when handling graphics.
D4, D5 - low words used for x/y - high words for widths/heights
D3 - low words mostly used for a colorinformation
D6 - keeps i.e. remaining stringlengths (in messageline etc.)

when used with pixelblocks, you often need a couple of masks, (quadwords need two longs, so two registers). Here D0,D1,D2 are heavily used as longs - often need the others too.
Of course D0 is the main register to transfer datas to and from a procedure, but also D7 is often used for this, loves to handle multibytes.

[Hungry Horace]

i'm working backwards from the ones we know late in the file, and trying to find all the appropriate references /addresses for ripping "pure" graphics data

I've attached where i am so far (the early ones, unlabelled are WIP), but there is a lot in there to be used / abused ,  and i'm currently at the main wall graphics.

There's some labels in the middle of graphics data that dont make sense, so that's either a decompile/resource error, or some special marker for the code. (hopefully not)

ignore the ones that say "exclude" , they are just data blocks for colour info.

[Hungry Horace]

Oh and regarding registers that's really interesting! I have used a few (addresses for data blocks , player info) but this is much more detailed than I've ever worked out! 

I tend to edit static data rather than the "live" stuff, other than my few extra code patches

[Bit]

That's pretty okay to do so. I didn't really care for the datas so far, I tend more to understand how to handle them. But in fact it's much better if you know what you got there. (I had no idea about button-stuff until I saw bruceuncles labelnames...)
Means, together we are much more complete.

My strategy is now:
You now, I got the Atari-sources (for both, normal and extended version) in some special way - which is executable pretty fine.
I also made this side-by-side view to the Amiga-code (which still lacks replacement of the OS-stuff, so, not executable, but with some worthful informations).
And now I go down to the end of the file (graphics etc. there), pick a routine, check which other routine it calls, go deeper until I get one which is a basic routine calling nothing anymore, translate it so that is much better readable, bring in posteffects everywhere it gets called - and continue this way again.
Here's a quick list what you get then:

  void BW_cursor_advance(IO areg& AREG0);
  void BW_cursor_backstep(IO areg& AREG0);
  void atari_putpixel(i16 x, i16 y, i8 color);
  bool BW_xy_to_offset(OO i16& offset, i16 x, i16 y, OO i16& helper);
  void BW_blit_vertical_line(i16 x, i16 y, i16 height, i8 color, OO areg& AREG0, OO dreg& DREG7, OO dreg& DREG6, OO dreg& DREG1, OO dreg& DREG0);
  void BW_blit_horizontal_line(i16 x, i16 y, i16 width, i16 color, OO areg& AREG1, OO areg& AREG0, ippO dreg& DREG6, OO dreg& DREG2, OO dreg& DREG1, OO dreg& DREG0);
  void BW_draw_frame(i16 x, i16 y, i16 width, i16 height, i16 color, OO areg& AREG1, OO areg& AREG0, OO dreg& DREG7, OO dreg& DREG6, OO dreg& DREG1, OO dreg& DREG0);
  void BW_cs_draw_frame(i16 x, i16 y, i16 width, i16 height, i16 color, i16 length2, OO dreg& DREG6, OO dreg& DREG1, OO dreg& DREG0);
  void BW_draw_bar(i16 x, i16 y, i16 width, i16 height, i16 color, OO areg& AREG1, OO areg& AREG0, ippO dreg& DREG6, OO dreg& DREG2, OO dreg& DREG1, OO dreg& DREG0);
  void BW_blitchar(i16 step, i8 character, IO areg& destadr, OO areg& AREG2, OO areg& AREG1, OO dreg& DREG4, OO dreg& DREG3, OO dreg& DREG2, OO dreg& DREG1, OO dreg& DREG0);
  void BW_print_nchars(i16 n, IO i16& length, IN areg textadr, IO areg& screenadr, OO areg& AREG2, OO areg& AREG1, OO dreg& DREG4, OO dreg& DREG3, OO dreg& DREG2, OO dreg& DREG1, iO dreg& DREG0);
  void BW_proceed_in_stringtable(i16 n, IO areg& table, OO i8& len);
  void BW_copy_from_stringtable(i16 n, IN areg table, IO areg& dest);
  void BW_mirror_pixelblock(IO dreg& DREG0, const areg AREG6, OO dreg& DREG2);
  void BW_mirror_009(IO dreg& DREG0, OO areg& AREG6, OO dreg& DREG2);
  void BW_table_coloring_sub(const areg AREG6, i16 idx, i16 mask_lo, i16 mask_hi, IO c_pixelblock& pixelblock);
  void BW_table_coloring(const areg AREG6, IO c_pixelblock& block1);
  void BW_gfx_01(i16 par, const areg AREG6, IO areg& AREG0, ui16 dctrl, IO dreg& DREG0, IO dreg& DREG1, OO dreg& DREG2, OO dreg& DREG3);
  void BW_gfx_02(const areg AREG6, OO areg& AREG2, IO areg& AREG1, IO areg& AREG0, iO dreg& DREG7, iO dreg& DREG6, OO dreg& DREG5, i8 shift, OO dreg& DREG3, iO dreg& DREG2, OO dreg& DREG1, OO dreg& DREG0);
  void BW_draw_woundflash(OO areg& AREG2, OO areg& AREG1, OO areg& AREG0, OO dreg& DREG7, OO dreg& DREG6, IN dreg DREG5, IN dreg DREG4, OO dreg& DREG3, OO dreg& DREG2, iO dreg& DREG0);

those are the function prototypes - a lot of parameters are solved, but often results of registers are given back, when you don't know if they will be used later. So far they stay alive, but may vanish later. This stuff is 'alive' as long as there are variables with no real name. Right now the last remaining in the file is this one that brings the (temporary) messages to the top in the screen. But there are still some to solve before.

I expect this plan to bring fast results once the base is done.

Interesting side effects: also those listed routines have no differences (except data offsets ofc) for both versions!
Still I know - this will change

[copse]

...
You now, I got the Atari-sources (for both, normal and extended version) in some special way - which is executable pretty fine.
I also made this side-by-side view to the Amiga-code (which still lacks replacement of the OS-stuff, so, not executable, but with some worthful informations).
And now I go down to the end of the file (graphics etc. there), pick a routine, check which other ...
Interesting side effects: also those listed routines have no differences (except data offsets ofc) for both versions!
Still I know - this will change

Hmm.. somewhat reminiscent of this.