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

[Player Lin]

Hendricks266, on 12 December 2012 - 10:37 PM, said:

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.

http://www.gog.com/n..._nukem_3d_pcmac

This promo ended at 2012/12/14 14:59 GMT.

Seriously, I hate them.

[Fox]

[quote name='Hendricks266' timestamp='1355378110' post='143415']
[quote="Helixhorned"]I think the tilesiz* arrays are still inaccessible from CON.[/quote]
[quote name='"TerminX"]The access could be pretty easily added to CONs' date=' just need some stuff merged into the EDuke32 CON system from the Mapster32 system.[/quote']
Done:
[quote="r3274"]Port [url="http://wiki.eduke32.com/wiki/System_gamearrays"]system gamearray[/url] access from M32Script to CON. Expose tilesizx and tilesizy.[/quote][/quote]
Thanks for that... but where are the arrays for tile x-y offset?

[rasmus thorup]

Tilesize is a must. If you have textures with very different pixel sizes, it can mess up a lot.

[Helixhorned]

CraigFatman, on 13 December 2012 - 01:44 AM, said:

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?

Actually, I can get HUD graphics to stretch in r3280 using a modification of your code:

// x, y, z etc. omitted

gamevar orient 1040 0

onevent EVENT_DISPLAYREST
  setvarvar a totalclock
  divvar a 120
  modvar a 4
  mulvar a 16384
  addvar a 16384
  // a is now one of {1,2,3,4}*16384
  setaspect 65536 a

  setvar x 64
  setvar y 100
  setvar z 65536
  setvar picnum 4584 // has y size 100
  setvar pal 0
  setvar shade 0
  rotatesprite x y z 0 picnum shade pal orient 0 0 xdim ydim
endevent

But note how they scale with screen x dimension: for example, in 640x400, the sprite reaches exactly to the bottom of the screen, while in wider resolutions such as 800x400, it goes below it. So it can really be hard to write HUD code in a generic fashion when various elements have to align etc., but drawing them at a different aspect ratio works.

[Kyanos]

Quote

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

I'd like to see a 64-bit build for sure! I've not ever built my own Eduke yet, but I will sooner or later. Sooner rather than later now that I have reason to.

[Jan Satcitananda]

Helixhorned, on 13 December 2012 - 02:17 PM, said:

Actually, I can get HUD graphics to stretch in r3280 using a modification of your code:

Well, now I have to use the 1024 flag in the orientation parameter everywhere. Maybe I should have made use of it before, but I didn't know about it, seems like a relatively recent addition. Let's see if I can get my graphics to work properly with this. Thanks anyway.
By the way, the scaling without that flag is now done in a different fashion because of no setaspect_new()... and that doesn't look correct to me (because it results in gaps between sprites). You guys might wanna check if any custom graphics is broken in the current version.

[Hendricks266]

Fox, on 13 December 2012 - 08:57 AM, said:

Thanks for that... but where are the arrays for tile x-y offset?

typedef struct {
    uint8_t num;  // animate number
    int8_t xofs, yofs;
    uint8_t sf;  // anim. speed and flags
} picanm_t;
EXTERN picanm_t picanm[MAXTILES];

To expose this to CON, I would need to be able to define gamearrays in a manner like this:

tileanmnum[] = picanm[].num
tilexofs[] = picanm[].xofs
tileyofs[] = picanm[].yofs
tileanmsf[] = picanm[].sf

In theory I could add a flag that treats the arrayPtr value as a function, then make four one-liners to return the correct address. I don't know how that would interact with the other gamearray systems, including the copy command. This needs more thought.

[Fox]

Hendricks266, on 13 December 2012 - 07:06 PM, said:

tileanmnum[]
tilexofs[]
tileyofs[]
tileanmsf[]

That would be just fine for me.

[Hendricks266]

I didn't like the contributor credits scroller, so I wrote code to take the list and make columns.



Not yet committed. Design thoughts?

[Fox]

If you want my opinion, you should avoid as much as possible to use Duke 3D fonts. Why can't these credits be in the Eduke32 start menu?

But I guess it's better than the scrolling credits, it reminded me of those 90's html websites

[Inspector Lagomorf]

Fox, on 13 December 2012 - 11:49 PM, said:

If you want my opinion, you should avoid as much as possible to use Duke 3D fonts. Why can't these credits be in the Eduke32 start menu?

But I guess it's better than the scrolling credits, it reminded me of those 90's html websites

I can almost hear the MIDI music.

[Hendricks266]

Here is a 64-bit build. You will need to extract it over a synthesis build.

eduke64-r3283-20121214.7z

[Helixhorned]

CraigFatman, on 13 December 2012 - 04:56 PM, said:

Well, now I have to use the 1024 flag in the orientation parameter everywhere.

You're right. I checked LNGA2 and the widescreen-aware rotatesprite calls wreck the whole HUD. That's why there is a command-line-option to get the old behavior now:

r3284 said:

Add command line option "-rotatesprite-no-widescreen".

This global option will set bit 1024 and clear bits 256 and 512 for all
rotatesprite calls, fixing complex HUD drawing code relying on precise
alignment of individual elements (widescreen rotatesprite is entirely
unsuitable for this purpose).

[TerminX]

Hendricks266, on 13 December 2012 - 11:31 PM, said:

I didn't like the contributor credits scroller, so I wrote code to take the list and make columns.



Not yet committed. Design thoughts?

Approved! Though if we get many more contributors we're going to end up scrolling again...

[Kyanos]

Hendricks266, on 14 December 2012 - 10:36 AM, said:

Here is a 64-bit build. You will need to extract it over a synthesis build.
[/url]

Much thanks! I'll let you know how it delivers, I have some low framerate polymer maps that may just become playable with this. Fingers crossed.

[Jan Satcitananda]

Hendricks266, on 14 December 2012 - 10:36 AM, said:

Here is a 64-bit build. You will need to extract it over a synthesis build.

eduke64-r3283-20121214.7z

Whew, hail to EDuke64, baby! Gonna give it a try. Will it actually perform better in x64 OS than 32-bit one?

Helixhorned, on 14 December 2012 - 11:32 AM, said:

You're right. I checked LNGA2 and the widescreen-aware rotatesprite calls wreck the whole HUD. That's why there is a command-line-option to get the old behavior now:

Oh, thanks a lot, but I've already revised my drawing routines to use bit 1024. I think it's quite handy to have a set of pre-defined values for various orientations (here, C stands for corner, T for translucency, R for translucency reversal, Y for flipping and Q for no masking):

// Orientation presets

define OR_     0x400
define OR_Y    0x404
define OR_C    0x410
define OR_YC   0x414

define OR_T    0x401
define OR_YT   0x405
define OR_CT   0x411
define OR_YCT  0x415

define OR_TR   0x421
define OR_YTR  0x425
define OR_CTR  0x431
define OR_YCTR 0x435

define OR_Q    0x440
define OR_YQ   0x444
define OR_CQ   0x450
define OR_YCQ  0x454

By the way, savegames seem to be broken now (EDuke32 bails out with 'code 5' when trying to load a game).

[Kyanos]

64 bit FTW, almost a straight up doubling o' fps when rendering polymer lighting. Great work Hendricks!! I've started gathering the building tools, doesn't look too hard at all.

[Micky C]

Indeed there is a noticeable improvement in polymer with the lights. All hail EDuke64! (Looking forward to EDuke128 )

What are the CPP builds for?

[Hendricks266]

The C++ builds have no functional changes at present. They have been built as C++ instead of C. Within EDuke32, the only change is that certain structure variables are replaced with a class tracking changes made to them. In the future, the networking code will utilize this and EDuke32 will require C++ to build unless you disable networking. Some extra C++ stuff is also statically linked to the exe by the compiler to handle language features (like operators delete and new), though fortunately we avoid the STL completely. That's why they are about 300 KB bigger.