[Fox]

That's the plan I already had in mind.

[Plagman]

It'd be slow as hell with smaller steps, though. You'd probably only want to be doing at map load, and you're out of luck if sectors change shape after that.

[Fox]

It won't be a problem for me, I am going to calculate the area of something as simply as this:

[Kyanos]

What's going on here with the dlls? I planned on releasing an add on for Wgr2 soon with instructions to get the latest version of Eduke32 for better performance. Now it won't run without deleting preexisting dlls in the released version of wgr2.

[Hendricks266]

The DLLs in question are nedmalloc.dll and ebacktrace1.dll, right? ebacktrace only runs for the debug exe, and nedmalloc should work. At some point the DLL was updated so maybe that's the cause.

The latest synthesis (r3250) has both DLLs properly packaged.

[Kyanos]

When I use it ( I only copy over exuke32.exe and nedmalloc.dll ) it won't run. I'll do some more investigating when I get back to my PC. Rev. 3219? Is the last one I was working with and it was fine.
Polymer has improved a lot in the past year and a half so I really want to use a newer executable.

Added.
R 3250 eduke32.exe will not run.
This is tested in its own freshly unzipped folder. It won't bring up the start menu or anything. The debug exe does work.

[Helixhorned]

Does it run without nedmalloc.dll? In any case, it's safe to remove and I recall TX saying that it doesn't matter much on newer Windowses.

[Kyanos]

It just doesn't run. Unzipped by itself, run eduke32.exe or mapster32.exe nothing. the debug.exe files run.
I'm not talking about wgr2 anymore, just the synthesis download as is doesn't work.

edit:
I'm using windows 7, haven't changed anything on my end in ages, these packages are always just extract and run for me.

[Plagman]

Is 3233 the first one that breaks for you?

[Kyanos]

 Plagman, on 02 December 2012 - 01:12 PM, said:

Is 3233 the first one that breaks for you?

Confirmed.

[Plagman]

OK, it's reverted until we figure out what's wrong with the native cross-compiler we switched to. Can you confirm 3251 works again?

[Micky C]

Is there any progress on finding that bug that causes sprite shadows to be incorrect at some angles? The project it will be useful for will probably be out in a week if that's any motivation. It's not a game breaking bug but if it's going to be looked at in the near future at all it would be nice if the fix was squeezed in before the deadline.

[Kyanos]

 Plagman, on 02 December 2012 - 03:26 PM, said:

OK, it's reverted until we figure out what's wrong with the native cross-compiler we switched to. Can you confirm 3251 works again?

All better. Thanks guys.

[Daedolon]

Fox, on 01 December 2012 - 11:36 PM, said:

I was thinking "That looks like a nicely laid out, classic level design." and was about to congratulate you for it...

Still, it's a nice design.

[rasmus thorup]

Can't get more classic literaly.

[TerminX]

Sure you can... Catabomb 3-D map remakes, anyone?!

[Inspector Lagomorf]

TerminX, on 07 December 2012 - 08:48 AM, said:

Catabomb 3-D map remakes, anyone?!

I see what you did there.

Where are the doors in that map? There are red lines where they're supposed to be. Are they just masked walls?

[Fox]

Paperthin walls

[RichardStorm]

Damn, that map is 1st level of Wolfenstein3d ! (I think...)

[rasmus thorup]

I dunno, but it's also map 31 in doom 2. In doom, the secret just before the exit of this level leads to the next secret map in doom 2, grosse. What does it lead to in the real wolfenstein game?

[Fox]

It just leads to a secret level. The "grosse" level was the boss level from the first episode.

[Inspector Lagomorf]

Fox, on 07 December 2012 - 09:14 AM, said:

Paperthin walls

Have fun making sliding doors out of those.

The amount of wasted effort that always went into building those annoying sliding doors in Duke Nukem 3D pretty much guaranteed that every door I made in my map was a Doom-style door...

[Jan Satcitananda]

Can somebody tell what happened to the setaspect command? Apparently it doesn't correct for the ratio distortion of onscreen rotatesprite routines with no regard to current render settings, just scaling them down instead. In classic renderer this began to occur since r2915...

[Helixhorned]

CraigFatman, on 09 December 2012 - 04:02 AM, said:

Can somebody tell what happened to the setaspect command? Apparently it doesn't correct for the ratio distortion of onscreen rotatesprite routines with no regard to current render settings, just scaling them down instead. In classic renderer this began to occur since r2915...

This is probably due to r2913. Unfortunately, setaspect() is called internally from various places and it's hard to predict the effect of those code changes to CON. For a quick workaround, does setting r_usenewaspect to 0 give the desired results? I try to keep the drawing behavior as close to the original as possible with new aspect determination off. If you prepared a small stand-alone CON mutuator showcasing your particular problem that is loadable with versions before and after r2913, I could give it a deeper look.

So I'm sorry that those changes probably broke your drawing code, but the real problem is that those commands were never really well-specified; they were exposed when not even we knew exactly their full behavior.

[rasmus thorup]

Achenar, on 08 December 2012 - 09:09 PM, said:

Have fun making sliding doors out of those.

The amount of wasted effort that always went into building those annoying sliding doors in Duke Nukem 3D pretty much guaranteed that every door I made in my map was a Doom-style door...

All hail futuristic maps

[Hank]

rasmus thorup, on 09 December 2012 - 05:44 AM, said:

All hail futuristic maps

Hardly anyone updated info through the years

http://wiki.eduke32....i/Sliding_Doors
This simple way of sliding doors was developed in 1998 by Ursurper. I added this to the wiki. No one reads it.

[Helixhorned]

Helixhorned, on 09 December 2012 - 04:47 AM, said:

Unfortunately, setaspect() is called internally from various places and it's hard to predict the effect of those code changes to CON.

Somewhat related, would anyone object to removing the "pixel doubling" option for classic? If it was supposed to speed up things, then it failed -- it needs to draw the scene into a tile and display that with rotatesprite. Besides, it only gives trouble with other draw-to-tile functionality, such as when rotating the view (rotscrnang) and probably doesn't work correctly with new-aspect on. It's one small step toward cleaner fullscreen drawing interfaces from the script.

[TerminX]

Achenar, on 08 December 2012 - 09:09 PM, said:

Have fun making sliding doors out of those.

The amount of wasted effort that always went into building those annoying sliding doors in Duke Nukem 3D pretty much guaranteed that every door I made in my map was a Doom-style door...

When I made maps as a kid, I just copied them out of official maps (usually the one from the beginning of E1L3) and pasted them into mine.

[Jan Satcitananda]

Helixhorned, on 09 December 2012 - 04:47 AM, said:

If you prepared a small stand-alone CON mutuator showcasing your particular problem that is loadable with versions before and after r2913, I could give it a deeper look.

So I'm sorry that those changes probably broke your drawing code, but the real problem is that those commands were never really well-specified; they were exposed when not even we knew exactly their full behavior.

Sure. It should be noted that the problem was present in the Polymost mode for a while before this behavior has affected the classic mode as well. You can check this sample script:

include GAME.CON

gamevar x 0 0
gamevar y 0 0
gamevar z 0 0
gamevar a 0 0
gamevar picnum 0 0
gamevar pal 0 0
gamevar shade 0 0

onevent EVENT_DISPLAYREST
  setaspect 65536 65536 // Setup 1:1 ratio
  setvar x 64
  setvar y 64
  setvar z 65536
  setvarvar a totalclock
  setvar picnum FEMPIC2
  setvar pal 0
  setvar shade 0
  rotatesprite x y z a picnum shade pal 0 0 0 xdim ydim
  addvar x 64
  rotatesprite x y z a picnum shade pal 0 0 0 xdim ydim
  setaspect 65536 78643 // Restore default 240:200 ratio
endevent

This is how it looks in r2877. The 8-bit mode (top) shows both tiles as rotating squares next to each other, as they are programmed to look. Now if we switch to Polymost, they react to the presence of the setaspect command by simple scaling. Moreover, their size and vertical placement begin to differ what is apparently makes no sense (the first sprite to display has a different scale as compared with the rest).




The difference between this and newest EDuke32 builds is that the classic now behaves the same way as the Polymost. Actually this renders me unable to display on-screen graphics with arbitrary aspect ratio, so I suppose that it should be reworked in the fashion it was before for both modes.

[Hendricks266]

Helixhorned, on 09 December 2012 - 08:23 AM, said:

Somewhat related, would anyone object to removing the "pixel doubling" option for classic?

Please banish pixel doubling to hell.