ZDoom

G4 user here, waiting on that Universal binary. Thanks for all your work.

Since my request for this was marked "Duplicate," I want to add my support to this thread. I also want to mention that, in the Customize Controls menu, only the automap key is described as a toggle function. A more consistent menu should include "toggle console", "toggle chasecam" and "toggle coop ...

Currently, the automap functions in ZDoom are hard-mapped to specific keys (i.e., "M" for marking and "C" for clearing). This makes it so that those keys are totally off-limits to other functions while in automap mode. In my case, I actually mapped the automap toggle to "M". Needless to say, it took ...

More than likely not, but we can always hope! Keep us posted, k0da.

Graf Zahl wrote:To sum it up: Even if the Skulltag team gave their ok I wouldn't use it.

No one ever said you need to convert to Skulltag's code. Hell, as long as the current ZDoom code is still usable then go for it.

But why do you need to have the same code in ZDoom? Why not just use Skulltag instead. It's not that it is based on an outdated version of ZDoom - unlike ZDaemon. I think most here would agree that a modern netcode system would be a major functional improvement for ZDoom -- especially since other ...

In case of cheating, I'd suggest the development of a separate anti-cheating system apart from the functional netcode. Maybe R1Q2 would be a good starting point for more ideas?

Well, I know k0da was working on replacing the old FMOD with the more cross-platform FMOD Ex, which would go a long way toward resolving audo playback problems on other platforms, but sadly that seems to have gone nowhere. Also, why not work with the Skulltag team to standardize the netcode across ...

I'd really like ZDoom to be more cross-platform, or in other words, less Windows-biased. Simultaneous Linux and even OS X releases would be awesome.

My primary machine is an iBook G4 in case you'd like me to test your builds as well.

Moving to FMOD Ex and having an overall more cross-platform friendly ZDoom would be awesome. Go k0da!

How difficult would it be to implement a Game_Speed (fixed speed) function like Kate mentioned?

But what if you want to just slow down or speed up objects rather than freeze them completely? Besides, the time it takes for objects to enter or leave a frozen state should be configurable.

Oooh! I would really really really love the ability to define a separate main menu music! If that gets added... don't forget that the map music should resume where it left off when you accessed the menu, and not play back from the beginning. Take a break from an intense fragging session and relax ...

How about something more flexible and generalized like this? Time_Shift (bool state, fixed transition1, fixed limit, fixed duration, fixed transition2) If state is TRUE, the game's current speed (not necessarily the normal speed) slows down/speeds up over a period of transition1 seconds, until ...