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

drfrag

Members
  • Content count

    105
  • Joined

  • Last visited

3 Followers

About drfrag

  • Rank
    Junior Member

Recent Profile Visitors

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

  1. drfrag

    GZDoom won't run WAD

    Of course not, you can use ECWolf.
  2. drfrag

    Boom sight bug

    Also fileconvoy.
  3. drfrag

    RUDE: another chocolate-doom fork

    Yeah but i'm using tdm-gcc 5.1 (MinGW) and it runs on 98 the same as older versions. There are known problems: setup cannot launch the game. BTW Houston (fraggle) we've (i've) got a problem: after restoring the console launching the game from setup to test controls and then closing it causes an infinite loop executing doom. The only way of closing it successfully on win 8.1 is from the task bar when it doesn't have focus. No idea of what's going on.
  4. drfrag

    RUDE: another chocolate-doom fork

    I've tested it on win98 and works but there are know problems. I've heard that chocolate crashed there so no idea if this one is stable. About requirements i dunno but i set the minimum ram to 8 MB. I updated the release yesterday to enable the console for Heretic but it's a very minor thing and Heretic is not supported.
  5. drfrag

    RUDE: another chocolate-doom fork

    I've updated the release (somehow the server was old) and added the Heretic binary, it's unsupported but hey if it works it works. On the resolution thing there's no high resolution here, i never said that. Like in old Choco the game is rendered on a 320x200 framebuffer and then upscaled. Seems i'm always stuck with old versions, hoping this can run on older hardware. Sure if you use a low resolution the game runs somewhat slower.
  6. This is a fork of Chocolate Doom 2.3.0 with some stuff from Crispy Doom. The name is some kind of a play on words and suits the fork in all senses also stands for Romero's Ultimate Doom Engine and it's another tribute to John Romero. Easy to understand if you know my Romero's Heresy II project for Heretic. :) It's better than my other proposals such as Choco-chewy or QDDoom (Quick N' Dirty Doom) or Doom++ but not to be taken seriously. It's a strong limit removing port aiming to preserve most bugs in the original executables including rendering bugs while preventing crashes at the same time. It's somewhere in the middle between Chocolate Doom and Crispy, this is still mostly Chocolate of course. Some features: Has support for extended nodes and the autorun key from Crispy. The startup console is back (running from the command line is recommended). There's a new 'Unholy massacre' skill level (-skill 6 or setup, not in the menu). :D It's not as hard as nightmare but it's a legitimate skill level and apparently it works great. It was the obvious thing to do and i wonder why no one has done it before (AFAIK), it will bring back old memories. Heretic compiles and runs also i removed limits (in theory) and has a new 'One thousand deaths await thee' skill level. But you'd need to compile yourselves or just use Crispy. There's a test build (may be final?) here: https://github.com/drfrag666/chocolate-doom/releases Now i'll clarify that this is not your usual source port, it's some kind of re-engineered Crispy and it's about the magic of Git. I've done this in only a few days applying and refactoring Fabian's patches so this is mostly his work, it's like rewriting the history of Crispy. So yes this is Crispy's bastard son. Many times i followed commit history in reverse order since i wanted to minimize changes and preserve many vanilla bugs (also many Crispy features are not in) so i had to resolve a lot of serious conflicts. I'm pretty good at it so it should be fine but there are a few things i'm not completely sure. I didn't know what i needed to do to prevent the crashes so i had to do some research in Doomworld and Doomwiki. I had to apply the medusa fix or else there were crashes here and there but Medusa was not there, also i think i ever saw her only once and i've been playing since Doom came out. Also the SlopeDiv overflow fix or else massive redering errors on big maps. And fix other overflows of course. The wiggle (tall sectors) and wall wobble fixes are in as well to prevent crashes. Not fixed: HOMs, tutti-frutti, slime trails and most of the other game bugs. So in the end most of the merit is of fraggle and fabian and they must be credited for their great work here. Have fun! And i hope it won't crash. :)
  7. drfrag

    New port (sort of) and crash [fixed]

    I didn't heard about that Doom+, what about QDDoom (Quick N' Dirty Doom)? Just kidding, i've already got a name. It's catchy and fits very well and has nothing to do with food. :) I had the name years ago for a port i never did with some crazy features. I'll create a thread later to explain things and i plan to do a release very soon. I hope it won't crash (it should be fine) but i'll explain later.
  8. drfrag

    New port (sort of) and crash [fixed]

    Thanks, it was the SlopeDiv overflow. It's fixed now and the map is playable i think. But i have not fixed HOMs nor slime trails.
  9. drfrag

    New port (sort of) and crash [fixed]

    It's fixed, i've applied the medusa fix. However that map is unplayable due to massive rendering errors, mainly HOM i guess. The main problem is sprites dissapearing here and there. Some serious conflicts due to not following history but should be fine. Now i shoud choose a name, what about chocochewy or doom++? :)
  10. I guess it's 1.3. That old doomsday version's docs should clarify it.
  11. drfrag

    New port (sort of) and crash [fixed]

    I've fixed that crash, it happened on maps with zero size or very big SEGS lumps. I had to debug the damn thing for a while. Now back to the starting point but with the wobble fix, but i think now it's even worse. Now rw_distance is a uint32_t but i think the problem with the crash is not there. Sprites dissapear a lot with the savegame. rw_distance =1563838844, curline->length = 92681. Crashes at for ( ; column->topdelta != 0xff ; ) in r_things.c and i'm using the original draw functions. Note that x1=x2 in R_RenderMaskedSegRange, could that be a problem? Any ideas? Thanks. Edit: fixed the crash.
  12. drfrag

    New port (sort of) and crash [fixed]

    I don't know what's going on but i've set two breakpoints: one at li->length = (fixed_t)sqrt((double)dx*dx + (double)dy*dy); in p_setup.c and another one at dist = (dy * dx1 - dx * dy1) / curline->length; in r_segs.c. For non crashing maps it stops at the first one, for crashing ones at the second. I'm using tdm-gcc 5.1 and Code::Blocks.
  13. drfrag

    New port (sort of) and crash [fixed]

    Some progress, i think, now i've applied the wooble fix and the game still works (it was a quick bad merge) but Planisphere 2 crashes as soon as i start a new game. Crispy 3.0 also crashes and probably is the same crash. How do i test the wooble fix? Now a get a division by zero calculating rw_distance where curline->length is zero. I've tracked it down to li->length in p_setup.c. What's next? Should i apply the slime trail fix? Edit: Now sunder map14 also crashes (didn't before neither in crispy so it was not the same crash). May be this is a regression. Edit2: removed the backtrace, this crash is fixed.
  14. drfrag

    New port (sort of) and crash [fixed]

    Thanks for confirming the overflow, there's only a long wall about 17000 units long and i was not facing that direction so i guess it's just the map is too big? Also doing that new game/load game trick there's no crash. The problem is i don't know how to keep the overflow at bay without the wooble fix, something is missing since with that fix all maps crash.
×