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


  • Content count

  • Joined

  • Last visited


About jval

  • Rank

Recent Profile Visitors

1387 profile views
  1. Unfortunately I can't reproduce the problem (tried in in Windows XP virtual machine and the midi volume change works fine). This is the control panel of my VM:
  2. I thing I know what's wrong, probably because the CPU can not draw the whole frame in 1/70 sec. I'll try to fix this.... ROTT has many multiplayer modes and more variety in enemy think/AI. Also ROTT source code, in terms of source code lines, is 4x times the Greed source code (and 2x the size of Doom source code).
  3. jval

    What's the best source port to play Hexen?

    You can also try the Hexen branch of DelphiDoom (DelphiHexen) which is in active development. It has gameplay mechanics close to vanilla with the advantage of high screen resolutions and scaleable visual output from old hardware to high-end modern systems.
  4. Is it version or I had some thoughts about ROTT in the past, but I discarded the idea. ROTT is too much more complex compared to GREED and it needs a dedicated developer for such a project. Since I have other projects running it wouldn't work.
  5. jval

    What's the best movie you've ever seen?

    If I have to pick one it's "City Lights".
  6. jval

    Smallest source port?

    Probably CDoom.
  7. WIP 20200712 is available. What's new (since latest official release Corrections to ACTORDEF export procedure (DEH_PrintActordef/DEH_SaveActordef console commands). Run earthquake effect code only when needed. Fixes to 3d floors drawing in software rendering mode. RandomRange() function in PascalScript. Support for ANIMDEFS lump. Line specials 291 & 292, set floor and ceiling texture offsets. Prevent crash in lines with invalid sides. Corrected issues with voxel clipping. Fixed problems when installed in a directory that it's name contained spaces. Added -mididevice command line parameter. Added MF3_EX_BLOODIGNOREDAMAGE mobj flag. Dehacked export saves the state name as comment. Dehacked "NEXT FRAME" keyword will accept global state names as value. Custom ACTORDEF labels can be accessed with [mobjname]::[label] by dehacked fields and other actions involving state names. Added A_ChangeFlag ACTORDEF function. Downloads: DelphiDoom: https://sourceforge.net/projects/delphidoom/files/WIP_BUILDS/WIP_Doom_20200712.zip/download DelphiHeretic: https://sourceforge.net/projects/delphidoom/files/WIP_BUILDS/WIP_Heretic_20200712.zip/download DelphiHexen: https://sourceforge.net/projects/delphidoom/files/WIP_BUILDS/WIP_Hexen_20200712.zip/download DelphiStrife: https://sourceforge.net/projects/delphidoom/files/WIP_BUILDS/WIP_Strife_20200712.zip/download
  8. Let's say that we have 1000 hardcoded states. The example adds 4 new states. Now we have 1004 states. To alter the example patch with another we can still use absolute values, and that will work if we preserve the correct load order. eg remove the BRIGHT from NewFrame 4: Frame 1004 Sprite Subnumber = 4 IMO not that complex, also why does it have to be too-simple to be a standard? It's nothing compared to a full working dehacked parser.
  9. I can't see why patches modifying other patches wouldn't work if you keep the same loading order. I'll also mention another idea, why limit frame and thing id's to numbers and don't use aliases and let the engine decide internally for the actual id. I don't thing, from a developer side of view, that this is that much more complex to implement. The only thing that must be done is to reallocate the internal tables, and that will happen only at load time (assuming we do no have the extreme need to load on demand, during gameplay, a dehacked patch).
  10. Absolute values will limit to only one DEHACKED patch at a time and will cause problems with multiple patches. I'm talking about a syntax like this (please ignore the extra fields): DelphiDoom's and FPCDoom's ACTORDEF script (similar to DECORATE) is a convenient way to write dechacked patches, since the only thing the ACTORDEF parser does is to convert the ACTORDEF script to a dehacked patch. Then the dehacked subsystem parses the auto-generated dehacked script and does all the job. And by using the -devparm parameter it prints the dehacked script to the log file.
  11. Instead of adding a constant number of new states, objects etc why this couldn't be dynamic? And eg instead of 'FRAME' or 'THING' keyword the parser could recognize 'NEW FRAME' or 'NEW THING' as an extra new frame / thing.
  12. I've added a flag to prevent blood state changes (BLOODIGNOREDAMAGE) and also I've made some improvements to the dehacked subsystem. The changes are already in the source code repository but I need to make some tests before I make a WIP release. The BLOODIGNOREDAMAGE flag prevents the engine from changing the blood states depending on damage and the dehacked improvents will allow to define the next state/frame of a state/frame using labels/aliases instead of absolute numbering. For blood color there are the GREENBLOOD and BLUEBLOOD flags but no other handling for blood color. Extra specific states are not a problem but still some a lot of thing will still be hard-coded (eg 3 different states, the damage range to use each of them etc - also Strife uses 4 different blood states not 3). I also have an idea working in my mind which could give unlimited freedom to modders not only for blood but other assets/mechanics of the game (eg puff spawning). I'm thinking of the possibility to redefine hardcoded engine functions using PascalScript. With such a feature you could easily handle eg blood splats changing the number of different states, the damage range for each state etc with a small script. Unfortunatelly such a feature requires not trivial changes to the engine, so it can not be implemented in just a couple of days. Anyway, I hope until weekend I 'll have a WIP with the BLOODIGNOREDAMAGE and the dehacked changes I've mentioned in the first paragraph of this post along with appropriate examples.
  13. jval

    very simple doom source port recommendation

    Maybe you should try some of the first Windows ports released at late 90's
  14. A_SpawnItemEx is works in relative coordinates, unless you specify the as flags (9th parameter) the number "2" (or SIXF_ABSOLUTEPOSITION in ZDoom). Ooohh, it's the Doom engine that, depending on the damage, sets the new spawned blood ACTOR to a new state. If damage is 8 or less sets the state to S_BLOOD3 and if the damage is from 9 to 12 sets the state to S_BLOOD2. So in your video only when damage is 13 or greater you see the new replacement ACTOR. The replaces keyword creates all new states for the ACTOR but the old states are intact (they can be changed only with DEHACKED script), so when the damage is 12 or less it switches to the old states. Give me a couple of days to think about it, I'll probably add a flag to prevent the state changes of blood spawning.
  15. Sorry, didn't noticed earlier: There is a problem with the "EMPT A 0" in RD_BloodStarter ACTOR declaration. First state can not have 0 tics. Please change it to "EMPT A 1" or remove it. Also the A_CustomMissile() function will fire a missile only if the calling ACTOR has a target, since RD_BloodStarter has not a target it will not spawn the missile. If it is absolutely necessary to use A_CustomMissile() instead of A_SpawnItemEx() I've added a small script to work around: vpblood.zip