Fishin' Frenzy COJAG Conversion

[WAVE 1 GAMES]

5 minutes ago, LinkoVitch said:

I'm going to chip in as there seems to be some confusion with what I said and stuff, so just to add in my 2p
 

Fishing frenzy most certainly shouldn't tax the jag at all, punting sprites it can do.  Of course a badly created object list will overly tax the system for what it is drawing on the screen, but even with a simple list with no branches I'd imagine the jag could happily handle fishing Frenzy.

There seems to be some confusion about the "bit" of colours...

 

Now, this is the confusion.. a 1bit, 2bit, 4bit and 8bit image on the jag are all using 16bit colour :).. the 1,2,4, & 8 refer to the size of the colour index into the CLUT (Colour Look-Up Table).  Each entry in the CLUT is 16bit RGB or CRY depending on mode.  The index value of a pixel simply points to which colour in that LUT to use.  So a 1bit image can be 0 or 1, 2bit = 0-3, 4bit =  0-15, and 8bit = 0 - 255.

 

The assets are high quality colour, just the pixel data is stored efficiently.  Plus backgrounds should be somewhat duller and less detailed to avoid making foreground objects difficult to differentiate.

 

 

Not for the graphics, but depending on the complexity you can spam the bus by making too many calls or tie the OP up with too long a list (the whole list is processed every single scan-line, every frame.)

 

If you have a large image using indexed pixels saves a load of RAM and also memory bandwidth.  The OP will like to read it's data in 64bit wide chunks.  1 64bit read is 4x 16bit pixels, 8x 8 bit pixels, 16x 4 bit pixels, 32x 2 bit pixels, and 64 1bit pixels.. so for Jeffs 352 pixel @ 4bit that's 22 reads to read a whole scan-line, vs 176 reads if it were 16bit.  (assuming my dodgy mental maths worked there ).  Of course if the object is smaller than a single read, you are going to waist a chunk of that potential pixel slurping.

 

Whilst this may all sound super ossum, it does have it's own cost, in that an indexed Object has to also do a lookup in the CLUT to find the actual colour to paint, so there is additional overhead there, only slight, but still something to bear in mind.  oh and you are limited to 256 colours in total shared between all those Indexed objects.

 

Sorry Jeff, it won't.. not if it's done correctly.  When you move something on the screen with the OP, it doesn't actually "move" anything.  If you badly build your list, don't make use of branches and a well structured list, or have overly large objects that hang off the sides of the screen, then yeah it's going to struggle and fail.  But it is entirely possible to have a full screen image with many layers of parallax.

 

Sorry if that's a bit all over the place   HTH anyway
 

So to confirm you are saying that all objects should be 16 bit (including those large backgrounds) and there is no need to worry about it taxing performance at all?

 

And may I ask what is the overall benefit of having 2 352x224 bmps as 16 bit assets if they only need 32 colors?

 

Do you not recommend I conserve when possible for overall better performance?

 

I'm actually not picking a fight and arguing with you I am asking for clarity.

 

I just don't see the point of having such a large image be 16 bit if it only requires 32 colors and there is no way that doesnt have a negative impact on performance.

 

I'm talking preventive damage control

[agradeneu]

25 minutes ago, LinkoVitch said:

 

 

The assets are high quality colour, just the pixel data is stored efficiently.  Plus backgrounds should be somewhat duller and less detailed to avoid making foreground objects difficult to differentiate.

 

 

 

Hm, if I understood you right, no to both.

1.

The image quality of 16 bit bitmaps are much higher than indexed 4 bit. It's 2000+ colors vs 16 colors. If you downsample 24 bit photos or high detailed artwork to 16 colors it will look ugly. However you can do nice pixelart with 16 colors. 4 bit bitmaps consume much less data when you store them, that can be handy. 

From my experience, 16 bit color makes a huge difference when you use it effectively. But that needs high quality artwork.

 

2.  An 16 bit background image can use a blur effect to differentiate. Apart from that it depends on artistic direction and choice of colors. There is no need to make a background dull. Just use color contrasts. In fact you have much more possibilities.

Edited August 21, 2020 by agradeneu

[LinkoVitch]

7 minutes ago, WAVE 1 GAMES said:

So to confirm you are saying that all objects should be 16 bit (including those large backgrounds) and there is no need to worry about it taxing performance at all?

 

And may I ask what is the overall benefit of having 2 352x224 bmps as 16 bit assets if they only need 32 colors?

 

Do you not recommend I conserve when possible for overall better performance?

 

I'm actually not picking a fight and arguing with you I am asking for clarity.

 

I just don't see the point of having such a large image be 16 bit if it only requires 32 colors and there is no way that doesnt have a negative impact on performance.

 

I'm talking preventive damage control

Nope, I think you should re-read what I put about the reasons for using indexed objects.  You are absolutely correct you should use indexed object for those types of images, and I never said otherwise.  Save on storage, bandwidth etc, much more efficient.

 

I *DID* say that you *COULD* use those and the jag would be able to handle it, counter to what you put saying it could not.  I don't recommend you do mind, but if done properly the Jag COULD do that.

[LinkoVitch]

6 minutes ago, agradeneu said:

Hm, if I understand correctly what you mean, no to both.

1.

The image quality of 16 bit bitmaps are much higher than index 4 bit. It's 2000+ colors vs 16 colors. If you downsample 24 bit photos or high detailed artwork to 16 colors it will look ugly. However you can do nice pixelart with 16 colors. 4 bit bitmaps consume much less data when you store them, that can be handy. 

From my experience, 16 bit color makes a huge difference when you use it effectively. But that needs high quality artwork.

 

2.  An 16 bit background image can use a blur effect to differentiate. Apart from that it depends on artistic direction and choice of colors. There is no need to make a background dull. Just use color contrasts. In fact you have much more possibilities.

Think we are at cross purposes here and perhaps I haven't understood your meaning.

1) Yes obviously if you are taking a photo and want it to look like a photo, a horribly dithered mess isn't going to cut it.  If you have an image that can be rendered using less than 256 distinct colours and look the part, then that should absolutely use indexed pixels.  There maybe fewer colours, but they are still 16bit.

2) I am no artist :), so yes there are more ways to do things which won't mangle foreground sprites.  Having a more subdued palette in the background works nicely for me (in games where I have seen it).  If there is memory and bandwidth to spare, sure have a 16bit or a 32bit colour background.. but if the background isn't the key focus of the game, might be worth halving the memory/bandwidth footprint and squishing it into 256 or less.  Won't always be possible.

 

It's going to matter precisely on the project and the resources, there is no single right answer.

[WAVE 1 GAMES]

Just now, LinkoVitch said:

Nope, I think you should re-read what I put about the reasons for using indexed objects.  You are absolutely correct you should use indexed object for those types of images, and I never said otherwise.  Save on storage, bandwidth etc, much more efficient.

 

I *DID* say that you *COULD* use those and the jag would be able to handle it, counter to what you put saying it could not.  I don't recommend you do mind, but if done properly the Jag COULD do that.

Ok gotcha. So if one wanted to do this it would be possible if done correctly.

 

With no impact to performance whatsoever?

 

But since there is absolutely no need to do it this way I should use indexed images when possible

 

Thanks.

[agradeneu]

3 minutes ago, LinkoVitch said:

Nope, I think you should re-read what I put about the reasons for using indexed objects.  You are absolutely correct you should use indexed object for those types of images, and I never said otherwise.  Save on storage, bandwidth etc, much more efficient.

 

I *DID* say that you *COULD* use those and the jag would be able to handle it, counter to what you put saying it could not.  I don't recommend you do mind, but if done properly the Jag COULD do that.

It can and it does.

 

16 minutes ago, WAVE 1 GAMES said:

So to confirm you are saying that all objects should be 16 bit (including those large backgrounds) and there is no need to worry about it taxing performance at all?

 

And may I ask what is the overall benefit of having 2 352x224 bmps as 16 bit assets if they only need 32 colors?

 

Do you not recommend I conserve when possible for overall better performance?

 

I'm actually not picking a fight and arguing with you I am asking for clarity.

 

I just don't see the point of having such a large image be 16 bit if it only requires 32 colors and there is no way that doesnt have a negative impact on performance.

 

I'm talking preventive damage control

No need to use 16 bit for low color images. Waste of data. However, if you had images of higher quality....

From my knowledge those background could look a ton better if they were genuine 24 bit quality and then downsampled to 16 bit Jaguar format.

[LinkoVitch]

1 minute ago, agradeneu said:

It can and it does.

 

No need to use 16 bit for low color images. Waste of data. However, if you had images of higher quality....

From my knowledge those background could look a ton better if they were genuine 24 bit quality and then downsampled to 16 bit Jaguar format.

From my own CoJag digging, ATari do like to use 8bit colours.. dunno why, CoJag has more memory, more ROM, more CPU and more bandwidth..

[agradeneu]

3 minutes ago, LinkoVitch said:

Think we are at cross purposes here and perhaps I haven't understood your meaning.

1) Yes obviously if you are taking a photo and want it to look like a photo, a horribly dithered mess isn't going to cut it.  If you have an image that can be rendered using less than 256 distinct colours and look the part, then that should absolutely use indexed pixels.  There maybe fewer colours, but they are still 16bit.

2) I am no artist :), so yes there are more ways to do things which won't mangle foreground sprites.  Having a more subdued palette in the background works nicely for me (in games where I have seen it).  If there is memory and bandwidth to spare, sure have a 16bit or a 32bit colour background.. but if the background isn't the key focus of the game, might be worth halving the memory/bandwidth footprint and squishing it into 256 or less.  Won't always be possible.

 

It's going to matter precisely on the project and the resources, there is no single right answer.

Not only photos, e.g. the painting style of Raymans artwork was done in 24 bit (at least) and it would look terrible if downsampled to 16 colors. The 256 color CLUT is a limiting factor, so I guess they had to use a mix of 16 bit and 8 bit to achieve the fidelity of the graphics. 

[agradeneu]

4 minutes ago, LinkoVitch said:

From my own CoJag digging, ATari do like to use 8bit colours.. dunno why, CoJag has more memory, more ROM, more CPU and more bandwidth..

I got confirmation that "Native" artwork is 16 bit throughout, and the lowest quality assets some 8 bit sprites where it uses the CLUT.

I suspect Rayman uses 16 bit graphics as well, in combination with 8 bit.

Then there is "Gravitic Mines", the game I'm working on with CJ, where scrolling backgrounds and sprites are 16 bit, and the level overlay 8 bit (because it's 1024x900 pixels big), we are still running at 60 FPS.

[LinkoVitch]

1 minute ago, agradeneu said:

Not only photos, e.g. the painting style of Raymans artwork was done in 24 bit (at least) and it would look terrible if downsampled to 16 colors. The 256 color CLUT is a limiting factor, so I guess they had to use a mix of 16 bit and 8 bit to achieve the fidelity of the graphics. 

I don't know why you are fixating on 16 colour TBH, that is just one of the options.  Personally I'd go for 16bit 1st unless it was blatantly unnecessary, and scale back as issues arise. 

I'd not be surprised if the large static background on Rayman was 8bit, it has a fairly subdued colour scheme, possibly less than all 256 freeing up some of the palette for the text etc.  I am speculating I've not tried pulling the ROM apart yet

[agradeneu]

12 minutes ago, LinkoVitch said:

I don't know why you are fixating on 16 colour TBH, that is just one of the options.  Personally I'd go for 16bit 1st unless it was blatantly unnecessary, and scale back as issues arise. 

I'd not be surprised if the large static background on Rayman was 8bit, it has a fairly subdued colour scheme, possibly less than all 256 freeing up some of the palette for the text etc.  I am speculating I've not tried pulling the ROM apart yet

That is exactly my point, actually.

As for Rayman, the background could be 8 bit, but then it needs to use up a lot colors of the CLUT, because it's quite detailed. That means you really can't use the 256 color CLUT for all graphics (background, layers, sprites) without sacrificing quality. As smooth as Rayman looks, I'm almost sure  it uses 16 bit assets for the sprites and tiles. 

And if it was 8 bit throughout, KUDOS to the artists to achieve such an impressive result! 

 

Edited August 21, 2020 by agradeneu

[WAVE 1 GAMES]

14 minutes ago, LinkoVitch said:

unless it was blatantly unnecessary, and scale back as issues arise.

And that was exactly my point.

[+atari2600land]

Are you confusing 16-bit with 16 colors? Something with 16 colors is 4-bit, which would be how I would do the fish if I was doing it.

[WAVE 1 GAMES]

25 minutes ago, agradeneu said:

That is exactly my point, actually.

As for Rayman, the background could be 8 bit, but then it needs to use up a lot colors of the CLUT, because it's quite detailed. That means you really can't use the 256 color CLUT for all graphics (background, layers, sprites) without sacrificing quality. As smooth as Rayman looks, I'm almost sure  it uses 16 bit assets for the sprites and tiles. 

And if it was 8 bit throughout, KUDOS to the artists to achieve such an impressive result! 

 

It's obvious to me that you hold Rayman in high regard, which you should but does it not occur or seem more reasonable to you that all of the sprites/game objects and the foreground layers (ie the platforms) are all 16 bit and every single one of the background layers are sharing a 256 CLUT? Maybe it's my lack of a "professional eye" but to me eyeballing it, It's kind of obvious that's how its done. I could be wrong, mind you I COULD BE WRONG. But visually to me that is what I see. Especially given how dull (maybe not the right word) the colors of the actual backgrounds are. It also makes a lot more sense to do it that way vs everything being 16 bit. It is a cartoon style of graphics and in most cartoons the background uses duller colors so the foreground stuff is the focus point

Edited August 21, 2020 by WAVE 1 GAMES
added Rayman screenshot for reference

[WAVE 1 GAMES]

6 minutes ago, atari2600land said:

Are you confusing 16-bit with 16 colors? Something with 16 colors is 4-bit, which would be how I would do the fish if I was doing it.

Is this question for me or somebody else?

 

The fish are all 16 bit. Not 16 colors. You only get 16 different CLUTs for 4 bit graphics and there are way more than 16 type of fish in Fishin Frenzy. So using 4 bit for the fish doesn't make a whole lot of sense. Could be done yes and some of them would probably not look any different at all. Others would though, and then you would eventually run out of pallettes.

[agradeneu]

43 minutes ago, LinkoVitch said:

 

 

 

8 minutes ago, WAVE 1 GAMES said:

It's obvious to me that you hold Rayman in high regard, which you should but does it not occur or seem more reasonable to you that all of the sprites/game objects and the foreground layers (ie the platforms) are all 16 bit and every single one of the background layers are sharing a 256 CLUT? Maybe it's my lack of a "professional eye" but to me eyeballing it, It's kind of obvious that's how its done. I could be wrong, mind you I COULD BE WRONG. But visually to me that is what I see. Especially given how dull (maybe not the right word) the colors of the actual backgrounds are. It also makes a lot more sense to do it that way vs everything being 16 bit. It is a cartoon style of graphics and in most cartoons the background uses duller colors so the foreground stuff is the focus point

 

I just wrote that, if you care to read again. So you are 100% correct on Rayman, but it contradicts all the BS you claimed/boasted about your game "taxing" the Jaguar.

 So you might have a professional eye for Rayman, but regarding your own game, you are acting like a blind amateur. 

 

 

 

Edited August 21, 2020 by agradeneu

[+atari2600land]

Is my assumption of the Jaguar only being able to show 256 colors at a time correct? Having 16 CLUTS available, with each CLUT being able to have 16 colors in it, with 16x16=256. If this is true, then how can one object be 16-bit, using up the 256 colors, and then have more objects using different colors?

[LinkoVitch]

5 minutes ago, atari2600land said:

Is my assumption of the Jaguar only being able to show 256 colors at a time correct? Having 16 CLUTS available, with each CLUT being able to have 16 colors in it, with 16x16=256. If this is true, then how can one object be 16-bit, using up the 256 colors, and then have more objects using different colors?

Your assumption is wrong, the Jag can display 24bit true colour images, 16/15bit RGB, 16 bit CRY, as well as 256x 16bit colours on screen at the same time.

[+atari2600land]

So does that mean a CLUT can have up to 256 colors in it? If that's the case, then how does someone using Raptor Basic achieve this? In my programming with it, it seems like a CLUT can only have 16 colors in it.

[LinkoVitch]

1 minute ago, atari2600land said:

So does that mean a CLUT can have up to 256 colors in it? If that's the case, then how does someone using Raptor Basic achieve this? In my programming with it, it seems like a CLUT can only have 16 colors in it.

Yes the CLUT can only have 256 colours in it.  Don't use an indexed bitmap object, use a 16bit or 32 bit object.  The CLUT isn't used if the colour data is stored directly in the pixel data.  Might be worth asking this question in the RB programming section, I have never used Raptor Basic

[WAVE 1 GAMES]

29 minutes ago, agradeneu said:

 

 

 

I just wrote that, if you care to read again. So you are 100% correct on Rayman, but it contradicts all the BS you claimed/boasted about your game "taxing" the Jaguar.

 So you might have an professional eye for Rayman, but regarding your own game, you are acting like a blind amateur. 

 

 

 

I never bragged or said my game was taxing the Jaguar. What I said was I AM NOT using 16 bit backgrounds and foregrounds because I know that it WILL tax the Jaguar. How do I know this?  Because of course I already tried it AND IT DID. Then I said to myself why the hell am I making this a 16 bit graphic if the source is 256? Then after looking at what colors from the 256 color pallette the image is actually using I find that it is only 32 colors so silly me for thinking only using those 32 colors would give a boost in performance.... Which it did...  (Cuts back accordingly) At what point was I bragging or boasting????

 

I never once said my game was taxing the Jaguar. The only thing I said is I didn't want it to. I did say if those backgrounds were 16 bit (which they are not and dont need to be) that it WOULD tax the bus. And I still say it does. You can step around it all you want and say "not if you do it the right way" or "but what if you do this" IT USES MORE BANDWIDTH. Do you deny that a 352X224 16 bit image uses more bandwidth than a 352X224 4 bit image? Or a 352X224 8 bit image? Surely you are joking if you honestly believe that. and in this particular case it's ridiculous to even talk about it. What is the problem? There isn't one as I already have my solution. You keep going on and on about you did this and other people did that but why? 

 

Why do you insist on insulting me and challenging me? I don't get it we are practically saying the same exact things but you just keep going and going.

 

Did you have an interest in making Fishin Frenzy? Did I somehow steal your thunder by starting the project? Are you just not happy with the overall visual quality/progress of the game from the video I posted? Do you want me to turn the game over to your more "professional" hands?

 

What the hell do you want? I don't get it

Edited August 21, 2020 by WAVE 1 GAMES

[WAVE 1 GAMES]

4 minutes ago, atari2600land said:

So does that mean a CLUT can have up to 256 colors in it? If that's the case, then how does someone using Raptor Basic achieve this? In my programming with it, it seems like a CLUT can only have 16 colors in it.

When you want to use an 8 bit image you are using all 256 colors from an 8 bit pallette. So you don't designate the cluts to 16 individual 4 bit images. You set it to 0 and use an 8 bit image. This lets you use all 256 colors but if you want to use a 4 bit image you still can but it will need to pull from that same 256 color image you chose. (Like fishin frenzy arcade does with the text)

When you set up your object in the object list change the color mode to 8 bit and for CLUT put no_CLUT. I think you can also put 0 but I might be wrong.

 

4 bit objects work the same way when using a 256 CLUT but you definitely have to set the CLUT to 0 here in the object list

 

There is a tutorial page for this in the RB+ subforum. ggn does a fantastic job explaining this stuff

[+CyranoJ]

Three pages later and we still don't know what you think "32 Color spliced gfx mode" is supposed to mean.

 

 

[+Sauron]

1 hour ago, agradeneu said:

I just wrote that, if you care to read again. So you are 100% correct on Rayman, but it contradicts all the BS you claimed/boasted about your game "taxing" the Jaguar.

 So you might have a professional eye for Rayman, but regarding your own game, you are acting like a blind amateur. 

 

Just my own 2 cents here, but I don't think Jeff was "boasting" about "taxing" the Jag. He was stating that in his experience, using those color depths caused the Jag to struggle. To me, this makes perfect sense, as 1) Jeff is using rB+, not coding in asm, and 2) he's obviously not an expert coder who knows all of the tricks for maximizing performance. Despite whatever dumb stuff he's said in the past, I don't see anything he said here as trying to big himself up. Cut him a bit of slack.

 

 

[agradeneu]

1 hour ago, Sauron said:

Just my own 2 cents here, but I don't think Jeff was "boasting" about "taxing" the Jag. He was stating that in his experience, using those color depths caused the Jag to struggle. To me, this makes perfect sense, as 1) Jeff is using rB+, not coding in asm, and 2) he's obviously not an expert coder who knows all of the tricks for maximizing performance. Despite whatever dumb stuff he's said in the past, I don't see anything he said here as trying to big himself up. Cut him a bit of slack.

 

 

Well, despite this fact, he insisted on "that no coder could do better than him".  I think I understood the message very well.