Print

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

[BooBoo]

Hi - Im new
Had a bit of luck editing RAW graphics with SSF2 -Chaos Engine CD32 and Great Giana Sisters the main problem I find is that to edit the RAW graphics they first have to be Ripped with GFX rip and in order to this you need to figure out the dimensions and number of Bitplanes.

With SSF2 I was very luck that BippyM figured out the Dimenstions -I find it very hard to workout / Guess these dimensions
Has anyone got any tricks or Tips to help Rip graphics?

[Hungry Horace]

yes


i have edited gfx on SWOS since the World Cup 98 update myself an my brother did, (he arranged the team-data updates whilst i got on with the hard stuff!!!)

i can only really give advice on games that use files, and not disk images, but the dealing of raw formats with files seems to be fairly universal, so if you can "isolate" and area of a disk image, that equate to a raw gfx file in a disk image, you may be onto a winner.

The below has worked for me on SWOS, Cannon Fodder and Wipe-Out. I have found some game (mega lo mania) een use IFF/ILBM files once extracted. Cannon Fodder in fact uses a bizarre mix of both.



1) check the files are uncompressed
 - the filesize is your friend here
 - a dead giveaway for this is a file that is not a multiple of 2/4/8 
 - run the file through xfddecrunch and see if it uncompresses
 - open the file in a hex editor otherwise... is often fairly obvious to see with the naked eye if it is compressed or not. lots of OSYHX,8UHD3GSS vs .....s..1......2.3.  - then the former is likely decrunched, whilst the latter is not.



2) If you are sure you are dealing with an uncompressed file, check out the multiples.

i found on SWOS there were two regular filesizes.

- LOADER00.raw and MENUBG.raw for example (loading screen / menu background) were 47,872 bytes
- CJCGRAFS.raw (game gfx) were 40960 bytes.

- A basic screen grab from action replay 3 at this stages reveled that these games were 16 colours, which mean 4 bitplanes.

- Up to 8 bitplanes can be store within a single byte, and it is important to bear this in mind when looking to find the right allocation of file width/height/bitplane number, as they are vital for converting the file back to a usable (e.g IFF) format.

- The most common Amiga screensize used is 320 x 256

let take that as a sum .... 320 x 256 = 81920

- This means that with 32 colours (5 bitplanes) we can store a full 320 x 256 picture file within 81920 bytes.

we can now guess that 4 bitplanes, (16 colours) would only need half the number of bits for  320 x 256 size file... which would give us a file size of; 40960

it is here we should notice that it matches the filesize of the file; CJCGRAFS.raw in SWOS, and various other files once uncompressed.

- Using a program such as ArtPro (see aminet) we are able to attempt a load of a RAW file. however, it does ask for the size and number of bitplanes.

Enter; 320 . 256 . 4 . and you will find the file loads, and can then be saved as an IFF file for later editing. There will be no colour data, but you can obtain this with a basic Action Replay 3 (or other cartridge) screen grab for now.

- Going back to our SWOS files;
LOADER00.raw and MENUBG.raw for example (loading screen / menu background) were 47,872 bytes

we can start to summise that, by doubling the file size, (to 95744) we can calculate our height /width values. This may take some experimentation, but any division that creates whole numbers each way should be tested.

- In this case the answer is 352 x 272 (x 4 bitplanes), however, with the .MAP files in swos, you will find that nothing other than a 16 width solution returns an appropriate image. It seems these files largely construct the tile-set for the SWOS football-pitches.

I'm afraid, the crux of this, is that you need to experiment to find what file sizes/depths each game uses.  afew background rips from a suitable ripping cartridge goes a long way to help with this though.



3) bare in mind that amiga raw gfx can come in 'normal' or 'interleaved' formats.
 - with regards to resultant size, these are identical.
 - These are simpley two simialr, but different, ways of arranging the raw gfx data
 - gfx convertors such as 'ArtPro' will give you the option to use both.
- you may need to experiment to find out which one is used on each game. The example from SWOS above use 'raw interlaced' format.



I hope this helps get you started BooBoo! Good luck

[BooBoo]

Thanks HH but in a lot cases ARTPro is no good for ripping Tiles for example Turrican 2 CDTV the main game tiles are stored mixed with other data including the LevelMap data and much more.
Althouth makeing a Screen Grab with ARIII is a good idea like you say you can determine the number of bitplanes and with some Maths I might be able to figure out some dimensions.

Turriacn 2 CDTV file L1-1
Game tiles dec $27002 - $132268 32x32x4 Raw inter
Stored 32x32 next to another 32x32 tile and so on.

As result the graphics need to ripped with GFXrip -ARTPRo would be no good for ripping here

Using this method once the tiles are ripped with GFXRip they can then be edited and converted back to RAW with ARTpro and inserted back into the game.

Also looking through the Project Sprites section of EAB -Alot of Sprites are stored in very unusual sizes makeing it hard to guess its dimensions and the way the guys rip them strate out of WinUae savestates with all the other data that must contain thats insanely hard! to me.

I wanted to have a go at editing the graphics of Lemmings1/Xmas Lemmings but again I need to be able to Rip the Tiles.
and figuring out there dimentions im crap.

[Hungry Horace]

Turriacn 2 CDTV file L1-1
Game tiles dec $27002 - $132268 32x32x4 Raw inter
Stored 32x32 next to another 32x32 tile and so on.

As result the graphics need to ripped with GFXrip -ARTPRo would be no good for ripping here

are those values in hex, only they dont add up? ...  $132268-$27002 =(file size) 10B266 ... if it is 5 bitplanes, that might work as as file size 32 x 21884 (which would suggest 683 tiles???), but you did say it was 4 (16 colours)

i just loaded the T2-2 file, and it is only $2CD06 (or !183558) bytes long, so i am really confused by your offsets above.


Can we not 'back calculate' the size?

If you know the (correct!!) starting offset in the file for the tiles, and you know there are (e.g. 50 tiles each 32x32) , then you need to extract a file of size;


32 x 32 x 50 / 2 (the division by 2 is for 4 bitplanes) = !25600 = $6400

which could load as a raw file with dimensions 32 x 1600


i dont see why Art Pro would be no good? If you have the right kind of file, Art-Pro can convert any size. just a matter of 'extrapolating' the area we want, converting it, changing graphics, converting back, and putting it back at the right offset.

Some Hex editors are really good for that kind of 'brutal' treatment. I do something similar with Bloodwych map data to break it down into similar files as the PC version of the game.



As i said about, with SWOS the .map files (sprite sheet for the pitches) you end us wit files that are 16 x 5000 or so. The conversion wont work any other way. You may need to do something like this. It gets a bit tricky with conversion back, but i can take you though the process there.


one thing i noticed with the graphics in wipe-out is that the last 16 bytes had  the pallette data tacked on the end, which you'd need to remove to get a normal 320x256 file size. This isnt relevant with T2 but i forgot to add it in above


edit; i will probably be in chatroom all day for further discussion

[Hungry Horace]

right, following out conversation on IRC, even though i know the offsets you game me are decimal, i still dont trust them!

i 'cut' the first !27002 bytes from the L1.1 file to get to the right offset. now... the values you game me for ending; 132268 minus the initial offset = 105266 ... this isnt divisable by 32!

i think a back-calculation is needed, as something has gone wrong here.

I am going to try something out...

[Hungry Horace]

here is the T2 tiles extracted from the L1-1 File [attached]


Using an offset of ; $6734
And a file length of; $19E00  ($19A00 will dump the two collision tiles, maybe it is a good idea to do this afterall)
(hex values)

size is 32 x 6624 x 4(bitplanes)- you'll need to get palette data from an AR3 picture rip in order to do a practical edit.

if you know the offsets for the other tile sets, i can make a program in amos to extract and insert files in/out of it.

[Hungry Horace]

attached for booboo

[Hungry Horace]