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

[Hank]

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

lost for words - I am impressed.

[Kyanos]

I've got two three bugs to report using Eduke32_64BIT.exe

1) Loading saved games crash for me. Obviously saved from this same build.

2) WGR2 monsters can be grouped using z-vel. Once all monsters of a group die they activate a tag. Using this build the tag is activated each time a monster dies in the specific group. ( similar code is used in duke plus too )

Added 3) Pow menu slots say invalid value


I will gladly test more 64 bit builds for you if you'd like.

[MusicallyInspired]

64-Bit build is nice! I always had nice framerate on my machine, but I notice a lot less jumpiness and glitches now!

[Fox]

TerminX, on 14 December 2012 - 01:22 PM, said:

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

[Hendricks266]

Drek, on 14 December 2012 - 05:55 PM, said:

I will gladly test more 64 bit builds for you if you'd like.

Thanks for the reports!

I created this wiki page to stay organized and serve as a proper to-do list that I can use as a reference. If you come across more issues please add them.

[Micky C]

Is the slower software renderer really that bad? I mean so what if you get 200 fps instead of 250.