saboteur Posted December 18, 2017 Share Posted December 18, 2017 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 Quote Link to comment Share on other sites More sharing options...
Sporadic Posted December 18, 2017 Share Posted December 18, 2017 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. Quote Link to comment Share on other sites More sharing options...
ggn Posted December 18, 2017 Share Posted December 18, 2017 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. 3 Quote Link to comment Share on other sites More sharing options...
LinkoVitch Posted December 18, 2017 Share Posted December 18, 2017 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. 2 Quote Link to comment Share on other sites More sharing options...
Clint Thompson Posted December 18, 2017 Share Posted December 18, 2017 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. Quote Link to comment Share on other sites More sharing options...
ggn Posted December 18, 2017 Share Posted December 18, 2017 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. Quote Link to comment Share on other sites More sharing options...
+CyranoJ Posted December 18, 2017 Share Posted December 18, 2017 VMODE needs to change. 1 Quote Link to comment Share on other sites More sharing options...
WAVE 1 GAMES Posted December 19, 2017 Share Posted December 19, 2017 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!!!!!!!!!!!!!!!!!!!!!!!!!!!!! 3 Quote Link to comment Share on other sites More sharing options...
ggn Posted December 20, 2017 Share Posted December 20, 2017 Well there we go, the post above says much more on the subject than I could say - mind your bandwidth! Quote Link to comment Share on other sites More sharing options...
saboteur Posted December 20, 2017 Author Share Posted December 20, 2017 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 Quote Link to comment Share on other sites More sharing options...
+CyranoJ Posted December 20, 2017 Share Posted December 20, 2017 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 Quote Link to comment Share on other sites More sharing options...
saboteur Posted December 20, 2017 Author Share Posted December 20, 2017 a case of rtfcl - read the f***ing comments luke. 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 Quote Link to comment Share on other sites More sharing options...
Sporadic Posted December 20, 2017 Share Posted December 20, 2017 Out of interest, try this one. I opened it in Paint Shop Pro 7 and resaved it. AP70573254_new.bmp Quote Link to comment Share on other sites More sharing options...
Clint Thompson Posted December 20, 2017 Share Posted December 20, 2017 a case of rtfcl - read the f***ing comments luke. 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. 1 Quote Link to comment Share on other sites More sharing options...
saboteur Posted December 20, 2017 Author Share Posted December 20, 2017 Yep that works - must be gimps bmp formating then. 2 Quote Link to comment Share on other sites More sharing options...
saboteur Posted December 20, 2017 Author Share Posted December 20, 2017 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 Quote Link to comment Share on other sites More sharing options...
Sporadic Posted December 20, 2017 Share Posted December 20, 2017 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 Quote Link to comment Share on other sites More sharing options...
LinkoVitch Posted December 20, 2017 Share Posted December 20, 2017 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+ ? Quote Link to comment Share on other sites More sharing options...
Sporadic Posted December 20, 2017 Share Posted December 20, 2017 (edited) 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 December 20, 2017 by Sporadic Quote Link to comment Share on other sites More sharing options...
omf Posted December 20, 2017 Share Posted December 20, 2017 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* Quote Link to comment Share on other sites More sharing options...
Clint Thompson Posted December 20, 2017 Share Posted December 20, 2017 @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 Quote Link to comment Share on other sites More sharing options...
ggn Posted December 20, 2017 Share Posted December 20, 2017 (edited) Hello and thanks for reporting a rb+ bug 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 December 20, 2017 by ggn 6 Quote Link to comment Share on other sites More sharing options...
LinkoVitch Posted December 20, 2017 Share Posted December 20, 2017 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. 1 Quote Link to comment Share on other sites More sharing options...
ggn Posted December 20, 2017 Share Posted December 20, 2017 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?????!??!? 1 Quote Link to comment Share on other sites More sharing options...
omf Posted December 25, 2017 Share Posted December 25, 2017 @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 1 Quote Link to comment Share on other sites More sharing options...
Recommended Posts
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.