Welcome to the ZDoom Forums!

randomlag wrote:This is problem on Windows 98 and/or if a program uses 16bit. Screen coordinates are processed as 16bit numbers in Windows98 no matter what the program uses. XP does support 32bit coordinates. So what you have to do is clip the stuff yourself since zooming causes overflow.

• Exactly what is meant by 'clip the stuff yourself' ???
  
  Why does that happen only in WinZETH and not in any other editor ?

Sorry for not offering this suggestion earlier:

What about Daedalus? It has about every example available for Decorate objects (at least the ones supported up to cab60 IIRC).

Great, thanks. My DECORATE loader wasn't working as well as I hoped (read: not at all), but with that I was able to get it fixed. It's still not as good as I would want, though. The code's pretty ugly, and it doesn't use the custom sprites to display, but they're selectable and viewable. I'll be working on it some more today.

Chris wrote:My DECORATE loader wasn't working as well as I hoped (read: not at all), but with that I was able to get it fixed. It's still not as good as I would want, though. The code's pretty ugly, and it doesn't use the custom sprites to display, but they're selectable and viewable. I'll be working on it some more today.

Very cool. When you need a tester, I'm available. The decorate lump for ED4 is growing by leaps and bounds. I'll be happy to test any WINZETH updates in our environment.

Thanks a ton Chris!

Kappes Buur wrote:

randomlag wrote:This is problem on Windows 98 and/or if a program uses 16bit. Screen coordinates are processed as 16bit numbers in Windows98 no matter what the program uses. XP does support 32bit coordinates. So what you have to do is clip the stuff yourself since zooming causes overflow.

• Exactly what is meant by 'clip the stuff yourself' ???
  
  Why does that happen only in WinZETH and not in any other editor ?

It DOES happen in other editors You might see it happen at different points though. For example, ZETH had this problem too. It is the main reason WA didn't zoom past 8 because he knew that 9x had this problem.

Clipping is checking the coordinates against the actual screen. So if a coordinate is way off the deep end (accidental pun), what you do is recalculate the coordinate so it "clips" to the screen edge. Or you can use an offscreen area and rather than using API's to "draw", do your own drawing into the buffer (clippping inside the buffer area instead).

Chris wrote:

Sorry for not offering this suggestion earlier:

What about Daedalus? It has about every example available for Decorate objects (at least the ones supported up to cab60 IIRC).

Great, thanks. My DECORATE loader wasn't working as well as I hoped (read: not at all), but with that I was able to get it fixed. It's still not as good as I would want, though. The code's pretty ugly, and it doesn't use the custom sprites to display, but they're selectable and viewable. I'll be working on it some more today.

And how can I forget to mention two WADs that test ZDOOM's Decorate lump for changes made in cab63/64:

Gary wrote:It may be useful to point him to a wad file that has examples of the cab 63 capabilities (new monsters). I'd suggest you point him to Nanami's monsters.zip or LWM's Hquest.

Here's a link to Nanami's zip:

http://koti.phnet.fi/repoes/monsters.zip

LWM's HQuest link is here:

http://home.midmaine.com/~lilwhitemo/hquest9.cab

Ok.. the problem I'm facing now is that ZETH wasn't originally designed to have multiple lumps of the same name (with levels being the exception of course). I made it so all the lumps load, but now it won't use the last-loaded lump. Two things I can do... One is to try another hack so it just searches for the last lump of a particular name, or another is to change the lump management system so it better matches something like ZDoom has currently. The latter of course taking more time to do, while being more proper.

Chris wrote:Two things I can do... One is to try another hack so it just searches for the last lump of a particular name, or another is to change the lump management system so it better matches something like ZDoom has currently. The latter of course taking more time to do, while being more proper.

Chris: if you are going to do this, do it right. I vote for the latter. ZETH is after all: ZDOOM Editor for Total Headcases!

I wonder how hard it would be to replace ZETH's wad handling code with genuine Doom code. Then getting it right wouldn't be a problem.

In all honesty I'm not sure how ZDoom does wad handling.. but what I'd attempt to do is something like this: First, log each wadfile seperately, each with its wadfile directory loaded. Then when you ask for a lump, it searches the last loaded wadfile, looking at the first entry to the last, then goes to the second to last wadfile loaded, etc,etc. In any case, it shouldn't be too difficult, though possibly time consuming.

Of course there's also another concern of mine. ZETH takes data loaded straight from disk and casts it directly to structures. This is quite evil since it can't take into account structure padding. The two things there I could do would be to manually go through those certain structures and add the packed attribute (this being GCC-only however), or I could look for a GCC commandline switch that automatically packs structures. Though this would be GCC only as well, I would hope other compilers would have a similar commandline option.

Hi Chris,

Any word on a new version of WINZETH?

Unfortunately not. My time has been stolen by another, highly anticipated (by me), project of mine. Working on the wad handling stuff, though, is really daunting since I a) want to redo all of it, and b) want to do it right, so I've been procrastinating. :/

Chris wrote:Unfortunately not. My time has been stolen by another, highly anticipated (by me), project of mine. Working on the wad handling stuff, though, is really daunting since I a) want to redo all of it, and b) want to do it right, so I've been procrastinating. :/

Still procrastinating? Yes, time for the monthly bump er.... inquiry.

Actually, it's not really a "bump", since it's a sticky thread.

Oh, well. Carry on. Ignore this post.

Yup, unfortuantely. If someone's willing to redo the WAD/resource handling code I may be more willing, though.

But really, I can see why Randy said ZETH was not a good editor to make a new one from, code-wise. It's so ugly and intermingled and messy.. that even when you know what it's doing you can barely work with it.

Hmm, what about Doom builder? I was under the impression that most of the important stuff was done in C, is that a correct assumption?