Jump to content
IGNORED

A couple graphics questions


flux

Recommended Posts

First, I'm having trouble getting text to show up over my sprites -- my background sprite in particular. It isn't clear to me what I should add or move around to make this happen. What do I need to make sure I am doing with the rprint or other related commands to fix that?

 

Speaking of my background sprite, currently i have an 8 bit image serving as the background. It actually is made up of about 200 colors. By itself, it seems to display fine, but when I add my little sprites (currently two different 4 bit images), then all of a sudden big chunks of my background start getting discolored and seem to be taking on colors from the other sprites. I came across a post on this forum and I could be misinterpreting it but it seemed to be saying that the 4 bit palettes I'm using need to be a subset of the 8 bit palette.

 

This is the part I'm having trouble wrapping my head around the most. I thought that the system could display 16 bit color, and, I mean, of course it does. But is it an either/or type situation? Meaning, if I use a sprite with a limited palette, then I am committing myself to such restrictions in my other sprites? I know this has undoubtedly been explained before and I've even read some things here but it's not really "clicking" for me yet. If anyone wouldn't mind indulging me and explaining this again, and perhaps field some followups should they arise, I'd be super grateful.

Link to comment
Share on other sites

First, I'm having trouble getting text to show up over my sprites -- my background sprite in particular. It isn't clear to me what I should add or move around to make this happen. What do I need to make sure I am doing with the rprint or other related commands to fix that?

Try reordering your objects in rapinit.s, to be more accurate: move the text/particle layer (typically the first one) lower than the other objects.

 

Speaking of my background sprite, currently i have an 8 bit image serving as the background. It actually is made up of about 200 colors. By itself, it seems to display fine, but when I add my little sprites (currently two different 4 bit images), then all of a sudden big chunks of my background start getting discolored and seem to be taking on colors from the other sprites. I came across a post on this forum and I could be misinterpreting it but it seemed to be saying that the 4 bit palettes I'm using need to be a subset of the 8 bit palette.

 

This is the part I'm having trouble wrapping my head around the most. I thought that the system could display 16 bit color, and, I mean, of course it does. But is it an either/or type situation? Meaning, if I use a sprite with a limited palette, then I am committing myself to such restrictions in my other sprites? I know this has undoubtedly been explained before and I've even read some things here but it's not really "clicking" for me yet. If anyone wouldn't mind indulging me and explaining this again, and perhaps field some followups should they arise, I'd be super grateful.

When you define an object you have the option of it being paletted (i.e. use 2,4,8,16,256 colours from a user defined palette) or 16-bit. sh3's post here explains this more visually. I would also recommend reading my OP ramblings if you haven't already - perhaps this will help you grasp things better.

 

If you're still confused you could also try omf's list editor and see the kind of objects it creates.

Edited by ggn
  • Like 4
Link to comment
Share on other sites

Basically, the Jaguar only supports a single 256-color palette, shared by all paletted graphic objects, regardless of their number of colors. So if you use more than a single paletted object, you have to take care that there palettes are compatible ; you can't have a different palette for each object.

 

16-bit objects don't use the palette and are not subject to these limitations.

Edited by Zerosquare
  • Like 2
Link to comment
Share on other sites

Basically, the Jaguar only supports a single 256-color palette, shared by all paletted graphic objects, regardless of their number of colors. So if you use more than a single paletted object, you have to take care that there palettes are compatible ; you can't have a different palette for each object.

 

16-bit objects don't use the palette and are not subject to these limitations.

 

That actually pretty well resolves one of the key points I couldn't understand. Thanks! If one wanted to divvy up the palette between different objects, how is that done exactly? For example, like I mentioned in my initial post, my background sprite currently uses around 200 colors which leaves more than enough for the other objects which are each 4-bits. Yet, as soon as I include those 2 objects, or really only one of them even, it messes up the background object and the background starts taking on colors of the other objects. What is the mechanism for getting these 4 bit objects to use colors outside of those in use by the 8 bit object and instead use some of the leftover space for them?

 

Currently, the palettes seem to pretty much be getting determined by the bitmaps themselves. Is there something I'm supposed to do to manually define the palette instead and specify each of the 256 colors? Seems tedious but if that's what has to be done. Or am I supposed to first include some kind of bitmap that contains the entire palette I want and just not use it in the game and instead only use it to define the palette that the other objects use? Or does it have something to do with the order in which the assets are loaded? Sorry if these are dumb questions!

Link to comment
Share on other sites

If one wanted to divvy up the palette between different objects, how is that done exactly?

With great care :)

 

Yes, it's a bitch

No, it isn't fun.

 

You should have asked this before you drew all your sprites, so at this point, you have to go back and adjust the palette manually. I quite like how PainShopPro 6 lets you load/save/switch palettes.

 

Everybody has different workflow, but the easiest test you can do yourself is to create one giant spritesheet with all your sprites in it (which has plenty of other advantages). That way, you are 100% guaranteed that all colors are used properly and you didn't forget a sprite or two which will suddenly throw your palette into oblivion...

 

 

 

256 colors should be enough for everyone :)

Link to comment
Share on other sites

With great care :)

 

Yes, it's a bitch

No, it isn't fun.

 

You should have asked this before you drew all your sprites, so at this point, you have to go back and adjust the palette manually. I quite like how PainShopPro 6 lets you load/save/switch palettes.

 

Everybody has different workflow, but the easiest test you can do yourself is to create one giant spritesheet with all your sprites in it (which has plenty of other advantages). That way, you are 100% guaranteed that all colors are used properly and you didn't forget a sprite or two which will suddenly throw your palette into oblivion...

 

 

 

256 colors should be enough for everyone :)

 

I guess specifically I was wondering how I get the "global" (so to speak) 256 palette loaded. That is, is there some syntax where I manually specify each of the 256 rgb values in my code? Loading my objects normally doesn't seem to work unless I'm doing something wrong there. That is, my 8 bit object which uses 200 colors and my two 4 bit objects seem to interfere with one another's palettes despite there being room for all of the colors. So my thinking was that maybe I need to manually define a palette and every rgb value, or maybe I need to first create a bitmap/object that has the 256 colors I want to use, and use that to define the palette that my other objects will then use a subset of?

Link to comment
Share on other sites

With great care :)

 

Yes, it's a bitch

No, it isn't fun.

 

You should have asked this before you drew all your sprites, so at this point, you have to go back and adjust the palette manually. I quite like how PainShopPro 6 lets you load/save/switch palettes.

 

Everybody has different workflow, but the easiest test you can do yourself is to create one giant spritesheet with all your sprites in it (which has plenty of other advantages). That way, you are 100% guaranteed that all colors are used properly and you didn't forget a sprite or two which will suddenly throw your palette into oblivion...

 

 

 

256 colors should be enough for everyone :)

 

Let's have less sarcasm and more constructive comments, mmkay?

  • Like 2
Link to comment
Share on other sites

I guess specifically I was wondering how I get the "global" (so to speak) 256 palette loaded. That is, is there some syntax where I manually specify each of the 256 rgb values in my code? Loading my objects normally doesn't seem to work unless I'm doing something wrong there. That is, my 8 bit object which uses 200 colors and my two 4 bit objects seem to interfere with one another's palettes despite there being room for all of the colors. So my thinking was that maybe I need to manually define a palette and every rgb value, or maybe I need to first create a bitmap/object that has the 256 colors I want to use, and use that to define the palette that my other objects will then use a subset of?

loadclut is your friend

Link to comment
Share on other sites

Currently, the palettes seem to pretty much be getting determined by the bitmaps themselves. Is there something I'm supposed to do to manually define the palette instead and specify each of the 256 colors? Seems tedious but if that's what has to be done. Or am I supposed to first include some kind of bitmap that contains the entire palette I want and just not use it in the game and instead only use it to define the palette that the other objects use? Or does it have something to do with the order in which the assets are loaded? Sorry if these are dumb questions!

 

You could reduce the colour of the backdrop to say 64 (4 x 16c) or 128 (8x16c) colours, then just save all the sprites as 16 colour BMPs and set a CLUT for each one, as long as ones with the same CLUT go into the same 'colour bank' then it's pretty trivial to manage using the object definitions in _rapinit.s

 

It's quite simple, have a look at some of the examples. If you get stuck, just yell out again.

Link to comment
Share on other sites

I think I got one of my major hurdles cleared. I would load my various cluts, but for some reason I couldn't ever get my background object and my player object to use a separate clut. I tried loading things in different orders and all of that kind of thing and it occurred to me that there was nothing in my program explicitly assigning a specific clut to a specific sprite. I suppose as I was initially figuring everything out, I assumed a clut number was intrinsically linked to what I was using for the object numbers. Not for any good reason -- just working backwards and trying to figure out what does what.

 

In any event, once I had that epiphany, I looked it up in the quick reference guide and figured out this gem which solved a whole heap of my problems.

 

rlist[2].CLUT=2

 

I think that has me squared away for now but I'll probably be back next time I get stuck. I like to think it will be a little while, but probably not.

Edited by flux
  • Like 3
Link to comment
Share on other sites

I'm finding myself stuck with this. I have never really messed with the CLUTs because I was having problems with it but wanted most of my stuff to be 16bit anyways. What I need to know is, if there's a problem displaying full-screen clut graphics or should it just work like everything else? If so, then why am I having problems? The only way I can ever get it to show anything is under clut15 in rapint.s, everything else is pitch black (yes, it's set to opaque) . 4bit graphic, with clut in assets and /2 across the board. This is all I get with red dots on the right hand side but it's supposed to look like the left:

 

post-985-0-45290000-1536885778_thumb.png

 

This is the file.... nightsky4.bmp

 

I know I'm probably doing something wrong as usual but I don't know what else to try.. it should just be 4 different shades of gray. Not sure where it's throwing red in there.

 

*also would like to note that there are no other CLUT graphics used, it's all 16bit otherwise.

Edited by Clint Thompson
Link to comment
Share on other sites

I'm finding myself stuck with this. I have never really messed with the CLUTs because I was having problems with it but wanted most of my stuff to be 16bit anyways. What I need to know is, if there's a problem displaying full-screen clut graphics or should it just work like everything else? If so, then why am I having problems? The only way I can ever get it to show anything is under clut15 in rapint.s, everything else is pitch black (yes, it's set to opaque) . 4bit graphic, with clut in assets and /2 across the board. This is all I get with red dots on the right hand side but it's supposed to look like the left:

 

attachicon.gifshit.PNG

 

This is the file.... attachicon.gifnightsky4.bmp

 

I know I'm probably doing something wrong as usual but I don't know what else to try.. it should just be 4 different shades of gray. Not sure where it's throwing red in there.

 

*also would like to note that there are no other CLUT graphics used, it's all 16bit otherwise.

If you want to use paletted objects then you have to load the palette manually into the slots you're going to use. rb+ doesn't do this automatically for you because it can't assume how you're going to arrange your palettes. By default the CLUT is completely zeroed and raptor just claims #15 for displaying text and particles, so it loads some values in there by default.

 

Let's take a quick look at project nyandodge. In rapinit.s the player and enemy objects look like:

 

...
	dc.l	4								; (BIT DEPTH)					; bitmap depth (1/2/4/8/16/24)
...
(player)
	dc.l	1								; sprite_CLUT					; no_CLUT (8/16/24 bit) or CLUT (1/2/4 bit)
(enemy)
	dc.l	2								; sprite_CLUT					; no_CLUT (8/16/24 bit) or CLUT (1/2/4 bit)
...
This means: a) we're setting the bit depth to 4 bits per pixel (AKA 4bpp mode), b) we're asking raptor to use CLUT 1 and 2 respectively for the different objects. That's all fine and you've probably done this already. But then in the .bas file there are two lines near the top:

 

loadclut(strptr(BMP_PLAYER_clut),1,16)
loadclut(strptr(BMP_ENEMY_clut),2,16)
These are the "magic" commands that tell rb+ to load CLUT values into the proper slots. Now, you're going to have to read up tutorial #4 again if you haven't. Basically the rb+ build system automatically creates the CLUT values for you, stores them into a file and imports them when you ask it to import CLUT based images.
  • Like 2
Link to comment
Share on other sites

...
	dc.l	4								; (BIT DEPTH)					; bitmap depth (1/2/4/8/16/24)
...
(player)
	dc.l	1								; sprite_CLUT					; no_CLUT (8/16/24 bit) or CLUT (1/2/4 bit)
(enemy)
	dc.l	2								; sprite_CLUT					; no_CLUT (8/16/24 bit) or CLUT (1/2/4 bit)
...
This means: a) we're setting the bit depth to 4 bits per pixel (AKA 4bpp mode), b) we're asking raptor to use CLUT 1 and 2 respectively for the different objects. That's all fine and you've probably done this already. But then in the .bas file there are two lines near the top:

 

This is the other part of what I was missing and I didn't even get this bit until I just read this post. I wasn't sure what the ; sprite_CLUT value was exactly, and I mostly just copied the whole lot from something else as a reference and tweaked it as needed for things like dimensions. I assumed this was just a flag that was on or off so I put that setting as "1" for all my objects, since "1" worked well enough for the one I was referencing then it ought to work for everything! I was able to fix it with the thing I mentioned in my previous post, but this explains how it ended up that way to begin with.

  • Like 2
Link to comment
Share on other sites

Indeed, fantastic info and thanks again for your guys feedback, truly appreciated. I'll hopefully get some more time to experiment with using this all soon.

 

One last question before I'm off into the wind, if using an 8-bit image, is there a way to use it as 256 colors and if so, it still requires a CLUT? I see the no_clut lines listed in some of the example flags for 8/16/24 bit but that doesn't seem right?

 

Thanks so much!

  • Like 3
Link to comment
Share on other sites

Indeed, fantastic info and thanks again for your guys feedback, truly appreciated. I'll hopefully get some more time to experiment with using this all soon.

 

One last question before I'm off into the wind, if using an 8-bit image, is there a way to use it as 256 colors and if so, it still requires a CLUT? I see the no_clut lines listed in some of the example flags for 8/16/24 bit but that doesn't seem right?

 

Thanks so much!

 

A 256C image goes in CLUT0 and uses all 256 colours (16x16 sub cluts)

  • Like 3
Link to comment
Share on other sites

I have another issue. How is the color that gets used as a transparency determined? I thought it would be something in the rapinit.s file but I don't see anything there besides switching it on or off. Is it something within the bitmap itself?

 

In modes using a CLUT, it is index 0. So in 256c, Index 0, in 4bpp mode, 0,16,32,48,64, etc (the first colour in each sub-clut)

In RGB modes, it is 0,0,0

  • Like 4
Link to comment
Share on other sites

Ok,hopefully the last issue of the day. I'm trying to load a 96x128 sprite with three frames of animation (so my bitmap is 96x384). It mostly works, but on two of the frames, the very bottom pixel row of my character's feet appear as the top row of the sprite, sort of floating above his head. On the third frame, it seems to be a thin row of random junk pixels as the top most row -- still with the bottom row of pixels missing from the feet. Additionally, the very back of his foot what should be on the left side of the sprite is appearing on the far right edge. Also, while the bottom of my character's feet is indeed on the bottom edge of each frame in the bitmap, the back of the foot is not against the edge and there is some buffer space there but some of his foot still seems to be ending up on the wrong side of the sprite.

 

As near as I can tell, which is by no means an expert analysis, all of the sizes are properly specified in the rapinit.s. The parts I'm most unsure about are these:

 

dc.l 96/2 ; sprite_hbox ; width of collision box
dc.l 128/2 ; sprite_vbox ; height of collision box

dc.l 96*128/2 ; sprite_framesz ; size per frame in bytes of sprite data
dc.l 96/2 ; sprite_bytewid ; width in bytes of one line of sprite data

dc.l 96/2 ; sprite_gwidth ; GFX width (of data)

 

I pretty much copied it from some of the included examples, substituting my own dimensions. But I don't really know what's happening or why I'm dividing by 2. It gets reasonably close results and whenever I try to change any of these values, it gets worse.

 

I'm pretty sure the bitmap itself is fine. I checked the first 128 rows carefully, as well as each one, and made sure each was the size it was supposed to be and that everything is where it ought to be. Now I'm out of ideas.

Link to comment
Share on other sites

I'm not sure of the horizontal wrapping but the vertical one is most probably that you weren't precise enough when placing your sprites in the file. My guess is what we see at the top is in fact the last line of the first frame - if I'm not mistaken we are seeing frame #2 in that pic.

 

Thinking about horizontal: it's a bit bizarre, maybe it's a slightly different BMP flavour my converter doesn't handle properly. If you can't get it to work I'd appreciate if you uploaded your project and bmp file.

 

(Also: I hardly think anyone here cares much about how programmer art looks like as long as it works!)

Edited by ggn
  • 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...
  • Recently Browsing   0 members

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