• Content count

  • Joined

  • Last visited


About jval

Recent Profile Visitors

176 profile views
  1. You can look at that thread: https://www.doomworld.com/forum/topic/64148-delphidoom-progress-in-3d-perspective-in-software-mode-now-with-voxel-support/#comment-1165911 It's a compination of zaxisshift aspect ratio changing depending on the look up/look down angle panning and stretching of horizontal lines depending on the line Y position a trapezoid to rectangle transformation
  2. I consider multiple TEXTURE3 lumps inside the WAD structure as more appropriate behaviour, since using TEXTURE4, TEXTURE5 etc will cause uncertainty among loading at once multiple mods. But ... for now, only one single TEXTURE3 lump is supported (the one at the last WAD loaded). I stick to that since the purpose of TEXTURE3 lump is to: provide textures that are using existing patches (PNAMES) easy declaration of texture names (set numpatches to zero and use a hi resolution replacement between HI_START & HI_END lump markers). Future plans include the creation of an extended (probably with scipt/text-based syntax) declaration of user defined textures. Before that I want first to find out how other ports deal with custom texture definition (ZDoom, Vavoom, others?) and make a compatible implementation.
  3. A new meintainance release (ver is available. This release includes new features such as: Support for PCX images as external textures. New mobj functions to control flow depending on map & world variables. Support for 'TEXTURE3' texture lump. Builds map nodes if missing from wad file. Download link at sourceforge: https://sourceforge.net/projects/delphidoom/files/DelphiDoom%202.0.3/
  4. Radge stands for [RA]ndom [D]oom [GE]nerator and it is a command line tool for Windows to create random maps. It is based on slige (build 490). Downloads: https://sourceforge.net/projects/radge/ The purpose of this project is to explore the potential of random map generation using various algorithms in the future. In order to use the levels with a source port you must first build the nodes with an external tool such as glbsp. The project is written in Pascal language. The source code can be compiled with FPC/Lazarus.
  5. The only thing that DelphiDoom shares with the quake engine are the MD2 model typedefs. There is no zdoom compatibility.
  6. The most characteristic features of DelphiDoom are: Fast multithreading software renderer with true color output, external textures, transparency, voxels, and post processing effect to eliminate perspective distortion Custom actor definition (ACTORDEF lumps) Advanced script engine (PascalScript) to customize levels and actors (procedures, functions, recursion, loops, user defined types, dll function calls etc) Support for all official releases of Doom, Heretic, Hexen, Strife & Chex Quest (including the very first Doom Shareware 0.99, Heretic Wide Area Beta and Strife Teasers) Developed in Pascal language
  7. A new meintainance release (ver is available. This release includes minor fixes such as: Fixed alpha channel in TGA screenshots. You do not have to re-ender the save game name when overwritting saves. The mouse sensitivity slider within menus can accept values up to 20. Will not crush when finishing MAP33 etc levels. (but it will crash if MAP34 not found) Fixed revenant internal demo bug (thanks to Crispy Doom) Download link at sourceforge
  8. I'm suspecting that the usage of the gametic variable in A_Tracer() could create desync problems. Using the leveltime variable seems the most logical alternative. Any opinions?
  9. He's making a source port!
  10. Im' using glBSP as DelphiDoom's internal node builder.
  11. DelphiDoom uses 1-282 plus 386-391 for slopes (same as Eternity).
  12. Not actually a port, but rather a total conversion, never announced to the Doom community (was announced in a Pascal development community instead) was Portal. It is a stand alone game coded back in 2012, based on DelphiDoom's source code ( beta - opengl mode). It added new features to the Doom engine such as:Object indicators (friendly/interactive/pushable/enemy) Pushable oblects Interactive objects Comic bubbles with interactive dialog (engine suppoted also voice but game data was limited to bubble text only) Sloped surfaces 3D mesh map enhancements Hub level progression Procedural generated content (scenery) Both procedural(pascal compiled code) and scripted AI (ACTORDEF) Clevel chase camera (AI controled) AI controled fog Underwater player control (swimming) Earthquake effect AI controled movement restriction rules(eg direction turn) New HUD Some of the above features were backported to DelphiDoom (eg pushable and interactive objects etc) and some others were re-implemented using different approach (big portions of the pascal compiled code AI can be reproduced with DelphiDoom's 2.0 PascalScript). This is the (Download link) (The game itself does not feel like Doom).
  13. Since I do speed Greek it isn't that hard then :) Yes, indeed, then code takes many years to master. It's 80.000 - 100.000 lines of code. It's big. But to correct my latest post, the game mechanics are indeed complex and hard to understand. But if you focus to any point it's far more readable that eg. the source code of the build engine (written in double Dutch :D). Doom source code is split to self-explained units/filenames, no crazy C-isms and well formatted. If you focus to a function, you can actually understand what is doing. In build engine you do not even know where to look.
  14. The Doom source is readable and easy to understand. It's not like this.
  15. All of a suddent I read something I was thinking a long time ago. IMO, not only the demo file will grow large in size, but also performance issues may occur while recording (and/or while playback). Just as the difference between a still image and a video, this is like the difference between a saved game and a version-independent demo format.