Displaying 8 bit color sprites

[WAVE 1 GAMES]

[+CyranoJ]

No, there is nothing special.

[WAVE 1 GAMES]

No, there is nothing special.

Then is there another more rB+ friendly image editing program other than Adobe Photoshop and XNVIEW? I'm certain I'm doing everything correct. I know there are tons of programs out there, but which one has the best compatibility with rB+ when exporting the bitmaps?

[+CyranoJ]

I use XNView.

[Sporadic]

Paint shop pro is my go to for Jag stuff.

[GroovyBee]

Paint shop pro is my go to for Jag stuff.

Agreed 100%. Older versions, that work with image palettes in an easy to understand manner, can be had for peanuts on ebay.

[WAVE 1 GAMES]

https://www.youtube.com/watch?v=30fAG9DFzoI&feature=youtu.be

jagpad8.bmp

 

_{; jagpad - object
; value possible values description rb+ label to access
dc.l 1 ; ; How many sprites like this one do you want in the sprite list?
dc.l is_inactive ; is_active is_inactive ; Will the sprite be active on screen or inactive? ; R_sprite_active
dc.w 240,0 ; ; Put sprite this many pixels from left side of screen. ; R_sprite_x
dc.w 160,0 ; ; Put sprite this many pixels down from top of screen. ; R_sprite_y
dc.w 0,0 ; ; How many pixels will this sprite move automatically in x? ; R_sprite_xadd
dc.w 0,0 ; ; How many pixels will this sprite move automatically in x? ; R_sprite_xadd
dc.l 96 ; ; Width of sprite in pixels ; * R_sprite_width
dc.l 80 ; ; Height of sprite in pixels ; * R_sprite_height
dc.l is_normal ; is_normal is_flipped ; Will the sprite be mirrored in x? ; R_sprite_flip
dc.l 0 ; ; Collision box x offset - pixel distance from centre of sprite ; * R_sprite_coffx
dc.l 0 ; ; Collision box y offset - pixel distance from centre of sprite ; * R_sprite_coffy
dc.l 96 ; ; Width of collision box from centre in pixels ; * R_sprite_hbox
dc.l 80 ; ; Height of collision box from centre in pixels ; * R_sprite_vbox
dc.l SPRITE_JAGPAD ; ; Place in memory where the sprite lives: label from RAPAPP.S ; R_sprite_gfxbase
dc.l 8 ; 1 2 4 8 16 24 ; Sprite graphics type: 1,2,4,8,16 or 24 bit ; * R_sprite_?
dc.l is_RGB ; is_RGB is_cry ; Sprite graphics type. RGB or Atari's CRY format. ; * R_sprite_?
dc.l is_trans ; is_trans is_opaque ; Trans for see-through background, opaque for solid background ; * R_sprite_?
dc.l 96*80 ; ; Size of sprite in bytes - used to find next frame of animation ; R_sprite_framesz
; Enter the x-size * the y-size and add the following next:
; /8 for 1bit
; /4 for 2bit
; /2 for 4bit
; nothing for 8bit
; *2 for 16bit
; *4 for 24bit
dc.l 96 ; ; Width of a single row of sprite pixels ; * R_sprite_bytewid
; Enter the x-size and add the following:
; /8 for 1bit
; /4 for 2bit
; /2 for 4bit
; nothing for 8bit
; *2 for 16bit
; *4 for 24bit
dc.l 7 ; ; Number of screen updates (VB) before the animation advances ; R_sprite_framedel
dc.l 9 ; ; Additional number of animation frames after the first ; R_sprite_maxframe
dc.l ani_rept ; ani_rept ani_once ; Loop theanimation or play a single time ; R_sprite_animloop
dc.l edge_wrap ; edge_wrap R_edge_kill ; What do you want to do if sprite leaves the edge of the screen? ; R_sprite_wrap
dc.l spr_inf ; spr_inf ; Want sprite to stay forever or a number of frames? ; R_sprite_timer
dc.l spr_linear ; spr_linear ; Use automatic movement above or use a tracking table. ; R_sprite_track
dc.l 0 ; ; If using above tracking table, input the loop point here ; R_sprite_tracktop
dc.l spr_scale ; spr_unscale spr_scale ; Is the sprite going to be scaleable or not scaled? ; R_spr_scaled
dc.l 28 ; ; 32 is 1:1. 0-31 are scaled down, 33-255 are scaled up. ; R_sprite_scale_x
; It's probably best to think of the binary number %00100000...
; Adding numbers to the right increases the size fractionally...
; Adding them to the left increases buy a factor of one each time
; So %01000000 is scaled 2x bigger than the original
; %00010000 is scaled half size
; %00010001 is a tiny bit bigger than half size
dc.l 28 ; ; 32 is 1:1. 0-31 are scaled down, 33-255 are scaled up. ; R_sprite_scale_y
; See above for more info.
dc.l -1 ; ; Did the sprite collide with another? ; R_sprite_was_hit
; Set to not hit to begin with, used later to flag collisions
dc.l no_CLUT ; no_CLUT ; Define sprite colours. ; R_sprite_CLUT
; no_CLUT for 8, 16 and 24bit
; CLUT number 0 to 15 for 1, 2 and 4bit
dc.l can_hit ; can_hit cant_hit ; Want to be able to check if this sprite hits others? ; R_sprite_colchk
dc.l cd_keep ; cd_keep cd_remove ; What to do if a collision is detected. ; R_sprite_remhit
dc.l single ; single ; Bounding box for collision detect 'single'. Or address of table ; R_sprite_bboxlink
dc.l 1 ; ; Hit points before sprite is killed ; R_sprite_hitpoint
dc.l 0 ; ; Hit points inflicted upon other sprites ; R_sprite_damage
dc.l 96 ; ; Width of sprite within larger graphic. ; R_sprite_gwidth
; Enter the x-size and add the following:
; /8 for 1bit
; /4 for 2bit
; /2 for 4bit
; nothing for 8bit
; *2 for 16bit
; *4 for 24bit}

Edited May 22, 2017 by Jeffrey_Bones

[WAVE 1 GAMES]

The above was done using Paintshop Pro X9 ^ Same exact result

[+CyranoJ]

I think you will find people are going to be very reluctant to assist you due to the fact that you have people associated with WAVE 1 GAMES who are openly hostile to AtariAge and have made accusations against its moderators, and who constantly attack Reboot every chance they get.

 

I belive you just want to make games and have fun, and wish you all the best in that endeavour.

[WAVE 1 GAMES]

I think you will find people are going to be very reluctant to assist you due to the fact that you have people associated with WAVE 1 GAMES who are openly hostile to AtariAge and have made accusations against its moderators, and who constantly attack Reboot every chance they get.

 

I belive you just want to make games and have fun, and wish you all the best in that endeavour.

 

 

 

 

If not lets just all watch this great new Coldplay video (song is just stuck in my head)

 

[ggn]

That's a 256 col bmp, so if the palette it uses doesn't match the palette you set for the game then the graphics are going to look hosed.

 

Also: cmon people, cut the 8-year-old kintergarten attitude.

Edited May 22, 2017 by ggn

[WAVE 1 GAMES]

That's a 256 col bmp, so if the palette it uses doesn't match the palette you set for the game then the graphics are going to look

Im not sure what you mean ggn. 256 colors is 8 bit and thats what I have it set to. The only way I know of to give the graphics a set color palette is to asign the sprite a CLUT, but I thought 8 bit bmps did not need a CLUT. how am I going to squeeze 256 colors into a 16 color table anyway even if I tried that? I'm kind of confused. Am I missing something here?

[sh3-rg]

Im not sure what you mean ggn. 256 colors is 8 bit and thats what I have it set to. The only way I know of to give the graphics a set color palette is to asign the sprite a CLUT, but I thought 8 bit bmps did not need a CLUT. how am I going to squeeze 256 colors into a 16 color table anyway even if I tried that? I'm kind of confused. Am I missing something here?

 

What kind of magic do they use then?

 

They need all 256 colours of the colour look up table (i.e. all rb+'s 16 sets of 16 "minicluts")... or rather, they can make use of all 256 colours in the CLUT.

 

EDIT: So your solution could be to use 16bpp for your animation (wasteful) or rework the graphic to something like 48 or 64 colours, it'd keep most of the quality (the graphic could do with touching up anyway, the halo like it's been clipped off a bright background is a bit nasty/amateur-looking) but you'd just need to manage the clut properly/reserve the 3 or 4 minicluts for this graphic.

 

 

I'm certain I'm doing everything correct.

 

It's usually user error. Not always, but 99 times out of 100 yep, you're doing it wrong. Not you specifically, just 99 out of 100 people who report errors and insist they're doing everything right and the world is broken.

Edited May 22, 2017 by sh3-rg

[ggn]

Let me try to be a bit more verbose then (unless you read and understood sh3's reply, in which case this is pointless). Sorry if this sounds patronising or anything, just wanted to lay down the basics.

 

When using indexed colour modes (that means 1,2,4,8bits per pixel for the Jaguar) you don't actually store any pixel RGB values per pixel when you save a graphic file. In fact what you do is store the indexes to a look up table that has the RGB values. 256 of them. This is called a "palette". So for example in 4 bit mode you store values that range from 0 to 15 per pixel. Then you tell the hardware which palette indices you intend to use - that's the no_CLUT parameter in raptor: the jaguar actually splits the palette into smaller sections of 16 colours each. So setting no_CLUT to 0 you're selecting indices 0 to 15, setting it to 1 you get 16 to 31 and so on - you get the idea. Now notice that you still need 4 bits for these - the hardware does the calculation 16*no_CLUT + palette_index for you.

 

With me so far?

 

So you start drawing your sprites, taking care they're the bit depth you desire - let's say you go for 16 colours per sprite to take advantage of the full palette sections. You start filling up global palette indices 0-15, 16-31, 32-47 and so on. And you of course set no_CLUT properly so the sprites look properly.

 

Then you try to import a 256 colour sprite and have it co-exist with the rest of the sprites.

 

(bonus points if you got what's happening just by reading this far!)

 

A 256 coloured sprite demands all palette indices to be loaded exactly as its palette. All the other palettes - whamo, they have to go. In order to display this you'll need to load all palette entries to the ones that are written with the sprite. Otherwise your sprite will look the way it looks on your screenshot.

 

So.... how can you fix this?

 

There are many ways one can go about doing this. I'll cover the one that comes to mind right now. (Anyone have any easier suggestions, please reply to this post). Just make your source graphic file 8 bit, but keep the palette entries of the other sprites intact. Then change the rest to your liking. It's more or less what sh3 suggests. If you use the 3 first 16-col palettes, arrange your source file's palette to contain those and use the rest for your sprite. Then when you import the file as an asset in rb+ you'll get a 256 col palette that you can load and it'll keep every palette entry intact. Of course this limits the available number of colours you'll have for thr 256-colour sprite but you'll have to live with this.

 

Besides, living with limitations and overcoming them is one of the main reasons why people do things on such old computers and consoles!

Edited March 8, 2018 by ggn

[WAVE 1 GAMES]

I think I get what you both are saying. I have a ton of 4 bit sprites each with a CLUT. 0-13 are being used. I can convert some of the smaller 4 bit images to 16 bit to free up 4 color look up tables (16 colors each meaning 64 colors total) and reduce the sprite to 64 colors in paintshop pro and it should display properly?

Edited May 22, 2017 by Jeffrey_Bones

[ggn]

It's all up to you how you arrange your palette. Just note that 64 colours is 6 bits/pixel format and the OP doesn't have something close to this, so you'd have to go 8bit or 4. However if you (like I said above) arrange your palette so the last 64 cols are used for your sprite and then load those at runtime a 8bit image should work fine.

[Songbird]

Protector mostly uses 256-color graphics. Whenever I create new graphics, I simply load the same palette into the new graphic file -- Paint Shop Pro handles this process quite easily. Sometimes I do it before I start the bitmap editing, and sometimes (when importing a graphic) I just let it do a palette optimization so it color matches the best it can. That way, whenever I convert the graphic to the desired Jaguar display format, it can use the correct CLUT values to access the single 256-color palette I have loaded.