issue with display 4-bit color files

[TXG/MNX]

Hi,

 

I got an issue when I save a bmp as 8-bit and load without clut it looks the same in vj as my created graphics.

But now I did save the same picture with 16 colors, tested it afterwards in xnview en paint from windows the picture looks good but VJ does display it not the same.

 

Anyone knows what issue this is ?

 

The attached demo.bmp is 4-bit color.

 

I got this set in RB+

 

=========================

 

Sprite info

 

dc.l 1 ; (REPEAT COUNTER) ; Create this many objects of this type (or 1 for a single object)
dc.l is_active ; sprite_active ; sprite active flag
dc.w 0,0 ; sprite_x ; 16.16 x value to position at
dc.w 0,0 ; sprite_y ; 16.16 y value to position at
dc.w 0,0 ; sprite_xadd ; 16.16 x addition for sprite movement
dc.w 0,0 ; sprite_yadd ; 16.16 y addition for sprite movement
dc.l 320 ; sprite_width ; width of sprite (in pixels)
dc.l 112 ; sprite_height ; height of sprite (in pixels)
dc.l is_normal ; sprite_flip ; flag for mirroring data left<>right
dc.l 0 ; sprite_coffx ; x offset from center for collision box center
dc.l 0 ; sprite_coffy ; y offset from center for collision box center
dc.l 320/2 ; sprite_hbox ; width of collision box
dc.l 112/2 ; sprite_vbox ; height of collision box
dc.l BMP_water ; sprite_gfxbase ; start of bitmap data
dc.l 4 ; (BIT DEPTH) ; bitmap depth (1/2/4/8/16/24)
dc.l is_RGB ; (CRY/RGB) ; bitmap GFX type
dc.l is_trans ; (TRANSPARENCY) ; bitmap TRANS flag
dc.l 320*112/2 ; sprite_framesz ; size per frame in bytes of sprite data
dc.l 320/2 ; sprite_bytewid ; width in bytes of one line of sprite data
dc.l 0 ; sprite_animspd ; frame delay between animation changes
dc.l 0 ; sprite_maxframe ; number of frames in animation chain
dc.l ani_rept ; sprite_animloop ; repeat or play once
dc.l edge_wrap ; sprite_wrap ; wrap on screen exit, or remove
dc.l spr_inf ; sprite_timer ; frames sprite is active for (or spr_inf)
dc.l spr_linear ; sprite_track ; use 16.16 xadd/yadd or point to 16.16 x/y table
dc.l 0 ; sprite_tracktop ; pointer to loop point in track table (if used)
dc.l spr_unscale ; sprite_scaled ; flag for scaleable object
dc.l %00100000 ; sprite_scale_x ; x scale factor (if scaled)
dc.l %00100000 ; sprite_scale_y ; y scale factor (if scaled)
dc.l -1 ; sprite_was_hit ; initially flagged as not hit
dc.l 1 ; sprite_CLUT ; no_CLUT (8/16/24 bit) or CLUT (1/2/4 bit)
dc.l can_hit ; sprite_colchk ; if sprite can collide with another
dc.l cd_keep ; sprite_remhit ; flag to remove (or keep) on collision
dc.l single ; sprite_bboxlink ; single for normal bounding box, else pointer to table
dc.l 1 ; sprite_hitpoint ; Hitpoints before death
dc.l 2 ; sprite_damage ; Hitpoints deducted from target
dc.l 320/2 ; sprite_gwidth ; GFX width (of data)


Build.info

Reading assets.txt line
Processing ASSETS\GFX\demo.bmp
Converting BMP internally into gfxdata/clut...
File is 320 pixels wide, 112 pixels high and is 4 bits/pixel

Asset info

abs,BMP_water,gfx_clut,ASSETS\GFX\demo.bmp

In main code

loadclut(strptr(BMP_water_clut),1,16)

demo.bmp

Edited February 8, 2017 by TXG/MNX

[sh3-rg]

Your image looks weird above (corrupt palette as shown in chrome browser) but loads into psp8 fine and displays as a thumb in win7 fine. I resaved using psp8 and the header is very slightly different - this could be causing some sort of conversion problem.

 

What tool are you using to create your 16 colour images? Some tools botch palette-based files.

 

Here is the same image re-saved with psp8:

 

demo2.bmp

Edited February 8, 2017 by sh3-rg

[TXG/MNX]

I used paint.net with the lowcolor.plugin or maybe there is new pluging will look for it. I will test your bmp later this evening when I am using my dev laptop.

 

I don't have psp anymore had it in the old days, seems I need to find the cd again.

[WAVE 1 GAMES]

try deleting this line

 

dc.l 320*112/2 ; sprite_framesz ; size per frame in bytes of sprite data

 

 

Also make sure you have it set to clut 1 in the LOADCLUT list in the .bas file

 

then go in the build folder delete the water.bmp.gfxdata and water.bmp.clut files and build again

Edited February 8, 2017 by Jeffrey_Bones

[TXG/MNX]

I did try everything but the demo2.bmp no success it doesnot look the sane, On windows on every program the bmp lookw good :-(

[sh3-rg]

Show some photos of what you see and what you expect. It's not really important that your other tools display the image correctly - the one that does the conversion is the one that counts.

 

Also delete the whole build folder and contents and build again.

 

Do some sanity checking, write the word "arse" over your image and prove that it's displaying the one you have saved. If so and it still looks wrong, your code is to blame.

 

Are you using some 256 colour object or overwriting and killing the CLUT with that data afterwards are you?

There could be all kinds of reasons for not seeing what you expect.

 

ps Don't randomly delete lines from rapinit.s, that's nuts.

Edited February 8, 2017 by sh3-rg

[ggn]

I took a look at the headers of both files, and it seems like the field that specifies number of colours is zero in txg's bitmap. At least if I counted right (reference: https://en.wikipedia.org/wiki/BMP_file_format).So it probably does bad things.

 

If you want a free and (from our experiments, working) program that can write 16 colour bmp files try xnview.

[+CyranoJ]

try deleting this line

 

dc.l 320*112/2 ; sprite_framesz ; size per frame in bytes of sprite data

 

 

Don't EVER delete lines from _rapinit.s

[omf]

 

Don't EVER delete lines from _rapinit.s

rainbow!

[TXG/MNX]

I took a look at the headers of both files, and it seems like the field that specifies number of colours is zero in txg's bitmap. At least if I counted right (reference: https://en.wikipedia.org/wiki/BMP_file_format).So it probably does bad things.

 

If you want a free and (from our experiments, working) program that can write 16 colour bmp files try xnview.

 

Hi,

 

After trying several programs (paint, paint.net, psp I did manage to export the picture with xnview and it displays fine now in 4-bit

 

I only used the save function within xnview but found out that the export function did allow me to export 4-bit with or without transparancy.

The exported file does display correct just like I see it in any program.

 

Thanx for the help, I was lost by the fact that paint.net/paint/psp 8 did load and save the file and did preview fine. The properties from the file in windows did show also 4 colors.

[VladR]

Or, instead of banging your head against the wall as other tools don't do what you want, you could do what I did and spend one hour in VisualStudio.NET and write a simple function that will load the image (using MSDN .NET library) and alter/sort/adjust the palette exactly the way you want before exporting. Literally less than one screen of code.

 

Only then you're going to have 100% consistency, not dependent on order of actions in given gfx program. Not even the old PaintShopPro 6 is 100% consistent. Keep it running for a while, load few hundred bitmaps, and it will mess your exports now and then.

[sh3-rg]

 

Thanx for the help, I was lost by the fact that paint.net/paint/psp 8 did load and save the file and did preview fine. The properties from the file in windows did show also 4 colors.

 

I've only ever used PSP6 and PSP 8 to create gfx assets for rb+ and neither have ever produced a broken image.

 

The tool chain works, but as always: GIGO.

 

That image Iposted should have worked - the header in your original file was broken as I said. If you didn't delete your whole build folder, it could easily have missed the new image and not converted it, instead used the existing .gfxdata file and palette file and just build the same broken stuff as before. When you get issues like these, deleting the build folder is step 1 on the path to finding wtf is going wrong.

 

As for writing your own tool to manage image conversion as suggested above... irrelevant, no place here. If you're the sort of person who writes your own tools, wtf are you doing making games in BASIC or wasting time reading threads about them?

[+Sporadic]

I use psp7 with zero issues.

 

Reinvent the wheel? No thanks lol