Jump to content

Photo

A couple graphics questions


32 replies to this topic

#1 flux OFFLINE  

flux

    Space Invader

  • 32 posts

Posted Tue Sep 11, 2018 9:11 PM

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.



#2 ggn ONLINE  

ggn

    Stargunner

  • 1,378 posts
  • Location:Athens, Greece

Posted Wed Sep 12, 2018 2:35 AM

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, Wed Sep 12, 2018 2:36 AM.


#3 Zerosquare OFFLINE  

Zerosquare

    River Patroller

  • 2,672 posts
  • Location:France

Posted Wed Sep 12, 2018 7:37 AM

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, Wed Sep 12, 2018 7:38 AM.


#4 flux OFFLINE  

flux

    Space Invader

  • Topic Starter
  • 32 posts

Posted Wed Sep 12, 2018 9:20 AM

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!



#5 VladR OFFLINE  

VladR

    Stargunner

  • 1,481 posts
  • Location:Montana

Posted Wed Sep 12, 2018 11:58 AM

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



#6 flux OFFLINE  

flux

    Space Invader

  • Topic Starter
  • 32 posts

Posted Wed Sep 12, 2018 12:22 PM

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?



#7 ggn ONLINE  

ggn

    Stargunner

  • 1,378 posts
  • Location:Athens, Greece

Posted Wed Sep 12, 2018 12:25 PM

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?

#8 ggn ONLINE  

ggn

    Stargunner

  • 1,378 posts
  • Location:Athens, Greece

Posted Wed Sep 12, 2018 12:27 PM

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

#9 CyranoJ OFFLINE  

CyranoJ

    Quadrunner

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

Posted Wed Sep 12, 2018 3:58 PM

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.



#10 flux OFFLINE  

flux

    Space Invader

  • Topic Starter
  • 32 posts

Posted Thu Sep 13, 2018 4:01 PM

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, Thu Sep 13, 2018 4:03 PM.


#11 Clint Thompson OFFLINE  

Clint Thompson

    River Patroller

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

Posted Thu Sep 13, 2018 6:45 PM

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:

 

Attached File  shit.PNG   72.11KB   0 downloads

 

This is the file.... Attached File  nightsky4.bmp   37.62KB   3 downloads

 

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, Thu Sep 13, 2018 6:47 PM.


#12 Clint Thompson OFFLINE  

Clint Thompson

    River Patroller

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

Posted Thu Sep 13, 2018 7:28 PM

On the flipside, drugs are cool...

 

Attached File  acid1.jpg   908.69KB   0 downloads

 

Attached File  acid2.jpg   739.86KB   0 downloads

 

Attached File  acid3.jpg   560.67KB   0 downloads



#13 ggn ONLINE  

ggn

    Stargunner

  • 1,378 posts
  • Location:Athens, Greece

Posted Fri Sep 14, 2018 1:18 AM

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.

#14 ggn ONLINE  

ggn

    Stargunner

  • 1,378 posts
  • Location:Athens, Greece

Posted Fri Sep 14, 2018 1:21 AM

Also, I've made a couple of images to depict the various indexed and non-indexed modes. I'll just leave them here for now and might do a write up later.

Attached File  depths.png   761.6KB   0 downloads

Attached File  depth-full.png   18.22KB   0 downloads

Attached File  nyanindex.png   133.81KB   0 downloads

#15 CyranoJ OFFLINE  

CyranoJ

    Quadrunner

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

Posted Fri Sep 14, 2018 1:24 AM

Also, I've made a couple of images to depict the various indexed and non-indexed modes. I'll just leave them here for now and might do a write up later.
 

 

Nicely done, might 'borrow' that for the API documentation if that is ok ?



#16 ggn ONLINE  

ggn

    Stargunner

  • 1,378 posts
  • Location:Athens, Greece

Posted Fri Sep 14, 2018 3:17 AM

Nicely done, might 'borrow' that for the API documentation if that is ok ?


Feel free!

Also, if you do bother writing supporting text we'd all appreciate a copy here!

#17 flux OFFLINE  

flux

    Space Invader

  • Topic Starter
  • 32 posts

Posted Fri Sep 14, 2018 6:19 PM

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



#18 Clint Thompson OFFLINE  

Clint Thompson

    River Patroller

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

Posted Sat Sep 15, 2018 7:32 PM

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!



#19 CyranoJ OFFLINE  

CyranoJ

    Quadrunner

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

Posted Sat Sep 15, 2018 8:47 PM

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)



#20 flux OFFLINE  

flux

    Space Invader

  • Topic Starter
  • 32 posts

Posted Sun Sep 16, 2018 3:46 PM

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?



#21 CyranoJ OFFLINE  

CyranoJ

    Quadrunner

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

Posted Sun Sep 16, 2018 3:56 PM

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



#22 flux OFFLINE  

flux

    Space Invader

  • Topic Starter
  • 32 posts

Posted Sun Sep 16, 2018 7:56 PM

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.



#23 CyranoJ OFFLINE  

CyranoJ

    Quadrunner

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

Posted Sun Sep 16, 2018 8:04 PM

You divide by 2 because it is in 16 colour, 4 bit per pixel. So one byte is 2 pixels.

 

Without seeing the sprite itself, we couldn't say why it is displaying like this.  A binary and the sprite image would be handy.



#24 flux OFFLINE  

flux

    Space Invader

  • Topic Starter
  • 32 posts

Posted Sun Sep 16, 2018 8:45 PM

Well, dang. I was afraid you'd say that. It is an embarrassingly crude placeholder stick man. Just trying to get pieces in place before I get into the final graphics. A link to the sprite sheet and a screenshot is here.



#25 ggn ONLINE  

ggn

    Stargunner

  • 1,378 posts
  • Location:Athens, Greece

Posted Yesterday, 12:13 AM

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, Yesterday, 12:14 AM.




Reply to this topic



  


1 user(s) are browsing this forum

1 members, 0 guests, 0 anonymous users