Rewriting Options/Menu Code

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

Rewriting Options/Menu Code

Post by Corbachu »

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: 224
Joined: Sat Jan 26, 2013 9:56 am

Re: Rewriting Options/Menu Code

Post by CeeJay »

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
Corbachu
Site Admin
Posts: 778
Joined: Fri Jun 08, 2012 11:22 am
Gender:
Contact:

Re: Rewriting Options/Menu Code

Post by Corbachu »

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: 224
Joined: Sat Jan 26, 2013 9:56 am

Re: Rewriting Options/Menu Code

Post by CeeJay »

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
Image
Centered right
Image
Centered center
Image

CeeJay
Posts: 224
Joined: Sat Jan 26, 2013 9:56 am

Re: Rewriting Options/Menu Code

Post by CeeJay »

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
Corbachu
Site Admin
Posts: 778
Joined: Fri Jun 08, 2012 11:22 am
Gender:
Contact:

Re: Rewriting Options/Menu Code

Post by Corbachu »

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: 224
Joined: Sat Jan 26, 2013 9:56 am

Re: Rewriting Options/Menu Code

Post by CeeJay »

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
Corbachu
Site Admin
Posts: 778
Joined: Fri Jun 08, 2012 11:22 am
Gender:
Contact:

Re: Rewriting Options/Menu Code

Post by Corbachu »

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

Re: Rewriting Options/Menu Code

Post by 3rd_3ye »

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

User avatar
Corbachu
Site Admin
Posts: 778
Joined: Fri Jun 08, 2012 11:22 am
Gender:
Contact:

Re: Rewriting Options/Menu Code

Post by Corbachu »

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 :-)
\(סּںסּَ` )/ۜ