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

wesleyjohnson

Members
  • Content count

    1301
  • Joined

  • Last visited

5 Followers

About wesleyjohnson

  • Rank
    Senior Member

Recent Profile Visitors

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

  1. wesleyjohnson

    Make Freedoom Great Again

    I heard indirectly about the current state of FreeDoom from some other Doom players. They did not consider it to be worthy of downloading anymore. I looked myself and found that my level map contributions had been replaced by this neon junk. I won't even consider playing that kind of mapping. Apparently the project plan of people contributing to Freedoom, of members signing up to contribute a level map, has been usurped by a few people who have moved in on the freedoom name, like it was an someone else's house they could trash for their personal whims. The original freedoom project, upto freedoom-iwad-0.8 still has my permission to use my level maps, and sprites. That is what I contributed to. I will be transferring that work to a new wad project, probably a community project, I just don't know where. Because you are trashing other peoples contributions to make this into your personal project, this new project does NOT have permission to use my level maps, or sprites. This is NOT the project that I contributed to. I do not want to be associated with this new version of freedoom. I doubt that there is much left that you have not replaced anyway. But, the last time I looked the Pain-Elemental, the SpiderDemon, and the Revenant, were still my work. I want it clear that I do not allow you to grab stuff of mine at your whim. I think most authors of the stuff you are planning to grab are going to have the same opinion. You want to trash everything not to your liking, so why not get your own project name, and create your own work. Why did you have to trash the nearly completed FreeDoom community project. Just because you had control of it and could.
  2. wesleyjohnson

    Boom sight bug

    Usually, by now, something like this would have attracted lots of attention by now. I know KB1 is still alive. What is going on, did a bunch of forum regulars and port maintainers die off or retire or something ?
  3. wesleyjohnson

    Need testers for Eureka DOOM Editor

    Even if it is software draw, it should still be drawing it at 20 frames a second. Every Doom port can do that. It has to be the geometry structures are too complicated to traverse fast, or else you have a bug in your drawing routines. Tried to make the drawing routine too simple, or you have some common function that should have been specialized. But to really slow things down to a crawl, you have to re-traverse the entire structure several thousand times with every render. Such things happen if something gets invalidated while drawing, and it cascades to invalidate something else. If you are going to have trouble with rendering floors so slow. then I have to ask the question, what is rendering the floors trying to accomplish? This is an editor, so a great display of the floor (top down) is not a great feature that makes creating a level such a better experience. If what you need is to see that all the floor in an area have the same texture then it would be equally useful to have one of the check functions that shows you all the sectors (in orange or some highlight), that match the floor texture you point at. Then you could easily find any sectors with mismatched floor texture. It would also help to have the capability to click a menu selector on a sector to make it's floor texture match the reference sector. That is one capability in Yadex that I use often, but the Yadex version makes it the same sector. For more selective changes, I use the group change capability of Yadex. Select a bunch of sectors, then any attributes you change, changes all the sectors at the same time. I will have to check in Eureka for similar capability, because I use those quite often. I am not sure if it is not there or I just have not figured how to do it yet.
  4. wesleyjohnson

    Need testers for Eureka DOOM Editor

    I still have version 1.09, so I will have to update. I have tried Eureka several times, but have always been unable to figure out how to do tricky stuff. I have gotten used to using Yadex where I can create something that may be invalid, but then I had the commands to fix the invalid stuff and make it right. I have tried to use Eureka to deal with some bad wad files, and I could not make them better, but it was too long ago to remember details. I will have to try it again, but don't have any current editing projects.
  5. I looked at the sound code feeding SDL. A MUS format lump will go through the mus2mid converter. Otherwise, the comment says "MIDI, MP3, Ogg Vorbis, and various other formats" are fed directly to the SDL sound. So what music format that SDL will play will be determined by the SDL version you have. Newer versions may differ on support. I have never experimented with this myself. I believe the "-digmusic" parameter actually was to make DoomLegacy use the FMOD support. This required that FMOD be compiled in (a non-standard selection) and that you be building a WIN32 port (not the standard SDL port). Much of this was updated and the code made conditional some years ago. FMOD support has not been tested in years. I have been unable to get an FMOD library that will work on my system. The binaries you can get from Source Forge are Windows SDL, LInux SDL, and Linux X11. These do not include the WIN32 version, which you would have to compile yourself.
  6. wesleyjohnson

    Boom sight bug

    Probably damage due to years of writing reports for Defense Department contracts. Or it could be that I write like I am coding a program. You have to see the curly brackets.... Could be because I have been studying German, and Japanese. They like to, at the end of the sentence, the verb, to put.
  7. wesleyjohnson

    Boom sight bug

    Thanks, bonnie. I did not notice that, perfect. (I have edited the previous post). Thanks, drfrag. Fileconvy is the one I used before. But since the system upgrade, I have lost all my bookmarks. I was just about to get a box account, just to publish files for these forums.
  8. wesleyjohnson

    Boom sight bug

    The dropcanvas link is only good for 6 hours. Fixed ....
  9. wesleyjohnson

    Boom sight bug

    I have created a test wad. http://dropcanvas.com/w0daj sight_test.zip With the latest DoomLegacy code in the SVN (SVN 1396), I can walk the player around without any of the monsters detecting the player. I have tested it with eternity-engine 3.40 (which uses the same CheckSight as Boom, PrBoom, etc.) and it fails in the back room with the spider-demon. With most of the monsters, the monster height is the same as the player height, so adding the wrong height in the calculation does not make a difference. When you make the monster a spider-demon, it makes a difference. Please try this wad out. You should be able to walk around most rooms without being seen by any monsters. Each room has a way to expose the player, and verify that the monsters can actually see. Sight tests where the player is under the slime (monsters above the slime) are to the right. Walk down into the slime and turn the corner. To be seen, step the player up onto the small pad near the wall, the top of your head will barely stick out. Sight tests where the monster is under the slime are directly to the left. The monsters are in the slime and cannot see you, until you step in the slime. To the left, through the smallish opening, are the ceiling test rooms. In the right ceiling-room, a spider-demon waits on a platform below the ceiling. Go up the stairs and turn right again to get the player over the ceiling. Do not step past the post, as there are stairs there leading down to the spider-demon. You will be seen when stepping down into the green ceiling (you cannot see the steps because of the way deep water works, sorry). In the left ceiling-room, a spider-demon waits on a platform above the ceiling. Stay at the low level and just turn left, to stay under the ceiling. If you go up the stairs, and turn left, you will be over the ceiling with the left-room spider-demon (which can then see you).
  10. wesleyjohnson

    Boom sight bug

    I would be surprised that this would not have been noticed before, but it looks like a bug to me. I cannot convince myself that is right to add the height of monster t2, to the z position of monster t1, in this sight check. Can anyone give a convincing argument as why the orig code would be correct. boolean P_CheckSight( mobj_t* t1, mobj_t* t2 ) { const sector_t * s1p = t1->subsector->sector; const sector_t * s2p = t2->subsector->sector; int result; // First check for trivial rejection. // Determine subsector entries in REJECT table. int s1 = (s1p - sectors); int s2 = (s2p - sectors); unsigned int pnum = s1*numsectors + s2; unsigned int bytenum = pnum>>3; unsigned int bitnum = 1 << (pnum&7); // Check in REJECT table. if (rejectmatrix[bytenum]&bitnum) { cs_sightcounts[0]++; // can't possibly be connected return false; } // [WDJ] From PrBoom // Uses model and modelsec, instead of the PrBoom heightsec. // killough 4/19/98: make fake floors and ceilings block monster view if( s1p->model > SM_fluid ) { s1p = &sectors[s1p->modelsec]; if( (t1->z + t1->height <= s1p->floorheight && t2->z >= s1p->floorheight ) || (t1->z >= s1p->ceilingheight #if SIGHT_HEIGHT_BUG_FIX // [WDJ] entire t2 is below ceiling && t2->z + t2->height <= s1p->ceilingheight) ) #else // PrBoom orig && t2->z + t1->height <= s1p->ceilingheight) ) #endif return false; } if( s2p->model > SM_fluid ) { s2p = &sectors[s2p->modelsec]; if( (t2->z + t2->height <= s2p->floorheight && t1->z >= s2p->floorheight ) || (t2->z >= s2p->ceilingheight #if SIGHT_HEIGHT_BUG_FIX // [WDJ] entire t1 is below ceiling && t1->z + t1->height <= s2p->ceilingheight) ) #else // PrBoom orig && t1->z + t2->height <= s2p->ceilingheight) ) #endif return false; } // [WDJ] MBF, From MBF, PrBoom. // killough 11/98: shortcut for melee situations. // same subsector? obviously visible // cph - compatibility optioned for demo sync, cf HR06-UV.LMP if( EN_mbf && (t1->subsector == t2->subsector) ) return true; // An unobstructed LOS is possible. // Now look from eyes of t1 to any part of t2. cs_sightcounts[1]++; validcount++; cs_startz = t1->z + t1->height - (t1->height>>2); // eyes at 3/4 // Slope is (height / horz.), where horz. is measured such that the // the distance from eyes to target = 1. Slope here is (height/1). see_bottomslope = t2->z - cs_startz; // feet of target see_topslope = see_bottomslope + t2->height; // head of target cs_trace.x = t1->x; cs_trace.y = t1->y; cs_t2x = t2->x; cs_t2y = t2->y; cs_trace.dx = t2->x - t1->x; cs_trace.dy = t2->y - t1->y; cs_t2_subsector = t2->subsector; // location of t2 // Setup for 3dfloor sight tests prev_frac = 0; // the head node is the last node output return P_CrossBSPNode (numnodes-1); }
  11. wesleyjohnson

    Ultimate Doom tree driven into ground

    The rendering errors when disabling Boom support were weird. Not the kind of thing I could describe in detail. Also too long ago now to remember accurately. I think I fixed one of the causes, but then saw more.
  12. wesleyjohnson

    Ultimate Doom tree driven into ground

    Been working on DoomLegacy, trying to get it ready for the 1.47 release. That is I am trying to find any important bugs introduced by adding the MBF capabilities. To that end, I have a version of DoomLegacy with the SyncDebug (TM) debugging system (from KB1) installed. He has been helping me with SyncDebug output. I have made some changes to SyncDebug, which KB1 has incorporated into his product. We have found some things that influence the demo sync. The fixes have not been big nor even memorable. I cannot remember what they are even now. At least DoomLegacy does now seem to complete some demos in UltDoom and Doom2, though not perfectly. I was not aiming for perfect demo sync, although KB1 is much more enthusiastic about reaching that goal. I am, at this time, just trying to find bugs important to the 1.47 release. There is a nagging position error in the LSB that gradually makes the player position vary from KB1's reference position. I have been unable to find that. I have taken the P_TryMove, P_CheckPosition, PIT_CheckThing, PIT_CheckLine functions from prboom, and wedged them into a copy of DoomLegacy. I am running them in parallel with the DoomLegacy functions, and comparing the results and some internal variables, looking for significant differences. Of course, it puts out page after page of error reports, which turn out to be problems with two functions working on the same data set and interfering with each other. I think I finally got them tamed so they don't stomp on each other's data (I make separate copies of everything for the PrBoom functions, and only keep output from the DoomLegacy functions). The end result of all this is that it can run through entire demos without reporting any difference between the DoomLegacy and PrBoom functions. I did notice some MBF specific code was missing from a DoomLegacy function, so I have to include that now. I will get 1.47 released, really soon now (some time this year, I hope).
  13. This is new to me. There is some weird stuff concerning music that is specific to Windows versions of the build. It being that I develop using Linux, this does not show up in any binary that I run. Some of that code was experimental and probably has not been touched in 10 years, except for trying to keep it unbroken while making systematic changes of the music interfaces.
  14. wesleyjohnson

    Doom Source Ports family tree (simplified, for Wikipedia)

    I would categorize that as code borrowing, not feature implementation. Implementing Boom generalized linedefs would be feature inherited from Boom. The code we borrowed actually came from PrBoom, but if you are only going to show feature inheritance, then that indirect source would not have to be shown. I think that the feature inheritance is probably more important to an end user than code borrowing. I expect only source port developers would be interested in a tree that showed all the code borrowing too.
  15. wesleyjohnson

    Doom Source Ports family tree (simplified, for Wikipedia)

    That just about what I expected. But it shows the truth, that the relationships between ports is not simple, nor elegant, nor pretty. I assume that is showing features inherited (not code borrowed, or else there would be alot more lines), so I have to question what features Chocolate Doom could have contributed to Eternity Engine. But, in general .. yes that is more like what I remember
×