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

582 profile views
  1. Version 1.6.1 is available. What's new Create or modify voxels with advanced scripting (thanks to Remobject's PascalScript). Create auxiliary voxel buffers at start-up to avoid repetitive memory allocation and de-allocation. Paint-Editing preview changed to be more "eye-friendly". The borders of the rectangle that represents a voxel/pixel, are not black anymore. Instead we use a color similar to the color of the voxel itself. OpenGL rendering clean-up and fixes. Downloads Windows Executable and source code: https://sourceforge.net/projects/delphidoom-voxel-editor/files/DD_VOXEL_1.6.1/ Scripting examples: https://sourceforge.net/projects/delphidoom-voxel-editor/files/Examples/ Screenshots
  2. Ooops, sorry, binary ports then! :) :)
  3. Dehacked & DEU were amazing achievements considering that were build before Doom source code released. From source ports svStrife & Chocolate Strife and Doom64 EX.
  4. jval

    DelphiDoom 2.0

    Version is available. Latest improvements include: The parameters of ACTORDEF functions can access Global Pascalscript Map & World variables. Usage of multiple cpu cores for HUD drawing. Sprite sorting uses conditionally (depending on number of vissprites) various sorting algorithms to improve performance (see also this post). Also the sorting process takes place in parallel with columns and spans drawing as suggested by @zocum here. Download link at sourceforge: https://sourceforge.net/projects/delphidoom/files/DelphiDoom%202.0.4/
  5. jval

    Back to mapping after 15 years

    By the way, Slade 3 has a nice integration with DoomBuilder:
  6. I've checked some time ago an algorithm (link here) which describes the creation of voxel volume using depth information from different views of an object. Doom sprites do not have depth info, but I was thinking of using the +/- 90 degrees angle to create it. Also Doom sprites do not have up/down view/info. Unfortunately never came even close to implement this method (not even tried). The only thing left from this, is just a note in my TO-DO list.
  7. DD_VOXEL uses OpenGL rendering for voxel preview (the right part of the main screen with the 3D preview). In early version the rendering was crude and slow, but in latest versions it generates an optimized mesh from voxel data and saves it to a compiled list. Then it calls the list, binding a procedural generated 512x512 texture, (gld_InitVoxelTexture in vxe_gl.pas) with 262144 distinct colors. I've developed that method when I was implementing voxels to DelphiDoom (version 1.1.5 build 580). So, in OpenGL the rendering is actual polygon based. The ddmesh export format (File/Export/Optimized mesh) contains the precalculated mesh information, so DelphiDoom do not have to generate it at runtime/loadtime. For sprite export it uses purely software calculations with z-buffer. DelphiDoom in sortware rendering, renders the voxels as sprites, using a "colorcolfunc". i.e. voxel=collection of vertical columns, vertical column=collection of color fractions. In all rendering scenarios non visible voxel pixels are eliminated before the actual rendering. This procedure can be done on demand using the Voxel/Remove non visible voxels command of the menu.
  8. Version 1.5.2 is available. Download link:https://sourceforge.net/projects/delphidoom-voxel-editor/files/DD_VOXEL_1.5.2/ New features: Option to save sprites in 32 angles. Sprite export dialog with many options. Small fixes Screenshots: The new sprite export dialog: Sprite with 32 angles export example: The WAD file with the above example can be downloaded here. (requires DelphiDoom version 2.0.4 built 715 or higher)
  9. jval

    Complete iwad list

    IWAD or PWAD signature is the same exact think to the engine. // WAD file read (handle, &header, sizeof(header)); if (strncmp(header.identification,"IWAD",4)) { // Homebrew levels? if (strncmp(header.identification,"PWAD",4)) { I_Error ("Wad file %s doesn't have IWAD " "or PWAD id\n", filename); } // ???modifiedgame = true; } But users consider IWAD as wad files with all the assets to run the game and PWAD as wad files with some extra content (but not complete game).
  10. That's what I have in mind. Radix sort seems to behave better that mergesort & quicksort when we have more than 500-1000 vissprites to draw.
  11. Please consider the fact, that the absolute values are in a relatively fast modern core i7 processor. The absolute and relative gain will be higher in a lower-end CPU. I'll post some tests as soon as I can reach a lower - spec PC. I can not use the method using the BSP since I can not fully understand it. One other approach I've considered is front to back sprite drawing using dephbuffer, to avoid overdraw. I've already tested this with good results, since the sorting is performed right after the bsp traverse, in paraller with the column and flat drawers. Since the sorting is finished in less time than the drawers, I'm considering the possibility to use the extra thread for other stuff also, to improve multiple-core expoiltation.
  12. jval

    Share Your Jokes

    Salesman: We have high quality and low prices, which do you prefer?
  13. Of course a new better algorithm, could open new possibilities as mentioned above. The only fps slowdown on any level, it is, literally, the slowdown of a couple of if(numvissprites < X) can cause once on each frame, just to find what sort function to call. Also made some real vissprite data and tested some of the sort speed. The data were collected in random frames of the mentioned maps. The test application can be downloaded from here You can also create your own data, save then on a text file (containing the integer values to be sorted), and load them to see the results. -------------------------------------------- Doom2.wad / MAP18 Sort Test 132 Items (Mean time from 1000 tests) -------------------------------------------- Algorithm Time Validation Stable -------------------------------------------- QuickSort 0,0000015 OK Undefined MergeSort 0,0000019 OK Undefined RadixSort #2 0,0000098 OK Undefined -------------------------------------------- -------------------------------------------- sunlust.wad / MAP28 Sort Test 174 Items (Mean time from 1000 tests) -------------------------------------------- Algorithm Time Validation Stable -------------------------------------------- QuickSort 0,0000020 OK No MergeSort 0,0000029 OK Yes RadixSort #2 0,0000093 OK Yes -------------------------------------------- -------------------------------------------- epic.wad / MAP05 Sort Test 319 Items (Mean time from 1000 tests) -------------------------------------------- Algorithm Time Validation Stable -------------------------------------------- QuickSort 0,0000049 OK No MergeSort 0,0000073 OK Yes RadixSort #2 0,0000110 OK Yes -------------------------------------------- -------------------------------------------- sunder.wad / MAP14 Sort Test 876 Items (Mean time from 1000 tests) -------------------------------------------- Algorithm Time Validation Stable -------------------------------------------- QuickSort 0,0000433 OK No MergeSort 0,0000238 OK Yes RadixSort #2 0,0000178 OK Yes -------------------------------------------- -------------------------------------------- DVII-1i.wad / MAP03 Sort Test 967 Items (Mean time from 1000 tests) -------------------------------------------- Algorithm Time Validation Stable -------------------------------------------- QuickSort 0,0000492 OK No MergeSort 0,0000372 OK Yes RadixSort #2 0,0000187 OK Yes -------------------------------------------- -------------------------------------------- sunder.wad / MAP08 Sort Test 1241 Items (Mean time from 1000 tests) -------------------------------------------- Algorithm Time Validation Stable -------------------------------------------- QuickSort 0,0000616 OK No MergeSort 0,0000419 OK Yes RadixSort #2 0,0000254 OK Yes -------------------------------------------- -------------------------------------------- nuts.wad / MAP01 Sort Test 3840 Items (Mean time from 1000 tests) -------------------------------------------- Algorithm Time Validation Stable -------------------------------------------- QuickSort 0,0001019 OK No MergeSort 0,0000899 OK Yes RadixSort #2 0,0000545 OK Yes --------------------------------------------
  14. No, I did 't include the intermediate step. I used the a pattern of unsorted vissprites as created by the bsp. The tests were not performed in nuts.wad, it was just picked as an easy choice for screenshot, since it has many vissprites at start of the map. The benefit stands in all maps, since we're trying to optimize a task that needs constant time of CPU time regardless the screen resolution. That's why the benefit also is more observable in lower-end CPUs. @Gez Why lose fps?
  15. @kb1 Indeed, it's not that much memory in modern computing terms, even in the case that the array holds the actual data, not only pointers. But merge-sort needs only half of the array size as extra memory. Could more extra memory lead to cache hit misses? I 'll try to test this using an lower cache CPU... @zokum Multi threading seems an excellent idea, and I thing the right place to do it is while rendering the Planes (R_DrawPlanes). lI'll try this ASAP! @anotak & @scifista42 I've added merge-sort to the test-case and here are the results: As we can see, merge-sort is faster than quick-sort, but not that fast as the radix-sort. Next step will be to test this in a lower-end CPU as I mentioned above, to make sure that smaller CPU cache does not bottleneck radix-sort. And @anotak since I was curious about this comment of Lee Killough , I've made a comparison of merge-sort in random data vs vissprite-like unsorted data. The results are obvious: