Print

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

[Xertese]

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.

[SamuraiCrow]

@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]

@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

[DJ METUNE]

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.

[SamuraiCrow]

You can write a Copper list from scratch but it is hard.

[Xertese]

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.

[DJ METUNE]

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?

[Lonewolf10]

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??

[SamuraiCrow]

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.

[DJ METUNE]

OK. But does the whole copperlist need to be rewritten just for the extra sprite, or would only copper commands be sufficient?

[SamuraiCrow]

The whole Copper list needs to be recreated.  What other Copper effects are in use?  Rainbows?  Split screen?

[SamuraiCrow]

http://www.ultimateamiga.co.uk/HostedProjects/AMOSFactory/AMOSProManual/14/1442.html is what you can read.

[DJ METUNE]

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

[SamuraiCrow]

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?

[DJ METUNE]

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?