camgunz / d2k Goto Github PK

• Need to add bindings for screen drawing and sounds
• Refactor screens
  • From what I can tell:
    • screens[0] is the foreground for HUD, status bar, finale, and menu
    • screens[1] is kept blank to erase screens[0]
      ...although it looks like everything in r_draw.c uses it...
    • screens[2] and screens[3] are used for the screen wipe (src and dst
      respectively)
    • screens[4] is the STBAR background
  • V_CopyRect
  • V_FillFlat
  • V_FillPatch
  • V_DrawBackground
  • V_DrawMemPatch
  • V_DrawNumPatch
  • V_DrawLine
    • Uses screen[0] always, via PUTDOT -> V_PlotPixel(0, ...)
  • V_FillRect
  • V_PlotPixel

Add configurable maplists. Basically Odamex style.

Implementing game modes in native code means mappers and modders can't make new ones without forking the source. This doesn't scale, so game modes should be implemented in scripting instead, including the traditional game modes (cooperative and deathmatch).

n.b.

n.b.

Currently, font scaling happens at 1/32 the height, so at 640x480 the font point size will be 15. Users will want a different scale, if only because not all fonts look good with that scaling.

This has been on my TODO list for a while; not sure if it's still true.

This is petty, but I don't like the word "widget". Basic UI elements should become *Box, and HUD elements should become *Element. Preferably done before proto release, to sort of kinda maintain API stability and avoid a bunch of duplicate work or whatever.

Look into getting this code from EECS and tidying it up a little.

Includes ZDoom SSG spread.

RCON support needs proper access controls. That's the bulk of this issue. But also there's currently no way to intercept console I/O and pipe it back to an RCON user.

n.b.

Since the input event conversion into scripting, the cheat interceptors don't work. I have a branch that starts moving cheats into scripting too, but the cheats themselves touch so much of the game sim and it's taking a long time. I think I'll probably have to shim the interceptors back into the pipeline in the interim.

If there is a long, unbroken line in the console, Pango won't wrap it. I don't know if I'm misconfiguring Pango, or if I need to break the line manually, but right now it just goes off the side of the screen unreadably.

One thing about manually breaking the line is I'd have to keep track of where those are; if the screen size changes lines need to be broken manually again... which is what a text layout library is for, so....

n.b.

Sometimes the server doesn't call G_WorldDone when gameaction is set to ga_worlddone; something sets it back to ga_nothing first. It looks like this might also set GS_FINALE, and also prevents the server from sending a gameaction update and NM_FULLSTATE to clients.

Not everyone will want UI scaling, so don't force it on them.

Ports like ZDaemon, Zandronum and Odamex provide more powerful PWO support than PrBoom+ does. At first I thought this would just be a Lua function, but supporting that sort of means a per-client Lua interpreter serverside and I feel like that's asking for trouble. So I'll be collecting ideas.

Look into getting this code from Odamex.

There's already a branch for this that... seems like it's working. Requires more support and testing.

Look into getting this from EECS and tidying it up a little.

This will be a small web app with a couple JSON endpoints. I built one for EE; I'll probably use that as the jumping off point here.

Probably just radio/tink buuuuut, I feel like it could be better.

There's a mostly-complete (but completely untested) implementation in the master-advertise branch already (hmm, maybe I'll rename that branch or something). Also depends on external resource support, which it also sort of adds support for (HTTP-only for now).

P_Printf isn't C/S enabled. I think? Its been a while since I looked at this.

n.b.

Currently nothing clears or renders when you switch to "GL surface in software" mode from OpenGL mode. This bug's in SDL1 PrBoom+ too, but I think it's fixed after the SDL2 conversion. I might look into that; as maybe it's an SDL bug...? I've looked a few times and couldn't find the problem.

As the console build scrollback, it lags laying out all the text. I know how to deal with this, it's just boring :)

Look into grabbing the code from EECS and tidying it up.

Includes serverside demos as well.

If you somehow get bad Pango markup in the console or a HUD interface, that interface will stop rendering because Pango refuses to render text with bad markup.

The messaging pipelines are pretty complicated and may need a refactor. But the interim fix is to check new text to see if it contains bad markup and give an error if so. Just dumping whatever into a Pango-processed buffer is bad practice I think.