EDuke32 2.0 and Polymer! "talk about the wonders of EDuke32 and the new renderer"
#3295 Posted 14 December 2012 - 10:09 PM
#3296 Posted 14 December 2012 - 10:12 PM
Micky C, on 14 December 2012 - 04:00 PM, said:
I didn't know we were porting eduke to Nintendo 64
Glad to see 54-bit getting some love!
#3297 Posted 15 December 2012 - 04:50 PM
(edit: I know it won't work, give me a few minutes.)
(This include potential fixes for ebacktrace and DirectInput.)
#3298 Posted 15 December 2012 - 05:21 PM
This time I verified in GDB that my changes actually took effect.
#3299 Posted 15 December 2012 - 05:44 PM
Drek, on 14 December 2012 - 05:55 PM, said:
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.
#3300 Posted 15 December 2012 - 06:22 PM
I have a controller and will test that too.
Added: It works. I'm dizzy. Keyboard and mouse for me.
This post has been edited by Drek: 15 December 2012 - 06:46 PM
#3301 Posted 15 December 2012 - 09:46 PM
Drek, on 15 December 2012 - 06:22 PM, said:
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.
#3302 Posted 15 December 2012 - 11:10 PM
probably for the directinput fix ion 64bit Windows.
This post has been edited by supergoofy: 15 December 2012 - 11:15 PM
#3303 Posted 15 December 2012 - 11:51 PM
I didn't know it then, but we'll be seeing 64-bit builds in synthesis soon, so it will be useful.
#3304 Posted 16 December 2012 - 12:03 AM
#3305 Posted 16 December 2012 - 11:31 AM
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.
This post has been edited by Drek: 16 December 2012 - 11:34 AM
#3306 Posted 16 December 2012 - 11:32 AM
edit: you also may want to set the other shade/visibility-related options to neutral values. That is, "r_ambientlight 1", "r_shadescale 1".
#3307 Posted 18 December 2012 - 08:47 AM
#3308 Posted 18 December 2012 - 09:25 AM
Helixhorned, on 16 December 2012 - 11:32 AM, said:
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!
This post has been edited by Norvak: 18 December 2012 - 10:06 AM
#3309 Posted 18 December 2012 - 10:17 AM
Fox, on 18 December 2012 - 08:47 AM, said:
Do you mean highpal? Palmaps got nuked years ago for sucking.
#3310 Posted 18 December 2012 - 10:20 AM
Norvak, on 18 December 2012 - 09:25 AM, said:
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):
diststart = -D*shade/combvis
distend = 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.
#3311 Posted 18 December 2012 - 02:15 PM
Hendricks266, on 18 December 2012 - 10:17 AM, said:
Yeah, I meant highpals.
#3312 Posted 18 December 2012 - 03:11 PM
#3313 Posted 18 December 2012 - 11:39 PM
#3314 Posted 19 December 2012 - 02:33 AM
#3315 Posted 22 December 2012 - 11:34 PM
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).
This post has been edited by Fox: 22 December 2012 - 11:34 PM
#3316 Posted 23 December 2012 - 07:14 AM
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
#3317 Posted 23 December 2012 - 05:06 PM
Mblackwell, on 23 December 2012 - 07:14 AM, said:
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:
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:
http://wiki.eduke32.com/wiki/Xdim
http://wiki.eduke32.com/wiki/Ydim
All those forms are ugly hacks with side-effects.
This post has been edited by Fox: 23 December 2012 - 05:06 PM
#3318 Posted 23 December 2012 - 06:08 PM
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.
#3319 Posted 29 December 2012 - 03:50 PM
#3320 Posted 29 December 2012 - 04:05 PM
blizzart, on 29 December 2012 - 03:50 PM, said:
-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.
#3322 Posted 30 December 2012 - 02:19 PM
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.

Help
Duke4.net
DNF #1
Duke 3D #1


