Graphics conversion from other arcade formats to Neo-Geo. - Page 1

Fortunately, Metal Savior sprgfx format requires a minimal effort - just unite the first-7.uor1 and first-8.uor2 to .c1, then first-9.uor2 and first-10.uor3 - to .c2 file. But is there any way to change the endianity in the each separate byte of C rom file, to unmirror tiles horizontally?

Fichier joint : metlsavr.bmp
Fichier joint : metlsavr_cd.bmp
Fichier joint : metlsavr_fix.bmp

I have no idea how to accomplish what you are hoping to accomplish but I will say this is a very cool project!
Also I wasn't aware of Metal Saver! Thanks for putting it on my radar!

Thank you. I also decide that instead of full rewrite of original game palette data (Metal Savior hardvare uses xBGR_444 colour space) it's would be easier to use an in-game software colour converter. At the first stage of conversion, is it enough to just shift a content of each RGB channel left by 1 bit?

I think that's not quite correct because you would lose the black value and you also don't get a maximum value 31!
maybe it looks better with this palette conversion!

0 -> 0 *
1 -> 2
2 -> 4
3 -> 6
4 -> 8
5 -> 10
6 -> 12
7 -> 14
8 -> 17 *
9 -> 19
10 -> 21
11 -> 23
12 -> 25
13 -> 27
14 -> 29
15 -> 31 *

I. e. it should look some kinda like this?

move.w D0, D1 ; D0 contains the whole colour code move.w D0, D2 andi.w #$f, D0 ; getting R component andi.w #$f0, D1 ; G andi.w #$f00, D2 ; B asl.b #1, D0 asl.w #1, D1 asl.w #1, D2 cmpi.b #$10, D0 blt (2,PC) addi.b #1, D0 cmpi.w #$10, D1 blt (2,PC) addi.w #1, D1 cmpi.w #$10, D2 blt (2,PC) addi.w #1, D2

Your idea is correct but this code won't work that way... I don't know which compiler you are using, but BLT shouldn't really work like this!?
Do you want to do it in real time or on NEOGEO? why no pre-calculated palettes?

blastar (./6):I don't know which compiler you are using, but BLT shouldn't really work like this!?

I mean the 6dxxh opcode. MAME debugger decyphering it as BLT, and its behaviour is according (by the way, in my case it's turned out to be, that offset must be 4, not 2). Assembler I use is Bruce Tomlin's ASMX (the part of BasiEgaXorz responsible for final stage of program build). In a result, the new code looks that:
move.w #$888, D0 ; D0 contains the whole colour code move.w D0, D1 move.w D0, D2 andi.w #$f, D0 ; getting R component andi.w #$f0, D1 asr.w #4, D1 ; G andi.w #$f00, D2 asr.w #8, D2 ; B asl.b #1, D0 asl.b #1, D1 asl.b #1, D2 cmpi.b #$10, D0 dc.w $6d04 addi.b #1, D0 cmpi.b #$10, D1 dc.w $6d04 addi.b #1, D1 cmpi.b #$10, D2 dc.w $6d04 addi.b #1, D2
I doubt it's able to overload the M68k - the conversion operation are planning to be applied only once, during the palette data loading from rom. The original game all the same uses a work RAM as intermediary storage for palettes, and exactly from there the data gets send to palette ram in the screen refresh subroutine after interrupts.

You can get almost the same by copying the MSB of each component to the LSB. Meaning you can get away with just an AND and a shift, and no branching.
Also, for this format of colors, a table would also work, it'd take just 8 kB.

blastar (./4):
I think that's not quite correct because you would lose the black value and you also don't get a maximum value 31!
maybe it looks better with this palette conversion!

0 -> 0 *
1 -> 2
2 -> 4
3 -> 6
4 -> 8
5 -> 10
6 -> 12
7 -> 14
8 -> 17 *
9 -> 19
10 -> 21
11 -> 23
12 -> 25
13 -> 27
14 -> 29
15 -> 31 *

Few days ago I decided that instead of Metal Savior porting to Neo Geo it'll be better to create an own game for Metal Savior hardware. So I'd like to ask now about, vice versa, reduction of colour from 8 bit per channel to 4.
Fichier joint :
Fichier joint :

I switch a target platform for Metal Savior clone to PS2 and 7G consloses, and instead of Metal Savior to clone for Neo-Geo the Double Point.

Double Point reverse engineering is going on here.