Yeah I'm not a mod or admin or anything, but this is just something I'd like to mention now that I've finally got DKP to stop having a rectal prolapse every time I try recompiling DSDoom's source and will be committing source changes fairly regularly with FANADICALCOWHEAD (hopefully).
I will absolutely not take any requests for ZDoom/Legacy/Doomsday/etc... compatibility. I mean that as lightly as possible and I only say that on my part - anyone else with valid code to contribute for any features or bugfixes is quite welcome, it's just that I wouldn't personally be maintaining such features/compatibility and if it becomes broken it will not exactly be primary in priority to get it working as intended again.
That being said, I'd like to announce that I've started poking around the DSDoom source and if anyone would like to contribute ideas, code, or whatnot to the cause, I'd like to set up an equivalent of ZDoom for the DS. I don't literally mean ZDoomDS, but a Doom-based engine that is intended to be as flexible as possible for developers. Codename: "Forge."
TO-DO LIST BEFORE FIRST RELEASE:
-Incorporate Hexen-style MAPINFO parser
-Jumping
-Possibly move over to Hexen-format maps (including special detection for old Doom format maps)
-Less homoerotic control scheme
Any ideas, feature requests, etc?
Zdoom Ds ?
Good idéa ! ![]()
But that they will be the improvements by report has DS Doom?
I'll probably be rewriting some of stuff once I get a stable build. Things like reading texture data I'll be trying to make a bit more elegant (maybe reading raw bitmap data right out of the WAD?). As it stands, there's some things in the code like simpler division and multiply operations that the DS really doesn't like, so replacing those with bitshifts is another to-do because that would increase speed quite a bit in some cases. See, the DS doesn't have built-in hardware for handling division and multiplication, so it calls on the other math hardware to pick up the slack and that's very slow.
The above means nothing to the end-user or the typical modder except for a good speed increase. For coders that means of course you'll have to be more careful where you place your division and multiplication operators.
Somewhere down the line I'm going to be rewriting the saving/loading routines to streamline the process as much as possible and hopefully come up with a method that will at least partially eliminate savegame buffer overflows and other little bugs like that.
As I said as well, I'm entertaining the idea of introducing the Hexen map format into the code, which will greatly increase flexibility for mappers. Polyobjects... Maybe?
This Topic Is Locked To Guest Posts
It's been a while since this topic was active, if you'd like to get it going again, please post as a registered member