Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[SamuraiCrow]

Blitting to the sprites is the most efficient way to do what you want.  Consider the icon paste command for each character.  It will allow you to use more color and takes the same amount of time.

[SamuraiCrow]

Continuing, the way to convert an integer to a string is with the str$ function.  Once it's in a string, you can use the asc function to get each character value and subtract the ASCII code for zero from that to get the icon number assuming your icon bank starts the digits at zero.  This should make multicolor text easy and not slower than the text command since it does something similar internally.

I'd not recommend trying to skip the sprite grab though.

[KevG]

Is it possible to view the score on top of the screen as a 128 wide sprite even if the game at the same time need to show a 64 pixel wide computed 15 colour sprite lower down on the screen at a not interfering line? Or do I have to make the score text on another screen?

The score text I want visible is just in 1 colour. ($EEE).

Hello. Yes it is possible. You can do it with just sprites but you will have to sacrifice a few colours in your 64 pixel wide sprite from 16 colours down to 12. If that is ok then this is one way I would do it.......

Your 128 pixel sprite will take up the maximum width of all 8 sprites. However, if you use computed sprites (>7)  you can position more sprites further down the screen. Note that sprites lose a colour for transparency and you would have to layer 3 colour sprites on top of each other to create the extra colours. Many commercial games use this method. See the Brian The Lion example at Codetappers web site.

for example:

********              = 128 pixels (score board): *=16 pixels )
****                     = 64 pixel wide sprite (but only 6 colours)
       ****              = 64 pixel wide sprite (another 6 colours)

Layer the second 64 pixel wide sprite over the first. Voila! a 12 colour sprite ;-). Note that for your 64 pixel wide sprites there needs to be a common colour with your 128 pixel wide score board but this isn't a problem if your score board is only using one colour anyway (as you stated).

Anyway, that is how I would do it and it would remain fast due to only using sprites rather than bobs/icons.

Hope that helps.

[DJ METUNE]

Thanks very much guys for all your help on this subject! 

It's indeed awesome the fact that it's really possible to show 128 pixel wide sprite at the same time as a 64 pixel wide 12 colour sprite!  I could live with only 12 colors for the 64 pixel wide sprite.

Though I wonder how that trick could apply for me in Amos. Would that require to program a new copperlist from scratch? Or is it possible to just insert the orders to the existing default copperlist?

I had a look at the 'Brian the lion' code that Codetapper showed. But it looks very difficult to understand, at least for such a newbie coder like myself at this point.

How could I tell Amos Pro to merge two 6 colour sprites into one 12 colour sprite? And how do I even get 6 colour sprites to begin with?

[KevG]

Don't worry, you don't have to delve into the murky world of modified copper lists. Just use two 64 pixel wide sprites. You would have to move both of them at the same time to create the illusion of one sprite. If I have some time later on I will write some code for you.

[KevG]

OK, here is something I just knocked up....

Code: [Select]

Screen Open 0,320,200,8,Lowres
Flash off:Hide:cls

Proc Create_64_Pixel_Sprites
'
a$="Your Score Board"
L=Text Length(A$)
If L>128
  Text 0,10,"Ooop! String is too long":end
end if
'
ink 1,3:text 0,10,a$
get bob 1,0,0 to 127,15:cls
Sprite update off: x mouse=220:y mouse=200
Repeat
  Sprite 8,220,50,1:rem score board
  sprite 40, xmouse,y mouse,2 : rem 1st 64 pixel sprite
  sprite 50, xmouse, y mouse,3: rem 2nd 64 pixel sprite
  wait vbl:Sprite Update
until mouse click
'
procedure Create_64_Pixel_Sprites
iterations=30
For n=0 to iterations
  ink 0+rnd(3)
  x=rnd(63):y= rnd(63):h=1+rnd(20):w=1+rnd(20)
bar x,y to x+W,Y+H
next n
get bob 2,0,0 to 63,63
cls
'
For n=0 to iterations
  ink 0+rnd(3)
  x=rnd(63):y= rnd(63):h=1+rnd(20):w=1+rnd(20)
  bar x,y to x+W,Y+H
next n
get bob 3,0,0 to 63,63
cls
end proc


I have done this quick but I have run it and it seems to work OK. Move your mouse around when the program is running.

Its up to you to sort the colours out for your sprites but you should get the idea.

Kev G.

[DJ METUNE]

Thank you very much for the code example Kev G!

That means that I'm able to use the first intended font that is 7 pixels wide.

But what if I want to spread the text out? If I want the 1UP score to the left of the screen and the HIGH SCORE in the middle, and maybe a 2UP score to the right? Could the sprite be split in parts?

In that case if we have such an intention, it requires 6 numbers each for the possible scorenumbers. So that would require 18 cuts. If the font is 7 pixels wide, its 7x18=126 pixels. And except for the big spaces it should also be positioned with one pixel horizontal space between each character to make it look no different than how the font looks when printed normally elsewhere in the game.

[SamuraiCrow]

Keep in mind that the 128-pixel-wide "sprite" is actually 8 sprites of 16 pixels width.  The 1UP would be one sprite, the HIGH SCORE would be six sprites, and the 2UP would be one sprite.  The numbers beneath them should be computed sprite images also so you don't have to redraw and reconvert the labels that don't ever change.  As long as you're not using any of the colors above color 16 from the palette entries, there's nothing stopping you from using 3-color sprites as long as you don't need them more colorful elsewhere on the screen.  Does this help you?

-edit-
To explain better, if you want the colors of the 3 color sprites to be uniform and predictable, you need to set them all to the same 3 colors.  Palette entries 17,21,25 and 29 should be set to the same color.  Palette entries 18,22,26 and 30 should be set to the next color.  Palette entries 19, 23, 27 and 31 should be set to the third color.  This will allow all the sprites to be used interchangeably as the same 3 colors encodings.  If you need 16-color sprites elsewhere, the palette will be jumbled up because of the duplicate colors.

[DJ METUNE]

OK. So that means that the text and numbers also have to deal with 8 different 3 colour palettes?

Will that mean that all 8 sprites must have colour $EEE ?
And 6 of those sprites need to also have the same red colour?   
Does the 12 colour 64 pixel sprite also need to have the 8 different pens of the same white and the 6 of the same red in it's palette? 

If that's true, my only change to free up the 12 pens for the 64 wide sprite(s) is to use the copper to change the line colours of those pens where the scoreboard is visible.

[DJ METUNE]

-edit-
To explain better, if you want the colors of the 3 color sprites to be uniform and predictable, you need to set them all to the same 3 colors.  Palette entries 17,21,25 and 29 should be set to the same color.  Palette entries 18,22,26 and 30 should be set to the next color.  Palette entries 19, 23, 27 and 31 should be set to the third color.  This will allow all the sprites to be used interchangeably as the same 3 colors encodings.  If you need 16-color sprites elsewhere, the palette will be jumbled up because of the duplicate colors.

OK. I read this too late!  I guess that explain my recent question.
This will also change the pens of the 12 colour sprite in other words?

[SamuraiCrow]

Only 4 palettes of 3 colors each.  Sprites 0 and 1 use colors 17, 18 and 19 of the palette registers.  Sprites 2 and 3 use colors 21, 22 and 23.  Sprites 4 and 5 use colors 25, 26 and 27.  Sprites 6 and 7 use colors 29, 30 and 31.  Now do you understand?

Looking at the example picture you attached, you are using one color for 1UP, another color for High Score, and a third color for 2UP.  The numbers for the scores are all white but also all wide enough to need at least 2 sprites a piece, unfortunately.  That may complicate things since you don't have more than 8 sprites horizontally if you tried for 3 sprites each.

[SamuraiCrow]

This will also change the pens of the 12 colour sprite in other words?

Yes.  You'll need to add Copper instructions to do a palette change in between.

[DJ METUNE]

OK. Thank you! Yes. I think I understand now what you're trying to say.

I can only use 16 pixel wide hardware sprites as 16 pixels building blocks for the first line to get out the needed parts of the 1UP HIGH SCORE 2UP. And the rest I can use computed sprites that can be cutted in pieces?

I made a planning here. Attached JPG. But I had to change to HI SCORE instead of HIGH SCORE to make it fit.

[SamuraiCrow]

Not quite...

You will have to drop the trailing zeros for the score also.  Those sprites can't exceed the 8 sprite limit either.

The limit is that you can have only 8 sprites horizontally aligned with each other without hacks.

[DJ METUNE]

Ahh!  OK. Sorry! I wonder where I got that thought from.
I should have known that computed sprites allow only to be freely size adjusted vertically.

Either I skip 2UP and it's score completely or let it only be seen when player 2 is to actually play. The game allows nevertheless not that two playing together.

Then it leaves also enough sprites to have the heading HIGH SCORE again, instead of just HI SCORE.

Or, as you suggest, remove the two zeros at the end of the score. Though I don't really love that idea very much.

Or as the easiest way out. Just let the scoreboard lie above the playing surface, maybe on a separate screen. Then I would also not have to deal with the extra problem with the colours of the 64 wide sprite.