[Daedolon]

https://forums.duke4.net/public/style_images/cgs/snapback.png' alt='View Post' />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.

0

[rasmus thorup]

Can't get more classic :P literaly.

[TerminX]

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

[Inspector Lagomorf]

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

Catabomb 3-D map remakes, anyone?! :P

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

http://i1110.photobucket.com/albums/h441/Fox_969/capt0003.png

[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. http://forums.duke4.net/public/style_emoticons/default/tongue.gif

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

http://img21.imageshack.us/img21/9514/aspbug1a.png
http://img442.imageshack.us/img442/6884/aspbug1b.png

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.

[Hendricks266]

Big updates (from my perspective, at least):

Helixhorned, on 05 November 2012 - 04:48 AM, said:

I think the tilesiz* arrays are still inaccessible from CON.

TerminX, on 05 November 2012 - 08:32 AM, said:

The access could be pretty easily added to CONs, just need some stuff merged into the EDuke32 CON system from the Mapster32 system.

Done:

r3274 said:

Port system gamearray access from M32Script to CON. Expose tilesizx and tilesizy.

I also added support for building 64-bit Windows executables. We are not planning on distributing packages containing 64-bit exes, but they may be of some use.

At present, 64-bit builds have some drawbacks:

• DirectInput is broken--this means that you will get an error if you have a joystick plugged in at runtime. Mouse and keyboard are unaffected. Fixed.
  
• ebacktrace needs special attention to be ported to work with the structure of 64-bit executables. FIxed.
  
• The classic renderer will be measurably slower compared to 32-bit builds because Ken's ultrafast ASM code is 32-bit, forcing other architectures to use the slower C ports of the code. This is the only truly endemic drawback and is unlikely to be resolved anytime soon.

If you are interested, you can take a look at the updated build instructions. If there is enough interest, I could post some 64-bit binaries for the curious, but not regularly.

On a related note, the 32-bit build setup has been simplified because the DirectX headers and import libraries are completely self-contained now, no longer an external dependency.

[supergoofy]

Sorry to write this here, GOG.com has Duke Nukem 3D: Atomic Edition free of charge (just by creating an account you get it).
http://www.gog.com/g..._atomic_edition


Does this mean that we can now share it, freely ?

[Tetsuo]

Maybe if it's not a limited time offer but I don't think that's automatic.

[Hendricks266]

No. GOG has special distributor rights and is putting on this promotion for a limited time. Once the window is over, everything is back to normal.

[supergoofy]

@Hendricks266, thanks for your answer


and most important big thanks for your changes for an 64bit build. I'm looking forward to the future when all problems (especially the old ASM code) be fixed and the needed code parts ported to 64bit. Thanks man from the bottom of my heart. I believe a pure 64bit binary will boost eduke32's performance even further.

[Jan Satcitananda]

Helixhorned, on 11 December 2012 - 02:10 PM, said:

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

Yup... I'll have to stick to older builds until this is resolved. What about having a special command for altering the aspect of HUD graphics to maintain the backward compatibility?

Quote

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.

If so, how do you intend to display the HUD correctly? It's pretty obvious that the scene and the HUD in my case must be shown with different aspect ratio...