Print

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

[DJ METUNE]

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

[Lonewolf10]

Why not try it using dummy graphics??

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

[DJ METUNE]

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?

[Hungry Horace]

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.

[Lonewolf10]

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

[DJ METUNE]

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

[bruceuncle]

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

[DJ METUNE]

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?

[SamuraiCrow]

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.

[DJ METUNE]

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.

[SamuraiCrow]

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.

[DJ METUNE]

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.

[SamuraiCrow]

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

[DJ METUNE]

That would be very neat! Instead of having to use 15 colour sprites which only actually need one or two colours.

[DJ METUNE]

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?