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 / Problem with memBlock

Author
Message
SpecTre
Developer
21
Years of Service
User Offline
Joined: 24th Feb 2003
Location: UK
Posted: 29th Jan 2015 20:28
Ok, I have put a few post's on here lately as I am doing an AGK2 Colouring Book project.
See here for the code etc:

http://forum.thegamecreators.com/?m=forum_view&t=213305&b=48

Along the way I have run into some problems as AGK2 is quite new to me but I have coded before and in DBPro.
The problem is, is that when I get past one problem I come across another two and it seems to be never ending at the minute.

Anyway as part of my game I am using memBlocks to do a flood fill technique to make the colouring in, fill a section of the screen.
I have managed this with a screen res of 640 x 430 but when I up the picture res to 1130 x 800 it slows down somewhat.
Not just the filling of the screen but also reading the pixels in the memBlock. Again please see the full code on the other post to see the full code but as part of the code I am trying to create a memblock from an image and then when I change the picture to colour I delete this memblock and create another for the new picture and then start flood filling that one.

Here is a section of the code to demonstrate what I am trying to do.



I have come across a problem here though in that when I create the second memblock even though the first one was deleted it seems to do a merge of the 2 when I read the memblock pixels after and take forever to read the memblock but them doesn't colour the image correctly after.

Is there a way to fully flush the deleted memblock and would this solve the problem?
Do you know of a way to really speed up the program? 640 x 430 is ok but 1150 x 800 is not great on a tablet, just about ok on the PC though.

Other things I have thought is maybe change my grab pixel technique and change it to a more traditional flood fill routine but I was also wondering is it slow because AGK2 does not have the lock pixel command does this really slow down the memblock process when writing bytes etc as the same fill technique in DBPro is super fast at large screen res.

Here is an example of the flood fill idea but doesn't seem to work correctly yet!
I have attached a picture to colour for you to see what I mean.

Hope someone can assist and I guess it will be onto more problems

Cheers again for all the help so far.



Programming - AMOS on the AMIGA! / DBPro / Python / A bit of C & C++ / now also AGK2! Graphics - Deluxe Paint on the Amiga / Paintshop Pro / Photoshop / Lightroom / Grafx2
Previously worked for Prisma Software producing childrens educational software on the Amiga. Titles - Pepe's Garden - Paint Pot / Kids Academy range - Paint Pot II / Shopping Basket / Which Where What? / Blobs / Alvin's Puzzles

Attachments

Login to view attachments
SpecTre
Developer
21
Years of Service
User Offline
Joined: 24th Feb 2003
Location: UK
Posted: 29th Jan 2015 20:38
Oh forgot also to ask, when using CopyMemBlock to copy a portion of the memblock to another. Is it possible to copy a memblock to the back buffer of the screen?

I have been using a large Sprite 1150 x 800 as the image, flood filling, creating an image from the memblock and then using this image for the sprite to change the screen.

I thought of actually drawing to the screen instead of using a large sprite as I would have thought this would save memory but not sure?
AGK2 does not have a pixel/point option but lines and box drawing which are slow on the screen. Copymemblock to back buffer would work great but not sure.

So far I have 2 large sprites open to animate the screen between 2 pics at a time so when swiping the screen the picture changes from one to the other.
I then have multiple images open and also then doing the flood fill.
This would use a bit of memory and would also slow things down.

Programming - AMOS on the AMIGA! / DBPro / Python / A bit of C & C++ / now also AGK2! Graphics - Deluxe Paint on the Amiga / Paintshop Pro / Photoshop / Lightroom / Grafx2
Previously worked for Prisma Software producing childrens educational software on the Amiga. Titles - Pepe's Garden - Paint Pot / Kids Academy range - Paint Pot II / Shopping Basket / Which Where What? / Blobs / Alvin's Puzzles
JimHawkins
14
Years of Service
User Offline
Joined: 26th Jul 2009
Location: Hull - UK
Posted: 29th Jan 2015 23:39
Flood-fill is always a bit slow - and risky. If they are "clicking" a selected colour into a region you could have some small sprites preprepared for that section and then colour appropriately?

Onwards and sometimes upwards
Kevin Picone
21
Years of Service
User Offline
Joined: 27th Aug 2002
Location: Australia
Posted: 30th Jan 2015 02:59
Recursion is a nice simple way to do flood filling but it's pretty awful in terms of performance and can be potentially problematic due to unforeseen stack overflows. So coming from a compiled native language like Dbpro to an interrupted one like AGK1 or 2 basic means you'll need to shine for a light on the approach than you might like.

The most common issue programmers seem to have in interrupted languages is redundancy, so routine is computing some effectively constant value over and over again. If you're filling thousands of pixels, then this is magnified probably 10 fold (give or take) by the AppGameKit runtimes execution overhead.


Ignoring the method for the time being, you could stream line the routine by passing less parameters in and removing redundant calculations and function calls. For the parameters it'd be between the pack the ARGB colour into a single integer. Same as memblock read/writing inside the function, read/write integers / dwords (whatever they've called them)


So if we analyze just the few lines bellow in terms of what the AppGameKit runtime/VM has to execute, it's at least 5 operations, potentially 8 (or more) operations. That's at least 5 times the VM falls through the instruction look up, potentially more, which isn't cheap.




Reading the buffer as 32bit integer saves at least 4 operations.



Since all the fields are in the same integer, you can just compare the FILL_COLOUR_RGB with the CURRENT_RGB

So this code, which is as least 6 VM operations,




So this code can reduce potentially 2 VM operations,




Same goes for writing the new pixel to the memblock, just poke an integer.

Trimming the fat from the filler function will get you some of the way, but a bread crumb styledscanner is likely to be more efficient. Recursion is replaced by a start point stack array, ideally the array (or mem block) is oversided to begin with, so there's, or you can resize during the fill.

Then rather than compare all 4 sides of the current pixel, we cast rays out from any source pixel in 4 directions. Since we know the location of the source pixel and the width /height of the buffer, you no longer need clipping inside the scanning routines and can just use a pixel delta to move in any direction.

For scanlp=0 to numberofpixels
This_RGB=GetMemblockInt(Memblock, Address)
if This_ARGB<> FILL_COLOUR
; drop these points to bread crumb stack as new start points
endif
Address=Address+AddressDelta
next


If you scanned from any point say right 50 pixels. Then you no longer need to scan left from the inner pixels only the start/end pixel. So those points are dropped on the bread crumb stack as start points, flagged to scan Up/Down. The inverse occurs when scanning up down.

SpecTre
Developer
21
Years of Service
User Offline
Joined: 24th Feb 2003
Location: UK
Posted: 30th Jan 2015 11:34
Cheers Kevin,

Some good tips there which I will look at and can carry through to all my code to see if I can gain some speed. Reading and writing one integer for RGBA instead of doing the 4 bytes should be a start and makes sense.

The flood fill on the fly, last code block on the post is an alternative method I was thinking of to try and speed up the process but ideally using the original method would be better due to it working out the fill areas first and storing these into an array first so then all I do is check the colour point at x,y and then go through the array from start to end looking for the same value as the one at x,y and colour that point to fill. This works at lower res but maybe I can speed this up also using your advice too because again I write 4 bytes each time instead of one integer so will try that.

Any advice on the other issues anyone?

I must say the TGC community has got to be one of the best and there is always someone who will try to help unlike some other forums I have been on.

Programming - AMOS on the AMIGA! / DBPro / Python / A bit of C &amp;amp;amp;amp;amp;amp;amp;amp;amp;amp; C++ / now also AGK2! Graphics - Deluxe Paint on the Amiga / Paintshop Pro / Photoshop / Lightroom / Grafx2
Previously worked for Prisma Software producing childrens educational software on the Amiga. Titles - Pepe's Garden - Paint Pot / Kids Academy range - Paint Pot II / Shopping Basket / Which Where What? / Blobs / Alvin's Puzzles
CJB
Valued Member
20
Years of Service
User Offline
Joined: 10th Feb 2004
Location: Essex, UK
Posted: 30th Jan 2015 11:43
I wrote a nice little recursive flood-fill for DB-Pro back in the day. The initial version was very simple to read to show exactly how it all worked. The community evolved it into quite a nice efficient routine. But do you think I can find it?

Was probably on the DBDN forums. Are they still available anywhere?

V2 T1 (Mostly)
Uzmadesign
JimHawkins
14
Years of Service
User Offline
Joined: 26th Jul 2009
Location: Hull - UK
Posted: 30th Jan 2015 12:06
Rather then doing this at run-time I would "pre-process" into a list of bounded shapes and their vectors. If you have 20 bounded areas you have 20 vector lists - a 2-dimensional array. You also put the min and max X and Y coordinates at the start of each sub-list.

You save the list in a convenient probably binary format to load with this picture.

When the user clicks at a certain X,Y to compare the click to each min and max and see if it is within the bounds. You may have a small number of candidates.

You can then scan the candidates and see if the click is in this list. If it is, you use the vector list to colour the pixels in the memblock.

Alternatively you could preprocess out a series of images and turn them into sprites. They are the background colour. When the user clicks on them you simply use the sprite colouring commands in AppGameKit to re-colour them. This has to be the fastest way to do it, and will still work well on slow devices, which flood-fill will not.

Onwards and sometimes upwards
SpecTre
Developer
21
Years of Service
User Offline
Joined: 24th Feb 2003
Location: UK
Posted: 30th Jan 2015 13:36
@CJB
yes not sure if they are still up or not but will have a search for that.

@JimHawkins
The Sprites method is another take on the problem but not sure if that would be practical as I plan to have around 30 pictures to colour at this stage which may grow so the number of sprites would be a large amount and there would be maybe 30 to 40 fill areas per picture.

The main program for Colour Splash already pre processes the fill areas into a 2d array creating fill areas a specific number much like paint by numbers would. To fill I then go through the full array and just change the pixels in the memblock for that specific fill area.
See code below.
Not sure if it is possible to only check the array at the specific area instead of the full array for each number? This could speed things up.



Maybe instead of doing
For y = 0 to 800
For x = 0 to 1150
Check 2d array for colour fill number
Next
Next

It would be possible to just check the section of the array for the fill area?
Is this what you meant re the main and Max bounds?



Also @ everyone, any reason for the memblock not flushing after deleting and setting up a new memblock with memblock messing up and combining old and new memblock?


Cheers

Programming - AMOS on the AMIGA! / DBPro / Python / A bit of C &amp;amp;amp;amp;amp;amp;amp;amp;amp;amp; C++ / now also AGK2! Graphics - Deluxe Paint on the Amiga / Paintshop Pro / Photoshop / Lightroom / Grafx2
Previously worked for Prisma Software producing childrens educational software on the Amiga. Titles - Pepe's Garden - Paint Pot / Kids Academy range - Paint Pot II / Shopping Basket / Which Where What? / Blobs / Alvin's Puzzles
Preben
AGK Studio Developer
19
Years of Service
User Offline
Joined: 30th Jun 2004
Location:
Posted: 30th Jan 2015 14:19
Hi spectrepaul,

It do not have to be that complicated, you could just do like this:

Look at the image below , every fill area has a different color.
you loop into your array and replace all colors that is not black ( or gray ) with its own unique alpha value. so each fill area gets its own alpha value. after you set the alpha values you replace the color with white, so it will look just like it did before you made the "color" fill areas. So now when you need to fill an area you just read the alpha value , and change ALL pixels with that alpha value to the selected color.

Should be mush more easy/faster then doing a flood fill.

You could also just have 2 images , one hidden ( the colored one ) and your normal image , and then just replace everything with the selected color ( from the hidden image ) to the visible image.

Hope you can use it.



best regards Preben Eriksen,
BatVink
Moderator
21
Years of Service
User Offline
Joined: 4th Apr 2003
Location: Gods own County, UK
Posted: 30th Jan 2015 14:58 Edited at: 30th Jan 2015 14:59
Quote: "Alternatively you could preprocess out a series of images and turn them into sprites."


I like JimHawkins idea about sprites.

The image files for these will be very small. Memory wise, I don't see an issue, you will essentially have a set of rectangular sprites with perhaps 30% transparent (redundant) pixels around the borders. So your graphical memory requirements are around 1.3x screen size. You could even get smart and rotate sprites to the best fit to reduce redundancy.

BUT at any given time the system (AGK colouring sprites) is dealing with only a small percentage. Your goal at the moment seems to be reducing the amount of pixels being processed at any one time, and this fulfills that need.

Quidquid latine dictum sit, altum sonatur
SpecTre
Developer
21
Years of Service
User Offline
Joined: 24th Feb 2003
Location: UK
Posted: 30th Jan 2015 16:55
I see now with the sprite method but is there a limit to the number of sprites and sizes of them on the screen at once?
The colouring of the sprite would be very simple to do but I can't get my head around the creation of them yet! ☺
I would have to figure a way to process my array to create them and sort some x y coord system to cut them out. It took me quite a while with some graph paper to work out how to create the array from pixel fill areas into it with different numbers for each fill area! Lol.
Any tips would be helpful ☺

As part of my GUI for the game I have around 28 sprites already on the screen for the colour buttons these are 128x64 pixels in size with a visible area of 64x64 and it animates for icon pressed or not.

I was looking at your memblock tutorial in the tgc newsletter also which I think is on the same lines as Prebens idea because I can see how that could work too using the alpha values.

It is giving me a headache I must admit lol and think it is getting beyond my programming abilities, although in the last few weeks I think I have learned a vast amount from everyone's help so far.

I still have issues with the memblock not seeming to flush after deleting it also because like I mentioned if I create another memblock with a different image it seems to create a messed up memblock.

If I go along the sprite route though then I won't be able to expand the program to be able to also let the user draw their own picture to colour. Yet another problem!

Here is the section for reading my picture into an array:


This was created from my original DBPro version which was developed with help from IanM and Spooky and like I said I managed to learn and get my head round it with some graph paper lol

Back to the drawing board but I am determined to finish this damn game lol

Programming - AMOS on the AMIGA! / DBPro / Python / A bit of C &amp;amp;amp;amp;amp;amp;amp;amp;amp;amp; C++ / now also AGK2! Graphics - Deluxe Paint on the Amiga / Paintshop Pro / Photoshop / Lightroom / Grafx2
Previously worked for Prisma Software producing childrens educational software on the Amiga. Titles - Pepe's Garden - Paint Pot / Kids Academy range - Paint Pot II / Shopping Basket / Which Where What? / Blobs / Alvin's Puzzles
JimHawkins
14
Years of Service
User Offline
Joined: 26th Jul 2009
Location: Hull - UK
Posted: 30th Jan 2015 19:44
You can have thousands of sprites and hundreds on screen with no problems.

If you are using flat colour, which you probably are, you can use run-length encoding to keep your sprite data small. If you don't know what that is, ask and I'll explain.

This technique will be fast, even on a crap Android phones, because you do all the heavy-lifting on a PC at design time.

Onwards and sometimes upwards
SpecTre
Developer
21
Years of Service
User Offline
Joined: 24th Feb 2003
Location: UK
Posted: 30th Jan 2015 20:20
Well I implemented your advice on the RGB values reading and writing Integers instead of bytes and the code is much neater for a start lol.
Not a working program but code samples below:



I think I might have a go at the Sprite version and I would have to research run-length encoding but if you have 5 mins to explain?

The Sprites would be flat colour however in the future I was thinking of texture fill but I think I am getting ahead of myself here haha.


I was also thinking of creating some data Types for my original option and do 2 versions of the program one as sprites and the original version expanded on, at least I would learn more this way.
The data Types here:



I was thinking of saving a box area for each fill store and when doing the for next x 2 part to check x,y pixels to only check in this box section to minimize the pixel area to search.
Worth a try also

Thanks for your help so far, learning all the time.

Programming - AMOS on the AMIGA! / DBPro / Python / A bit of C &amp;amp;amp;amp;amp;amp;amp;amp;amp;amp; C++ / now also AGK2! Graphics - Deluxe Paint on the Amiga / Paintshop Pro / Photoshop / Lightroom / Grafx2
Previously worked for Prisma Software producing childrens educational software on the Amiga. Titles - Pepe's Garden - Paint Pot / Kids Academy range - Paint Pot II / Shopping Basket / Which Where What? / Blobs / Alvin's Puzzles
SpecTre
Developer
21
Years of Service
User Offline
Joined: 24th Feb 2003
Location: UK
Posted: 30th Jan 2015 21:48
Just as a test I did a rough edit to the FloodFill function, this is what I meant by the box area to fill. Look at the Columns and Rows numbers in the For Loop.

I just got the coords from the picture in Windows Paint to try quick.
I need to work out how to store these coords into an array or data type or something on the fly when doing the pixel store 2D array routine.

This makes it much faster as it is checking a smaller area depending on the size of the fill section.

The pixelcheck if part number is the number which is stored for that particular fill area.

Still think Sprites will probably be best though at the moment as the bigger the area the slower the fill.



Programming - AMOS on the AMIGA! / DBPro / Python / A bit of C &amp;amp;amp;amp;amp;amp;amp;amp;amp;amp; C++ / now also AGK2! Graphics - Deluxe Paint on the Amiga / Paintshop Pro / Photoshop / Lightroom / Grafx2
Previously worked for Prisma Software producing childrens educational software on the Amiga. Titles - Pepe's Garden - Paint Pot / Kids Academy range - Paint Pot II / Shopping Basket / Which Where What? / Blobs / Alvin's Puzzles
JimHawkins
14
Years of Service
User Offline
Joined: 26th Jul 2009
Location: Hull - UK
Posted: 30th Jan 2015 22:48 Edited at: 30th Jan 2015 22:54
Run-length encoding (RLE) is good for areas of flat colour.

Lets have an image. Here's the top line, where T is transparent and V is the base colour value:

TTTTTTVVVVVVVVVVVVVVVVVVVVTTTTTTTT

We can code this as:

6T40V8T

That means starting at left, turn 6 pixels to transparent (or ignore) then turn 40 pixels to colour, then turn 8 to transparent (or ignore).

If the image was 84 x 84, stored as proper image data it would be 84 * 84 * 4 bytes. That's 28224 bytes. Assuming each line was similar to the first line it would be ~= 504 bytes. There's no precise value because it depends on the data. We used to do this a lot in the days of 8-bit computers.

Storing in binary bytes rather than string format the length can yield a run of up to 256 identical values. That's because you add one - so if the length is zero it's one, and so on.

For further compression, with a simple flat-plane image, it's either transparent or not: 0 = transparent 1 = colour. You can then use 7 bits for the length (up to 128) and 1 bit for the colour switch. In that scheme the example above would be ~= 252 bytes. That's a compression ratio of over 114 to 1.

This does not work with "photographic" data. RLE can turn out to be much bigger.

I think Preben's solution above is the best, and least complicated. You have an invisible coloured copy with a distinct colour value for each filled area. When the user clicks on an area in the front image you look for the colour value in the back image, then you loop over the back image and if it's in the selector colour you change it to the required colour in the front image.

Programming is about compromises and efficiency. Choosing the best approach to a specific problem is painful!

Onwards and sometimes upwards
Kevin Picone
21
Years of Service
User Offline
Joined: 27th Aug 2002
Location: Australia
Posted: 31st Jan 2015 02:26
spectrepaul,

Simpler is better, just be careful with redundancy in nested loops. Inside the columns loop there's computations occurring with ROWS that are effectively constant during the inner loop.




Since ROWS is known before the inner loop, it's better to compute the offset for the ROW once per row, rather than once per pixel. That's at least 3 operations less work per drawn pixel.




Just looked and it appears the image is known before hand, if that's the case, then so storing some pre-computed info about filling picture the picture would be handy. Assuming the user won't be drawing stuff themselves, which gets thrown that out the window if the setup is too slow a process.

One approach I've used in the past is a time shared filler. So the routine doesn't sit inside the rendering/worker loop forever, rather it's allowed to do a specific number of iterations and upon reaching the limit it returns. The filler state is stored and restored upon successive calls, until the job is complete. This lets you refresh the display while the fill taking place. So even if the fill takes a few seconds the program is still responsive.

SpecTre
Developer
21
Years of Service
User Offline
Joined: 24th Feb 2003
Location: UK
Posted: 31st Jan 2015 16:02
Jim, RLE sounds interesting especially since my pics are only 2 colours with lots of white space. Never come across it before so will do more research for that. I am still trying to get my head round Prebens idea, I understand the just checking alpha value but if I am checking the pixels on the back image surely I would still be doing a loop through every pixel for that colour value and I already have my fill areas stored in the 2d pixel array?
You are right compromises and efficiency its been that long since I have coded properly I think I have forgot loads but it is gradually coming back lol I think.

Kevin, I should imagine it will take me a while to get back to full speed with efficient coding as said it has been a while but all this advice helps and is very appreciated.
Regarding the image being known, this part of the program reads every pixel:




What happens is that I load my image, I have 2 diferent pics loaded at the start and displayed as 2 sprites. One is the main colouring PIC the other is off screen so that when I swipe the screen up or down I scroll between pics to colour.
First though when the images are loaded, I call the store pixels function for the main image after creating it as a memblock.
The above function then goes through every pixel of the memblock and stores each fill area in a 2d array called pixel store. This 2d array is the same size as the picture 1150x800 so then every point on the array has a number. Zero for a black line and a different number for each fill area, eg for the PIC displayed on the post above, every pixel in the array for the top left cloud is 1 and the sky area is 181 and so on. The function sorts the fill areas out for whatever PIC I put through it.
This worked really well on a 640x400 image but is a bit slower for the 1150x800 as obviously it is checking a larger area.
I thought about saving this array info as a .txt file and loading this in with the picture then instead of checking every pixel in the memblock with the above function for the array, just read the file into the array however this was much slower!

Anyway, once I have my array sorted I don't need to call that function again unless I change the PIC to colour.
So if I swipe the screen up my 2nd PIC scrolls on screen and the original image scrolls off. I delete the memblock and create a new one for the new PIC to colour and call the function again to store the pixels to change the array values.
It messes up here though as previously mentioned though because for some reason,storing values from the memblock even after deleting the old one seems to have mixed up data in the memblock when its created.

Eg:


As a test first part works second time doesn't as it stores all strange values as if the 2 memblocks are merged even though it was deleted before creating the new one.

Regarding the fill part of the program, once I have my 2d array values stored. Wherever you press on the screen or mouse, it saves the coords and checks that place in the array for the fill area value.
It then checks the full array for any matching number and changes the memblock pixel colour so only the fill area with the same number is filled. I don't actually do a flood fill routine as I already have the fill area stored in the array. I just mentioned doing a flood fill method instead to see if it would be quicker but I haven't perfected that yet lol.
So I guess what I have stored in my array is similar to Prebens method but instead of a different colour for each area I have a different number for each. So I am not sure how Prebens method would be quicker yet?

I can get it filling quicker by not checking all the array and only checking a boxed area around the fill section but then I would have to find a method to store coords as well for a box section around the fill area whilst creating the 2d array but it is all getting a bit complicated to just fill an area lol

Eg as a test I got the coords from the picture whilst loaded in windows paint to check if it fills quicker which it does but one picture has a large section to colour so would still be slow. Problems problems



Maybe as a first program to do with AppGameKit on just getting it, this was not the one to start with but this was the last one I did in DBPro so thought I would box this off quite quick lol
I do like this AppGameKit though as it has a lot of potential but you need to do a lot more thinking to get to the same stage as I don't think it's quite up to speed with DBPro yet for features.
Think I am gradually getting the old brain cells thinking like a coder again...... Gradually lol

Programming - AMOS on the AMIGA! / DBPro / Python / A bit of C &amp;amp;amp;amp;amp;amp;amp;amp;amp;amp; C++ / now also AGK2! Graphics - Deluxe Paint on the Amiga / Paintshop Pro / Photoshop / Lightroom / Grafx2
Previously worked for Prisma Software producing childrens educational software on the Amiga. Titles - Pepe's Garden - Paint Pot / Kids Academy range - Paint Pot II / Shopping Basket / Which Where What? / Blobs / Alvin's Puzzles
SpecTre
Developer
21
Years of Service
User Offline
Joined: 24th Feb 2003
Location: UK
Posted: 31st Jan 2015 18:51
Just reading this post again and thinking about the program and just realised what Preben was trying to say!
So if I have 2 images the same for one picture one plain and the other coloured in with different colour for each fill area, I can load the coloured version into a memblock and delete the image then I do not need to have the function to check for the stored pixel values and will not need the 2d array because essentially I will be using this memblock as the 2d array to check the fill area.
Then when I click the mouse I can check the fill area instead of the array and colour the pixel on the plain image memblock.
Have I read this right?
That will really speed up the process for getting the data in the first place because I won't need to check every pixel to store into the 2d array!

I still don't know if I will have the same issue of messed up memblocks so will have to check.
Is there a problem with memblocks when storing the image memblock into say memB=thememblock then deleting this memblock later and storing another memblock image into memB=difmemblock or do you have to flush memB somehow first by say memB=0 ?
Hope you get what I mean there.

I will still have to optimise the fill part though because the fill method I use will still check the full memblock for the coloured picture area value to change the pixel in the plain picture and I guess there will be no speed difference there than the array version?
Unless I can work out a box section area of the memblock store area to check instead of having to check the full area of the memblock as I previously mentioned on one of the test parts above.

Any ideas how I would create the sprites and x y position from the picture to try the sprite method without having to create them in a paint program?
Going to have to read more into this RLE thing I understand the principal of what you were saying Jim, it is just implementing it.
I have found a few sites to read over the subject but am still going to do 2 versions of this program the way above and also the sprite version as I think it will only help me when I go onto my next project.

Programming - AMOS on the AMIGA! / DBPro / Python / A bit of C &amp;amp;amp;amp;amp;amp;amp;amp;amp;amp; C++ / now also AGK2! Graphics - Deluxe Paint on the Amiga / Paintshop Pro / Photoshop / Lightroom / Grafx2
Previously worked for Prisma Software producing childrens educational software on the Amiga. Titles - Pepe's Garden - Paint Pot / Kids Academy range - Paint Pot II / Shopping Basket / Which Where What? / Blobs / Alvin's Puzzles
JimHawkins
14
Years of Service
User Offline
Joined: 26th Jul 2009
Location: Hull - UK
Posted: 31st Jan 2015 19:21
Okay - The key to this is doing the area calculations off-line, and storing them. You only need byte values unless you have more than 256 areas - which is unlikely.

I'll code the generator using Delphi tonight or tomorrow morning. That will not take very long - VCL already has a Floodfill() function.

The main AppGameKit program could then be quite short!

I'll include RLE as a demo!

Onwards and sometimes upwards
SpecTre
Developer
21
Years of Service
User Offline
Joined: 24th Feb 2003
Location: UK
Posted: 31st Jan 2015 20:11
Jim,
Thanks for your help with this, really appreciate it. I will read up on RLE in the mean time so I can understand it proper.
I am not at home at the minute but there is a picture attached at the top of the post as an example picture which will be coloured in the program. Size is 1150x800. The other pictures I have drawn are not much more complicated so it won't be more than 256 fill areas for sure.

Again thanks greatly for your help.
I owe you a beer mate

Programming - AMOS on the AMIGA! / DBPro / Python / A bit of C &amp;amp;amp;amp;amp;amp;amp;amp;amp;amp; C++ / now also AGK2! Graphics - Deluxe Paint on the Amiga / Paintshop Pro / Photoshop / Lightroom / Grafx2
Previously worked for Prisma Software producing childrens educational software on the Amiga. Titles - Pepe's Garden - Paint Pot / Kids Academy range - Paint Pot II / Shopping Basket / Which Where What? / Blobs / Alvin's Puzzles
JimHawkins
14
Years of Service
User Offline
Joined: 26th Jul 2009
Location: Hull - UK
Posted: 31st Jan 2015 22:51
Not a problem - It's fun compared to the rather complex multi-track video syncing I'm programming for the day job!

Onwards and sometimes upwards
SpecTre
Developer
21
Years of Service
User Offline
Joined: 24th Feb 2003
Location: UK
Posted: 1st Feb 2015 01:07
Wow sounds interesting This must seem like a child's project in comparison hehe.
Well can't wait to see how this goes, just reading up on RLE as I speak!

Cheers again.

Programming - AMOS on the AMIGA! / DBPro / Python / A bit of C &amp;amp;amp;amp;amp;amp;amp;amp;amp;amp; C++ / now also AGK2! Graphics - Deluxe Paint on the Amiga / Paintshop Pro / Photoshop / Lightroom / Grafx2
Previously worked for Prisma Software producing childrens educational software on the Amiga. Titles - Pepe's Garden - Paint Pot / Kids Academy range - Paint Pot II / Shopping Basket / Which Where What? / Blobs / Alvin's Puzzles
SpecTre
Developer
21
Years of Service
User Offline
Joined: 24th Feb 2003
Location: UK
Posted: 1st Feb 2015 19:25
Hi again, in the mean time I have updated the original method to include Prebens idea of using an already filled in image of different shades as a memblock and acting as the 2D array, so the 2D array is not needed now or my Function to read all the pixels which makes the program a vast amount smaller for a start and faster when initialising the image for filling.

I have included a zip file which contains a folder called pages with 2 images in it for you to try if you wish. One is the main picture to colour and the other is a shaded in image with a different colour value in each fill area.
I decided to fill the image using just the RED byte value as the areas do not have more than 256 colour sections and instead of reading integers from the memblock I just read the RED byte as the shades range from 255,0,0 to 1,0,0 obviously 0,0,0 is the lines of the image like a colouring book.

Here is the code:


Think I am starting to get this now! lol

I just need to find a way to store x,y,x1,y1 box areas now for each fill section so I can narrow down the checking of the pixel area to make the filling in part quicker.

If you take out the comments from the FloodFill function "/*" "*/" and try to fill in the Cloud's, Sky, Sun and Mouth areas you will see they fill in much faster so just need to work out the box area coords saving
Still not ideal as if the fill area is large it will still be slow.


Getting there though and I can't wait to try Jim's method with the sprites now! Still reading about RLE at the minute and it is really interesting.
Could open up a whole new area of ideas!

Programming - AMOS on the AMIGA! / DBPro / Python / A bit of C &amp;amp;amp;amp;amp;amp;amp;amp;amp;amp; C++ / now also AGK2! Graphics - Deluxe Paint on the Amiga / Paintshop Pro / Photoshop / Lightroom / Grafx2
Previously worked for Prisma Software producing childrens educational software on the Amiga. Titles - Pepe's Garden - Paint Pot / Kids Academy range - Paint Pot II / Shopping Basket / Which Where What? / Blobs / Alvin's Puzzles

Attachments

Login to view attachments
SpecTre
Developer
21
Years of Service
User Offline
Joined: 24th Feb 2003
Location: UK
Posted: 1st Feb 2015 20:03
Just tested changing of pictures to colour and now I am using the method of the memBlock as the array re Prebens idea, it seems to have sorted the problem with the merged memblocks after deleting and when the second image is loaded it works instead of having all strange data in the memblock so that's a result!



Programming - AMOS on the AMIGA! / DBPro / Python / A bit of C &amp;amp;amp;amp;amp;amp;amp;amp;amp;amp; C++ / now also AGK2! Graphics - Deluxe Paint on the Amiga / Paintshop Pro / Photoshop / Lightroom / Grafx2
Previously worked for Prisma Software producing childrens educational software on the Amiga. Titles - Pepe's Garden - Paint Pot / Kids Academy range - Paint Pot II / Shopping Basket / Which Where What? / Blobs / Alvin's Puzzles
SpecTre
Developer
21
Years of Service
User Offline
Joined: 24th Feb 2003
Location: UK
Posted: 1st Feb 2015 20:15 Edited at: 1st Feb 2015 20:16
Hey Jim,

as a test on my phone and tablet I tried using the full picture 1150x800 as a sprite and when I tapped the screen instead of changing the fill area I changed the whole sprite colour using this:



The colour of the sprite changed immediately with no lag what so ever!
So if it can change colour that quick on the 1150x800 sprite it will be amazing using your method with each fill area as a sprite!
Very excited to try now

Programming - AMOS on the AMIGA! / DBPro / Python / A bit of C &amp;amp;amp;amp;amp;amp;amp;amp;amp;amp; C++ / now also AGK2! Graphics - Deluxe Paint on the Amiga / Paintshop Pro / Photoshop / Lightroom / Grafx2
Previously worked for Prisma Software producing childrens educational software on the Amiga. Titles - Pepe's Garden - Paint Pot / Kids Academy range - Paint Pot II / Shopping Basket / Which Where What? / Blobs / Alvin's Puzzles
JimHawkins
14
Years of Service
User Offline
Joined: 26th Jul 2009
Location: Hull - UK
Posted: 1st Feb 2015 23:29
Hi spectrpual - I got a bit waylaid by crossword, tennis, roast dinner and two episodes of Spiral, but I've done most of it. I'll finish it in the morning.

The first stage is complete. It automatically scans the image and floodfills the regions with a unique colour.

To do this it has to convert the png or jpeg to a bitmap internally. You can see this stage completed in the attached BMP image. It's not optimised, because off-line tools don't need to be.

The last stage is easy: convert the pixels into a byte-array of the colour indices, where 0 is the edge colour (the drawing colour).

It's fun! More soon...

Onwards and sometimes upwards

Attachments

Login to view attachments
SpecTre
Developer
21
Years of Service
User Offline
Joined: 24th Feb 2003
Location: UK
Posted: 2nd Feb 2015 00:58
Hey Jim, nice work.
You got that boxed off quick. Loving this ☺
This RLE stuff I am reading up on is quite interesting.

Oooh roast dinner sounds good,I ended up getting pizza ☺

Programming - AMOS on the AMIGA! / DBPro / Python / A bit of C &amp;amp;amp;amp;amp;amp;amp;amp;amp;amp; C++ / now also AGK2! Graphics - Deluxe Paint on the Amiga / Paintshop Pro / Photoshop / Lightroom / Grafx2
Previously worked for Prisma Software producing childrens educational software on the Amiga. Titles - Pepe's Garden - Paint Pot / Kids Academy range - Paint Pot II / Shopping Basket / Which Where What? / Blobs / Alvin's Puzzles
JimHawkins
14
Years of Service
User Offline
Joined: 26th Jul 2009
Location: Hull - UK
Posted: 2nd Feb 2015 09:11
Can you post another picture, just for sanity-checking?

Onwards and sometimes upwards
Kevin Picone
21
Years of Service
User Offline
Joined: 27th Aug 2002
Location: Australia
Posted: 2nd Feb 2015 09:36
spectrepaul,

The link bellow is to some example written in PB, there's async methods, general purpose as well as pre-computed palette mapped optimization with RLE / Span compression..

Async Flood Filling & Flood Filling Optimizations Example

Obviously the code won't run 'as is' in AGK/AGK2, but principles used should be easy to follow.

BatVink
Moderator
21
Years of Service
User Offline
Joined: 4th Apr 2003
Location: Gods own County, UK
Posted: 2nd Feb 2015 10:27
Another thought, on a slight tangent to the filling challenge.

I think you need two versions of the black&white image. One is to allow you to map out the fill areas, and the one attached to the first post would do that.
The second is one with a slight blur to the edge, which will smooth out the lines. This can be overlaid on the coloured image. It will improve the final image on-screen for the user.

Quidquid latine dictum sit, altum sonatur
JimHawkins
14
Years of Service
User Offline
Joined: 26th Jul 2009
Location: Hull - UK
Posted: 2nd Feb 2015 11:00
Interestingly enough, there is an error in the example picture: the small triangular area under the armpit is NOT the background colour. That had me fooled for a bit. Error correction now in!

Onwards and sometimes upwards
SpecTre
Developer
21
Years of Service
User Offline
Joined: 24th Feb 2003
Location: UK
Posted: 2nd Feb 2015 11:19
Jim, just noticed that and just slightly off topic although you did mention it earlier, do you use Delphi/Pascal to code AppGameKit?

Batvink, lol think my head is mashed enough Although could do a a PNG image with the background as transparent and just have that as a sprite on the top layer so all you would see is the lines smoothed out?
Doesn't AppGameKit have auto anti aliasing on sprites though?

My mind runs overtime normally and I come up with a hundred ideas a minute and then have to pull myself back and think well first I haven't finished the first project yet and second can I do it lol.
I have a notebook full of stuff lol. Sometimes there has to be some compromises or I won't finish anything 😀

Programming - AMOS on the AMIGA! / DBPro / Python / A bit of C C++ / now also AGK2! - Graphics - Deluxe Paint on the Amiga / Paintshop Pro / Photoshop / Lightroom / Grafx2
Previously worked for Prisma Software producing childrens educational software on the Amiga - Titles - Pepe's Garden - Paint Pot / Kids Academy range - Paint Pot II / Shopping Basket / Which Where What? / Blobs / Alvin's Puzzles
SpecTre
Developer
21
Years of Service
User Offline
Joined: 24th Feb 2003
Location: UK
Posted: 2nd Feb 2015 11:26
Using the background image version of my code in Prebens implementation opens lots of possibilities for selection areas on screen for user interfaces. You could just have the image of your interface with different fill areas in the background to check mouse areas for your main game in the forground and you wouldn't need to check mouse areas in the if commands just the colour fill area. You could have quite a complicated GUI this way.
Just a thought on a side note.

Programming - AMOS on the AMIGA! / DBPro / Python / A bit of C C++ / now also AGK2! - Graphics - Deluxe Paint on the Amiga / Paintshop Pro / Photoshop / Lightroom / Grafx2
Previously worked for Prisma Software producing childrens educational software on the Amiga - Titles - Pepe's Garden - Paint Pot / Kids Academy range - Paint Pot II / Shopping Basket / Which Where What? / Blobs / Alvin's Puzzles
SpecTre
Developer
21
Years of Service
User Offline
Joined: 24th Feb 2003
Location: UK
Posted: 2nd Feb 2015 11:31
Jim, give me 15 mins and will upload some more pics, just notice the post.

Programming - AMOS on the AMIGA! / DBPro / Python / A bit of C C++ / now also AGK2! - Graphics - Deluxe Paint on the Amiga / Paintshop Pro / Photoshop / Lightroom / Grafx2
Previously worked for Prisma Software producing childrens educational software on the Amiga - Titles - Pepe's Garden - Paint Pot / Kids Academy range - Paint Pot II / Shopping Basket / Which Where What? / Blobs / Alvin's Puzzles
SpecTre
Developer
21
Years of Service
User Offline
Joined: 24th Feb 2003
Location: UK
Posted: 2nd Feb 2015 11:35
Here you go, there are a few in here

Programming - AMOS on the AMIGA! / DBPro / Python / A bit of C C++ / now also AGK2! - Graphics - Deluxe Paint on the Amiga / Paintshop Pro / Photoshop / Lightroom / Grafx2
Previously worked for Prisma Software producing childrens educational software on the Amiga - Titles - Pepe's Garden - Paint Pot / Kids Academy range - Paint Pot II / Shopping Basket / Which Where What? / Blobs / Alvin's Puzzles

Attachments

Login to view attachments
JimHawkins
14
Years of Service
User Offline
Joined: 26th Jul 2009
Location: Hull - UK
Posted: 2nd Feb 2015 11:37
Np problem.

It turns out that it's best to convert the colour-filled reference bitmap out to a PNG of the same size as the original. PNG compression is highly efficient with flat colour planes.

The orginal PNG size is 24.8K - the mapped image at PNG compression level 9 is 22.1K.

More explanation and program later.

Yes - Delphi for Windows - FPC for Android. Same code.

Onwards and sometimes upwards
SpecTre
Developer
21
Years of Service
User Offline
Joined: 24th Feb 2003
Location: UK
Posted: 2nd Feb 2015 11:37
Kevin cheers for that, will have a good look over them. I might as well get that working as well. Going to be a top coder after all this lol
Thanks again guys, all good!

Programming - AMOS on the AMIGA! / DBPro / Python / A bit of C C++ / now also AGK2! - Graphics - Deluxe Paint on the Amiga / Paintshop Pro / Photoshop / Lightroom / Grafx2
Previously worked for Prisma Software producing childrens educational software on the Amiga - Titles - Pepe's Garden - Paint Pot / Kids Academy range - Paint Pot II / Shopping Basket / Which Where What? / Blobs / Alvin's Puzzles
SpecTre
Developer
21
Years of Service
User Offline
Joined: 24th Feb 2003
Location: UK
Posted: 2nd Feb 2015 11:40
Cheers Jim, pics uploaded.
Does that mean you use tier 2 using Delphi?
Does that up the speed a bit too?
Whats the FPC for Android?

Programming - AMOS on the AMIGA! / DBPro / Python / A bit of C C++ / now also AGK2! - Graphics - Deluxe Paint on the Amiga / Paintshop Pro / Photoshop / Lightroom / Grafx2
Previously worked for Prisma Software producing childrens educational software on the Amiga - Titles - Pepe's Garden - Paint Pot / Kids Academy range - Paint Pot II / Shopping Basket / Which Where What? / Blobs / Alvin's Puzzles
JimHawkins
14
Years of Service
User Offline
Joined: 26th Jul 2009
Location: Hull - UK
Posted: 2nd Feb 2015 11:58
Thanks - FPC = Free Pascal Compiler.

Onwards and sometimes upwards
SpecTre
Developer
21
Years of Service
User Offline
Joined: 24th Feb 2003
Location: UK
Posted: 2nd Feb 2015 22:32
Just been messing and put all the program together using the none array method with screen swipes for changing pictures and colours to select, just so you can get an idea of how the program works.
All the media is attached in a zip folder.
Obviously this is the slow flood fill method for now but will be great when converted to a sprite method with the help of the amazing coder Jim

I will also have to optimize the coding as I slapped all the pieces together so you can get the idea of what I am trying to achieve



Programming - AMOS on the AMIGA! / DBPro / Python / A bit of C C++ / now also AGK2! - Graphics - Deluxe Paint on the Amiga / Paintshop Pro / Photoshop / Lightroom / Grafx2
Previously worked for Prisma Software producing childrens educational software on the Amiga - Titles - Pepe's Garden - Paint Pot / Kids Academy range - Paint Pot II / Shopping Basket / Which Where What? / Blobs / Alvin's Puzzles

Attachments

Login to view attachments
JimHawkins
14
Years of Service
User Offline
Joined: 26th Jul 2009
Location: Hull - UK
Posted: 2nd Feb 2015 22:55
Just back on it now. Been teaching a night-class. It's VERY cold!

Onwards and sometimes upwards
SpecTre
Developer
21
Years of Service
User Offline
Joined: 24th Feb 2003
Location: UK
Posted: 2nd Feb 2015 23:02
Yes it's freezing tonight ☺
Don't rush pal if you got lots on, I am just really greatful for the help.
Have a look at the program so far in the last post, it has the interface and music in place so people can see what I am trying to achieve with it.
This incorporates screen swipes for up and down to select pictures and also colour selections which can be moved up and down for more colours.

Hope you like it but a long way to go yet lol
Cheers again.

Programming - AMOS on the AMIGA! / DBPro / Python / A bit of C C++ / now also AGK2! - Graphics - Deluxe Paint on the Amiga / Paintshop Pro / Photoshop / Lightroom / Grafx2
Previously worked for Prisma Software producing childrens educational software on the Amiga - Titles - Pepe's Garden - Paint Pot / Kids Academy range - Paint Pot II / Shopping Basket / Which Where What? / Blobs / Alvin's Puzzles
JimHawkins
14
Years of Service
User Offline
Joined: 26th Jul 2009
Location: Hull - UK
Posted: 3rd Feb 2015 00:03
That's great. But I think you'll find it's massively simplified using a pre-computed reference image.

Finished the constructor program. Will write a little demo tomorrow morning.

Onwards and sometimes upwards
SpecTre
Developer
21
Years of Service
User Offline
Joined: 24th Feb 2003
Location: UK
Posted: 3rd Feb 2015 00:36
That's great, well I think I might have over complicated my code a bit lol.
Very interesting to see how it works and how the program does the constructing.

Programming - AMOS on the AMIGA! / DBPro / Python / A bit of C C++ / now also AGK2! - Graphics - Deluxe Paint on the Amiga / Paintshop Pro / Photoshop / Lightroom / Grafx2
Previously worked for Prisma Software producing childrens educational software on the Amiga - Titles - Pepe's Garden - Paint Pot / Kids Academy range - Paint Pot II / Shopping Basket / Which Where What? / Blobs / Alvin's Puzzles
JimHawkins
14
Years of Service
User Offline
Joined: 26th Jul 2009
Location: Hull - UK
Posted: 3rd Feb 2015 23:33
I've done more on this today. But I now really think that my suggestion of decomposing it into sprites was the best idea, for several reasons:

* Individual sprites can be coloured in various ways, including shaders.
* You could animate the "fly-in" - like a jigsaw puzzle solving itself.
* You don't need the image itself - just a background colour.
* Sprite clicking is easy than converting world coordinates.
* Sprite colouring is way faster than doing memblock operations.
* There's a massively reduced memory overhead.
* There is no need for memory intensive flood-fills.

All it needs is a zipped pack of the png sprite images and a simple list of the origin of each. The sprites can be automatically named along the lines of "spr001" etc. The new images can overwrite the old ones.

I'll modify the generator to create a pack of images in a zip file, together with the origin list.

Hope you agree!

Onwards and sometimes upwards
SpecTre
Developer
21
Years of Service
User Offline
Joined: 24th Feb 2003
Location: UK
Posted: 3rd Feb 2015 23:56
Yes I think so also, I seem to have got to the speed limit with the method as it stands because I tried a box section around each fill area for speed and although faster, on large areas and on the tablet it was still slow.
I think realistically for the purposes of drawing etc AGK2 really needs a native Flood Fill command. It shouldn't be too much for the AppGameKit team to put it in as the Box command already has the flood fill option.

As I mentioned before I tried colouring the screen sprite which is 1150 x 800 and the sprite changed colour immediately so this method of yours is really the best option I think and I can't wait to implement it.

Once it is all in place and running I will start looking at shaders to see how they are implemented as I have seen a few posts now about shading techniques.

You must be reading my mind regarding the sprite animation as I was thinking of this, either spinning on or off or scrolling on or off the screen starting at one side moving up first then working across the screen

The fact that this will also get rid of the image would save memory too and I might think of other methods re the colour palette selection method etc.

Yes I agree sprite clicking is much easier and I use this method to select the colours from the palette so that will be easy to implement into the game.
As it stands I have an invisible 1x1 pixel sprite which detects sprite collisions at the mouse pointer x and y.

It will be good to get it on lower spec tablets and mobiles too due to the memory reduction.


So with the generator you have created, will this create the sprites, pack them up and create a list or something re the x,y co-ords then?
What would I need to do simply load the image into it?

Well this is fantastic and when you say, "Hope yo agree!", I totally agree all the way and am looking forward to trying and testing this method out!


I was going to ask you also as I was going to try and convert the original method as it stands to C++ using tier 2 just to see if there is a speed difference. It has been a long time since I have done any C++ coding, however it seems easy enough to change the code line by line and I think I owe it to myself to test it this way and gain experience with a bit of tier 2.
What I was wanting to ask you however was that you mentioned Delphi Pascal AppGameKit coding.
Would this be the same?
I have looked at Lazerus Pascal and thought I would try that also, as I have heard that Pascal is quite good as a language to learn even if you haven't used it before.
I can't seem to find out where AppGameKit Pascal is however.
I bought AGK2 and have downloads for Windows/Mac and Linux but no Pascal?
You got any ideas?


Anyway, looking forward to the Sprite method and I think that the Sprites will be the making of this little game!
Thanks again Jim.

Programming - AMOS on the AMIGA! / DBPro / Python / A bit of C C++ / now also AGK2! - Graphics - Deluxe Paint on the Amiga / Paintshop Pro / Photoshop / Lightroom / Grafx2
Previously worked for Prisma Software producing childrens educational software on the Amiga - Titles - Pepe's Garden - Paint Pot / Kids Academy range - Paint Pot II / Shopping Basket / Which Where What? / Blobs / Alvin's Puzzles
BatVink
Moderator
21
Years of Service
User Offline
Joined: 4th Apr 2003
Location: Gods own County, UK
Posted: 4th Feb 2015 10:12
Quote: "As it stands I have an invisible 1x1 pixel sprite which detects sprite collisions at the mouse pointer x and y."


I guess you are using getSpriteCollision()?
GetSpriteHit() will be more efficient as it doesn't need to do any calculations around sprite shape, and it removes the need for the invisible sprite.

getSpriteCollision() is good for irregular shaped sprites, and also for square sprites when checking area collisions.

Quidquid latine dictum sit, altum sonatur
JimHawkins
14
Years of Service
User Offline
Joined: 26th Jul 2009
Location: Hull - UK
Posted: 4th Feb 2015 12:00
I'm just optimising - BatVink is correct (as always).

Onwards and sometimes upwards
BatVink
Moderator
21
Years of Service
User Offline
Joined: 4th Apr 2003
Location: Gods own County, UK
Posted: 4th Feb 2015 12:37 Edited at: 4th Feb 2015 12:37
Quote: "GetSpriteHit() will be more efficient as it doesn't need to do any calculations around sprite shape"


I think I was too vague, and there is a little more work required to your overall solution if using sprites.

What I said was true, GetSpriteHit() is what you need. It means it has to work out one shape (the image) rather than 2 (the image and the mouse sprite)

More importantly, you're not going to be able to use GetSpriteCollision() on the image sprites. Here's why:

In this image, you can (automatically) make one sprite shape from the green examples because they are concave.
The red examples need multiple sprite shapes to make up the detectable area, because they have convex angles in them. You can't have a single convex shape.

GetSpriteCollision() only works on sprites with one shape.



To make up your shapes, baxslash has a tool for defining them. (I have one too but I'll be using the one baxslash made next time I need it!)

Extra effort to make the image, but worth it in my opinion. It gives so much more scope for extra effects in V2 like JimHawkins said earlier.

Quidquid latine dictum sit, altum sonatur

Attachments

Login to view attachments
SpecTre
Developer
21
Years of Service
User Offline
Joined: 24th Feb 2003
Location: UK
Posted: 4th Feb 2015 13:36
Hi again,

I wasn't aware of GetSpriteHit() so will check that.
Oh dear I will check the posts you mention later, I think I have created a monster with this project! I started converting to C++ last night and also got stuck again lol.
It must have been around 4am when I realised the time and put yet another post up for help lol.

Time for some more reading in a bit but got to get some work done today 😀 haha

Programming - AMOS on the AMIGA! / DBPro / Python / A bit of C C++ / now also AGK2! - Graphics - Deluxe Paint on the Amiga / Paintshop Pro / Photoshop / Lightroom / Grafx2
Previously worked for Prisma Software producing childrens educational software on the Amiga - Titles - Pepe's Garden - Paint Pot / Kids Academy range - Paint Pot II / Shopping Basket / Which Where What? / Blobs / Alvin's Puzzles

Login to post a reply

Server time is: 2024-04-23 09:17:31
Your offset time is: 2024-04-23 09:17:31