Rachael

Members
  • Content count

    216
  • Joined

  • Last visited

1 Follower

About Rachael

  • Rank
    Junior Member
  1. I've done a little bit more work on GZDoom today to get it Haiku-compatible. I've decided to branch my work since the changes I'm starting to make could be seen as a bit disruptive and I want to minimize that as much as possible. The issue I am running into right now is thread-local storage not being supported. There was an issue with that regarding OpenBSD, too, and unfortunately I can't find what the OpenBSD guy did to get it to compile on his system (or if he even did). It's a bit daunting to encounter a system that has this issue. For now, I am keeping development in the Haiku-develop branch. However, unless the BSD's and Haiku decide to pick up thread-local storage, we may have to deprecate all of them preemptively, because this is something that's going to be counted on in future development for GZDoom.
  2. I never really liked the idea of source ports competing with each other. Everyone will simply say their favorite one, or the one they are a primary developer on, is the best. I am biased - I am well aware of this and cannot escape this, myself. But that doesn't mean I don't appreciate others' work, or the things that GZDoom has incorporated over the years from others. I would agree it was more a cultural thing than anything. As much as it is natural to want to be better than others, none of it was helped by source port debates which wholly discarded the fact that each one has its own goals, ideas, strengths, and weaknesses, which itself means that it's not inherently better than another for any of those reasons. There's also a lot of people who take pride in being the "first" to do something. Sometimes to a destructive level.
  3. This has kind of been bugging me since the original question was asked, even though the topic has steered in an entirely different direction. OP asking if it would be possible to remake the game code and put whatever license we want on it - yes, that is possible, although people have been happy enough with the GPL that there never really was a need to write a new game from scratch. Also, I am not sure what the license technicalities will be if you reverse engineer the code, versus writing your own back-ends and building a game engine entirely from scratch (without quite as much regard to Doom specifications, although it could be written for Doom compatibility) and going that route. GZDoom, for example, has almost no resemblance to the original DSC, due to how much the code has been refactored over the years, but in all that time it was always still based on original Doom code. And one thing - no one wants to put all that work into a new game engine just to release it under the public domain and without restrictions. The GPL is, as previously mentioned, commercially exploitable, and it also actually protects all the users who use it. As many restrictions as there are in the GPL, they're put in place to prevent abuse, which you can definitely bet will happen in one form or another as long as someone stands to gain something from it.
  4. Zooming out is more efficient because it's less pixels, overall. Setting low graphic detail simply doubled the pixel width which itself did offer a significant boost because it only had to do half the column walks which was the biggest performance killer, but it still had the overhead with ultimately having to deal with all those pixels that shrinking the screen did not have; and memory access between the CPU and the VGA was not cheap for performance in those days.
  5. Well either way, I need a distro that supports hardware acceleration in order to port it over and test it. And that won't come until I have a spare SD card to stick it onto. >_<
  6. Right now I'd recommend sticking with 32-bit until things stabilize a bit on 64-bit from the OS side. 64-bit confers no major benefits until you are at at least 2 gigs of memory or more. I am not sure what the register situation is like on ARM, though, regarding 32-bit vs 64-bit.
  7. Mostly, I just want to focus everything onto one architecture/processor and the difference between arm7 and arm8 is significant in terms of speed boost. Supporting RPi2 feels a bit like dead weight to me. Dropping RPi2 won't immediately mean hardware acceleration. I ultimately will need to save up money to buy a new MicroSD card for my Pi in order to start supporting that, so I can flash a Raspbian image or something that actually supports it. (My Ubuntu Mate, sadly, does advertise supporting it, but every time I activate it, the system freezes on boot) What I am thinking of doing is activating GZDoom's legacy renderer for GL ES, to see if that works. GL ES 3.0 does support the modern rendering path (inasmuch as you can get it working) but GL ES 2.0 apparently does not.
  8. For those of you on Raspberry Pi, I have a poll that I need answered: https://forum.zdoom.org/viewtopic.php?f=4&t=58256 The question is which RPi generation you have (2 or 3). Based on the responses so far (as of this post) I am ready to deprecate Raspberry Pi 2 completely and remove the CMake directives that allow it to build, making Raspberry Pi 3 a base requirement for GZDoom. That will happen unless I see a significant number of users interested in keeping Pi 2 support.
  9. I can tell you that if no post is made on the Feature Suggestions forum at ZDF, no such thing will ever happen. Our only active Mac developer does not come here often that I know of.
  10. Congrats on getting this to a release version!
  11. Some people take their megalomania very seriously.
  12. I think that's much easier said than done, with how DEHACKED actually works. ZDoom has to process all of its internal stuff first in order for DEHACKED to be even functional - since all the actors are external now, not having them loaded beforehand makes them impossible to modify. Naturally, the LANGUAGE lump is loaded around the same time too - which is, before the IWAD is even checked for, since it kind of makes sense to have all the pre-IWAD script processing done in order to properly present the IWAD selection box as well as give basic diagnostics about the system it is being run on (in the user's own language, if possible...). To me, it seems like DEHACKED more or less suits its original purpose in ZDoom - it's simply a crude hacking tool, its operations are added in at the last minute for game processing after the resources are already loaded - which creates the problem we presently see now. This is why I suggested the //$commented meta-command killswitch - a special code that only GZDoom recognizes that shuts down DEHACKED processing and forces it to use the LANGUAGE lump, instead. It might be a bit unpleasant, but it's effective.
  13. I think the best solution to ZDoom is to include a directive that gets ignored (a pseudo-"comment" like how QuickBasic did it) by other ports, and forces the use of the language lump, instead. When ZDoom detects such a meta-command, it will cease processing on that DEHACKED file and let the mod's own LANGUAGE lumps take over. (For reference, here's how QuickBasic did it: https://en.wikibooks.org/wiki/QBasic/Appendix#INCLUDE_.28QUICKbasic_Only.29 By default, any line that starts with an apostrophe is a comment. That works in backwards with GWBASIC and prior versions of Basic. However, if a $ dollar sign is appended to the apostrophe, it creates a meta command that only QuickBasic understands.)
  14. Saints Row 2, and Dr. Who, Ghostbusters, and a lot of other things all prove one MAJOR thing: It matters the person and their actions, not their gender, in the end.
  15. Don't like it? Stop watching Dr. Who. Simple as that. I am sure the real Dr. Who fans will be happy not to count you among them any more - no real loss!