[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.

[MusicallyInspired]

I like pixel doubling when playing in 8-bit mode and I want the original experience, because my monitors just aren't capable of 320x200/240 . Playing at 640x480 and enabling pixel doubling fixes this. Of course, I DO have an old 486 for the classic experience.

[TerminX]

It's not really "doubling" though (kind of a misnomer as far as the menu is concerned, which is my fault). It just makes it look like shit. I would be in favor of turning it into actual pixel doubling on the rendering side...

[Inspector Lagomorf]

Yeah I just tried pixel doubling and it crashed my PC. I guess I'm doing it wrong.

[Hendricks266]

TerminX, on 09 December 2012 - 03:49 PM, said:

I would be in favor of turning it into actual pixel doubling on the rendering side...

This sounds good.

[Helixhorned]

In PM, zykov eddy called my attention to discrepancies in the way visibility fog is handled in classic vs. OpenGL renderers. In particular, the fact that dark areas are too dark when viewed from a distance. This is all my fault, particularly due to revisions around r1943:

Quote

* New shade/visibility calculation code, which is activated with 'r_usenewshading' (on by default), and is closer to the classic look. Also tweak the FOGSCALE macro to have approximately the same fog distance with all renderers.

I really tweaked the fog factor to look closer to classic (a permanent goal, if you ask me) for a simple test scene, but overshot it for large distances. So if your open maps became darker in a way that looks wrong, the solution is to use the old GL fog factor calculation method by setting r_usenewshading to 0. With usenewshade on, I'll probably have to throw in another round of tweaking (or better, finding out the actual equation used by classic and rewriting to fit the GL fog), but hopefully the change won't be that drastic.

edit: oops, it's r_usenewshading.

[Helixhorned]

CraigFatman, on 09 December 2012 - 01:51 PM, said:

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.

That the behavior was adapted to the GL renderers was deliberate. The past history to this was r1658, in which TerminX added widescreen support to rotatesprite in OpenGL modes. Old behavior could then be specified by setting bit 1024. On one hand, this was a non-backwards-compatible change, but on the other hand you really want the engine to correct the aspect -- in your case, the rotated FEMPICs would appear as lozenges/rhombi in widescreen resolutions. In r2911 and following, I took that code and made it also affect classic for consistency across all renderers.

Quote

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

Yeah, this is a real bug, fixed in r3265.

Quote

Now if we switch to Polymost, they react to the presence of the setaspect command by simple scaling.
(...)
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.

I see that this is a limitiation, but I'll have to think about how to best combine the different aspect state dependent behaviors in a way that doesn't introduce a host of new problems. Ideally, you'd pass the aspect to rotatesprite itself instead of having "hidden" state...

Quote

You can check this sample script:

// (...)
onevent EVENT_DISPLAYREST
  setaspect 65536 65536 // Setup 1:1 ratio
  // (...)
  setaspect 65536 78643 // Restore default 240:200 ratio
endevent

This is a little troublesome. As I noted on a different occasion, user code should be resolution- and aspect-agnostic. With r3265, the last setaspect will have no effect, as it's backed up and restored across the event.

[Fox]

I have spoken about this before, but there is an error in Eduke32 when checking sector / wall structures with ifvare command.

This code works just fine:

  getsector[MYSECTOR].floorpal TEMP
  ifvare TEMP 1
    <do something>

However, this doesn't:

  ifvare sector[MYSECTOR].floorpal 1
    <do something>

In fact, even something like this may fuck things up:

  setsector[MYSECTOR].floorpal sector[MYSECTOR].floorpal

Which is ridiculous, considering this is essentially redundant and should do absolutely nothing.

I have figured out that the problem occur when you check the ID of an sector or wall that is the same as the current actor.

For example, if my APLAYER actor has an ID of 43, and I use APLAYER to check the floorpal of all sectors in the map, it will fails to return the value of sector 43.