Jump to content
IGNORED

Importing backgound images


saboteur
 Share

Recommended Posts

Hi all,

 

been quite a while since i've had the time to muck about with rb+, had to move our companies it system into a new building and this has taken up a whole heap of time, dealing with contractors, phone comapnies etc.

 

I also ran into some issues with manic miner that I think I'm going to have to come back too when I can get my head around them.

 

Anyhoo i'm having a go at something over the christmas period and have a question regarding importing images for backdrops.

 

So i have an image in jpeg format that I reduced to 320x200 ( although i could reduce it to any size I suppose ).

 

So far so good, but where i really come unstuck is what to convert to and then the format in the op.

 

Should i convert it to bmp format ? idealy i'd like to keep it at best quality so I figure 24bit bmp, but when i try to use this i just get a jumbled mess on the screen.

 

I get the same result using a 256 colour bitmap.

 

Any pointers as what the list settings sould be for either.

 

All help appreciated.

 

cheers

Link to comment
Share on other sites

So like Sporadic says, you should probably refresh your memory on assets.txt first! Also, have a look at the list of programs you can use. But what the hell, let me add a few more words in this post (which might find their way to the tutorial posts as they're a bit "dry").


So the Object Processor supports bit depths of 1, 2, 4, 8, 16 and 24. This means how many bits are needed to represent a pixel. This is directly in proportion to how many colours your objects can have. Just see the following table:


Bit depth: 1 - 2 colours

Bit depth: 2 - 4 colours

Bit depth: 4 - 16 colours

Bit depth: 8 - 256 colours

Bit depth: 16 - 65536 colours

Bit depth: 24 - 16777216 colours


For the beginner this is sure a daunting list. "How do I choose?". Naturally if we had infinite RAM and bandwidth we'd of course choose "24" as it makes our lives easier. In practice however, this consumes 24 times more bandwidth than depth 1! And bandwidth is something of a premium here because the OP can't display too many 24bit objects in the same line. So we need to compromise.


Use your paint program to count how many colours your sprites or background actually use. If, for example, it uses 117 then there's no reason to use 16 or 24 bit mode - you're burning bandwidth :). Does it use 20? Maybe you should consider reducing that to 16 so you cut your bandwidth consumption in half. And so on and so forth. Another thing worth mentioning again here: 16 and 24 bit modes produce very similar results on the Jaguar's resolutions so the recommendation is to avoid 24 bit mode. Also, using 24bit images requires some extra code to be added so it's another reason to avoid 24 bits mode :)


As said in the assets.txt tutorial, the only valid file format that the rb+ importer accepts is Windows Bitmap, or .bmp. A quick look at the .bmp format shows that the bit depth is stored directly inside the file. We take advantage of this in order not to have to guess the pixel format at all. But this adds a burden to the user - they simply have to save the bmp file in the correct format. Most of the graphic packages in the list above do have options for reducing or increasing the palette - learn them and use them!


One last point (which is pretty much what I wanted to write when I started this). You will notice that most packages do not save 16 bit bmp images, even if they offer to reduce the palette to 65536 colours. So how to overcome this? It turns out that 16 bit images are written as 24 bit, which means the packages will wite 16 bits of useful information and 8 bits of zeros! After realising this, the "gfx_clut16"/"gfx_noclut16" options were added to assets.txt - effectively this tells the importer to discard the extra 8 bits and use only 16. Otherwise there isn't an easy way to distinguish between 16 and 24 bit modes in bmp.

  • Like 3
Link to comment
Share on other sites

Slight correction.. as the Jag is special in many ways the 24bit colour depth is stored as 32bits in Jag memory. 8 of those bits do nothing, but it keeps the pixel data nicely aligned. So if you do go the 24bit route you will actually be using up 32 bits for each pixel (twice as much as 16bit), including memory bus bandwidth.

  • Like 2
Link to comment
Share on other sites

Even so, I don't think the 24-bit mode even works in Rb+ - it was something I was seriously considering for static images but could never get it to work and then someone later mentioned that it was probably never even linked to work anyways. XNVIEW is your friend.

 

To my knowledge the conversion during import should work fine. It's just that it requires magic poking of values during startup that I can't remember nor I'm inclined to dig up. But I'm sure I've verified it working in the past otherwise it wouldn't be there as an option.

Link to comment
Share on other sites

One last point (which is pretty much what I wanted to write when I started this). You will notice that most packages do not save 16 bit bmp images, even if they offer to reduce the palette to 65536 colours. So how to overcome this? It turns out that 16 bit images are written as 24 bit, which means the packages will wite 16 bits of useful information and 8 bits of zeros! After realising this, the "gfx_clut16"/"gfx_noclut16" options were added to assets.txt - effectively this tells the importer to discard the extra 8 bits and use only 16. Otherwise there isn't an easy way to distinguish between 16 and 24 bit modes in bmp.

 

 

OH MY GOD GGN!!!!!! THANK YOU SO MUCH! YOU HAVE HELPED ME GREATLY WITH THIS!

 

You see none of my 16 bit zombies had the noclut16 in the assets file. (it was just noclut) I was getting some pretty wonky performance. I went through and changed them all. Not only did the ROM size drop from 1.5 MB to 1.3 MB but the game is running smoother now

 

 

THANK YOU THANK YOU THANK YOU!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

  • Like 3
Link to comment
Share on other sites

Hands up - i don't get it.

 

I have my image, which i have resized to 320x200px and then saved as a 16bit windows bitmap using the GIMP.

 

I added it to the assets using :

 

ABS,BACKGROUND_2,gfx_noclut16,assets\GFX\AP70573254.bmp

 

and then create an entry in the rapinit :

 

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 200 ; 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 0 ; sprite_hbox ; width of collision box
dc.l 0 ; sprite_vbox ; height of collision box
dc.l BACKGROUND_2 ; sprite_gfxbase ; start of bitmap data
dc.l 16 ; (BIT DEPTH) ; bitmap depth (1/2/4/8/16/24)
dc.l is_RGB ; (CRY/RGB) ; bitmap GFX type
dc.l is_opaque ; (TRANSPARENCY) ; bitmap TRANS flag
dc.l 320*200 ; sprite_framesz ; size per frame in bytes of sprite data
dc.l 320 ; 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 0 ; 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 0 ; sprite_hitpoint ; Hitpoints before death
dc.l 0 ; sprite_damage ; Hitpoints deducted from target
dc.l 320 ; sprite_gwidth ; GFX width (of data)

 

and when i try and use it i get a load of rubbish on the screen.

 

So i'm either getting the assets declaration wrong or the rapint config wrong.

 

Cheers

Link to comment
Share on other sites

a case of rtfcl - read the f***ing comments luke. :-o

 

However still doesn't fix this issue - just gives me a slightly wider/deeper mess on the screen :)

 

The image i'm attempting to use can be found here.

 

cheers

 

This is why I use XNVIEW for everything. I copy from GIMP and just resize a template image that I know works in XNVIEW and then save over it and rename it for what I need. It's not an ideal process but it works. I'm not new to graphic editors and changing settings, why on Earth GIMP doesn't export to something the Jag doesn't like doesn't make sense to me. I don't use any other commercial software to test with and since both GIMP and XNVIEW are free, they are the best options to use, even if the process is a little more copy/pasty.

  • Like 1
Link to comment
Share on other sites

 

This is why I use XNVIEW for everything. I copy from GIMP and just resize a template image that I know works in XNVIEW and then save over it and rename it for what I need. It's not an ideal process but it works. I'm not new to graphic editors and changing settings, why on Earth GIMP doesn't export to something the Jag doesn't like doesn't make sense to me. I don't use any other commercial software to test with and since both GIMP and XNVIEW are free, they are the best options to use, even if the process is a little more copy/pasty.

 

Yeah ill give that a go and see how I get on.

 

There is always something waiting to trip you up :)

Link to comment
Share on other sites

I also noticed the original file was 16bit and the psp version was 24 bit (and larger).

 

Perhaps this goes in line with GGNs statement above and gimp isn't filling the end of the file with zeros? Where as the PSP file is correctly being downsized to 16bit by rB+ ?

Edited by Sporadic
Link to comment
Share on other sites

Hands up - i don't get it.

 

I have my image, which i have resized to 320x200px and then saved as a 16bit windows bitmap using the GIMP.

 

I added it to the assets using :

 

ABS,BACKGROUND_2,gfx_noclut16,assets\GFX\AP70573254.bmp

 

and then create an entry in the rapinit :

 

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 200 ; 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 0 ; sprite_hbox ; width of collision box

dc.l 0 ; sprite_vbox ; height of collision box

dc.l BACKGROUND_2 ; sprite_gfxbase ; start of bitmap data

dc.l 16 ; (BIT DEPTH) ; bitmap depth (1/2/4/8/16/24)

dc.l is_RGB ; (CRY/RGB) ; bitmap GFX type

dc.l is_opaque ; (TRANSPARENCY) ; bitmap TRANS flag

dc.l 320*200 ; sprite_framesz ; size per frame in bytes of sprite data

dc.l 320 ; 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 0 ; 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 0 ; sprite_hitpoint ; Hitpoints before death

dc.l 0 ; sprite_damage ; Hitpoints deducted from target

dc.l 320 ; sprite_gwidth ; GFX width (of data)

 

and when i try and use it i get a load of rubbish on the screen.

 

So i'm either getting the assets declaration wrong or the rapint config wrong.

 

Cheers

why does no one use my list editor, *sigh*

Link to comment
Share on other sites

Hello and thanks for reporting a rb+ bug :P

 

While I was testing the import code years ago I wasn't able to produce a 16bit bmp file easily. Anyway I downloaded both images generated from gimp and psp7. First thing I noticed was file size: gimp's is 128138 bytes and psp7's 192054. Quick arithmetic gives us that the image is 320*200=64000 pixels. So 2*64000=128000 and 3*64000=192000. Let's discard the difference in bytes from the files as those are just the BMP header. What we're left with is that gimp's file is actually 2 bytes/pixel AKA a true 16bit BMP while psp7's file is 3 bytes per pixel, AKA 24bit (with some extra zeros thrown in for teh lulz).

 

When I did the bmp import experiments back in the early 1800s I only had psp7's so called 16bit BMPs as reference, so naturally Sporadic's image worked fine when importing it in rb+. But a true 16bit BMP was never ever tested, so it was natural that the importer would show b**llocks instead of an image :). After fiddling with the importer for 10-20 minutes I made a version that can handle both files properly now, unless I screwed something up badly!

 

The change is already live up on github/bitbucket - you only need to download bin/buildlink.exe if you are already up-to-date otherwise.For reference here's the two lines I had in assets.txt:

 

 

'ABS,BACKGROUND_2,gfx_noclut16,assets\GFX\AP70573254_new.bmp
ABS,BACKGROUND_2,gfx_noclut16,assets\GFX\AP70573254.bmp
To test I would alternate the apostrophe between the two lines to comment out one and test the other and rebuild (build projectname clean in order to wipe the cached files). Finally here's the object's definition:

 

    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    200                                ; 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    0                                ; sprite_hbox                    ; width of collision box
    dc.l    0                                ; sprite_vbox                    ; height of collision box
    dc.l    BACKGROUND_2                    ; sprite_gfxbase                ; start of bitmap data
    dc.l    16                                ; (BIT DEPTH)                    ; bitmap depth (1/2/4/8/16/24)
    dc.l    is_RGB                            ; (CRY/RGB)                        ; bitmap GFX type
    dc.l    is_opaque                        ; (TRANSPARENCY)                ; bitmap TRANS flag
    dc.l    320*200*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    0                                ; 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    0                                ; sprite_hitpoint                ; Hitpoints before death
    dc.l    0                                ; sprite_damage                    ; Hitpoints deducted from target
    dc.l    320*2                                ; sprite_gwidth                    ; GFX width (of data)
Let me know if it works for you or if I broke something in the process! Edited by ggn
  • Like 6
Link to comment
Share on other sites

If you want to fiddle more :) I had a lookie at Gimp earlier, and it seems when you export as BMP there are a few options you can play with. So you can specify if it outputs 24bit or 32bit in the BMP with a few byte ordering variations.

But... does it display Mick Hucknall when it boots up?????!??!?

  • Like 1
Link to comment
Share on other sites

@omf - in the beginning I tried but it immediately broke everything for some reason but that was when I very first started in the beginning and was ignorant to a lot of things so may have to give it another go

if you would like to give it another go, you can contact me directly for support. i don't mind helping people who actually use it :)

  • Like 1
Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
 Share

  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...