[RESOLVED] Cairo Equivalents Setpixel(Yes & Easy), Getpixel(???) [L-Plate Learner Edition]

[-Corso->]

Hi all, another question for the Cairo squad. Looks like Pycairo has a pixel interrogation thing, but we don’t appear to?

My question is basically, for speed (like running it hundreds of times a turn). Right now I use a couple of ways of analysing a pixel map image of a 1000x1000px.
1. Picturebox, Getpixel. (Somewhat slow)
2. Matrix, just accessing the entry. (Quite fast)
3. Cairo??



For those interested, I copy a PNG picture (an icon value map) to an invisible form.picturebox of 1000x1000 pixels. I interrogate those close-by pixel values to give icon numbers (of the cairo-imagelist) of the local map. It’s about-ish 20x20 pixels in total per go. This works pretty well, as the map only changes when you swap screens. (If that doesn’t make sense, imagine the picturebox has a shrunken down map on it made only of numbers).

Terrain maps, tree maps, grass and object maps are pretty good with this method. It can have many, many map chunks, as those 1000 square PNG’s are saved in files. Cairo allows saving and editing, meaning the map is living and can be literally 10’s to 100’s of kilometres long.
However, the big problem is with monsters and characters. A lot of them can fit on a 1000 square map chunk. Initially, I use a proximity matrix to count who is close and who isn’t. Then render that proximity matrix. It’s fast.

Now, here’s the trick. I’d like to, if possible, to stop using pictureboxes and matrices altogether, and only use surfaces as they are becoming my ‘normal way to think’.
It’s easy to ‘setpixel x,y’ of a (Long value) colour on a Cairo surface, with the rectangle function. But, can we ‘getpixel x,y’ of a (Long value) colour from that surface?

Pycario reference: https://stackoverflow.com/questions/...o-imagesurface
I had a look of the VB6 functions attached to the surface context, but nothing was apparent.

And aside, to the person who PM’d me to stop using images in my posts!


https://www.youtube.com/watch?v=2HJx...annel=RoyalOss

To everyone else, thank you kindly for all your help.

[Schmidt]

For speed-reasons, one should avoid accessing (single) Pixels via Function-(aka Method-)Calls.

What is built-in instead, is 4 Methods on a cCairoSurface:
- .BindToArray and .BindToArrayLong
...(which span a 2D-Byte, or Long-Array virtually over the 32Bit Mem-Allocation, "not making a copy")
- and the two matching Release-Methods .ReleaseArray, .ReleaseArrayLong

You can see this technique applied in a recent thread here:
https://www.vbforums.com/showthread....=1#post5550236

Though I wonder (if I understood you correctly), why you'd want to access or store:
- mapping-infos (which have nothing directly to do with "plain-pixel-colors")
- in a pixel-surface, which is a class-instance which wraps a mem-allocation, that's dedicated to... well, pixels

Why not use a normal, plain VB6-2D-Array for such mapping-infos...
(or a Dictionary, where you could store such Infos in a Sparse-Matrix, with a smaller memory footprint)?

Olaf

[-Corso->]

Thanks Olaf, lot's for me to check out.
I suspected the pixel test might be a little slow. Thank you for the .BindToArray and .BindToArrayLong, I had no idea we could do such a thing for a 2d array. This might be very cool indeed, I'll check it out.

The PNG Phase maps (the red pictures), are super handy. I wish I could have a full size map, but 1000^2 was the near enough to their upper limit for handling. So the overmap is made of many of these chunk pieces. It's easy and very fast to load in a new region. Plus, being able to tweak maps on Photoshop has it's advantages for testing buildings and sites.. It's like handling cards, oh, this card for trees, this one for grass, oh, time to file them away and load up the region to the right. I get to see visually how the random biomes join together too. I just found them a pleasure to deal with for this type of game test.

What you are saying to me is to load them into a VB 2d matrix. I'm embarrassed to say I actually don't know how to load a PNG into a matrix, but I'll find out. Or save it the other way for filing. I'll start hunting around for something.

A matrix will need to be 6 to 7 layers deep too. I always thought matrix handling in VB was a little on the slow side, I'll definitely run some more tests. I was wondering if Super-Cairo handled things a little better. ie: Blanking a VB 2d matrix to zeros, vs, blanking a Cairo Surface to RGB(0,0,0).

The PNG's take so little memory too, this was astonishing to me. So, pixel PNG maps are excellent in that regard. The map info is basically the Long value of the colour pixel, which is a number, which is the Cairo.ImageList.KeyByIndex value. Or, for the monsters, their serial number. 255x255x255 ends up being a lot of characters/monsters and or icons, which can be filed away on their respective cards and retrieved as needed. Or, played around on Photoshop for experiments.

I was excited to see if I could run the whole engine from Cairo commands?..... Because it seems to be so fast for everything else.

(Oh, and as you can see in the first post, the Cairo-Avatar face editor is coming along swimmingly. Now with fluffy ear manipulations.)

[Schmidt]

So, what you're saying is - that your 1000^2 Maps are just smaller representations of the
"fully rendered, tile-based views" (one Pixel in them, representing "a tile with a certain type").

In that case, since your mappings remain in the "visual realm" (are just "zoomed-out" Layers of the real thing),
editing such kind of "map-infos" in Cairo-Surfaces (or in PhotoShop or "Paint") does indeed make sense.

But for storing such "visually prepared" map-defs, I'd choose an SQLite-Database, for several "good reasons".
(an existing - e.g. PhotoShopped 1000x1000 overview-layer-map can be imported into a DB-Table in a small routine - within 1 sec).

I could explain these reasons in detail (in case you want to go there)...

If you don't want to go "all DB" (having all your image-resources, all your Map-Layer-definitions in a single file),
that's also an option (but a far less "elegant" one).

To mention at least the main-reason, why a DB-based approach makes sense...:
It would allow you, to have a "size-wise unlimited world-map" - and it would allow
"seamless scrolling and zooming" on that huge world-map via simple SQL-queries
(queries which would allow you, to give the true target-rectangle of your current tile-view,
and produce a result-recordset which contains all Layer-Type-infos for all Tile-Types of that View-Rect in about 1msec).

Olaf

[-Corso->]

And here I was thinking I was clever when I just finished penning-up and eradicating 99% of the engine code by using BindToArrayLong. <- I don't have to do any queries, the data is just, there, like, instant. Wow. And now you tell me I can use absolute coordinates and not local map-chunk coords (for everything) without loading delays? With everything on one file.



Honestly that sounds great, but I know 0.0001% about SQL. I wouldn't even know where to begin. I had written some queries to an SQL DB an age ago, and hooked up a few DB's to clients, but that's it. About the only database I used to use to any real degree was MSAccess. So I'm not sure if it's a monumental task to learn what is required? Are there any materials?

[-Corso->]

Mini update: Converted to BindToArrayLong to display the tile screens. Ended going from 80-140ms screen 'changes' to 40-60ms screen changes. That means rebuilding the entire screen, when you enter a new one.
And now my code is small.... Very small... What was I even doing before, small....

There was some long to hex to RGB fluff to convert over, but that ended up being sorted.
But still, this is waaay cool and fast. I'll resolve the thread to solved for now. Time to remake the 'real thing' in clean new Form and modules.

Goodbye matrices and pictureboxes(!)

Thanks muchly Olaf!

[Schmidt]

Time to remake the 'real thing' in clean new Form and modules.

If you do that anyways, perhaps the following CodeBank-entry is of some help:
https://www.vbforums.com/showthread....arge-Game-Maps

It shows, how to introduce an SQLite-DB (for efficient Resource- and Map-Handling) -
also showing how to work with an "absolute Coord-System" on your View-Window
(doing efficient queries, to find all the Tiles which are needed, to construct new BackGround-Surfaces after a View-Shift).

Olaf

[-Corso->]

I will most certainly review this. I was actually going to rebuild the code, 'just to get it done', while re-writing with the 'potential' for possible integration of SQL in the future, but now I can analyze it to see it working. I'll do some serious playing around with your code. Thanks for putting in the PNG's, it really helps things a lot.

That's above and beyond Olaf, many, many thanks!