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

[LeoD]

blizzart, on 29 December 2012 - 03:50 PM, said:

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

Its handling has been adapted to the other Build utilities:
-No distribution of binaries within the EDuke32 synthesis builds.
-No automatic build with make unless you use a certain command, I think make utils.

IIRC Hendricks266 distributes Windows binaries of the utilities every now and then, but I can't find them right now.

[supergoofy]

http://hendricks266....dtools_r3164.7z

[Hendricks266]

I build new set of the tools every time there is a change to the tools themselves. Which reminds me, I am overdue with building a new kextract. (I added functionality so that the modification time of the GRP is propagated to all extracted files. It's handy if you keep your collection of all the GRPs with the original file modification dates intact.)

I keep the Win32 binary link updated here: http://wiki.eduke32....iki/Build_tools

There should be some way for Helix, rhoenie, and I to access Dukeworld so we could store important stuff there, like Helix and rhoenie's OS X builds, and my builds of the Build tools and EDuke32 Wii.

[Mark]

I forgot how to turn off shadow casting from the SE50 spotlight. Can someone refresh my memory. I couldn't find the info after searching around.

[Micky C]

You press 1 on the SE to make it one sided. It's just a few pages back in this thread.

[Mark]

Thanks. Sometimes I guess I don't punch in the proper search words.