Sorry your browser is not supported!

You are using an outdated browser that does not support modern web technologies, in order to use this site please update to a new browser.

Browsers supported include Chrome, FireFox, Safari, Opera, Internet Explorer 10+ or Microsoft Edge.

AppGameKit Classic Chat / Scratch card effect using Memblocks

Author
Message
Kevin Cross
20
Years of Service
User Offline
Joined: 15th Nov 2003
Location: London, UK
Posted: 25th Apr 2017 15:56 Edited at: 26th Apr 2017 14:35
Piecing together a couple of forum posts I managed to get a scratch card effect working in AppGameKit using Memblocks. Hadn't used Memblocks before so took a little while to get it right.

In this example I'm using two coloured sprites, a yellowy/brown sprite for the background of the card and a grey one on top that acts as the silver part that you scratch. A white rectangle (the coin) follows the mouse and when you press down it rubs out the grey sprite. I've commented out lines that would place images on the sprites and one that rotates the coin. If you uncomment the rotation you will see that it scratches underneath the coin at all angles (using GetSpriteInBox).

It doesn't seem slow when running on the desktop (not tested on a device). It is a rough example and one I may work on some more but wanted to share it in-case anyone else finds it useful as a starting point.

The coin that follows the mouse does lag a little when you move the mouse fast. Also when scratching with a coin only part of the coin would actually scratch the silver in real life because the coin is round so you may want to have two sprites for the coin, one small one that scratches (have it invisible) and one sprite that shows the coin, and then constrain both sprites to the mouse pointer. You'd also want the coin to center on the mouse point with SetSpritePositionByOffset (I got lazy)



I should probably mention that I've only tested this on a 400x200 image/sprite. I don't know how much it slows down when the sprites are much larger.

Happy to receive any feedback/suggestions on how it can be improved.

EDIT:
A working version of the code using virtual resolution can be found in this comment below: https://forum.thegamecreators.com/thread/219503#msg2602008
A working version of the code using percentages can be found in this comment below: https://forum.thegamecreators.com/thread/219503#msg2602021
BatVink
Moderator
20
Years of Service
User Offline
Joined: 4th Apr 2003
Location: Gods own County, UK
Posted: 25th Apr 2017 16:38
It's a small amount of code for a nice effect.

But it didn't work for me
The calculations must be off somewhere, it was "scratching" a strange pattern that stretched diagonally across the screen.
I added a screen, window and virtual resolution of 1920 x 1080
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Quidquid latine dictum sit, altum sonatur
TutCity is being rebuilt
Kevin Cross
20
Years of Service
User Offline
Joined: 15th Nov 2003
Location: London, UK
Posted: 25th Apr 2017 17:04
@BatVink I used a standard template which is 1024, 766. Here's the code at the top of the file before the scratch card part. Another thing I haven't tried yet is positioning the scratchcard somewhere else on the screen (like the center) but it should be easy enough to modify

Kevin Cross
20
Years of Service
User Offline
Joined: 15th Nov 2003
Location: London, UK
Posted: 25th Apr 2017 17:11 Edited at: 25th Apr 2017 17:53
@BatVink I played around with the window size and resolution and you're right it's definitely not working when changed. I did say it was rough

The following window size and virtual resolutions work when used together

400*200
800*400
512*384
1024*768
960*540

960*540 is half of 1920*1080 so it doesn't seem to be a aspect ratio problem.

I'll play around with it some more to see if I can get to the bottom of it but I might need guidance from a more experienced user.

EDIT: When printing card width, silver width and memblock size I get the following values

card width = 400, silver width = 400, memblock size = 320012 with resolution 1024*768
card width = 400, silver width = 370, memblock size = 273812 with resolution 1920*1080

While I don't know why this is, this would probably be the reason why it's not working, the image when converted to memblocks isn't being converted in full
Kevin Cross
20
Years of Service
User Offline
Joined: 15th Nov 2003
Location: London, UK
Posted: 25th Apr 2017 18:11 Edited at: 25th Apr 2017 18:13
Does anyone know why the resolution 1920 * 1080 only works fine if you increase the width of the silver sprite to 432 and the height to 216, as well as setting GetImage to the same size i.e



I can't see what the pattern is to be able to come up with a solution for all resolutions.
BatVink
Moderator
20
Years of Service
User Offline
Joined: 4th Apr 2003
Location: Gods own County, UK
Posted: 26th Apr 2017 08:29
I think (but not 100% sure) that the reason is the way GetImage() works with virtual and actual resolutions. The memblock is probably not the same dimensions as the sprite.
instead of using GetSpriteWidth(), use the value in the first 4 bytes of the memblock.
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Quidquid latine dictum sit, altum sonatur
TutCity is being rebuilt
Kevin Cross
20
Years of Service
User Offline
Joined: 15th Nov 2003
Location: London, UK
Posted: 26th Apr 2017 09:58 Edited at: 26th Apr 2017 10:03
@BatVink After looking at it for a few hours I came to realise that it may have something to do with the device resolution and the virtual resolution but no amount of changes to both of these helped me find a pattern. I did however sort it this morning on the bus to work by changing a couple of lines. I'm setting the card size to the silverImage size with GetImageWidth/Height and I changed the for next loop to get the width of silverSprite instead of the card sprite. This would probably be the same as your suggestion with getting the information from the first 4 bytes.

Because I'm resizing the card sprite (the background that would contain the numbers and prizes) it might cause problems with the sprite that would go around it i.e. the rest of the card that sits around the scratch panel, the part that shows the scratch card name and images to entice you to buy the card. I'll cross that bridge when needed. Ideally I'd like to get this working with percentages rather than virtual resolution so that would be my next challenge

Kevin Cross
20
Years of Service
User Offline
Joined: 15th Nov 2003
Location: London, UK
Posted: 26th Apr 2017 14:15
Here's a percentage version. Again it should work with any WindowSize.

=PRoF=
21
Years of Service
User Offline
Joined: 17th Mar 2003
Location: Milton Keynes, UK
Posted: 26th Apr 2017 17:58
This is a really great idea. I'm thinking it would make an ideal 'mini game' or a daily prize thing in a larger game.

Nice work
Kevin Cross
20
Years of Service
User Offline
Joined: 15th Nov 2003
Location: London, UK
Posted: 27th Apr 2017 09:56
Quote: "This is a really great idea. I'm thinking it would make an ideal 'mini game' or a daily prize thing in a larger game.

Nice work"


Thanks

I was thinking this morning that the code could easily be modified to reverse the alpha channels on the image so instead of setting to 0 set it to 255 when a sprite crosses over pixels, and turn them back to 0 when the sprite leaves the pixel. You'd then have the affect of a light beam from like a torch that reveals part of the image as it moves over it. Maybe another mini game or daily reward there if they can find the hidden object within a second or two
BatVink
Moderator
20
Years of Service
User Offline
Joined: 4th Apr 2003
Location: Gods own County, UK
Posted: 27th Apr 2017 10:11
I did this many years ago in DBP. My approach was to change the alpha, it gives so much more scope.
For example, you can feather the edges instead of having a hard outline. You can use your "coin" sprite to dictate the shape and hardness of the revealed area, using it's alpha channel.
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Quidquid latine dictum sit, altum sonatur
TutCity is being rebuilt

Login to post a reply

Server time is: 2024-03-28 11:13:38
Your offset time is: 2024-03-28 11:13:38