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

[Lunick]

Micky C, on 14 December 2012 - 04:00 PM, said:

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

I didn't know we were porting eduke to Nintendo 64 (jk)

Glad to see 54-bit getting some love!

[Hendricks266]

I need someone to test if joysticks work:

(edit: I know it won't work, give me a few minutes.)

(This include potential fixes for ebacktrace and DirectInput.)

[Hendricks266]

Fixed build: http://hendricks266....est_20121215.7z

This time I verified in GDB that my changes actually took effect.

[Hendricks266]

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

Added 3) Pow menu slots say invalid value
duke0000.png

This must not be in the released v1.2 from 2011/03/10. You're lucky mods have access to private forums so I can have a shot at actually debugging this.

[Kyanos]

Well, somebody turned all that fancy pow stuff off in our new development code, which is the root of Knee Deeps code, which is where that screenshot is from. I forced the pow menu to work, and am no doubt responsible for that error with poor coding. (it's my first release)

I have a controller and will test that too.

Added: It works. I'm dizzy. Keyboard and mouse for me.

[Hendricks266]

Drek, on 15 December 2012 - 06:22 PM, said:

It works. I'm dizzy. Keyboard and mouse for me.

Thanks.

Could you retest the three problems you mentioned earlier using both the 64-bit you used to test joysticks and the latest (32-bit) synthesis build? I need to know if these are problems actually caused by 64-bit.

[supergoofy]

r3300 win32 binary build includes ebacktrace1-x64.dll,

probably for the directinput fix ion 64bit Windows.

[Hendricks266]

No, the DirectInput fix is internal to the executable. I committed the ebacktrace 64 dll to the package directory for convenience, so I wouldn't have to redistribute it with every new 64-bit build I make, and because I shrunk the size of the 32-bit dll from 5 MB to 1 MB anyway.

I didn't know it then, but we'll be seeing 64-bit builds in synthesis soon, so it will be useful.

[supergoofy]

Many thanks for the info and all your efforts for the 64bit binary

[Kyanos]

Just reading this now, sorry. I did test out the other issues. Save games fixed. Other issues stay the same.

I will do some more testing with both 32 and 64bit builds and add to my findings soon. Although I did go back to 32 bit to confirm before I posted bugs.

[Helixhorned]

Revision 3303 includes more classic-like fog/visibility code, toggled with "r_usenewshading 2". It's actually the new default, so if you stuck with the deficient "r_usenewshading 1" before, you might not need to change anything. The difference is clearly seen in maps like E3L4, or wide open maps. Visibility 240 should now also work as expected. Check it out and tell me what you think!

edit: you also may want to set the other shade/visibility-related options to neutral values. That is, "r_ambientlight 1", "r_shadescale 1".

[Fox]

Is it me or it seems palmaps are not working in newer versions?

[Mike Norvak]

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

Revision 3303 includes more classic-like fog/visibility code, toggled with "r_usenewshading 2". It's actually the new default, so if you stuck with the deficient "r_usenewshading 1" before, you might not need to change anything. The difference is clearly seen in maps like E3L4, or wide open maps. Visibility 240 should now also work as expected. Check it out and tell me what you think!

edit: you also may want to set the other shade/visibility-related options to neutral values. That is, "r_ambientlight 1", "r_shadescale 1".

Missed this!! Thank you Helix, gonna check it later.

EDIT: Now vis 240 works like expected, the problem comes with higher visibility values (241-255) where it becomes even more foggy. For example a 243 value in newshading = 2 looks like 254 in newshading = 0, a 253 value in ns = 2 looks like 64 in ns= 0. You may wonder: why he needs to use higher visibility values and not stick to 240?, the reason is that in 240 there's not fog at all so to make it a little bit more foggy you need to use higher visibilities, is like if the scale beginning at 255 and ends at 240.

I have maps with 250 vis that now looks even more foggy, there's no problem on turning to 243 or so, but if for some reason the system is changed again the map will look different again, and that's not the way vis should work anyway.
Hope you could check this issue. Thank you!

[Hendricks266]

Fox, on 18 December 2012 - 08:47 AM, said:

Is it me or it seems palmaps are not working in newer versions?

Do you mean highpal? Palmaps got nuked years ago for sucking.

[Helixhorned]

Norvak, on 18 December 2012 - 09:25 AM, said:

but if for some reason the system is changed again the map will look different again, and that's not the way vis should work anyway.

Agreed! I should have better said "fog that's almost perfectly close to classic", so the intent is to never change it again. And the old visibility determination can be toggled with the mentioned cvar, after all. FYI, classic's fog can be expressed in terms of a starting and ending distance, interpolating linearly in between (and clamping to full visibility on the near side and full darkness/fog on the far side):

dist_start = -D*shade/combvis
dist_end = D*(numshades-1-shade)/combvis,

where

numshades := 32,
combvis := globalvisibility * mod(visibility+16, 256),
D = const.

In contrast, the old Polymodes' fog calculation used a totally different kind of equation, making it impossible to always look the same as classic.

edit: corrected and edited the equations.

[Fox]

Hendricks266, on 18 December 2012 - 10:17 AM, said:

Do you mean highpal? Palmaps got nuked years ago for sucking.

Yeah, I meant highpals.

[Micky C]

Seems that .ogg music files reverberate along with sounds around the ecco effect in maps. I'm guessing it's because the music is played through the sound system and this can't be changed?

[Hendricks266]

By all means it should be changed. Is there a location in the original game where I can test this?

[Micky C]

Well I tried it out in the sewers in E1L2 and you can't really tell the difference, which might explain why this bug has gone unnoticed or whatever. I was playing a (beta) user map which had the effect turned up really high and it made the music incredibly tinny.

[Fox]

While working in a mod, the limtations and inconsistencies with the screen drawing commands often became a problem. Normally I use rotatesprite16, but gametext is necessary for drawing a text and it doesn't have the same accuracy. And frankly, overall the screen drawing seems very primitivee.

I would propose to have a new command that covers both fuctions of displaying tiles and text, and by having an entry for the quote which would display a text whenever the value doesn't equal -1. I also would like to define the horizontal and vertical scale independently, accuracy (which a value of 65536 would make it work like rotatesprite16), text spacing, and translucency (even if the function itself has not been implemented yet in Eduke32).

Other than that, I would look forward new orientation flags, which would control the text-align, and compatibility with hard-coded alphabets (by default gametextz will use STARTALPHANUM character set, which diffs from BIGALPHANUM).

[Mblackwell]

http://wiki.eduke32....iki/Orientation has bits for translucency? Not sure what else you'd like to do with it that means it wouldn't work for it, you'd have to post an example. Also you define the tile set you'd like to use with gametextz, so you can easily make a completely new font.

As for screen position, the different bits to set screen/tile orientation are important for accurate positioning, but in addition it is already possible to get the current screen size and with math magic do the positioning based on that.

http://wiki.eduke32.com/wiki/Xdim
http://wiki.eduke32.com/wiki/Ydim

[Fox]

Mblackwell, on 23 December 2012 - 07:14 AM, said:

http://wiki.eduke32....iki/Orientation has bits for translucency? Not sure what else you'd like to do with it that means it wouldn't work for it, you'd have to post an example.

Gradual translucency, ranging from 0 to 255. Even if the function doesn't exists yet in Eduke32 for tile on screen, it would be good to have it already predicted.

Mblackwell, on 23 December 2012 - 07:14 AM, said:

Also you define the tile set you'd like to use with gametextz, so you can easily make a completely new font.

I am speaking of character set, not tile set. Gametextz only work properly with STARTALPHANUM out of the default fonts in the game, because it uses only the Microsoft standard character set.

Mblackwell, on 23 December 2012 - 07:14 AM, said:

As for screen position, the different bits to set screen/tile orientation are important for accurate positioning, but in addition it is already possible to get the current screen size and with math magic do the positioning based on that.

http://wiki.eduke32.com/wiki/Xdim
http://wiki.eduke32.com/wiki/Ydim

All those forms are ugly hacks with side-effects.

[Mblackwell]

Side effects? I'm using it without side effects to erase unwanted portions of images at any resolution. The trick is to multiply by 65536 before doing your math.

Unless you can post a good use-case/example I don't think the request is going to get much attention, since there are quite a few ways of doing what it sounds like you'd like to do already.

[blizzart]

Is there a reason why ifvrate.exe is removed from the samples directory in the newer builds (rev. 3245 and newer)?