MTM2.com

I would have posted this on the Main but it seems to be non-exisitant at the moment... anyway, this forum is probably just as good.

Yesterday arvo I was looking at the BINedit source code that OP has released. Since no other programmers have stepped forth to try updating it, I thought I might have a crack at it and see if I can get it to run on WIndows NT systems. After all, it'd be good practice/study for the programming course I'm doing to mess around with code (my lecturer is very big on us writing/modifiying a program at least 5 times a week... hmm I've only got like 30 to catch up on).

Now don't hold your breath for anything - I've only been studying C and C++ for about six or seven months now, and BINedit is way out my league. I can understand maybe 20% of the code and guess at about 20% more, the rest is just arcane to me. But I know that most of it works under WinNT systems, and a few things don't, so I intend to concentrate on the things that don't and see if I can fix them (hopefully without breaking more things than I fix).

Most of these bugs are probably mostly down to the fact that WinNT uses a slightly different code base to the Win9x systems BINedit was written for, which is what makes me think I can fix them - I just need to find the Win9x-specific line(s), and change them for one that works with WinNT.

What I need are detailed descriptions of the bugs you get with the program when you try to run it under a WinNT system. I know that BINedit runs fine under WinNT, but the title bar displays corrupt text and you can't save your work. And that's all I know - it would help greatly if people could give me more detailed descriptions of what actually happens here, so I could better isolate the slabs of code I need to look at. For example - how much of the titlebar text is corrupt (I assume it's all of it)? What exactly happens when you select "Save" from the menu - the dialogs pop up but the save dialog doesn't appear, or does nothing happen at all?

If I can sort these out, I'll also try to fix the other bugs we've come to live with (I know there's one with the texture mapping window that can crash the entire program, plus there's the mysterious memory drain) and generally just add stuff to it. This of course could be 6 or 12 or more months down the track, so like I said don't hold your breath - this is just me messing around.

Good stuff, Dave!
I have no idea about the NT leaks, but I do know that the memory leak is graphics-related. It's the worst with the 2d views on (I bet it's related to that flicker - allocating a new buffer without releasing an old one?), and pretty much disappears with the 3d only option. It can sit for hours and hours, but as soon as you start moving the model around on the screen, it goes nuts.

Hope this helps. You probably know all this by now, but.... well, hey.
-Angus


Keep on truckin!
http://angus.karf.net/
[img]http://angus.karf.net/smsmash.gif"%20width=75%20height=75%20alt="Angus's%20Smiley%20Smasher[/img]

is there any chance I could get a copy of the code? my sons been studying c++ for close to two years now and may be of some assistance in identifying the lines that need updating.

[edit] thanks

[This message has been edited by Malibu350 (edited 31-07-2001).]

Sure can! http://www.viaregio.de/pieper/index.shtml is the main site. He says on the bottom that he's moved the BINedit site and released the source. Click on there, and you're laughing (likely accompanied by cheers from the MTM community)
-Angus


Keep on truckin!
http://angus.karf.net/
[img]http://angus.karf.net/smsmash.gif"%20width=75%20height=75%20alt="Angus's%20Smiley%20Smasher[/img]

Angus - If I'm reading your message right (I'm a little wired just now, so there's a chance that I'm not) I think the flicker you're talking about is just the screen repainting itself. When something changes and you want the program to show that change, you get it to erase what was there and repaint itself. You can tell it what region of the screen to repaint, but to make it easy on yourself you can just tell it to repaint the entire display, which it seems is what OP has programmed it to do whenever anything changes (whether cycling through faces or vertices, or rotating the model).

The flicker becomes noticeable with the 2D wireframes on because the program has to erase the entire screen and redraw everything. With a complex model, it can take it a little while to redraw all those lines. As far as I'm aware, the flicker is completely normal.

You could be right about it not releasing buffers and so forth, though. I've noticed that when you close BINedit, you don't gain back the system resources it was occupying until you restart your computer. I suspect that there might be graphic device context handles not being released when the program is terminated, or something like that (though I'd be surprised if someone as advanced as OP was doing this in his code).

>>you don't gain back the system resources

Perhaps you can clarify for me, but my understanding is that that is a myth. Are you talking below the 640k threshold of memory allocation or above? I have never, and I mean NEVER, had a problem with binedit and memory. It behaves the same as any other program running in the windows scheme of memory management. I heard rumors that under win95 there was a concern on some systems but that was cured with win98 (or the 2nd service pack), which again points to the OS rather than binedit. But if you mean below 640, well then I've never checked that. Reason I bring all this up is I'd hate to see you chasing your tail on this one; your time can be better spent. The only other thing to consider would be if win98 includes a routine that makes up for any deficiencies in programs. That would be something different again.

Yes Dave, I'm talking about the redraw time. I've done a fair bit of graphics work myself, and most of my stuff used at least one offscreen buffer to draw to for each update. My thought is that if OP doesn't release his old buffer handles, each one would take up a bit of memory. Using Norton System Doctor or some other similar tool, it's easy to watch the User resources fall away.

No, Phin, 640k isn't a problem with Windows. The swap files are what most memory access is handled by. The old divisions of memory don't exist anymore. There is no "upper", "high", "main" or any other kind of memory, it's all just... there. Actually ending up in the first 640k would be pretty rare for anything to do with Windows, especially because very little information is actually put in the RAM, mostly just OS information and stuff needed immediately, like onscreen dialog boxes, etc.
-Angus


Keep on truckin!
http://angus.karf.net/
[img]http://angus.karf.net/smsmash.gif"%20width=75%20height=75%20alt="Angus's%20Smiley%20Smasher[/img]

Phin - probably there is nothing to the memory thing... most of the time I've used BINedit it's behaved just like anything else would in regards to resources taken up and claimed back (tho it does sometimes take up an awful lot). Though I have had it really **** the life out of my system when some other program runs with it, like the screensaver kicking in for a while, or when I decide to tempt fate by running WinAmp - you see the Resource Meter dip below 15% free, and it doesn't reclaim most of the resources back until you restart. But yeah, that's probably attributable to other things.

Of course, I wouldn't chase pahntoms like these until I've sorted out everything else that needs sorting, and that we have concrete knowledge about (eg. Saving models, corrupt titlebar text and the bug with the Face Mapping window). And there's no guarantee I'll understand enough to fix those to begin with...

LOL, this forum has a word-censor thingo? Sheesh, the words they choose to censor...