• Content count

  • Joined

  • Last visited

Community Reputation

12 Neutral


About chungy

  • Rank
    Senior Member
  1. That could come in the form of shaders, if/when the feature is ever developed. I think it has a good chance whenever somebody sits down to do it :) As for the rest about slowdown: It's a pretty complicated feature. Capping the engine to only run at 15fps, for example, to "simulate" the vanilla 386DX experience might be possible, but it won't account for anything remotely similar to the 386's actual performance when it comes to handling certain amounts of things or map sizes. It'll just start down a path that has no good end besides running vanilla Doom in an emulator (like PCem or Bochs) that can actually emulate the hardware including the old CPU's speeds.
  2. I honestly don't know that there would be any value in artificially slowing down the engine. Chocolate behaves now with roughly the same performance as if you'd run vanilla Doom directly
  3. Voros, please don't assume a position of authority. Whether the czars want to develop in a bazaar-like model out in the open or a cathedral-like model in private, it's their choice. Blastfrog has no obligation to show what's in progress.
  4. Doom modding is anything that changes the game. ACS counts. Custom source ports count. Whatever you want.
  5. Crates are fine on any level. No need to avoid (nor use) them because of what Doom did.
  6. Wow. Are we really at a point that nobody can implement a feature unless it was already made before? Come on. It's totally unobvious and stupid that Doom doesn't have actual tracks for episode 4. Giving WAD makers the freedom to explicitly define them is a good idea.
  7. Excellent news :)
  8. Here's a bex file that should work with all ports supporting the format (pretty much all): I've changed the line breaks for the intermission text, but I haven't corrected any of the grammar. Doom seems to usually cut off lines at around 35 characters. It works fine included in the WAD as the "DEHACKED" lump.
  9. Topic bump, reminding that chapters 1 and 2 are still ripe for the picking :)
  10. That's been Nintendo's line for every console post-SNES, and the only time they had a moderate success was with the GameCube. Honestly, it's just an excuse to be cheap on hardware and never having to take a loss on hardware sales (compare to Sony and Microsoft that have consistently sold their consoles so that the first year or two, each console is a net loss: they make it up with online service charges and licensing fees for games). The Switch, however, is different. Unlike N64, GameCube, Wii, Wii U, it's no longer directly competing with PS4 and Xbox One. It is, basically, a mobile gaming device that happens to have a dock to plug it into the TV if you want to. So sure, it's weaker than those consoles, but you can't really take those consoles in hand anywhere you go. If any other tablet manufacturer had been serious about pushing forward their devices as gaming platforms, Nintendo probably wouldn't get very far, but they haven't, and Nintendo is taking the space for their own picking. Smart move, I think. On being weaker than PS4 and Xbox One: as with past Nintendo console generations, this has been the primary reason Nintendo doesn't get many 3rd-party games. The hardware is just too weak to justify porting costs and the hardcore gaming market leaves the systems behind too. When they stuck to trying to compete with the big boys, it just killed all their attempts. With the Switch being focused on handheld gaming, maybe we'll see the effort made anyway? (I don't know, it'd be cool to have Witcher 3 or Doom 2016 on it, but both games would need massive cuts to fit)
  11. Someone will port classic Doom whenever homebrew opens up to the system.
  12. Looks like that DeHackEd has several errors that makes it impossible to load in vanilla anyway, and Chocolate Doom (and Crispy as a downstream) is enforcing the vanilla restrictions. You may consider switching to bex instead (example from Freedoom), and possibly with a "# *allow-extended-strings*" line so Chocolate Doom can load it (with -dehlump).
  13. RjY's git hackery doesn't require changes to the repo contents itself, it can still store binary WAD files for levels. I think it's the best route to go if somebody wants this information out of git.
  14. I like the idea, but I'm not really sure how feasible it is. ZDoom seems to not support the GIF file format, or the other two formats DeuTex supports (BMP and PPM). We might be able to modify DeuTex to support PNG instead and move Freedoom over to it, but I don't know if anybody is willing to lift DeuTex into supporting this. Another issue seems to be its way of supporting Arch-Vile sprites differing from the WAD names. Because of Windows compatibility, ZDoom changes the \ character to ^ in the file name. DeuTex uses @ as the replacement character instead. We can probably work with it. Because of DOS compatibility, DeuTex also replaces [ and ] with $ and #. Both of those can probably be reconciled with a little bit of elbow grease. The last issue I see is just: what would the Freedoom tree be as-is? We do all kinds of building and manipulation during a build (generating graphics, sorting out IWADs to have unique contents, generating patches in different manners), and I honestly don't really know if this is solvable to work as a PK3. The tree as it is in the repository is basically useless on its own. It requires the Python and make scripts to build up to something usable, and I honestly can't see how this can change without losing the flexibility we presently have. I'm also unsure, if that wasn't even an issue, what loading the "freedoom.pk3" would mean. Phase 1, Phase 2, DM? Some combination of the three? I am open to all suggestions that might resolve the last point, so long as it doesn't kill the present dynamics of the build (eg, generating all the level/menu/etc graphics using the font in the present repository).