Display / Layers

[Samapico]

[Drake7707]

just take magenta as transparent color .. who the !@#$%^&* uses magenta anyway (or rgb(254,0,254) or something)

 

It's possible that vb controls allocate memory in chunks of memory and fill that up until more is required. That way you might not see the changes of memory if you add more pictureboxes on the fly. I'm not certain of this though.

[Samapico]

Ok, IT WORKS folks

 

Compared to the graphic above, we now have 2 additional layers: One for regions, and one for the selection.

 

At the moment, the tiles layer, with the grid and the tiles is drawn correctly. I did a test with a mostly-filled full screen, at zoom 1:4

With the old code, rendering the full thing took around 450ms. With this new code, it stays below 120ms. $$$

Those speeds are with un-compiled DCME though, just through the IDE, I can't compile yet.

 

Also, the code might be reduced of a few hundred lines in the process... the old code had become such a mess, because everything was drawn on the same image. So you didn't want to draw map tiles when there was a selection, for example. But then again, we had to check for the paste type (paste under, transparent...).

So yeah, now everything is drawn on its own layer, so it basically just keeps drawing, without checking a lot of things. The result is a more than 3 times faster rendering

 

Also, transparent fly under tiles appear transparent (You'll see the lvz's underneath them).

 

 

Some bugs I fixed on the way:

-When adding a new lvz from the 'Add image...' dialog, lvz names are now appended ".lvz" if needed.

-The 'Object ID' textbox in the lvz toolbar was not modifying the mapobject's properties.

[Samapico]

It compiles!!! woot

 

The same drawing test, with the compiled version, took 96ms per iteration. About 25% faster than non-compiled.

But the REAL enhancement is when you move around... before, a lot of stuff had to be completely redrawn; now, only the newly shown portions are redrawn, and that is for ALL layers, including LVZ's.

 

Still a lot of bugs to squish, and a couple more things to implement, though

 

-There are a few pixels that are not redrawn correctly when moving around

-Specific tools have not been tested at all (TileText, PicToMap, things like that)

-Selection edges are not drawn yet

-!@#$%^&*S regions are not drawn yet

 

I'll attach a test version soon, so you guys can try it out and maybe find some bugs.

[Samapico]

Was trying to improve Regions drawing speed...

I just spent a lot of time trying to make them all draw in a single virtual bitmap, then stretching that image once on the level to display it. However, overlapping regions became a problem when trying to remove tiles from a region. Performance was still OK with 4-5 regions, but when I tried it on Hyperspace's map, with like 50 regions, it was wayyyyyyy too slow. So I'll have to give each regions its own bitmap... this will take much more memory, however. But having a !@#$%^&*load of regions won't have a significant effect on performance.

 

This is all to avoid checking each tile to see if each region is part of it whenever we need to draw it. All regions will be pre-drawn and nothing will need to be redrawn until you add/remove parts of a region; and that will be very quick as well.

 

I can't wait til all this is done The overall speed improvements are quite impressive at this point

[Drake7707]

kay let's calculate the memory usage

 

For one map that'd be:

 

(1024x1024 bitmap = 4mb)

 

1 * tile layer * 4mb + 1 * tile selection layer * 4mb + 1* lvz layer * 4mb + nrRegions * region layer * 4mb + each lvz with variable size * dunno average 500kb or so

 

 

so a map with 10lvz images defined, and 10 regions would take up 4+4+4+40+~5 = ~57mb

 

If i didn't forget something (I left out the actual preview etc)

[Samapico]

actually, the layers are not 1024x1024, they are the size of the preview, which for a 1024x768 resolution would be something like 800x700 or so

 

there are 1024x1024 images used for : pixel-level tiles , pixel-level selection, and there will be one for each region

 

Also, a 1024x1024 24bit bitmap would be 3MB

 

Memory usage with 1 map opened: 30MB

with 2 maps opened: 40MB

 

My preview was 1088x718

 

(doh, got a leak somewhere, closed the 2nd and it stayed at 40MB)

 

Also, for the region 1024x1024 images, I'll actually try to make them as big as they need to be, so if a region takes only a 5x5 area, the bitmap will be 5x5, and will be enlarged as needed if the region takes a larger area.

 

So basically, I'm not sure why, but virtual hDC's don't seem to take up memory... Maybe they take memory of the GPU and it doesn't appear in the process? Enlightenment on the subject would be nice.

 

Edit: Just tried some stuff... memory usage only go up as stuff is painted; whatever remains as background color doesn't take any memory, so I'm not worried at all about large memory usage. Only maps with LOTS of stuff will take lots of memory, and that's pretty much normal.

[Drake7707]

So basically, I'm not sure why, but virtual hDC's don't seem to take up memory... Maybe they take memory of the GPU and it doesn't appear in the process? Enlightenment on the subject would be nice.

 

Yeah, i guess it uses the gpu memory. If you change your hardware acceleration from full to none (so it doesn't use the gpu) i guess you'll see the memory being much higher (not 100% certain here)

 

Windows xp api's use directx 8 after all (Vista uses dx10)

[Samapico]

Anyway, computers with less than 1GB of RAM are rare these days, so even if each map took 50MB, it wouldn't be much of a problem. And my guess is that large maps with lots of stuff will take somewhere around 50MB-70MB (+ ~15 MB of memory for the MDI form and all that stuff). And you usually don't have 5 maps like that opened at the same time.

And the performance increase will be worth it

[Samapico]

Getting closer...

 

I would show you a screenshot, but for some reason, it screenshots it as a monochrome image...

 

While it worked, region drawing was as fast as it could be, meaning there was no noticeable lag even with a huge number of regions.

For some reason, however, it started doing these weird things... sometimes one or several layers freak out and become all white, or all black, and some don't draw... Weird stuff.

On top of that, I can't get the memory to be released when closing the map... There must be some pointer somewhere, but I just can't find it.

 

But it will work eventually. Hopefully. Loading hyperspace's map (with like 60 regions and tiles all over the place) was just as fast as loading any other map... so for that, it will be a huge improvement. That map took between and 120MB of memory, by the way. Not too bad, with all the stuff there is in it.

There's a big chance that the next release will still have some glitches in the display, for not anything major. Like when you scroll around with the hand, some pixels don't get redrawn correctly, so you get several 1-pixel-large or 1-pixel-high small lines all over the place. Kind of ugly, but it's far from critical at the moment as I'm focusing on the bugs described above.

 

That's all for today.

 

 

By the way, school has started again, so I don't have as much time to spend on DCME as I used to at the end of August. There might be once or twice a week that I'll sit down to work on it.

[Samapico]

Progress, progress...

 

Memory leak fixed (finally), most stuff seems to be working

 

Selection edges remain to do,

and some other minor display bugs

 

ASSS regions opacity is adjustable (2 different levels, for when Region tool is selected, and for when other tools are selected)

With region tool, they also get drawn on top of everything, otherwise they are drawn under tiles.

 

(Thanks Hyperspace for their region-intensive map that allowed me to test )

 

Also note that this map only takes like 2 or 3 seconds to load, basically as fast as any other map.

 

Some other map with a little bit of everything, notice how the FlyUnder tiles are transparent