Rewriting Options/Menu Code

Discuss anything EDGE-related that doesn't fall into the categories.
User avatar
Coraline
Site Admin
Posts: 747
Joined: Fri Jun 08, 2012 11:22 am
Gender: Female
Contact:

Rewriting Options/Menu Code

Postby Coraline » Thu Feb 25, 2016 2:12 pm

Hi all,

I am in the process of rewriting the Options drawer. Basically, this is to ask what kinds of things you would like to see. Different layout, more options, cleaner text?

I have integrated some things like Crosshair scaling and more compatibility flags, but I would like to know what users and modders want.

Thanks!
\(סּںסּَ` )/ۜ

CeeJay
Posts: 209
Joined: Sat Jan 26, 2013 9:56 am
Gender: None specified

Re: Rewriting Options/Menu Code

Postby CeeJay » Sun Mar 06, 2016 9:23 pm

The thing I can think of is to better align all the texts. I've noticed that the big header texts are technically all over the place without any real consistency, these ones should probably always automatically be centered at the top. The main menu texts (new game, options, etc.) are also aligned differently than the skill and episode selections. It's a little jarring and most noticeable when you add your custom menus.

User avatar
Coraline
Site Admin
Posts: 747
Joined: Fri Jun 08, 2012 11:22 am
Gender: Female
Contact:

Re: Rewriting Options/Menu Code

Postby Coraline » Tue Mar 08, 2016 2:25 pm

Can you take pictures of what needs aligning? I can change the coords, but maybe a quick MSPaint of what isnt aligned. Then i can make changes, show screens, and we can keep tweaking it until it looks good.
\(סּںסּَ` )/ۜ

CeeJay
Posts: 209
Joined: Sat Jan 26, 2013 9:56 am
Gender: None specified

Re: Rewriting Options/Menu Code

Postby CeeJay » Tue Mar 08, 2016 8:40 pm

The problem is that 3DGE relies on both the X and Y of the lumps and internal engine alignment (or so it would seem). Wouldn't it be best if it just bypassed the lumps X and Y coordinates and instead make headers centered on top and the other texts changeable in styles.ddf? Centered center, centered left and centered right for these (longest text, per pixels, center and rest follow this one aligned either to the left or to the right or all centered). I'm of course no programmer, but is it difficult to make it automatically center-align a gfx on screen? Just seems like manually aligning each and every gfx individually is a lot of tedious work and makes adding custom menus difficult, as these may not have the same length and width as the originals. Check Duke It Out In DOOM, the option headers are all over the place. 3DGE would sort of center them but it was still off in places and I had to manually re-align a few, some even wen't off the screen.


Centered left

Centered right

Centered center

CeeJay
Posts: 209
Joined: Sat Jan 26, 2013 9:56 am
Gender: None specified

Re: Rewriting Options/Menu Code

Postby CeeJay » Wed Mar 09, 2016 1:11 am

Concerning the MAP05 issue (i was unable to post over at the homepage)...

See here...
http://imgur.com/a/gVAxY

A room behind the shotgunners is opened by a nearby switch revealing both of them and some armor. Once they leave the room (all non-solid objects that is) the door/room is slammed shut leaving behind an un-passable plain black wall which is what you see in the screenshots. What appears to be a similar issue occurs in the room surrounding the exit, where the cacodemons and imps reside. Both of these rooms are supposed to remain open, and certainly not leave behind a plain black wall. This is not a rare or obscure glitch, it happens every time I play the level and people have brought it up.

User avatar
Coraline
Site Admin
Posts: 747
Joined: Fri Jun 08, 2012 11:22 am
Gender: Female
Contact:

Re: Rewriting Options/Menu Code

Postby Coraline » Thu Mar 10, 2016 12:03 pm

I understand what is happening, and I might need to create a few RTS scripts to fix them, so it should not take me very long to fix. Being incorectly tagged with #9 when activated is the issue, so I will create RTS fixes for that map. This also might have been a bug in the original, where it would show a HOM. In 3DGE, it will just show a black texture unless debug_hom is set to 1 in the console.


As for the menu code, I am completely rewriting it based on Doom64 EX. This means no more support for LDF for the time being, until I get around to unifying the new code. This has the advantage of being lined up correctly and being much more responsive, and no longer relying on graphic patches for fonts (which is why LDF will not work for menus). New text drawing code replaces the ugly HL_WriteText functions, and uses OpenGL.

Right now the layout mirrors Doom 64's Options and Menu code, but as time goes on it will be changed slightly to accommodate LDF. If you have played Doom64EX, you have a perfect visual of how the menu system will work.

To accommodate the move to SDL2, I have completely dropped support for GLEW and its extension checking and replaced it with SDL_OpenGL (and completely removed the old r_modes file (scrnmode_t).

Now, one flag (r_glpath) will determine if your video card can use OpenGL 2. SDL2 also eliminated the resolution code, which now automatically picks screen ratio based on resolution that is selected. In short, less steps to take for much prettier video code and vsync performance.

The input, mouse, and joystick handling was also replaced. Now, we use DirectInput for joysticks and gamepad handling, and the mouse can now select game options in the menu.

Tons of overhauling to do, though. Just a quick update on the state of our SDL2 migration. Also, I am planning on supporting some stuff from ZDoom, such as sky handling (which is done in skydefs or something like that).
\(סּںסּَ` )/ۜ

CeeJay
Posts: 209
Joined: Sat Jan 26, 2013 9:56 am
Gender: None specified

Re: Rewriting Options/Menu Code

Postby CeeJay » Thu Mar 10, 2016 12:29 pm

Sounds like you're on top of things. By "LDF" do you mean languages.ldf? As in, support for it will become broken/unavailable with upcoming builds?

EDIT: I have played Doom 64 EX a little but It was quite a while ago and I can't honestly remember much other than it being more faithful visually than the older Doom 64 TC for Doomsday made by the same guy.

User avatar
Coraline
Site Admin
Posts: 747
Joined: Fri Jun 08, 2012 11:22 am
Gender: Female
Contact:

Re: Rewriting Options/Menu Code

Postby Coraline » Thu Mar 10, 2016 1:20 pm

Styles will be unavailable for menus - eventually, I will unify the new menu code with the styledef code. As of right now I cannot reliably support it, but I dont think this will be a big deal to be honest. The tradeoff is completely worth it IMO, as well as a nicer, much more modern and user-friendly system.

So, I know that might be disappointing, but Styles.cc itself needs an overhaul as well. This code will not affect RTS menus, however, but Styles will ONLY support RTS menus. It is just a little buggy is all. LDF will still be available for everything else but the menu options.

The entire menu setup has changed so I will update documentation shortly on that. Like I said, finally converted to a string system which took a lot of work. I also sped up the engine start system with an actual console window. I briefly thought about switching to Doom64s console, but it is kind of weird in its setup.

When I mention Doom64EX, I am talking about the engine itself (which is based on the old Doom3D codebase). Different authors, I believe. But if you fire it up, you can see how the menu system will now operate.

Its sort of funny - I just set out to redo just the Video code to support SDL2 and I ended up just throwing my hands up and redoing the entire damn backend!

The original EDGE suffered through constant updates to very old code. Case in point - the resolution code was overly convoluted and called 3 or 4 different functions on startup and kept the screen mode in a different class.

We dont need to test resolutions at startup nor do we need to test bit depth, since it will always assume bit depth will be 32. Partly this was due to SDL not always being part of EDGE (in the DOS days, it was Allegro). So, it was always hacked upstream, instead of being totally replaced for modern functions. Not their fault, but it was working against my efforts.

Part of "forward-thinking" I suppose, but it isnt 1999 anymore.
\(סּںסּَ` )/ۜ

User avatar
3rd_3ye
Community Manager
Posts: 291
Joined: Sat Jun 09, 2012 5:58 am
Gender: None specified

Re: Rewriting Options/Menu Code

Postby 3rd_3ye » Thu Mar 10, 2016 2:37 pm

Does sdl 2.0 change 3dges opengl 1.0 compatability?
The banlist has been updated successfully.

User avatar
Coraline
Site Admin
Posts: 747
Joined: Fri Jun 08, 2012 11:22 am
Gender: Female
Contact:

Re: Rewriting Options/Menu Code

Postby Coraline » Thu Mar 10, 2016 3:24 pm

No, it will still be CVAR based, we just wont be using GLEW. We are just letting SDL_OpenGL manage video code - this has nothing to do with the raw GL calls themselves.

It will break 16bit video cards like Voodoo (unless otherwise specified), but it will be worth it. Also, faster framebuffer access :-)
\(סּںסּَ` )/ۜ


Return to “General Discussion”

Who is online

Users browsing this forum: No registered users and 1 guest