DMap File Parsing

I finished the app, it correctly parses the DMap files and renders them to the screen (from what i could tell on the ones i tried, its slow because its using PSet plus its in vb, but at this point, i dont care about efficiency, i'll worry about that later, the fact is it works.

Refer to: [Only registered and activated users can see links. Click Here To Register...] for the COBot Project which this is part of.


I took this from my reply i made on my new bot i'm developing, i decided to make it it's own topic to possibly stir some interest in it and get some help on it? anyways, here is what i have, and i think this is right so far.

First 8 bytes appear to be a file identifier of sorts, i haven't exactly figured this part out yet.
the next 260 bytes, bytes 9 through 269, is the puzzle file, i guess they have it buffered this large just incase they need multiple puzzle files?
the next 4 bytes, bytes 270 through 274 is the number of x coordinates i believe.
the next 4 bytes, bytes 275 through 279 is the number of y coordinates i believe.
every 6 bytes after this, such as 280 through 286, 287 through 293, 294 through 300 and so on hold information on the coordinate
the first 2 bytes of it is the access i believe, the next 2 is the surface type, and then the last is the height.
after you have gone through all of the coordinates then i believe the portal data is there.
it looks like it has 3 parts of information, each one 4 bytes long, the first 2 being the x and the y location, but for some reason, it seems as though it only uses the first 2 bytes of it, so its wasting 2 bytes? i guess for neatness or incase for future plans? iunno, just pointing out what i observed. and the last one is the portal type. if anyone who knows for sure about this stuff can elaborate on it for me and tell me if i'm going in the right direction? then that would be great.

That sounds about right. What did you need elaborated?

~Chris

what does the surface type mean? what does the corresponding numbers mean, at what height does the game say "to high" or what ever, and does like 01 mean valid and something else mean invalid? And finnaly, the main thing, it seems like every 576 bytes of coords, there is 4 bytes of i dont know what, then another 576 bytes of coords, and so on, whats this 4 bytes for?

k, i got it, i'm attaching my PoC app in my first post, it parses the dmap file and then draws it to the screen. (slow as fuck since i'm using PSet, but i'm only using pset because it was easy as hell and easy to manipulate, personally i dont care about speed right now, this is development, i speed/clean things up towards the end).

Nice work.
Are you the Joolz that used to make CS hacks?

Very nice work.

How did you learn to analyze bytes and make the converter???

Hiyoal :D

Nice work but anyone who reads the readme might just get the impression you have some emotional problems to work through :p
I get that it's frustrating not to get any help but the few coders that are left here are mainly busy with their own work + it can be hard to spot a decent topic between all the crap ones.
Anyway hope you won't get demotivated by this forum because your work looks promising :D

Also: the drawing seems a lot faster when the app is in the background.

@RootCore yes... i am.

@hiyoal just picked things up over the years, i had times where i went to cracking apps and thats where i picked alot of stuff up from, thats after i left mpc and coding cs hacks... The app itself isn't a converter, all though it can be, and was as i was debugging everything, it saved all the valid coords per map to files, and at one point i accidentally forgot to take out it saving to a single file when i was testing it on just one map, and together the file went well over 5gb... yes... 5 gigs, so parsing the maps with each like saying like (x,y) only, for all the maps added together, it is about 5 gigs, plus it slowed it down, i might release another copy of it to allow the user to select whether they want to save the parsing data to a file, but as of right now, this just parses the dmap file, and renders it.

@mushypeas, yea, i could have it sped up about 20x but then the window looks like its frozen and will only display everything once its done rendering the map, so i opted to just throw DoEvents in the nested loops to let the computer do its shit and still beable to display everything as its happening. As for the readme, i'm just pissed because last time i started this bot project no one offered any help, and it died, then i restart it now, and still the same thing.

and thank you everyone for actually posting, has anyone found any problems yet?

Hey, I like your tool. Few suggestions. Make it be able to save the image file. Try using a buffer or similar to draw the image, graphic stuff in vb is possible and quick if done right. And increase window size for larger maps. Otherwise, not to shabby.

~Chris

Good worck +k :D

@ChrisR872, if i get the time, once i finish enough of the framework for COBot to where i can get a beta release of it, i might come back and add the saving image file... i already rewrote the rendering, it renders the map in about 2 seconds i think, big increase from before... and as for graphic stuff being possible to be quick, yea, it is possible for it to be faster than how i have it written now, but it will never be as fast as i want it to be, unless i write c# dlls and imported them to do it, but thats not in vb, vb will always have a shitload more overhead than alot of other languages, mainly c#, c++, java, especially asm, etc... but my thing for not consistently updating this to a full blown tool is that this was just a PoC for the pathing in COBot... and finnaly, you talking about increasing the window size for larger maps... it should, is it not? Because that i would go back and fix if it wasn't.

Draw the images, cache them, then just draw the portals and such over them.

How do you read DMAP files