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

jval

Members
  • Content count

    844
  • Joined

  • Last visited

About jval

  • Rank
    Forum Regular

Recent Profile Visitors

2900 profile views
  1. Yes, it's coded in Delphi. Should compile with FPC/Lazarus with minor changes.
  2. jval

    ENDEDIT - ENDSCREEN editor

    ENDEDIT does not use any fancy libraries and should be able to compile under Linux with Lazarus with minor changes. Unfortunately I do not have neither any Linux development environment, nor any Linux experience in GUI apps to try it myself. What errors? Can you post a screenshot ?
  3. I have no problems disabling bobing, as I had answered in PM. I can not think what is wrong and it does not work in your system...
  4. Voxel handling it's a bit different than GZDoom. DelphiDoom uses voxels as a sprite replacement (multiple voxels can be assigned to a single sprite). eg voxeldef "PMAPA.kvx" { droppedspin = 25 placedspin = 25 replaces sprite "PMAPA" } Sprite string can be 4 or 5 chars long. A 4 character declaration replaces all the frames of the sprite. Z axis Offset is not supported for voxels in software rendering, only in OpenGL mode ("offset" keyword).
  5. Try to compress the pk3 file with low of no compression, maybe this will help.
  6. Ohhh, I thing I've found what's wrong. Stupid me, I should have check the error log: It's the "Pain Frame" which causes all the damage.... As far as I can tell it should be "Injury frame" not "Pain frame". I removed the line from the Dehacked and it worked (there is already an "Injury frame" line). Do other source ports actually work with "Pain Frame"? I can easily put an alias for it. Work-around: DelphiDoom since it finds an unknown keyword ignores the next lines until it finds another "group" keyword, thus it does not register the next lines until the line with the "Frame 726". As a result, it does not set the "Far attack frame" equals 0, and also it does not set the initial bits. The A_HealChase() when it fails to find a corpse to resurrect, it calls A_Chase() which can set the actor to a non zero ""Far attack frame", calling A_HealChase() again and again.... I hope during week-end to find some time to look at the other issues too....
  7. Thank you for reporting! I checked how A_RadiusDamage() works in Woof and it seems to works a bit differently than DelphiDoom, when calculating damage. I suspect that DelphiDoom calcs damage=0, I'll try to confirm it and fix it. DelphiDoom already had other mechanics involving infighting and inheritance (flags like +DONTHURTSPECIES & +MISSILEHURTSPECIES) and custom damage types (eg projectiles with the +FLAMEDAMAGE can not hurt actors with the +NOFLAMEDAMAGE flag). The projectile and infighting groups of MBF21 made things more complicated (from the developer side of view). I'm glad it works! Unfortunately the resurrection causes an infinite recursive call to DelphiDoom, since it lacks the checking for not setting in the same frame/tic the same state again (as Woof/dsda or even prboom+). The crash occurs while calling the A_HealChase() on the "far attack frame" (736) of the new vile, which recursively ends up setting the vile to the "far attack frame" again and again, causing an infinite loop. Since DelphiDoom does not stop the recursion (as woof/dsda) the crash occurs. The fix to the problem is trivial (just a few lines of code, already done for testing) but the bad thing is that DelphiDoom deliberately allows recursive calls, since passing again of the same state in the same tic for the same actor is an absolutely acceptable behavior in case of: States with randomized tics, when the random range includes 0 tics (i.e. repeat the action at the state if the tics of the state set by random number generator equals zero) Actions with parametrized variables, which they are calculated on the fly, every time the function executes and change the flow dynamically e.g. A_RandomGoTo(label1; label2; etc...) Repeated calling of scripts until a condition/countdown is satisfied At the moment of writing this post I feel desperate for a proper solution in order to maintain both behaviors, at least without sacrificing valuable CPU time to make rough checks in each state change. :( :( I really don't know what to do... The easiest thing is to detect an MBF21 dehacked and disallow recursive calls maybe.... ? since MBF21 ports behave like that? Ohhh, what a nightmare! Thanks again for the detailed and helpful feedback!
  8. Issues reported by @Doomy__Doom & @Khorus has been addressed in v.2.0.7.735 What's new: Fix problem when starting from different folder than the executable. Fixed crash when enter automap mode in certain screen resolutions. Fixed drawing problem in OpenGL mode when changing screen resolution. Improved overlay drawing accuracy in hi-res. Displays statistics in automap. Automap stats screenshot: Crash bug in automap work-arround:
  9. I can not replicate the crash. Can you give me some more info? What WAD/MAP, or if it is possible a saved game? OpenGL or software rendering exe?
  10. Fixed to the repository. The changes will available in next update.
  11. Thanks for reporting, I'll look at this. In the meantime, you can put an extra cd command in your bat/cmd file in order to have the bat/cmd file in your doom folder, e.g.: cd delphi-doom-2.0.7.734-win32 GLDoom32.exe -iwad ..\wads\DOOM2.WAD Doom32.swd is the system wad and it must be in the same folder as Doom32.exe & GLDoom32.exe. The Doom32.swd file is inside the download zip that contains Doom32.exe & GLDoom32.exe.
  12. DelphiDoom can play without desync most of the 1.9 vanilla demos (all official Doom IWAD demos play without desync). In addition it can record demos in it's own format and has backward demo playback compatibility with demos recorded with previous official releases. Backward demo compatibility is not guaranteed in demos recorded with WIP versions. Heretic, Hexen & Strife branches are demo compatible only with the internal demo format, not vanilla.
  13. A new update (2.0.7.734) is available: https://github.com/jval1972/DelphiDoom/releases/tag/2.0.7.734 What's new: Faster startup, now it loads at about half the time compared to previous versions. Improved ZDoom compatibility in VOXEL declaration (VOXELDEF lump). Display correct quit messages depending on game, vulgar messages will be displayed only if the vulgarquitmessages console variable is set to true. Proper menu stretch in widescreen mode. Added option to use mouse for player movement (back and forward). It can be accessed from the Menu ("Options/Contols/Y Mouse axis"). Look up/down is disabled by default (Doom branch). Crosshairs are disabled by default. etc...
  14. One fundamental difference between id-tech1 and BUILD is that id-tech1 uses bsp while the BUILD is a portal engine. I'd like to mention voxels as well.
  15. It also crashes with the french IWAD, while the latest builds of Pr-Booom-UM & dsda-doom just completely ignore the episode menu due to missing M_EPISOD patch. Maybe this must be also taken into account.
×