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


  • Content count

  • Joined

  • Last visited

About jval

  • Rank
    Forum Regular

Recent Profile Visitors

2011 profile views
  1. DelphiDoom is alive, me too :). New updates will come soon.
  2. jval

    @jval : A request

    Can a plug-in do the work? I think that it needs some work in the Open Dialog, replace the standard listview with the level names (highlighted in the screenshot) with a listview with thumbnail preview. (i.e. modify the source code) Unfortunately I have never worked with C# (DoomBuilder source code language) to try something.
  3. jval

    Programming Languages in 2021

    As a professional my programming environment mostly involves COBOL in *NIX operating systems. As a hobby programmer I use Pascal for more than 30 years.
  4. Why not 32? Since DelphiDoom based ports support up to 32 sprite angles ;-) https://sourceforge.net/projects/voxelizer/files/VOXELIZER_1.0/VOXELIZER_1.0.2.29_bin.zip/download
  5. The same does DelphiDoom in OpenGL mode. In such cases the voxel conversion has meaning for aesthetics reasons...
  6. Voxelizer Voxelizer is an application that can create voxels and Doom sprites from MD2 (Quake2) models. It creates out of the box ACTOR definitions for DelphiDoom family source ports, ZDoom family source ports and all other source ports that support DECORATE scripting (eg. K8Vavoom) Downloads: Executable (win32): https://sourceforge.net/projects/voxelizer/files/VOXELIZER_1.0/VOXELIZER_1.0.2.29_bin.zip/download Source code: https://sourceforge.net/projects/voxelizer/files/VOXELIZER_1.0/VOXELIZER_1.0.2.29_src.zip/download Repository: https://github.com/jval1972/Voxelizer Sourceforge site: https://sourceforge.net/projects/voxelizer/ Thanks to @GRAU for giving me the idea of making a utility that can convert md2 models to voxels. Using Voxelizer The user interface is simple, just use the "Open" command to load an md2 mesh and the "Load Skin" button to load the skin/texture. There are 2 export buttons on the toolbar, the "Export Sprite" and the "Export Voxel" buttons. With this buttons you can export the current md2 model frame as a sprite or voxel. Sprite export: The sprite export dialog let you set the sprite parameters. If the target source port is DelphiDoom/RAD you have an extra option of saving the voxel as well. The sprite patches are saved in a stand alone WAD file or in a WAD file inside a PK3 file as well as with a standard ACTOR definition. Please note once again: Only the current frame is saved/converted to Doom patch. If you want multiple frames you must repeat the procedure. Also keep in mind that you may need to manually correct the offsets of the sprites (using e.g. SLADE3). Voxel Export: The voxel export dialog selects the voxel size and filename. Supported voxel formats: ddvox (DelphiDoom's voxel editor) vox (slab6) DelphiDoom family source ports support both the above voxel formats. If you want to use the exported voxels with source ports that do not support the above formats you must export the voxel in vox format and use slab6 to convert it to kvx. In game sample screenshots: GZDoom (sprite export) K8Vavoom (sprite export) DelphiDoom (voxel export) Exported voxel in DD_VOXEL tool:
  7. Welcome to GLSpeed, a remake of the 1995 DOS game "Speed Haste" using the id-tech1 General "Speed Haste" is a 1995 DOS racing game developed by NoriaWorks Entertainment and published by Friendware. It's source code (DOS, in non compiled form) is available on github. (Thanks Mr. Javier Arevalo Baeza!) GLSpeed is not supported neither by NoriaWorks Entertainment nor by Friendware. GLSpeed needs the main data file of the DOS game (speedh.jcl) in order to run. It works with both shareware and registered versions. You can find the shareware version in many sites with a simple google search. Downloads (v. - 20210428) Executable (win32): https://sourceforge.net/projects/speed-game/files/GLSpeed_1.0/GLSpeed_1.0.2.739_bin.zip/download Source code: https://sourceforge.net/projects/speed-game/files/GLSpeed_1.0/GLSpeed_1.0.2.739_src.zip/download Repository: https://github.com/jval1972/Speed Features High screen resolutions. OpenGL rendering. Uncapped framerate. Textured automap. Console for executing commands. Flac & ogg sound effects. MOD, S3M, IT & XM track music support. Screenshots. In game menu to configure gameplay, key bindings & screen resolution. Use Doom game editing utilities to create custom content. Lap records database Developing GLSpeed development started last December. I choosed not to use the original game source code as a base, but instead utilize (for one more time) a snapshot of my DelphiDoom source port. So, GLSpeed is based on DelphiDoom I used the original source code as a helper tool for the complex data structures that the game uses (mostly the i3d model format, which, even with the source code available, it seemed to me very complicated). The game logic was recreated from scratch, mostly by watching youtube videos (I had problems running the game under DOSBOX. I also tried a virtual machine with FreeDos but with no luck). Current project status: Stable, (but not optimized). Probably you will not be happy running the game with a build-in Intel GPU, a dedicated GPU will run the game smoother. Expansion pack The registered version of the game comes with 8 tracks (shareware version has 2 tracks). In order to extend the gaming experience, I decided to make an expansion pack to accompany the release. So GLSpeed comes with 8 additional tracks. The tracks are organized in 2 championships (original game and expansion). The main benefit of using an id-tech1 engine recreating the game is that custom content can be created using standard doom editing utilities. In addition, I've created some other helper tools (and utilized an old one). Tools for custom content: DoomBuilder configuration file (tested with Ultimate Doom Builder): https://sourceforge.net/projects/speed-game/files/TOOLS_AND_EXAMPLES/GLSpeed-DoomBuilder.zip/download Tile Editor (win32): https://sourceforge.net/projects/speed-game/files/TOOLS_AND_EXAMPLES/SpeedEd_1.0.1.13_bin.zip/download I3DViewer (Speed Haste model viewer): https://sourceforge.net/projects/i3dviewer/files/I3DViewer_1.0/I3DViewer_1.0.1.11_win32.zip/download I've also make extended usage of DD_MODEL (DelphiDoom Procedural Modeler) for creating dozens new models for the expansion pack (latest version is https://sourceforge.net/projects/delphidoom-procedural-modeler/files/DD_MODEL_1.1.4/DD_MODEL_1.1.4_bin.zip/download) Screenshots: Original tracks: Custom content screenshots: Enjoy!
  8. GRAU

    Hello, Jval, i got an idea, of very usefull, at my opinion, software/utility. It is an easy utility that could convert MD2 with a PNG skin, files into voxels or sprites. I know that it may be asy for you after creating a DOOMTREE, but i don't know how to code it myself( If you will find some time for such utility, it willhelp a lot to create voxel characters with animations in much faster way, because there are a lot of authors who can create md2, including me, and the md2's are easy at animating. But voxels themselves are far much harder to create animations, taking days or even weeks for each new frames. The additional function of exporting the model into 8 or 16 rotations sprites will be loved by vanilla doomfans, i belive.

    1. jval


      Done :)


    2. GRAU


      I don't belive my eyes! You are great! well, let me try it - interesting to see what it can do)

  9. Done :) https://github.com/jval1972/xGreed/commit/606be0a50f14dd65eb7122e5a34c7997ede93922
  10. The game is playable but not thoroughly tested. Mouse is not supported (yet). No, the GREED.SHR file is a compressed file used by the original install. XGreed needs data that the DOS installer produces: GREED.BLO file (data) All *.mod & *.s3m files (music) You can optionally copy the MOVIES folder of the original CD with the *.fli files (animations).
  11. jval


    An image in the clipboard is placed by a program that can manipulate images. A browser is one example. MS-Paint is another. Also, almost any image editing application can copy (place) an image to the clipboard.
  12. jval


    Which executable are you using to display the ENDOOM in your example? Which DOS emulator? ENDEDIT produces 80x25 screens, at the same size of the ENDOOM lump. The DOS screen is 80x25 in size, it looks like it displays the screen and exit an extra line is printed ('C:\GAMES\DOOM2' in your example) and the end screen is "shifted up" by one line. (i.e. you exe prints an extra LF - line feed - after displaying the ENDOOM). Here is how the official Doom II ENDOOM screen is displayed in Chocolate Doom: This is how it is displayed by the vanilla EXE in DOSBOX (notice that the vanilla EXE does not print the extra LF at the end of ENDOOM, only CR - carriage return): Also the original ENDOOM has it's last line blanc and black.
  13. He typed "idsubtitles" while watching.
  14. The bsp collects data, then the rendering starts (in order to use multithread). It's logical in a GPU not to gain much, but in software rendering maybe the gain would be better (can't tell until I try). The sprites are rendered in semi-horizontal spans when the same patch column occupies more than one screen vertical line. Rotating a 1920x1080x4 = 8MB buffer each frame is a lot of work (never tried it to be sure, just it looks like a lot of work). Cool :) I spend a couple of hours observing the lighmap code (it's more than a year since I've wrote it) and it looks a bit obscure. It's much more complicated than FPCDoom. Probably it wouldn't be hard to implement the main idea, but it would be hard to optimize it (without breaking something else). I do not worry that much for the sprites (also sprites have constant depth in all their surface due to face-player rotation, so it is cheaper to write them to depthbuffer) but for the voxels (not constant depth, i.e. more CPU to write them to depth-buffer) . Or, what if I use a constant depth for all the voxel surface (?). Probably this could also be a good chance to implement multithreading to voxel rendering, which is the only part of the actual sceen-write procedure that still works in a single thread.