Ultimate Amiga
Network Boards => AMOS Factory => AMOS Language Discussion => Topic started by: DJ METUNE on March 20, 2015, 08:13:31 PM
-
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).
-
Why not try it using dummy graphics?? :D
It's not something I have tried in AMOS before, but it should be possible (as long as your other sprite stays atleast 2 lines below the score - a minimum of 1 horizontal blank line between sprites).
-
Thanx for answering! :-) OK. Cool! But what do you mean with dummy graphics?
Codetapper wrote about the score text in Parasol Stars used only one sprite!!! That's an impossible mission in Amos, or?
I'm hoping to use the printfont I made in the Amos fonteditor for the score. But maybe I would be better off making the needed characters that are mostly numbers as individual sprite images?
-
i think the trick of this is to 'draw' the score on a hiddne page, then use GET SPRITE to grab it before displaying it on the screen?
I was probably going to try something like this myself for lapcounter or simialr, if i revert back to BOBs for my main sprites.
-
Thanx for answering! :-) OK. Cool! But what do you mean with dummy graphics?
Just use any text for the score and rough graphics for your sprites lower down.
Once you know it works, you can put the actual score in instead of the dummy text and draw the real graphics ready to replace the rough graphics for the sprites lower down.
There is nothing worse than spending ages drawing graphics, only to find that you can't use them.
Codetapper wrote about the score text in Parasol Stars used only one sprite!!! That's an impossible mission in Amos, or?
In assembler it's a case of manually reloading the appropriate sprite data (SPRxDAT) register/s every 16 pixels, by using a copperlist.
In AMOS try Hungry Horaces suggestion of drawing it elsewhere (e.g. hidden screen) and using GET SPRITE to grab it. AMOS will probably be able to do the trick I mentioned above ;)
I'm hoping to use the printfont I made in the Amos fonteditor for the score. But maybe I would be better off making the needed characters that are mostly numbers as individual sprite images?
Use them as sprites!
Simply print the needed characters (in this case just the numerics) onto a hidden screen. Grab them as sprites using GET SPRITE and you should be ok :)
-
Thank you for the suggestions! OK. I will try the method of get sprite from a hidden screen. Using dummy graphics at first to be on the safety side.
I see that many old games on Amiga placed the score outside of the main playscreen. As seen in Rainbow Islands for an example. Even though that was made in assembler I assume.
http://gamesdbase.com/Media/SYSTEM/Commodore_Amiga/Snap/big/Rainbow_Islands_-_1990_-_Ocean_Software_Ltd..jpg
-
I see that many old games on Amiga placed the score outside of the main playscreen. As seen in Rainbow Islands for an example. Even though that was made in assembler I assume.
Don't forget that with AMOS you can easily add an extra screen to hold the scores and any other stats. If you make it just, say 10 pixels high, you can use the default Topaz.font in 8 point for easy updating. Or something more fancy depending on how far you want to go. The great thing with a separate screen is that it's easy in AMOS to slide it gracefully up and down over your game screen(s). So eg. you might keep it out of view until the user presses a certain key which slides it neatly into view. Then the same key to make it slide back out of view again. Or make it appear when certain thing happen, etc. depending on your game. If the data you need to display suits it, and you're tight on chip ram, the short screen can be a simple two-colour or four-colour one. That still allows for it to be 'decorative'. And if you use Locate and a semi-colon when printing the text, your background graphics won't be disturbed (except where the actual text is, of course :) ).
-
Yes. I've been thinking about using a second screen for the score text/numbers. That would look nice as well. Though I will go for the transparent sprite overlay mode anyway, as seen in most arcade games. That will make the actual playing screen 16 pixels bigger vertically.
I've seen now that it looks after all like it's forbidden to use hardware sprites at the same time as computed 15 colored sprites even though they are placed on separate lines. So I will not be able to view 128 pixels of text (as hardware sprites) at the same time as viewing a 64 wide 15 colored computed sprite.
My plan B now is that by making a new slightly thinner font, I will have the whole text and numbers anyway but only eating up less than the maximum of 64 pixels in wideness.
This is going to work if I grab every rendered character from a hidden screen as separate sprite images WITHOUT the one pixel space between. Only the actual graphics of the characters that is.
Then I just have to figure out a way to get this into some kind of routine. So just after the player happens to get an added number to the score, the sprite grab and paste routine needs to be called. Or if I can make that into the same routine.
Does anyone know how such a code would best be written optimally?
-
Yes. I've been thinking about using a second screen for the score text/numbers. That would look nice as well. Though I will go for the transparent sprite overlay mode anyway, as seen in most arcade games. That will make the actual playing screen 16 pixels bigger vertically.
I've seen now that it looks after all like it's forbidden to use hardware sprites at the same time as computed 15 colored sprites even though they are placed on separate lines. So I will not be able to view 128 pixels of text (as hardware sprites) at the same time as viewing a 64 wide 15 colored computed sprite.
My plan B now is that by making a new slightly thinner font, I will have the whole text and numbers anyway but only eating up less than the maximum of 64 pixels in wideness.
This is going to work if I grab every rendered character from a hidden screen as separate sprite images WITHOUT the one pixel space between. Only the actual graphics of the characters that is.
Then I just have to figure out a way to get this into some kind of routine. So just after the player happens to get an added number to the score, the sprite grab and paste routine needs to be called. Or if I can make that into the same routine.
Does anyone know how such a code would best be written optimally?
The double blit would be unavoidable but since the transparency would be supplied by the sprites, you could use icon paste instead of bob paste and make up the difference.
-
How could I get sprite icons to work as numbers? I mean if I make 10 small icons with the needed numbers 0 to 9. How should I call them up to make them respond to addition, as if it was normal print font? The player has 0 points to begin with and get 100 points after killing a monster. The Amiga may need to show up to 12 of those 5 pixel wide icons at the same time on screen on the same line. It's 60 pixels together so it's 4 possible pixels left. 6 icons for the players score and 6 icons for the current high score that may also need to be updated to follow the players current score if he/she happen to beat it.
-
If you're only blitting a single bitplane image then the sprites will be very little help. Just grab a bob image or use the Screen Copy command with a custom minterm to blit the single bitplane image generated by blitting the numbers to a hidden screen. As inefficient as it sounds, it probably won't be much slower than blitting a hidden image to sprite buffers. The sprite DMA contents in Amos are always blitted to sprite buffers anyway. It's not quite like a C64 sprite where you can just jam a new index into a register and the new image will automatically appear at fetch time.
-
OK. That's very interesting what you say about blitting just a single bitplane.
Can you please give an example of such code?
Though one problem is that I'm using dual playfields and I have no colours left to show the white numbers, nor the yellow 1UP and the red HIGH SCORE that's 8 pixels above the numbers. And I can't change the colors with the copper as other graphics that using all the same pens also occupies that area at different times in the game.
-
Since you are using the sprites as a "third" playfield, there is really no way to whittle it down to one bitplane without consequences. One thing you might consider though, is making the 1UP and HIGH SCORE separate sprite images themselves if they never change or blink independently of the numbers.
What I was originally referring to is blitting only the unaffected bitplanes to the sprite, for example if only the first two bitplanes of the sprite image contain non-zero data, don't blit the other two since they will always be zero anyway. Unfortunately, AmosPro doesn't allow for such optimizations presently, and I can't think of a way to wrap a Bitmap structure around sprite images so the BlitBitMapRastPort function in Graphics.library can be used and still have AmosPro's sprite system recognize them. (The idea was to use the planes-pick parameter to select which bitplanes to blit using a Gfx Call command.)
-
That would be very neat! Instead of having to use 15 colour sprites which only actually need one or two colours.
-
But it seems 16 colour sprites is the only choice I have left if I must have it visible on the playscreen. 1UP and HIGH SCORE is static. No change. No blinking 1UP either as in Rainbow Islands as an example again.
I wonder if it going to be so much blit work anyway as the numbers change only in hundreds (100) at a time. Its always two zeros in the end. That alone could also be made static.
But the idea I had/have is either that I copy all but the last two zeroes whenever it's a chance in the numbers. All, because I can't figure a way to know which numbers I need to convert to sprites.
The other thought is to have all numbers as premade sprites and make them print the numbers instead of using normal print text and grab them all the time. I just don't know how I could make such thing work.
But I guess it could work. Perhaps similar to bitmapped fonts in typical scrolltexts that we all seen in a lot of demos and intros. They somehow wrote a text and assigned the text to use graphics instead of normal font characters. The same method could as well be used with sprite icons?
-
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.
-
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.
-
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.
-
Thanks very much guys for all your help on this subject! :D
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?
-
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.
-
OK, here is something I just knocked up....
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.
-
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.
-
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.
-
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? :o
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.
-
-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?
-
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.
-
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.
-
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.
-
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.
-
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.
-
Feel i need to comment here and you're goung about this the wrong way
You could find a font you like load it into amos then update scores on a hidden screen simply by printing them then grabbing the area they're printed on as a block then paste that block onto the screen area a very quick way to have what you want you could even design your own font in WB and use that it will eliminate a lot of headache.
-
@Xertese
He originally wanted the scores and highscore to overlap the game screen with transparency. That's why he was reluctant to use a separate screen. I think you're right though, using sprites as a big screen are too fiddly on ECS or OCS. AGA has much wider sprites but not supported by AmosPro.
-
@Xertese
He originally wanted the scores and highscore to overlap the game screen with transparency. That's why he was reluctant to use a separate screen. I think you're right though, using sprites as a big screen are too fiddly on ECS or OCS. AGA has much wider sprites but not supported by AmosPro.
He will still have the transparency using blocks just needs to use the right colours from the same game screen palette
-
Thanx Xertese for your proposal. I could do that if that area would be free from the background graphics that I would like to have the scoreboard on top of. The problem is that the background use all possible pens and every one of the pens is in that area many times.
And I can't just recolor those lines with help of the copper because then the background that using those pens and is visible in that area now and then would also be affected.
It's a horizontal (mainly) scrolling platform game using dual playfields.
So my only hope was to use sprites because they use a separate palette, plus it could just so lightly float on top of everything undisturbed.
But they're too thin for making the scoreboard fully visible.
Though it could be done if there would be some way in Amos Pro to reuse the same sprite(s) on the same line, as in Parasol Stars for instance.
-
You can write a Copper list from scratch but it is hard.
-
Thanx Xertese for your proposal. I could do that if that area would be free from the background graphics that I would like to have the scoreboard on top of. The problem is that the background use all possible pens and every one of the pens is in that area many times.
And I can't just recolor those lines with help of the copper because then the background that using those pens and is visible in that area now and then would also be affected.
It's a horizontal (mainly) scrolling platform game using dual playfields.
So my only hope was to use sprites because they use a separate palette, plus it could just so lightly float on top of everything undisturbed.
But they're too thin for making the scoreboard fully visible.
Though it could be done if there would be some way in Amos Pro to reuse the same sprite(s) on the same line, as in Parasol Stars for instance.
Ah now i understand fair enough.
-
You can write a Copper list from scratch but it is hard.
Yes! The only problem is that I don't know how.
It could be easier if it was a way to inject the needed istructions in the allready existing copperlist of Amos Pro, or having a copy of that copperlist that one could just modify slightly and then just replace.
Could such a sprite trick be coded by some hardcore Assembler genius as an Amos Pro extension?
-
You can write a Copper list from scratch but it is hard.
Yes! The only problem is that I don't know how.
It could be easier if it was a way to inject the needed istructions in the allready existing copperlist of Amos Pro, or having a copy of that copperlist that one could just modify slightly and then just replace.
Could such a sprite trick be coded by some hardcore Assembler genius as an Amos Pro extension?
Sadly, I don't think it's really doable within AMOS, or AMOS Pro :(
The copperlist that it uses is dynamically changed on a regular basis (every VBL?) in order to do sprite tricks (e.g. more than 8 sprites, which is the normal hardware limit) and other AMOS related things.
Yes, you could probably copy AMOS's copperlist (though I don't recall finding how to get AMOS's own copperlist in the past) and create your own.
However, in doing so you disable all of AMOS's graphical functions! :(
Maybe if there is an internal pointer to the AMOS copperlist, you could copy it and create your own in an AMOS bank and then point to it??
But there is no guarantee that the AMOS graphical functions would continue to work.
Anyone have any other thoughts on this??
-
You can write a Copper list from scratch but it is hard.
Yes! The only problem is that I don't know how.
It could be easier if it was a way to inject the needed istructions in the allready existing copperlist of Amos Pro, or having a copy of that copperlist that one could just modify slightly and then just replace.
Could such a sprite trick be coded by some hardcore Assembler genius as an Amos Pro extension?
Sadly, I don't think it's really doable within AMOS, or AMOS Pro :(
The copperlist that it uses is dynamically changed on a regular basis (every VBL?) in order to do sprite tricks (e.g. more than 8 sprites, which is the normal hardware limit) and other AMOS related things.
Yes, you could probably copy AMOS's copperlist (though I don't recall finding how to get AMOS's own copperlist in the past) and create your own.
However, in doing so you disable all of AMOS's graphical functions! :(
Maybe if there is an internal pointer to the AMOS copperlist, you could copy it and create your own in an AMOS bank and then point to it??
But there is no guarantee that the AMOS graphical functions would continue to work.
Anyone have any other thoughts on this??
First off the AmosPro manual has an appendix on Copper commands that tells how to do it manually, and second off the computed sprite capability is built-in to the sprite DMA, and lastly all that'd be needed to make a ninth sprite is to wait until the zero sprite of 1up has displayed its pixels, move it right to the 2up zero sprite position, wait until the sprite has been displayed again, then move it back for the display of the next row of pixels, and repeat the wait-and-move process until all of the rows of pixels have been displayed.
-
OK. But does the whole copperlist need to be rewritten just for the extra sprite, or would only copper commands be sufficient?
-
The whole Copper list needs to be recreated. What other Copper effects are in use? Rainbows? Split screen?
-
http://www.ultimateamiga.com/HostedProjects/AMOSFactory/AMOSProManual/14/1442.html (http://www.ultimateamiga.com/HostedProjects/AMOSFactory/AMOSProManual/14/1442.html) is what you can read.
-
Heavy use of rainbow effects, because there is otherwise no usable colours for anything else but the background, because it's in dual playfield. I have to share the front background layer with the enemy's and bullets etc. The main character use the 64 wide sprite, including his weapon(s).
-
If you can get the game working without the zeros, I can help you with the custom Copper lists later. How far do you want to go with this?
-
If you can get the game working without the zeros, I can help you with the custom Copper lists later. How far do you want to go with this?
Thanx a million SamuraiCrow! I would like to try to do the best I can, or not really can do at the moment. I'm sure it'll be a project with lots of learning on it's way of the progress. Probably I'll come up with even more questions here.
Is it best that I leave for later all the trailing two zeroes of the three different scores in the scoretable blank, or should / could I only leave blank the last two zeroes of the 2UP's score?
-
If you want to publish the game, I would leave them all off in case you don't get back to it. Makes sense?
-
Yes, that's a sense thought. Or else I could just let the game be for one player to begin with.
-
Sure! If you were planning on doing 2-player alternating instead of 2-player simultaneous, that would make even more sense! Just dropping the second player would be the sensible solution.
-
Yeah, I think that would probably be the best. The 2-player option could wait until I'll got the main parts of the thing working together satisfyingly.
It's not a simultaneous 2-player type of game so it may not even gonna feel like that option is even missing very much.
-
Agreed.