|
Post by steveinscotland on Mar 16, 2017 14:55:51 GMT
i understand how sprites default colours are set. They're all the same colour, at least initially.
lets say my background is black with white sprites.
i have an up/down sprite and a player sprite.
if I change the colour of the up/down sprite using the SPRITEINK command, its colour does change but so does the column underneath it. As if a coloured beam of light was shining downwards.
if my player sprite walks under the up/down spritehile it's up, the player sprite changes colour, to the colour of the up/down sprite. Once the player leaves the area under the up/down sprite it goes back to its normal colour.
what am I doing wrong?
Or can you not colour sprites?
|
|
|
Post by alessandro on Mar 16, 2017 19:08:25 GMT
You must understand how SPRITEINK works. As per the manual,
If the sprite passes in front of a background tile, set the INK of that tile to white, otherwise it will take the passing sprite's colour.
|
|
|
Post by andrewvanbeck on Mar 17, 2017 8:58:46 GMT
Sometimes its good to check a sprites block collisions before using spriteink, it can help avoid attribute changes on blocks.... like
IF CUSTOM ELSE IF DEADLY ELSE IF LADDERABOVE ELSE IF LADDERBELOW ELSE IF WATER ELSE SPRITEINK 5 ENDIF ENDIF ENDIF ENDIF ENDIF
This way, it won't recolour blocks if they aren't solid, so you could use CUSTOM block types for backdrops that the sprite can walk through. That stack of IF statements only really needs to cover the blocks that you're using, like CUSTOM - you can also quite easily colour a DEADLY block as red with this, like SPRITEINK 2 : KILL when the player hits a deadly block. I always hope that Jonathan will add more CUSTOM block types, like CUSTOMA and CUSTOMB etc - would really help us avoid colour issues I think and more... especially now that PUTBLOCK should be behaving a lot better - I mean collectable blocks for example, like Pac Man style games.
|
|
|
Post by alessandro on Mar 19, 2017 9:31:27 GMT
Sometimes its good to check a sprites block collisions before using spriteink, it can help avoid attribute changes on blocks... This way, it won't recolour blocks if they aren't solid, so you could use CUSTOM block types for backdrops that the sprite can walk through. It won't work. See what happens when the following code IF CUSTOM ELSE SPRITEINK 2 ENDIF is applied to the red sprite and the pass-through blocks (clouds, palm trunk etc.) are defined as custom with white ink: Placing the above code at the beginning or at the end of the sprite event yields the same result.
|
|
|
Post by gabriele1969 on May 9, 2017 17:57:16 GMT
Sometimes its good to check a sprites block collisions before using spriteink, it can help avoid attribute changes on blocks... This way, it won't recolour blocks if they aren't solid, so you could use CUSTOM block types for backdrops that the sprite can walk through. It won't work. See what happens when the following code IF CUSTOM ELSE SPRITEINK 2 ENDIF is applied to the red sprite and the pass-through blocks (clouds, palm trunk etc.) are defined as custom with white ink: Placing the above code at the beginning or at the end of the sprite event yields the same result. You need to sorround your custom blocks with extra custom blocks because sprite collision with a block is checked only at a specific coordinate (a specific pizel in your sprite). So your sprite may collide with the block (and colour it) before sprite collision with the block is detected. ...or at least i think that is what happens...
|
|
|
Post by alessandro on May 10, 2017 11:17:50 GMT
Hi Gab, that would be theoretically possible, I believe, but practically it would be too much of a fuss and lead to longer code and waste of precious memory. It is much easier and simpler to do as Jonathan himself suggests in the manual.
|
|
|
Post by fadgeplaysgames on Dec 27, 2017 22:56:34 GMT
You must understand how SPRITEINK works. As per the manual, If the sprite passes in front of a background tile, set the INK of that tile to white, otherwise it will take the passing sprite's colour. Hi, Ive been looking through the forum for a solution to this because it seems like Im doing what the manual suggests (resetting the spriteink at the beginning of the event to the same as the ink of the background block) but it doesnt seem to work. The background block still takes up the colour of the passing sprite, even if the spriteink at the start of the event is set to the same as the blocks ink colour. I wonder if someone can post an example of their sprite event code as an example so I can look over it and maybe figure out what Im doing wrong?
|
|
|
Post by alessandro on Dec 31, 2017 23:39:26 GMT
Happy New Year At the beginning of the sprite event, put a SPRITEINK command followed by the INK value of the background. E.g. if it is white, then use SPRITEINK 7. At the end, put another SPRITEINK command, this time with the sprite colour value, e.g. if it is red, SPRITEINK 2. The sprite event code must look like this: SPRITEINK 7 ... SPRITEINK 2
|
|
|
Post by quickie on Feb 16, 2018 16:58:24 GMT
Happy New Year At the beginning of the sprite event, put a SPRITEINK command followed by the INK value of the background. E.g. if it is white, then use SPRITEINK 7. At the end, put another SPRITEINK command, this time with the sprite colour value, e.g. if it is red, SPRITEINK 2. The sprite event code must look like this: SPRITEINK 7 ... SPRITEINK 2 Hi Alessandro, Sorry, I tried as you suggested but does not work as expected. See the following code: SPRITEINK 8FALL IF KEY 0 IF Y > 240 SCREENRIGHT LET Y = 8 EXIT ELSE IF CANGORIGHT LET IMAGE = 0 ANIMATE SPRITERIGHT ENDIF ENDIF ENDIF IF KEY 1 IF Y <= 8 SCREENLEFT LET Y = 240 EXIT ELSE IF CANGOLEFT LET IMAGE = 1 ANIMATE SPRITERLEFT ENDIF ENDIF ENDIF IF KEY 3 JUMP
ENDIF IF DEADLY KILL
ENDIF SPRITEINK 6The background is black with yellow sprites. Typing this piece of code on the sprite events produces an inked yellow player, but trails a yellow background when clashing with empty blocks with coloured ink. Here is the example:
|
|
|
Post by alessandro on Feb 16, 2018 19:14:29 GMT
Hi Quickie, why SPRITEINK 8 ? This is not a valid colour code, unless you select SPRITEINK mask 71 in Miscellaneous (I would not advice you to do so though). colour codes follow the normal Spectrum convention, ranging from 0 = black to 7 = white. If your background has yellow INK and black PAPER, and you would like a different INK for your sprite, the value for the first SPRITEINK must range from 1 to 5. If you just want to keep it yellow, do not add the SPRITEINK commands. P.S. I cannot see the image you posted. There is an error code in its place. P.P.S. Also remove that FALL from the beginning of the script. See here why.
|
|
|
Post by quickie on Feb 17, 2018 7:33:14 GMT
Hi Alessandro, First of all thank you for the swift reply I've ammended the gif link as it seems that it was hosted temporary and moved it to my personal storage. Now you should be able to see it. I've done two changes on the sprite code, as suggested. First one: moved the fall command as per your advise. Works fine. Second: Changed the ink colours: SPRITEINK 0 ... SPRITEINK 6 So, this should fit the Spectrum colour convention, however the result is exactly the same as the gif above. P.S.: The idea is to create this as a 2P game, so, perhaps 1P would be yellow, but I should be able to handle the spriteink commands for 2P. Cheers!
|
|
|
Post by alessandro on Feb 17, 2018 10:23:55 GMT
Now I understand it better You are using platform and empty space blocks holding a different INK value from that of your player sprite (or any other sprite). When the sprite passes through the blocks, their INK value will be substituted by that of the sprite. There is no workaround for this, unfortunately. The only thing you can do is either let your player sprite take the INK colour of whatever it passes through, by eliminating any SPRITEINK command in its script, and also make those blue dot blocks in the backgrounds yellow as well (or eliminate them altogether), for the same reason, or have the platform blocks all set to the same INK value of the background. One of my latest releases, Apulija-13 V2.01, handles colours this way, although it is a maze game viewed from above, not a platform like yours - nice graphics I must say! . Please have a look at it and see how I managed to avoid colour 'bleeding'. On a side note, 2-player games in AGD are theoretically possible, but you would face many inconvenients, such as being pretty much unable to use specific variables like LIVES, SCORE etc. because they would only refer to the first player, and the impossibility of assigning more than three keys to each player, since you may only define a maximum of 7 keys. And the colour limitations would force you to create two different player sprites of the same colour, rather than reusing the same sprite with a different colour. If I never made 2-player games with AGD, there is a reason
|
|
|
Post by quickie on Feb 17, 2018 12:10:48 GMT
Ciao Alessandro! That's it, a colour clash of a block INK with an object sprite INK. Initially I did not force the ink colour and this proves to work as expected, however I loose the ability to create another character for 2P avoiding colour confussion of who is who. Funny thing is that meanwhile I was creating the scenario and doing the usual try/catch tests I could check that the player's sprites sometimes where blue, others cyan and without any spriteink command. Also, they were consistent and did not leave a coloured trail as the current spriteink command does... so isn't there any way to set that initial value? (perhaps poking or with some ASM routine?). Thanks for the graphics comment. This is in fact a great job of Borja, our graphic designer, who has excellent capabilities to create nice graphics Your game looks fantastic! I would love to see the internals, it can be very useful Please, let me know if you consider this. Thank you!
|
|
|
Post by Anacl3to on Sept 6, 2022 7:56:30 GMT
Hi all,
How can i create multicolour sprites ?.
For example, a colour in each block of 8x8 pixels
Thanks
|
|
|
Post by flopping on Sept 6, 2022 11:41:49 GMT
|
|