Jump to content

Photo

Importing backgound images


24 replies to this topic

#1 saboteur OFFLINE  

saboteur

    Chopper Commander

  • 109 posts

Posted Mon Dec 18, 2017 4:56 AM

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



#2 Sporadic OFFLINE  

Sporadic

    Moonsweeper

  • 490 posts
  • Probably RB+ing
  • Location:UK

Posted Mon Dec 18, 2017 5:50 AM

Hi,

 

Save your image as a BMP. People have less compatibility  issues with 16 bit images too.

 

Did you check out ggns pinned tutorials in the RB+ forum? He covered assets.txt and the object list which should be a good resource for you.



#3 ggn OFFLINE  

ggn

    Stargunner

  • 1,356 posts
  • Location:Athens, Greece

Posted Mon Dec 18, 2017 10:40 AM

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.


#4 LinkoVitch OFFLINE  

LinkoVitch

    River Patroller

  • 2,504 posts
  • Location:Manchester UK

Posted Mon Dec 18, 2017 10:48 AM

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.



#5 Clint Thompson OFFLINE  

Clint Thompson

    River Patroller

  • 4,323 posts
  • Kiss Reality Goodbye.
  • Location:Indianapolis, Indiana

Posted Mon Dec 18, 2017 11:04 AM

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.



#6 ggn OFFLINE  

ggn

    Stargunner

  • 1,356 posts
  • Location:Athens, Greece

Posted Mon Dec 18, 2017 3:58 PM

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.



#7 CyranoJ OFFLINE  

CyranoJ

    Quadrunner

  • 5,317 posts
  • RAPTOR in LOCAL
  • Location:Adelaide, SA

Posted Mon Dec 18, 2017 4:43 PM

VMODE needs to change.



#8 Jeffrey_Bones OFFLINE  

Jeffrey_Bones

    Dragonstomper

  • 952 posts
  • Location:Charlotte, NC

Posted Mon Dec 18, 2017 10:53 PM

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!!!!!!!!!!!!!!!!!!!!!!!!!!!!!



#9 ggn OFFLINE  

ggn

    Stargunner

  • 1,356 posts
  • Location:Athens, Greece

Posted Wed Dec 20, 2017 12:36 AM

Well there we go, the post above says much more on the subject than I could say - mind your bandwidth!

#10 saboteur OFFLINE  

saboteur

    Chopper Commander

  • Topic Starter
  • 109 posts

Posted Wed Dec 20, 2017 6:16 AM

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



#11 CyranoJ OFFLINE  

CyranoJ

    Quadrunner

  • 5,317 posts
  • RAPTOR in LOCAL
  • Location:Adelaide, SA

Posted Wed Dec 20, 2017 6:18 AM

    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    320                            ; sprite_gwidth                 ; GFX width (of data)   

It's 16 bit, 1 pixel=2 bytes.

so its 320*200*2 and 320*2



#12 saboteur OFFLINE  

saboteur

    Chopper Commander

  • Topic Starter
  • 109 posts

Posted Wed Dec 20, 2017 7:53 AM

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



#13 Sporadic OFFLINE  

Sporadic

    Moonsweeper

  • 490 posts
  • Probably RB+ing
  • Location:UK

Posted Wed Dec 20, 2017 8:22 AM

Out of interest, try this one.

 

I opened it in Paint Shop Pro 7 and resaved it.

 

 

Attached Files



#14 Clint Thompson OFFLINE  

Clint Thompson

    River Patroller

  • 4,323 posts
  • Kiss Reality Goodbye.
  • Location:Indianapolis, Indiana

Posted Wed Dec 20, 2017 8:27 AM

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.



#15 saboteur OFFLINE  

saboteur

    Chopper Commander

  • Topic Starter
  • 109 posts

Posted Wed Dec 20, 2017 8:30 AM

Yep that works - must be gimps bmp formating then.



#16 saboteur OFFLINE  

saboteur

    Chopper Commander

  • Topic Starter
  • 109 posts

Posted Wed Dec 20, 2017 8:31 AM

 

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 :)



#17 Sporadic OFFLINE  

Sporadic

    Moonsweeper

  • 490 posts
  • Probably RB+ing
  • Location:UK

Posted Wed Dec 20, 2017 8:35 AM

Yep that works - must be gimps bmp formating then.

 

yes, PSP7 never lets me down.  I have had issues with Gimp before but couldn't be bothered to investigate when psp just worked ;)



#18 LinkoVitch OFFLINE  

LinkoVitch

    River Patroller

  • 2,504 posts
  • Location:Manchester UK

Posted Wed Dec 20, 2017 8:37 AM

Random thought.. when saving the BMP from GIMP check to see if there is an option for compression, might be GIMP is compressing the BMP by default, or applying some other options that are making it less compatible with RB+ ?



#19 Sporadic OFFLINE  

Sporadic

    Moonsweeper

  • 490 posts
  • Probably RB+ing
  • Location:UK

Posted Wed Dec 20, 2017 8:40 AM

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, Wed Dec 20, 2017 8:42 AM.


#20 omf OFFLINE  

omf

    Dragonstomper

  • 773 posts

Posted Wed Dec 20, 2017 12:29 PM

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*



#21 Clint Thompson OFFLINE  

Clint Thompson

    River Patroller

  • 4,323 posts
  • Kiss Reality Goodbye.
  • Location:Indianapolis, Indiana

Posted Wed Dec 20, 2017 1:29 PM

@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



#22 ggn OFFLINE  

ggn

    Stargunner

  • 1,356 posts
  • Location:Athens, Greece

Posted Wed Dec 20, 2017 2:27 PM

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, Wed Dec 20, 2017 2:28 PM.


#23 LinkoVitch OFFLINE  

LinkoVitch

    River Patroller

  • 2,504 posts
  • Location:Manchester UK

Posted Wed Dec 20, 2017 3:29 PM

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. 



#24 ggn OFFLINE  

ggn

    Stargunner

  • 1,356 posts
  • Location:Athens, Greece

Posted Wed Dec 20, 2017 3:39 PM

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?????!??!?

#25 omf OFFLINE  

omf

    Dragonstomper

  • 773 posts

Posted Sun Dec 24, 2017 6:00 PM

@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 :)





Reply to this topic



  


0 user(s) are browsing this forum

0 members, 0 guests, 0 anonymous users