Todo next

[Samapico]

That's pretty much my plan for the next days:

 

Tonight

• -Fix Popups under splash (openmap)
  
• -Fix Open map by args (opening a 2nd map by double-clicking)
  
• -3.3.2
  

 

-Total fix of opening map via windows explorer (i.e. opening several maps at once)

-3.3.3

 

-Make undo/redo for LVZ

-Fix drawing order for LVZ images (draw from lowest layer to top, from top-left to bottom-right) (This could eventually avoid the need for the ugly pseudo-transparency we use now)

-3.3.4

 

-Finish implementing the byteArray <- moving selection should be faster

---Implement a copy method from one array to another

-Make an int array the same way <- anything to do with the selection should be much faster

 

All these latest changes combined = Adding/removing from selection will be almost instant (It currently is pretty much the slowest part of DCME)

-3.3.5

 

 

Once this latest version has been used for a couple of days, you guys will have found most bugs, I'll fix them, and we'll be at 3.4

[Samapico]

I can open two maps at a time... but not 3... wtf

[RiiStar]

$$$$$$

 

[Samapico]

Ok... Drake and I discussed this issue for a while on MSN, and I think we figured out a solution... I'll try to test that tonight.

 

You guys probably don't care about this, and/or won't understand anything, but here it is anyway, for the few people who might be interested...

 

When you open a map from windows explorer, it opens dcme.exe with a command line argument containing the path of the file.

 

If dcme.exe is already started, however, we have to do some magic to make it open there, and not in a new instance. Windows has this 'Window message' thing, where you can send a message code to another window. You can tell it stuff like 'hey, hit the 'ctrl-c' keys' or 'hey you, minimize yourself'. You can make some custom messages as well; we made one that we call 'hey you, you have a map to open'. We can't tell it the whole path, cause we can only give it some numerical arguments. But we put the path in a file, then tell it there is a map to open, and it opens it.

 

That all works fine with one map to open. Really, 100% perfectly. But when you open more than one map at once...

 

What it 'SHOULD' do, !@#$%^&*uming dcme.exe is already running:

 

-open dcme.exe (1)

-send message to the original dcme.exe

-the original dcme.exe processes the message, opens the map

-dcme.exe (1) returns from sending a message, and closes

 

-open dcme.exe (2)

-send message to the original dcme.exe

-the original dcme.exe processes the message, opens the map

-dcme.exe (2) returns from sending a message, and closes

 

-open dcme.exe (3)

-send message to the original dcme.exe

-the original dcme.exe processes the message, opens the map

-dcme.exe (3) returns from sending a message, and closes

 

... You get the idea

 

However, due to how window messages work, or how we THINK they work, sometimes it won't wait until the message is fully processed before returning, which makes the following exe start right away, send a message, and then we basically get a message handler calling OpenMap( ... ), while the previous map is still being loaded (i.e. still somewhere in the OpenMap() function). For some reason, this causes a nice BOOM. Being at two points in the same function "at once", some variables being shared... weird stuff happen.

 

Being VB6, this is all only one thread, so these things are still handled somewhat in sequence... but VB does this weird thing, it kind of handles pseudo-threads himself... The WindowMessage processing functions are called as soon as the program gives it a chance to. This is typically either one of these 2 cases:

1- A messagebox appears, which makes the current thread idle (waiting for input)

2- A 'DoEvents' is called in the code, which lets other threads or processes run a bit

Apparently both these cases "wake up" the "messages pump", as Drake called it.

 

So what we need to do... or what we THINK we need to do, is:

 

-When a message is received, take note that there is a message being processed (using a global boolean value)

-If another message arrives while another is being processed, queue it, then leave

-When the first message handler is done with his message processing, the boolean is set back to false, and then it checks if there are any messages that were queued; if it's the case, it processes them, one at a time, again setting a boolean value while he is processing them.

 

Solution is pretty simple, actually, now that I type it up... It's something that I tried a few days ago, but I failed horribly and it crashed more... but I figured what I did wrong now, and in theory, it should work... If it doesn't, well, apparently we don't understand how it works

 

By the way, all this is VERY hard to debug, because we can't do it in the development environment. We have to print a !@#$%^&*load of debug info in dcme.log to see what's going on. And even then, it's not that easy

 

 

 

 

That was a long post... good to have it somewhere in here as a reference though, it's kind of a summary of the conversation Drake and I had on Messenger.

Yeah, a long summary... but still...

 

Congrats if you read all this... NERD.

 

 

edit: nvm, it won't be tonight... but... eventually

[Samapico]

Woot, it works

 

To make it crash, you really need to 'want' to... like... telling it to open a bunch of maps while it's not started yet, and try to open the same files again while it's still starting...

There's a way to make it more stupidproof, but for now I think this next update will fix all known problems

[Samapico]

Oh well, it's rock solid now... I did everything I could to try to crash it, it didn't want to

[Drake7707]

funny thing is that this text above took longer to type than the fix itself

[Samapico]

lol, yes

 

But I realised what I did wrong WHILE typing it (needed 'if' instead of 'while'), so it wasn't a waste

[Drake7707]

I've already made an IntegerArray (by adapting boolArray) in anticipation ^^

 

setting/getting is probably faster because it can copymemory it to/from the property

 

setrectangle will though be slower because the bytes can be alternating, i made a check though, if the bytes of the integers are the same or not

IntegerArray.zip

[Samapico]

Good point about setrectangle... however, we can still save half the job my making a first FillMemory with the first byte, then change the value of the remaining 1/2 bytes

 

But the greatest advantage in this will be copying parts of it.

 

We'll be able to copy portions of the map directly in the selection really quick

[L.C.]

Could you add an option to be able to turn off the splash?

[Samapico]

Could do that

 

Thought about doing it, actually, but I figured I'd do it only when people complain

 

What bothers you about it, actually?

It unloads as soon as the main window is done loading, so it shouldn't make you waste any time

 

 

wow... I used ' ' on EVERY line of this message...

[RiiStar]

No Splash = slightly improved runtime?

[Samapico]

Well, you gain the millisecond it takes to load it... that's about it

[Sketter]

Leave the splash screen. It serves the programmers right to let their name be known. It only loads for a second.

But maybe invest in a new easy/cooler one.

 

Sketter

[Samapico]

I hope no one still uses Windows 95/98... I'm about to use the TransparentBlt API from msimg32.dll. And apparently it has big memory leaks in win95 and 98, so for these OS i'll have to use an uglier 'manual' way of doing it that is much less efficient.

 

For everyone else, this seems to allow us to make transparent drawings as fast as non-transparent drawings... which was an issue for us before. So the result of this will be MUCH nicer LVZ display, and we'll be able to show the layers correctly. What is under the tiles will be under the tiles, and what is over them will have correct transparency. Not that pseudo screws-all-the-colors transparency

[Drake7707]

that uglier method being the method it uses now ?

 

I remember already trying to use TransBlt :/, something didn't work iirc, dno