Drake7707

downsizing uses the exact opposite, check lines for the most tile0 and leave them out if necessary

Which would you prefer ? The first option will copy regardless of there are not so many tile 0's, which leads to double walls. The second option checks the line to be copied from the source with the next line from the source, and compares the number of tile 0's on those lines. This will significantly decrease the amount of double walls, but introduces some holes in the walls (more like distortions) The third is actually the same as the second but also checks with the one next of the next one, which could remove double walls some more, but introduce a lot more gaps (don't mind the asteroids, it still doesn't keep that in mind) Edit: hm, seems like the gaps were made because of a bug, rather than with the prev<->next check. I'll edit the picture. Picture edited! And Apache, just see the picture, and pick the one you'd like best of the 3 resizes. I resized the original in 3 different ways explained above.

oh really ? i had seen my computer do weird stuff all of a sudden sometimes, but after a reboot its ok then . (i think my computer has a will of its own )

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]

heres what i have so far. It's way faster now, and moving selection works [Attachment removed ; outdated] - Sama

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

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

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

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

vb doesn't work with eclipse, else i would use the memory-hogging-always-crashing-every-5-min-because-it-needs-more-memory eclipse (i programmed my ray tracer in eclipse tho) But for vb6, these additions are a nice !@#$%^&*et to the ide

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

i retried opening the map with the last version of DCME, and now it opens, but i only get tiles here and there (like distortions)

I don't know if you've heard about MZ-Tools before ? Ring any bells ? no ? Well i didn't heard about it until now, and i find it a really nice add-in for vb6. It has a lot of features, such as inserting error handling code with a click, and more code-generating stuff. Really speeds up programming a lot You can find it on http://www.mztools.com/ Edit: !@#$%^&*, you can even get a statistics report or a inspection report on the source code for unused or unreachable code. Wicked Edit2: mmmm ability to sort the procedures by moving them in a list ... nice ^^. !@#$%^&* DCME is gonna get a lot cleaner

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)

i think it might be a little slow once the settings start to pile up. When searching for the key it's easier to use a sorted array and use binary search for the key. (but now its a bit unnecessary for only 2-4 settings)

or a slightly more complicated method is to vector the wall structure, and resize based on that. But like i said before, resize the open spaces, don't resize walls more than necessary. And it's not about if it's a valuable !@#$%^&*et to DCME, i also want to try if i'm able to pull that off

well when you construct your base with too small passages, it can be bigger by resizing (thats what i had in mind with resizing anyway)

you forgot export, discard tileset , i've updated the repository with my additions (settings!!! such as grid options )

i can't do such thing now in the current state of DCME, i first need to redo the selection part. Once that is done, it will be more efficient and it will be easier to implement new stuff with it, such as resizing. Also some retiling can also be removed when walltiles work. After a series of little implementations and bugs fixed, those 2 things should be the top priority for DCME. Once that is done, which is a major update, it will prolly go to DCME v2.0

i was thinking and after i redone the selection part of DCME, i could insert a resize thingy that allows you to resize your bases or anything at all (will be like a pixel resize, with some extra checks like every line that needs to be added will be as previous but check if the next line is more empty than the previous one, that way the walls of the base will stay the same size (i hope) Good idea? or not worth it ?

makes calculating the selected tile much more difficult

well its already fixed in v1.1.11

all fixed

ok i was able to fix it, but still don't understand how it happens in updateselectiononpreview there is If selstate = append And (Not SharedVar.MouseDown Or curtool = T_hand) Then and when using the arrow keys to navigate on the map, the updatelevel gets called in the change of the hscr and vscr (which wasn't exactly the way i want it to as it does it double but meh) and when using radar it calls updatelevel afterwards. Now somehow after 30min of debugging i found out that sharedvar.mousedown = false when using arrow keys, and it was true when clicking in the radar. Tadaah, you got yourself a bug, as it wont update when the mouse is down. This is, personnally, one of the most stupid and hidden bugs i've seen -_- I don't even know why i put (Not SharedVar.MouseDown Or curtool = T_hand) in the if in the first place Edit: oh yeah, you can't move the selection because it constantly updated to its position Conclusion: the sharedvar.mousedown using for both frmmain and frmgeneral => BAD IDEA !, i removed the mousedown = true from the radar as it was not needed anyway.

FIXED!