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

Julia Nechaevskaya

  • Content count

  • Joined

  • Last visited

About Julia Nechaevskaya

  • Rank
    Warming Up

Recent Profile Visitors

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

  1. Julia Nechaevskaya

    Crispy Doom 5.3 (Update: August 12, 2018)

    Oh dang, I've missed your message. Checked just now dev Crispy build with dev Choco DLLs - everything is fine. But now DLLs seems to be same in both dev Crispy and Choco?
  2. Julia Nechaevskaya

    Crispy Doom 5.3 (Update: August 12, 2018)

    Windows 10 LTSB 64-bit: - WASAPI (5.3 release, dev Crispy executable) - XAUDIO2 (5.3 release, dev Crispy executable and dev Choco DLLs). Everything sounds fine with both variants. I've also was never having a cartoonish sounds. Edit: same results on Windows 7 Enterprise, 64-bit.
  3. Julia Nechaevskaya

    Crispy Doom 5.3 (Update: August 12, 2018)

    Got it reproduced. Another place where you can easily see it (same map): https://youtu.be/z3AwLW_4TsU Not sure what is happening, but it's definitely not a DEHACKED lump issue, there only [STRINGS] lumps. Could it be a BLOCKMAP issue then?
  4. Julia Nechaevskaya

    Crispy Doom 5.3 (Update: August 12, 2018)

    It's working, but it's not very notable in some floors/ceilings because of limitation of 256 colors. For example:
  5. Julia Nechaevskaya

    Crispy Doom 5.3 (Update: August 12, 2018)

    MAJ, there is no way to fix it at the moment, because all Russian text strings are "hardcoded" into executable, as well as Russian alphabetic chars are using replaced English STCFN font numbers. I have some plans to transfer strings into something like DEHACKED/LANGUAGE lump to bring some nominal English backwards compatibility, but even after this, using a translation PWAD in other ports with non-Doom specific strings (i.e. port-specific) will not fix this case and probably left some strings as untranslated or unreadable abracadabra. In other words: it's very easy to make a simple translation PWAD compatible with other ports, but there is no way to make it looking perfectly proper with all the ports, especially with ports which are using other than standard Doom texts.
  6. Julia Nechaevskaya

    Crispy Doom 5.3 (Update: August 12, 2018)

    Not quite so, it's mostly issue #204 in Crispy Doom tracker. Formally, it's extremely easy to "fill" whole screen with game window, but the problem is - not everything easy as expected. In very short words: there are too many graphical elements and technical specifics, which are "binded" to original 320:200 (or even Crispy 640:400) resolution, like status bar, menu elements and many rendering-related things. Thus, there are a lot of aspects that's should be accounted to make game window friendly with any resolution and more of that - with any aspect ratio.
  7. Julia Nechaevskaya

    DOOM Retro v2.7.5 (updated November 18, 2018)

    Brad, since now I'm addicted on p_fix, I have some thoughts to share about hanging corpses. They are looking kinda unrealistic, yeah, but -- they have own "charm". I don't think it was a mapping error, since they are too notable in some places like E2M7 (above slime pool), and more of that, they can be found mostly in hellish Inferno levels, where, I believe "it is okay to see some odd and non-realistic things". Another interesting thing you surely know is missing hanging legs in Doom 1 episodes. I.e. they are not missing, just have no skill spawn flags. Some of them are placed beneath the ceiling, but some beneath the sky. I think they are more questionable, was id forgot to set spawn flags, or rejected them at all. I'm not suggesting to "turn on" those legs, remembering our discussion about trees in Wolfenstein levels, neither I'm not enforcing to add back hanging corpses - it should rely on your author's taste. But it's still very interesting case to think about. :)
  8. Julia Nechaevskaya

    PrBoom-Plus, ver.

    kb1, as Szymanski mentioned, it does not help. To be more clear: for me, this bug appears only while weapon is bobbing, in static position everything fine. To capture this screenshot I have recorded a video and get picture from it. Probably it's a screen resolution dependent thing.
  9. Julia Nechaevskaya

    PrBoom-Plus, ver.

    I've also have it, it seems to happens randomly while sprite moving. Here it is:
  10. Julia Nechaevskaya

    DOS Source Ports?

    @fabian, @Coraline, thanks colleagues! From my experience about DOS version - frankly, nowadays it's something like "demoscene" rather than source port in traditional meaning. Really not much people interesting in it, but hey, it's still good thing to do for fun and for self-education of course. Coraline, I can gladly adapt my translation for 3DGE, all resources and texts are polished. But since 3DGE must also have English language, some additions are absolutely necessary in the 3DGE's code, like support for Cyrillic characters in language.ddf and additional table for console font. There are also can be some "underwater rocks", since translation itself is highly resource-depending thing. In short words: it should be done perfectly, or should not be done at all.
  11. Julia Nechaevskaya

    Features you would like to see in EDGE

    Just one word: BRIGHTMAPS!
  12. Julia Nechaevskaya

    Crispy Doom 5.3 (Update: August 12, 2018)

    Ahh, those darn brighten switches are blinded me, and I'm missing the show again. Fabian, congratulations with this colossal step forward! A lot of great things has been done and a lot more will be done in future. I know it for sure, so please keep rocking! ;)
  13. Julia Nechaevskaya

    IMPORTANT FOR DEVS: SDL2 2.0.6's audio breakage in Windows

    Another problem that may occur with 2.0.7 - if the game/port is started in fullscreen mode and then changed to windowed (by Alt+Enter combination), window frame will be borderless. However, after pressing Alt+arrows borders will appear.
  14. Julia Nechaevskaya

    DOOM Retro v2.7.5 (updated November 18, 2018)

    bzzrak, thank you for posting a link, it's a treasure!
  15. Julia Nechaevskaya

    Chocolate Doom

    Colleagues, Thinking a little bit more about AlexMax's CMake project, I would like to suggest to don't remove completely Code::Blocks project files, created by Russell Rice. Well, as I said, there is nothing awful hard in setting up CMake, but -- I have found that current CB project files is more comfortable for configuring, more portable and more easy than ones generated by CMake. Another huge benefit of portability - current CB project files are independent from strict system path of GCC, it can be unpacked anywhere, the only thing is necessary is to properly choose toolchain's path in Code::Blocks itself. Maybe there is no need to keep them directly in Chocolate repository, but maybe it might be a good idea to keep them on the Wiki, for example in "Alternative build" section. I can take care about them in the future, there is nothing hard: just add new files to CB project (if they added in repository), and bump version (which is totally cosmetic action). These files are valuable not only because of usability, but also saves a lot of time - no need to re-generate CB project after every new download of the source code.