lowskill. wrote:Oh you guys, if you like how GZDoom feels and plays, all I'm saying is that you're gonna love this after just a couple of minutes of use .
That's what I'm most excited for! I've always wanted to play most of the build games, but after a few minutes of use I just can't get past the "feel" of the engine. Especially the mouse and mouse look. If this actually looks and feels like GZDoom, I will be able to die happy
It isn't *quite* the same due to the way things are handled by the different engines, but rest assured it's extremely close to what you're seeing in GZDoom . An absolute improvement over vanilla Build and EDuke32.
The menu texts are all in a string table already, just like almost all other texts. That part is not an issue - and many texts that were available in GZDoom are already translated as a result.
The bigger obstacle is to handle the fonts. Thanks to Build's tile indexing and the shitty font organization it won't be easy to generalize the character output to allow characters outside what the games define. The available font printing code is nowhere near what ZDoom had in terms of quality.
There's also a space problem. Many translated texts will simply be too long for the available screen space.
Yes, it uses the same controller code. Whether this is better or worse than EDuke's I cannot say, but since EDuke's depended on SDL I couldn't keep it.
In what way was it terrible? I didn't notice anything really bad when I set up my old controller to have a look at the menus.
Keep in mind that even though this uses ZDoom's controller code, in-game it's still the same as before, so it depends on what problems you had whether this is better.
When the times comes perhaps the Blood palette could be implemented, on the texture and sprite level, rather than affecting the entire final output. Thereby avoiding drawbacks of the original renderers 8-bit output while retaining the intended color presentation.
@Graf: To be honest, it's better than it used to be. Setting up z-axis triggers was a bit of a crapshoot and sometimes, for me at least, button assignments wouldn't 'take' when assigning through the menu and I'd have to open the config file to assign them permanently that way.
An ongoing problem is that EDuke only seems to recognise the first controller on one's system. Unfortunately for me, I have a D-Input Sega Saturn style pad plugged in and I connect my Dualshock 4 through Bluetooth when I want to use it (ie/ for ZDoom). To play EDuke I have to unplug my D-Input controller and restart my PC - and then that screws up my controller assignments in RetroArch... it's pretty tedious.
markanini wrote:When the times comes perhaps the Blood palette could be implemented, on the texture and sprite level, rather than affecting the entire final output. Thereby avoiding drawbacks of the original renderers 8-bit output while retaining the intended color presentation.
That's already done with a palette emulation option that's being inherited from EDuke.
Graf Zahl wrote:The menu texts are all in a string table already, just like almost all other texts. That part is not an issue - and many texts that were available in GZDoom are already translated as a result.
The bigger obstacle is to handle the fonts. Thanks to Build's tile indexing and the shitty font organization it won't be easy to generalize the character output to allow characters outside what the games define. The available font printing code is nowhere near what ZDoom had in terms of quality.
The modern Duke3D re-releases that use localization (XBLA, World Tour) skip these problems by just using Truetype fonts, which while not fitting the game's aesthetic almost certainly reduced the number of issues to deal with!
Localization can only go so far for EDuke32, though, since many mods - including Ion Fury - embed strings directly in CON code instead of defining them as quotes first.
Getting to the strings in CON files isn't that hard, and already implemented. After all the compiler has to store them somewhere - it got a second array next to the one for quotes. And once the texts are in there they can be grabbed and run through the string table. I already implemented that part.
Regarding the TT fonts - ugh. No, that's not what I want to do.
It's mainly the technical side of the game fonts which causes problems here - the Build tile system makes it a lot more complicated to extend existing fonts than Doom's solution of having a list of glyphs indexed by character code. Not impossible but awkward. It gets compounded by Duke having changed the font with the Atomic Edition so there's two different ones that can take the same place. Extensions here can only be done by using checksums for the glyphs, not their place in the file system - because due to the ART files, some mods will have included them as well, even though they didn't change them.
All the rest is solvable. Since the menu code is entirely my own I could scale down the menu, just as GZDoom does, if texts become too large. The option menu code being the same as GZDoom's before scriptification is already ready for using localized texts
Rachael wrote:
But ultimately it will be optional, not forced.
If we ever want advanced lighting effects it must be optional. Since this code is doing the entire lighting by using 8 bit lookup tables there is no way it can ever work with dynamic lighting and even less with more advanced stuff.
Google This Site]
.
. An absolute improvement over vanilla Build and EDuke32.
