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

Ramon_Demestre

Members
  • Content count

    82
  • Joined

  • Last visited

About Ramon_Demestre

  • Rank
    Mini-Member

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. Ramon_Demestre

    dsda-doom source port [v0.24.3]

    Latest Win32 test build for dsda-doom https://github.com/RamonUnch/dsda-doom/releases/download/v2022-11-14/DSDADoom-2022-11-14-win32.7z Use at your own risks.
  2. MAP18 UV Speed in 0:36.40 256v18-036.zip I was casually playing through this wad and discovered the that sometime when shooting at the very top of the first block almost all blocks would get lowered instantly. After a few tries I got 37.00 secs, then I worked until I got 36.40 secs.
  3. Ramon_Demestre

    dsda-doom source port [v0.24.3]

    I made a Win32 build of the latest dsda-doom master branch. Do not use for demo recording as it is not yet an official release. It may however help out some win32 users that want to checkout the new stuff. https://github.com/RamonUnch/dsda-doom/releases/tag/v2022-10-09
  4. Ramon_Demestre

    dsda-doom source port [v0.24.3]

    Usual win32 build of dsda-doom 0.24.3 https://github.com/RamonUnch/dsda-doom/releases/download/v0.24.3/DSDADoom-0.24.3-win32.7z
  5. Ramon_Demestre

    dsda-doom source port [v0.24.3]

    Here is a Win32 build of latest dsda-doom.exe (only) that has the fix, just to try. This is not an official release... dsda-doom0.24.2-win32exe-PKr-smoothmouse.7z
  6. Ramon_Demestre

    dsda-doom source port [v0.24.3]

    That is strange, the dsda_TickElapsedTime() uses the clock_gettime() timing function and should be microsecond accurate instead of the 1-2 milliseconds inaccuracy of the SDL_GetTicks() that is used by I_TickElapsedTime() in prboom+. dsda-doom changed all timing function to gain accuracy, I guess the implementation of clock_gettime() depends on the os and on the complier, but I hardly see how it could be worse than the SDL_GetTicks(), do you have any idea? Edit: Ok I see you figured it out, congratulations! This is a very nice improvement, I always used to turn OFF vsync but I guess It can be turned on now.
  7. Ramon_Demestre

    dsda-doom source port [v0.24.3]

    Win32 build of dsda-doom v0.24.2 https://github.com/RamonUnch/dsda-doom/releases/download/v0.24.2/DSDADoom-0.24.2-win32.7z Note that the download is twice bigger than usual (6.3MB) because it includes the soundfont in dsda-doom.wad It is the limit of what I am able to upload on GitHub in a reasonable time with my internet bandwidth. If needed I will only update the .exe files in the future.
  8. Ramon_Demestre

    dsda-doom source port [v0.24.3]

    Win32 build of dsda-doom 0.24.1 https://github.com/RamonUnch/dsda-doom/releases/download/v0.24.1/DSDADoom-0.24.1-win32.7z
  9. Ramon_Demestre

    dsda-doom source port [v0.24.3]

    Win32 build of dsda-doom 0.24.0 https://github.com/RamonUnch/dsda-doom/releases/download/v0.24.0/DSDADoom-0.24.0-win32.7z
  10. Ramon_Demestre

    dsda-doom source port [v0.24.3]

    >something similar to what has been implemented in russian doom would be nice, too  https://github.com/JNechaevsky/russian-doom/issues/262 For me the only concern I have with dsda-doom fullscreen hud is related to the order of the items. in doom you have from left to right: AMMO | HEALTH | ARMOR. Because I am so muche used to vanilla and tend to use the maximum fullscreen mode,then end up checking my status from time to time with the -/+ keys. This Russian Doom format looks quite good, but for me the way crispy does it is perfect because it matches exactly the vanilla order. The dsda-doom way is similar to the ZDoom fullscreen hud and to the heretic way which is not the best for doom because we are so much used to look at the very left to see ammo and not health. Of couse I am not taking about the advanced boom-style hud which has its own merits. Because dsda-doom is very focused towards demos and "purists". I think the fullscreen hud should match the position of the status bar, like crispy does. even though Vanilla does not have any kind of fullscreen hud. I like very much the dsda-doom philosophy, I like how it does not try to fix vanilla cosmetic bugs that I am so much used to, for example if a fast door makes a single closing sound I always have the feeling it did not really close, I far prefer the colored sky with the invul. etc. Usually on prboom-plus I had to spend half an hour to sort all of those settings out and have a working config; here I just need the complevel. By the way I made a PR for prboom-plus to add a vanilla_keymap option. any chances it will be merged in dsda-doom as well? I use mostly non-us keymaps and dsda-doom is mostly unusable outside of the box with a non-us keymap (try the french one!). You actually need to change many bindings before it works and if you switch by mistake to another keymap, then you have a problem again... vanilla_keymap option fixes it by using a static mapping table from key scan-codes, like chocolate-doom does.
  11. Ramon_Demestre

    dsda-doom source port [v0.24.3]

    I agree with you, however it appears that in opengl mode scaling behaves quite differently. In gl-exclusive mode, dsda-doom always uses the full video buffer resolution, and never makes margins to compensate for aspect ratio. It works nicely with 640x400 for me but there is not the option to scale like it does in exclusive-software, so I guess it would be nice if you add a flag that it applies to both GL and software render.
  12. Ramon_Demestre

    dsda-doom source port [v0.24.3]

    For me the fix "should" just be to check for the exclusive_fullscreen variable in software. This would also make it behave like the GL mode that does not do that and treat 640x400 and 320x200 like the software mode with this fix. // [FG] aspect ratio correction for the canonical video modes if (!exclusive_fullscreen && (SCREENHEIGHT == 200 || SCREENHEIGHT == 400)) { actualheight = 6*SCREENHEIGHT/5; } else { actualheight = SCREENHEIGHT; }
  13. Ramon_Demestre

    dsda-doom source port [v0.24.3]

    Yes indeed if I comment out the special case, everything is as intended in exclusive full-screen mode: // [FG] aspect ratio correction for the canonical video modes // if (SCREENHEIGHT == 200 || SCREENHEIGHT == 400) // { // actualheight = 6*SCREENHEIGHT/5; // } // else { actualheight = SCREENHEIGHT; } Exclusive mode, it looks "flat" here, but is actually rendered stretched to 4:3 on my monitor so it is perfect! but looks wrong in non-exclusive mode (flat): So I think this special treatment should be reserved to the non-exclusive mode? or it could be a separated flag? I think that if someone uses the exclusive mode and 320x200 or 640x400, it means he wants a vanilla style behavior, where the monitor has to do the aspect correction instead of not using the full width of the frame. Thanks a lot for your quick answer, I have my fixed build now
  14. Ramon_Demestre

    dsda-doom source port [v0.24.3]

    Exclusive full screen 640x400, the problem is that the whole image is stretched to 4:3: If my monitor was 16:10 then it would look fine, but Nonexclusive fullscreen (monitor resolution is 1400x1050), looke good!:
  15. Ramon_Demestre

    dsda-doom source port [v0.24.3]

    I have a very specific request about screen scaling, let me explain my specific case: I have a 4:3 monitor (old school) and I like to play with a resolution of 640x400. When I use the "non-exclusive" software mode, dsda-doom as well as prboom+ properly fills the whole monitor and renders exactly as intended (like crispy-doom). However on my machine I like to use the exclusive software rendering option because I get better performances this way (and it is helpful). My monitor stretches the 640x400 buffer to the full monitor rendering non-square pixels. However dsda-doom does not know this and assumes pixels are square on the screen and whatever settings I modify, I see black margins on the monitor sides and the image is stretched vertically using less than the full 640 pixels. Of course the fix is to use 640x480, but I far prefer 640x400. Note that the problem is exactly the same using 320x200, that is also stretched to 4:3 with non-square pixels on my monitor. There could be an additional "FILL" scaling option or something, maybe I am missing a setting, but I could not find reading the .cfg file.
×