Jump to content
Search In
  • More options...
Find results that contain...
Find results in...

legolas558

Members
  • Content count

    14
  • Joined

  • Last visited

About legolas558

  • Rank
    Warming Up

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. legolas558

    Forking GZDoom, anyone?

    Sorry but I can't find how to enable the FPS counter - is documentation lacking or perhaps am I blind? :(
  2. legolas558

    Forking GZDoom, anyone?

    minor bugs, otherwise I most probably wouldn't be able to fix'em :) Anyway the others are outside my capabilities: a dead body on the elevator is blocking me from jumping down on Doom2's map01 (right after activating the switch for the external secret area), and Imps and player seem able to stand on an invisible step of the small stairway introducing me in the big room before the external area with the shotgun. I am not particularly worried about these issues, they most probably are there to respect compatibility with vanilla Doom A better fix, indeed. I have defined "USE_VBO" as you suggested, however I am not able to sense any difference in performance between the 2 versions - it is very fast in both modes!
  3. legolas558

    Forking GZDoom, anyone?

    Nope, the actual repository is available (with anonymous access) here:svn co http://www.crowproductions.de/repos/prboom/branches/prboom-plus-24/prboom2If that repository wasn't meant to be public then you should close the hole; otherwise I think there should be some page with some information about it :) I am currently fixing some bugs like: error: ‘uint64_t’ undeclared (first use in this function)The fixing patch is:Index: src/r_main.c =================================================================== --- src/r_main.c (revisione 3471) +++ src/r_main.c (copia locale) @@ -59,6 +59,7 @@ #include "r_fps.h" #include <math.h> #include "e6y.h"//e6y +#include <stdint.h> // See OTTAWAU.WAD E1M1, sectors 226 and 300 // http://www.doomworld.com/idgames/index.php?id=1651 Edit: added patch
  4. legolas558

    Forking GZDoom, anyone?

    :eek: what is that? Windows binaries? I'll need to grab the source code from somewhere :)
  5. legolas558

    Forking GZDoom, anyone?

    Yeah, The Doom Wiki precedes you - I hadn't seen that :) Unfortunately I have just tested doomsday and there must be some serious texture bug because on my hardware (fast-food i855GM) textures are all messed up (seems like a pitch/width issue). I'll report this on Doomsday forums, which is a much more appropriate place - although the confirmation email has not yet arrived. By looking at the Doomsday project it looks really good! I like very much its modularity and believe that you can really get out with something good with this new planned renderer...perhaps I'll join testing (I already have a few bugs to report) later
  6. legolas558

    Forking GZDoom, anyone?

    Luckily comparing changes of such lists would not require too much time (I think they are in the order of magnitude of small strings comparation), so I still think that it is perfectly feasible and no lag would happen. Yes but the skeleton, e.g. lists for really static subsectors, could already be implemented, isn't it? You look quite ahead in the theory of this, have you been working on some 3D FPS engine?
  7. legolas558

    Forking GZDoom, anyone?

    Easy: half-dynamic, half-static e.g. dynamic caches! I think that DaniJ has explained this much better in the previous post. (This is easy to design and think about, and somewhat harder to implement). Do linedefs also modify their vertices or only translate? 100% agreeing here. Let's consider the 3D world without sprites e.g. the world of 3D planes. There is a huge amount of it which could be made up of OpenGL batchsets (aka compiled lists aka whatever), and the algorithms could even mark some batchsets as "rolling" and never cache them again e.g. render them in immediate mode because for some combination of effects they are changing very frequently. All this would be opaque to the user (if done correctly) so that only with a slow (or slown down) CPU you can detect the "calibration" hickup which properly selects immediate mode or cached mode. The advantage are huges and such adaptive technique would theoretically behave correctly even on complex maps with many effects. Hell, we could even implement a flag which says "be careful renderer, this (sub)sector is a hotspot, never cache it", and it would work. Next thing to do is to go lookup all these OpenGL engines and see how they are doing it :-)
  8. legolas558

    Forking GZDoom, anyone?

    I agree that most parts of the level could be made up of compiled lists, but it already works this way (for some engine) - doesn't it?
  9. legolas558

    Forking GZDoom, anyone?

    Given that ZDoom has defined sort of a new standard for enhanced maps, this is a big limitation to me. Yes that's something that becomes evident very quickly and causes indeed a "wow" effect Interesting...they might come up with an original and killer renderer When you're used to (G)ZDoom, this looks quite insufficient...although I recognize that it fulfills its proejct goals If only we could come up with some next generation renderer...
  10. legolas558

    Forking GZDoom, anyone?

    I may be the newbie here, but if I remember correctly OpenGL can nicely repeat the texture if you properly setup one or two matrices for it. I still don't understand why: what's wrong with an "atlas" with proper offsets? OpenGL has a powerful texture matrix, again if I remember correctly. Regarding my own experience: it is not something about an OpenGL FPS, but an OpenGL Orion-like game. We needed to render a 3D view of the planet surface, as well as a "space view" of the planet as a geoid. I was able to do so using the same cached textures without too much hassle. I know that Doom is totally a different thing, but I grouped many tiny pictures in big "texture tiles" (I developed an algorithm to properly fill such tiles second the hardware's suggested texture size) and then used offsets to render each mini-texture individually. I also got some issue with repetition, but I don't think it was of the kind that could prevent from using offset'd textures in Doom walls or floors (although I might not remember correctly and such limitation could exist).
  11. legolas558

    Forking GZDoom, anyone?

    This opens quite an interesting discussion :) - but unfortunately I am out of time now (although I am willing to contribute with my own little research on the subject), so I'll reply later!
  12. legolas558

    Forking GZDoom, anyone?

    Thank you Gez, this is the kind of summary I was expecting from somebody which has followed the scene much better and tightly than me. I have just tried Vavoom and it looks much better than last time! Although its OpenGL support is not that good, possibly because of the SDL layer in-between? I have tried (recently or in a recent past) all the source ports you have mentioned, and I finally picked up GZDoom because its OpenGL support was much better than the others (at that time, and anyway in my opinion). Is it today still the best one, when talking about OpenGL rendering? I will eventually give a hit to the other ports you specified above (like I did with Vavoom), but there has been a lot of FUSS about GZDoom so I really don't know where the facts are now
  13. legolas558

    Forking GZDoom, anyone?

    I would have apologized, if I had the chance to do so! I was indeed not behaving good at formulating "bitch sentences", as you said, but I don't think that it was moderated only for that. I am asking in this topic the current status, it seems a pretty clear question. If I had any answer I would not be asking anything. This chunk of text is already an answer to what I was asking, so thanks :) Technically speaking, what are exactly the blocking issues which prevent such renderer to be incrementally developed? Hardware support of OpenGL? (I don't understand this one, if it stands as one) Legacy support of Doom rendering? I'd really like to know where it becomes so hard...
  14. legolas558

    Forking GZDoom, anyone?

    After being really pissed off on another forum, I am going to start this discussion here where there is no medieval censorship at least. Can somebody please say what is the status of true OpenGL ports of Doom? I see it disapponting that we now have sci-fi graphics hardware (all devices of past 10 years can be considered so) and still need to relay on software rendering (ZDoom) without any good, scalable and modular OpenGL engine. I know that Doom needs virtual textures to run well on modern hardware, but still looks like a solvable problem to me (although I don't have alone the skill to implement such thing). This is the premise to talk about forking or continuing development on GZDoom; there's to say that Vortex is trying to fill such gap, although I have no direct experience of his work. What are you (players/modders/developers) thinking about this? Thanks
×