Selection

[Samapico]

Moving map while dragging floating selection screws it up (but still applies it correctly)

 

well a lot of problems can be solved if the selection starts to act like the clipboard' date=' but you can speed things up with the selection.

 

a probable solution could be this:

- define a picselection picturebox

- when selection becomes 'append' copy the selection to an array (much like the clipboard array). This alone fixes every problem and annoyance with you can't do this and that when you moved the selection, as you just apply that function to the selection array

- now for the visible stuff in that matter. you can either generate the picture in the picselecting by iterating over the selection array (note that picselection dimension == picpreview dimension to avoid overflow errors, and the rest will be useless work anyway as it is not visible, and you can't move the selection out of the boundaries so pieces becoming visible is also no problem, note that you still apply the whole selection array, not the visible part alone). So what about pixel level, as it takes too much time to draw the entire pixel level stuff, well you could copy the part of the pic1024 and store it in picpixelselection picturebox, and apply functions on that part (you should do that anyway, also when not on pixel level, as you can then copy that to the pic1024 for speed)

- when you apply the selection, the easy part is to just copy the selection array into the tile array on the right offset

- then after you did that, you can either bitblt from the picselection or the picpixelselection to the piclevel or pic1024 respectively (well actually, both, if not on pixel level, and the latter if on pixellevel and call an updatelevel)

 

and that should about cover it. You can then make any further optimizations by using selection for everyting from clipboard, PTM , TTM and such as it is basicly also an array and a picclipboard.

 

If things will get slower i don't know, but it should give you much more freedom with selections[/quote']

 

Wouldnt it be easier to just store the tiles contained by the selection, and then whenever the preview is refreshed (selection moved, map moved) , render the necessary tiles (i.e. if the current tile is contained in the selection area, render the seltiles(x,y) tile instead of tile(x,y) )

That way it would also be very easy to make it preview a 'draw under' selection, or a 'transparent' selection...

 

updating pixel level preview or radar wouldnt be a problem either

 

no need to screw around with pictureboxes ... and flipping / rotating / replacing tiles in... a moved selection would be a piece of cake as well

 

I think this way would be much simpler... I just don't know if it will be performant ; well it shouldnt take any more time than to do a normal UpdatePreview

[»SOS]

DCME is fast enough, don't worry about any theoretical "well-performing" stuff.

 

As for your methods, I can't comment since I do not know much about the internal structure of thing thing... except that it is not very OO

[Drake7707]

vb isn't meant to be OO, the main problem is that there isn't inheritance.

 

And i don't know about the selection, i mostly see if it's good when i implemented it partly.

 

Btw switching between vb and java all the time gets me confused (ive been programming in java for 25 hours in less than 2 days because my deadline for my ray tracer is due tomorrow :s, and yes that IS OO. If you want to see some result i got so far, i put them here)

[Samapico]

currently experimenting new way of selecting stuff... its going pretty well..

 

just the way that you got your rectangle to draw was wayyyyyyy too complicated... you were dealing with pixels and offset and drag correction... all of this caused a couple of bugs of selection flickering near the edge of map or when using shift

i made it much simpler by dealing only with the tiles, then convert only once to pixels to get the shape's coordinates ; it works very well

 

 

 

edit: try this out... make a backup of the files somewhere and replace what is in this zip file ; its like pre-pre-beta but moving selections normally / under / transparently works fine... selection's content is not updated while moving it yet.... and dont even try to compile half of the code of the .cls wont even work yet i copied from original selection.cls and am replacing the code gradually

 

at this point selection kind of acts as another layer and would be very easy to manipulate (flip / rotate after move)

and the way the selection is drawn is much more bug-free... no flickering near the edges and it works fine with shift to make a square selection

 

 

[Attachment removed ; outdated]

[Drake7707]

omg ..... i was like doing the exact same thing yesterday

 

 

I also made a backup of the code and deleted everything of selection, then gradually added new code to the selection to fit the 'wet dream topic'

 

I reused the drawing selection code, so i still have those bugs :s, once i finished up, maybe you could change the code, because i searched to fix them for hours and still couldn't change anything about it

[Drake7707]

Here is what i get so far, maybe you could tweak it a little to speed things up a bit, and the drawing selection

 

For the rest, selecting like photoshop works, and i've implemented a move method, but haven't inserted it in the mousedown/move/up yet.

 

I don't have time to finish it anymore, but maybe you could

 

 

 

[Attachment removed ; outdated] - Sama

[Samapico]

nice... I'll take a look in a couple of days when I get time

[Samapico]

working on it at the moment... great work you did there Drake

[Drake7707]

yeah, but way too slow when moving with hand tool when having an active selection

[Drake7707]

I've did some speed testing on my implementation with this function in frmgeneral

 

 

when i test sel.updatelevelselection blah blah i get 24ms average which is good

but when i test updatelevel of the map i get 240ms, which is way to much. It should be around 30-40ms

 

when zoomed out (not on pixel level but one before) i get even worse (well not that much of a difference but...)

sel.updatelev... = 27ms

updatelevel = 307ms

 

Interesting enough, when i skip updatepreview from updatelevel i get 97ms, so updatepreview has become quite slow...

 

After further inspection i saw that

- radar update takes about 130ms

- the updatepreview of selection with the transparentblt also takes about 100ms

 

--> those need to be optimized

 

When i remove the code in the radar update to draw the selection on the radar, it falls back 100ms!!!, so i'll have to find another way to draw selection on the radar

 

Note that these times are in the IDE, so when compiled it shouldn't be so much

 

I managed to get it compiled and did a speed test on updatelevel

-without selection: 14ms

- with selection 151ms

 

This is just waay too slow to work with

 

When i fully tile the preview, so no tile 0 anymore, i get

- without selection 150ms

- with selection 340ms

 

 

Function SpeedTest() As Long
Dim lbx As Integer 'lowestval for x
Dim hbx As Integer 'highestval for x
Dim lby As Integer 'lowestval for y
Dim hby As Integer 'highestval for y
lbx = Int(Maps(activemap).hScr.value / (TileW * Maps(activemap).magnifier.Zoom))
hbx = Int((Maps(activemap).hScr.value + Maps(activemap).picpreview.Width) / (TileW * Maps(activemap).magnifier.Zoom))
lby = Int(Maps(activemap).vscr.value / (TileH * Maps(activemap).magnifier.Zoom))
hby = Int((Maps(activemap).vscr.value + Maps(activemap).picpreview.Height) / (TileH * Maps(activemap).magnifier.Zoom))

Dim tick As Long
Dim finalresult As Long
finalresult = 0

Const nrOfTests = 100
ReDim results(nrOfTests)

Dim i As Integer
For i = 0 To nrOfTests - 1
	tick = GetTickCount
	'INSERT METHOD HERE
	Call Maps(activemap).UpdateLevel
	'Call Maps(activemap).sel.UpdateLevelSelection(lbx, lby, hbx, hby)
	'//////////////////
	finalresult = finalresult + GetTickCount - tick
	DoEvents
Next
finalresult = finalresult / nrOfTests

SpeedTest = finalresult
End Function

[Drake7707]

Ok lets be a little smart here, why did i do 2 pictureboxes while i still need to use updatelevel every time ?

 

I removed every updatinglevel and preview from selection, and instead just did a check in updatelevel of the map to check if the tile to be drawn is in the selection, if yes draw that one, else, draw the one from the map itself.

 

I just increased its speed 3-10times !!!, it is way faster and more acceptable now, 25-110ms

[Samapico]

ew nice

 

just did a check in updatelevel of the map to check if the tile to be drawn is in the selection, if yes draw that one, else, draw the one from the map itself.

Hm, could make it check for draw/paste type aswell...

 

if tileisinselection AND (parent.pastetype=p_normal or (parent.pastetype=p_under and parent.gettile(i,j)<>0) or (parent.pastetype=p_trans and sel.seltiles(i,j)<>0)) THEN

 

draw the tile from the selection

 

else

 

draw the tile from the map

 

end if

[Drake7707]

heres what i have so far. It's way faster now, and moving selection works

 

 

[Attachment removed ; outdated] - Sama

[Drake7707]

ok now PTM and TTM should work with the new selection, also some other bugs were fixed, recplace/switch should also works, same with count tiles in selection, also cut/copy/paste should work

 

still need to do:

-pixel level for selection

-fill in selection doesn't work

-rotate and flip/mirror needs to be reimplemented

-still a bug at positioning the selection when it can't fit into the map when its at the topleft of the picpreview

-undo/redo isn't any good at the selection

-sometimes it doesn't want to apply

-sama needs to recode the drawing selections

-selection edges need to be drawn onto the radar without much overhead (100ms is way to much)

 

I told you selection was one of the core systems of DCME didn't i, thats why it will still take a while until it's fully working with everything

 

Btw a binary is included for those who are interested

 

 

[Attachment removed ; outdated]

[Samapico]

-selection edges need to be drawn onto the radar without much overhead (100ms is way to much)

Actually, if it is redrawn only at mouseup, i.e. at the end of a movement, 100ms is nothing

[Samapico]

i just sped up 'moving selection' quite a bit... when not on pixel level, i made it skip the update of pic1024selection on mousemove, it only updates it at mouseup , that saves a couple hundreds of ms each time it moves

 

also, adding and removing parts of selection kept calling 'aretheretilesinselection' ... that function took like 300ms to give an answer on my computer with tiles in the center of the map (up to 600ms with no tiles at all)

I managed to avoid using it at all.

 

I also fixed something about cancelling a selection being drawn, which I had made but was buggy.

If you right-click while drawing a selection, it cancels the drawing without applying other selected parts

 

 

 

It's still WAYYYYYYYYYY too slow when moving selection at pixel level... it takes up to 3-4 seconds on my computer to update

[Drake7707]

really? at pixel level it is acceptable here, it was faster than moving selection on the level before pixel level (before you optimized)

[Samapico]

well its a pain for me... i'll do some gettickcount's later to give you an idea of how painful it is for me :'(