Print

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

[MadMunky]

I think we can all agree the Amiga had the best graphics, has anyone managed to rip all the graphics from the game into individual files rather than sprite sheets?

Bit, what are the chances of extract them via your app?

I know the images are stored in memory on the ST like this but I want each graphic ripped to a single file

[Bit]

Those are the easy ones, because they don't need color/alpha-masking.
A lot more do also mirroring, and there's the zooming.
There are a lot of routines that do all of this in a different way, and because there is a lot of indexing. So it's even hard to reveal which routine works on which sources. I am at it, but those pixelblock-formats make it extremely hard to understand what happens at all.
Atari and Amiga are same evil in this. i.e. watch the disassembly from 0D7E0 to 0D8BE, that's needed to draw a simple horizontal line that needs no masking, stretching or whatever.

[Hungry Horace]

i'm working on it MadMunky ...

http://www.ultimateamiga.co.uk/index.php/topic,9875.msg47497.html#msg47497

I've ripped out a lot of the graphics as 'pure data' ... the only problem with that is that they are not immediately viewable, even if you know how to turn the data into graphics, because differnt graphics have different widths.

What i am going to do, is once i have identified all the graphics as data blocks, program my 'viewer' to interpret each one differently... so for example, with a dragon, it might do 32 'lines' at 32 wide, then 32 'lines' at 24 wide, then change again.... so that you end up with something useable / viewable.

The aim is then to make them editable, so they can be exported back


You wont avoid the spite-sheet aspect though. It would have to then extract 16x16 blocks for the icons you've shown.....  (and different sizes again for characters/monsters) but i'm sure something could be worked out for it to be automated

edit:  attached pics to show how the different widths can be contained within the same datablock/graphic

[Bit]

I will add those soon to the source infos, but here as quick info:
(2nd value is Amiga-adress)

BW_mirror_halfpixelblock 1E07A 0A9C8
BW_mirror_halfpb_table 1E074 0A9C2, datatable: 164A8
BW_table_coloring_sub 1E314 0AC98, datatable 0ACC0
BW_table_coloring 1E2A8 0AC2C
BW_mask_ss 1E110 0AA5E/0AA66
BW_draw_bitmap1 1E09E 0A9CE

As you can see: those routines work even in the Amiga with pixelblocks (of 16 pixels).
 Mirror routines mirror just half of a pixelblock and are *always* called twice then. The first one is an allrounder, the second is bound to the mirrortable. (mirror within a line - so, horizontal)
 The 'table_coloring' is the routine that gives a bitmap the 'private' color. The subroutine is called only from here.
BW_mask_ss does some screen-to-screen masking. i.e. it blits the numbers into the woundflash.
BW_draw_bitmap1 is one of the bigger bitmap-routines. It may handle mirroring, and p(rivate)coloring and calls finally BW_mask_ss. So, is a screen-screen-routine too. It is able to draw the humanoid characters.
That's how far I am, I still follow my plan, so next comes the message-topline. Will be back in graphics after that one.
Maybe that's helpful for the decoding and search where things got blit. Input register for strings and bitmaps is always A6.

[Hungry Horace]

hi bit,

do you know if its possible that the variable widths of the graphics blocks are stored in the data?

I've managed to adapt my graphic viewer to use changing widths (particularly useful with walls etc) but to do so i have to write out my own data block, and finding the info for this is really really time consuming!!


picture attached of the output... (for MadMunky also to see)

[Hungry Horace]

and here is a full set of wall.... takes ages to make this though!

what this does open up is the possiblity of adding a 'new' wall set to the game... perhaps being selected on a separate tower etc, which is easily achieved by changing the address register for the location of the graphic.

i will need to see if i can 'back convert' this back into an identical data block, and then i can look at import/export via ILBM.

[MadMunky]

Nice one Horace! 

[Hungry Horace]

Are IFFs any good to you MadMunky?  If i change them to GIFs the palette changes :/

I've adapated the view further, so that the 'page break' (i.e. when it rolls onto the next column) doesnt happen in the middle of a graphic.

I've attached the IFF file (also zipped) for Osiris37 to take a look at

[Hungry Horace]

i started small.... by replacing the 'book' icon with an unused graphic... but it worked!

[Hungry Horace]

This has way too much potential.....

https://www.youtube.com/watch?v=K7LvZw3D0UA&

[MadMunky]

Very nice and I agree it is impressive changing the original

[Bit]

I created two textfiles from my gameimages Amiga/Atari-version.
One byte per line! Then made a detailed analysis with the help
of WinMerge and Notepad++. This could verify that the main gamedatas
match, with very few exceptions. Here is the outcoming:

Code: [Select]

Amiga    Atari
line 1   line 1   Amiga's Gamestart with codeadress 0x5C   
                  Atari codeadress 0x14000, game starts two bytes later

line
---------------
                 didn't compare datas before the last codeline!

55397    55519   "Wordstext" starts in both files: 07, then 'BLODWYN'...
                 Labels: Amiga 55397-1+0x5C = 0xD8C0, is okay
                         (see 439-disassembly)
                         Atari: 55519-1+0x14000 = 0x218DE, also okay

         57626   Atari adds 2 bytes: 2e,2e
         59120   Atari adds 65 bytes:
                        00,02,22,03,33,04,44,05,
                        55,00,40,00,60,01,17,02,
                        47,04,10,05,21,07,43,07,
                        00,07,60,07,77,06,24,
                        and 34* 00
         59367   Atari adds 20 bytes:
                        1c,64,1e,00,00,00,ee,a0,
                        00,fc,06,de,00,fc,29,ce,
                        00,00,75,5a
         60156   Atari adds 528 bytes
59948 x  60684
    x+78         Amiga: 00,ef,78 Atari: 02,2e,58 could be pointers!
    x+158        Amiga: 00, Atari: 70
    x+189        Amiga: 0f, Atari: 3c
    x+256        Amiga: 00, Atari: 70
    x+326        Amiga: 15,00,15,00,18
                 Atari: 1f,00,1f,05,4c
60729    61015      283820 equivalent bytes
        344835   Atari adds 512 bytes
344099  345347       20418 equivalent bytes
364517           now Amiga adds some stuff
                 32*db, then 4 times 00 and
                 then (maybe another pointer) 00,01,59,d8
364557  365765   145* 00 for both

364702  365910   is Amiga 0x590F9, Atari 0x6D555

Here the Amiga comes with a lot of data, while the Atari stays
with 00 bytes, but...

stopped tracking here, because the highest label I could find
for the Atari is 0x6ccf0 - and screen starts at 0x70000.
Amigascreen starts at 0x60000, and before is the stack, so this
all should be enough.
So - mapdatas and graphics are expected to be identical!

[Hungry Horace]

No where near finished, as i have to identify my data blocks manually, (and then work out their 'layout') but i have made a start at ripping clean graphics files

Being from the Amiga, they are in ILBM/IFF amiga format at the moment.

I'm surprised how much space they end up using in RAW form, but i still hope i can squeeze at least one new wall (and associated items) set into a future mod


Hopefully this is enough for Osiris37 to try some stuff out with.... As long as the layout is retained, the ILBMs can be converted back into a RAW form for patching.

[MadMunky]

I cant remember if I've shared this before but the Atari ST via Steem has a really nice way to see the graphics data. If you load in the Ultimate Ripper cartage you can browse the image buffer and by playing around with the widths you get the following images

[Hungry Horace]

This will be really useful when I start ripping BEXT gfx