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

intacowetrust

Members
  • Content count

    137
  • Joined

  • Last visited

2 Followers

About intacowetrust

  • Rank
    Junior Member

Recent Profile Visitors

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

  1. intacowetrust

    Do you use texture filtering? Why or why not?

    Yeah that's the one I use also - "None (Trillinear)".
  2. intacowetrust

    Do you use texture filtering? Why or why not?

    I use texture filtering in GZDoom, but just for stuff in the distance (minification filtering only). I like being able to mostly eliminate shimmer and temporal aliasing for distant objects while maintaining crisp pixels for stuff up close. To me its the best of both worlds and doesn't look like trash due to blurring.
  3. intacowetrust

    PsyDoom 0.4.0 - PSX Doom port (reverse engineered) for PC

    You're absolutely right - there's nothing in the code that would make it loop on it's own, you'd have to insert a sequencer command to make it jump back to the start of the track or some other suitable loop point. As to whether that command to loop back around was left out intentionally (assuming that's what the issue is), we can only speculate. However it does seem unlikely that the devs or @Aubrey Hodges would just want the music to stop completely, that sounds like a bug to me. @Erick194 can probably speak more as to why exactly it's stopping since I'm only getting started on Final Doom stuff and haven't had a chance to examine the data yet. It's probably a missing loop command but there is also a small bit of code that will kill the track if the sequencer encounters an unknown/bad sequencer command - possible it could be that either, or indeed some other issue. Speaking of Final Doom - some progress is already being made!
  4. intacowetrust

    PsyDoom 0.4.0 - PSX Doom port (reverse engineered) for PC

    Correct, there isn't really any savings to be made other than reducing the size of the sounds. The memory management is extremely simple - it just plonks the samples in the DOOMSFX.LCD file (menu, player sounds) followed by the MUSXLEVXX.LCD (music instruments) and MAPXX.LCD (map monsters/sounds) files into SPU RAM one after the other, in that order. The music sequence/notes/composition itself does not consume any SPU RAM however, that goes into a fixed/constant size buffer in main RAM. For Doom that buffer is 26,000 bytes in size and for Final Doom it's bumped up to 36,000 bytes.
  5. intacowetrust

    The poll of the century

    Coffee, French Roast. Freshly ground, nice and strong and without anything else!
  6. intacowetrust

    PsyDoom 0.4.0 - PSX Doom port (reverse engineered) for PC

    It's in his to-do list: Indeed it is. Interpolations are just for the player view right now, eventually that will be expanded to other things and also configurable to taste levels. Eventually I'm hoping to expand the SRAM limit for PsyDoom so that more complex tracks are possible with the original sequencer engine; but yeah if you are targeting the original hardware then you need to keep that limit in mind - it doesn't leave much room for music samples. Thanks for reporting, I will investigate.
  7. intacowetrust

    PsyDoom 0.4.0 - PSX Doom port (reverse engineered) for PC

    Yeah I'm trying separate files for broad categories like graphics and input this time around (unlike Phoenix Doom), just to make what you are looking for a bit easier to find. At the minute they are pretty sparse but there will be a lot more stuff in each by the time I'm done with all this. Yeah I used to have this CPU also, it's still pretty decent and probably faster overall than the MBP I tested with. Yep, absolutely. It'll get there eventually - not to worry... Indeed, I want to support that eventually. I'll need a very basic form of support for MAPINFO type stuff for properly naming maps, so chucking in the ability to change music tracks while I'm at it also makes sense. There's nothing stopping me from doing some music tooling eventually also. Having that said Erick will probably get to do stuff like that before me, since I'm quite busy right now with the more immediate goals for PsyDoom.
  8. intacowetrust

    PsyDoom 0.4.0 - PSX Doom port (reverse engineered) for PC

    At which point in the video did you notice the issue? (I could compare against the original) Can't say I heard anything strange myself... The pitch bend for this track does kind of shift and jolt in an unsettling way, which is entirely intentional. Is this what you are hearing perhaps? That's unfortunate. What kind of machine are you testing on and what is the refresh rate? Maybe the audio buffer needs to be larger in your case - trading sound responsiveness for more audio stability. I tried to maintain a balance between both but it would have tuned for my own CPU which is a i7 7700K @ 4.2 GHz. I did test on a much lower clocked MacBook Pro however (2.4 Ghz) and it was fine there also. Part of the problem with sound at the minute is that it is processed on the main game thread, which means it can be blocked by vsync, rendering and game logic. If it falls too far behind in providing samples to the sound card, you get stutter... Eventually I'm hoping to shift the audio onto a separate thread, where it can update in response to the needs of the audio device and feed it sound whenever required. That should be the proper fix for all of this. Part of the work I want to do for Final Doom support will be stepping towards this goal. I should probably add this one to the known issues list. At the minute there is a bug in Avocado with handling .cue files where the disc is split up into multiple files for the different tracks. In that case CD-DA won't work at all. If your .cue just has a single .bin file associated with it should work however... This should eventually be fixed as I am planning to do my own implementation of reading from the CD-ROM for data/audio and bypass Avocado entirely. This will also help me towards moving sound onto another thread (what I mentioned above) as I can have separate thread safe streams for CD-DA + data. Yep, I'll be getting round to it eventually - it's on the TODO list. Top priority for the next release though will be aiming for Final Doom support. I always like to get to the hardest and most difficult tasks first, then work my way down to the other stuff. That helps to take the risk out of a project earlier, and means you are tackling the meatier tasks while you are most motivated :)
  9. intacowetrust

    PsyDoom 0.4.0 - PSX Doom port (reverse engineered) for PC

    Yeah I believe that is the case. I had been comparing the timing code briefly and it looks similar for PAL, except in the case of PAL the refresh rate is 50 Hz so the game would be capped out at 25 FPS instead of 30 FPS, since the game runs at 1/2 of the refresh rate. That alone wouldn't cause a demo de-sync though, it would just make PAL demos play back a little faster in NTSC. I believe the de-sync is creeping in because some of the fundamental gameplay values for enemies (timing) are slightly tweaked or different for the PAL version to compensate for the slower tick rate. I plan to investigate at some point later and confirm if that is the case; PsyDoom might need a separate 'PAL' mode with these tweaked values in order to be able to play the PAL version properly. Thanks for catching this! Was rushing to get it out last night and made few small mistakes heh... I'll use the 'releases' page link as you suggested in future since it's much less fraught with danger :P
  10. intacowetrust

    PsyDoom 0.4.0 - PSX Doom port (reverse engineered) for PC

    Hey everyone, happy Friday! :) The time has come to do another release and this time round it's a big one! My original dream has finally been realized with PsyDoom hitting it's primary goal of replacing the PlayStation Doom executable with one that runs natively on modern systems. As of 0.4.0 you no longer need any BIOS, or original .EXE file to play the game - just a 'Doom.cue' file for the original game disc is all that is needed. With that being said, here is the full changelist for this version. There are many updates as you can see and I'm starting to expand/enhance the game beyond it's original limitations, including keyboard + mouse controls and uncapped FPS: PsyDoom no longer needs the original PSXDOOM.EXE to run and is now a standalone replacement for the original PlayStation binary. All that is needed to run the game is a valid .cue file (named Doom.cue) for the original game disc. Added fullscreen support and made it the default video mode. Implemented fully uncapped framerates, allowing the game to run at 60 Hz, 120 Hz, 144 Hz etc. When the framerate is uncapped, player movement and turning is smoothed for frames in-between the original 30 Hz (NTSC) ticks. Enemies and environment objects are not yet smoothed however and still run at 30 Hz, that may be added in future releases. Verified that the game can work with any edition of the original PlayStation Doom: NTSC-U, PAL etc. Note: PAL demos do not play back correctly however. The PAL version works correctly other than that. Added analog movement support for gamepads. Added mouse controls. Adjustments to player movement to help reduce input lag: Apply thrust AFTER getting inputs, not before. Tweak is not applied for original demo playback for reasons of compatibility. Allow turning to take place at any time (framerate independent) and outside of the normal game loop, which is capped at 15/30 FPS for certain logic. Helps make turning feel more responsive. Added a configuration file system (similar to Phoenix Doom) for configuring the game. The list of available options/settings will be expanded in coming releases. Main menu : added a 'quit' option (required for users in fullscreen). Networking: send the next planned move 1 tick ahead of time to try and workaround latency. Networking: try to fix/adjust game clocks for peers who are falling behind in the simulation. Should help keep both players ticking at the same rate, assuming latency is low. Keyboard: allow direct weapon switching with the number keys. Noclip cheat now has a proper message. Floor rendering : added a precision fix (configurable) for cracks in the floor in some of the larger, more outdoor maps. Cheat warp menu : allow wraparound to the other end of the map list for convenience Incoporate a change from Final Doom to change the default SFX level to 85. Makes music more audible by default. Windows : don't show a console window for release builds. Removed the temporary '-highfps' hack: now have a proper uncapped framerate mode. Here is a video of the game in action with uncapped FPS and mouse controls. Apologies for the volume levels, I forget to normalize before I uploaded (oops): Hope you enjoy!
  11. intacowetrust

    PsyDoom 0.4.0 - PSX Doom port (reverse engineered) for PC

    At the very least I want the game to remember the last password on disk and restore it next time you boot up, along with other settings like sound + music volume. That should solve most of the issue very easily. Now, if I go ahead and implement rollback networking then I more or less get a save function for free too - since that would require being able to save and restore the entire map state at any given point in time. Such capabilities would also allow a 'rewind' style feature (like the 'World Tour' edition of Duke3D) in theory too. So it kinda depends on what happens with networking. TBD :)
  12. intacowetrust

    PsyDoom 0.4.0 - PSX Doom port (reverse engineered) for PC

    Yeah that's a good fix to have. It would still be possible (in theory) however to get the blockmap issue if you (or something else) somehow made its way outside of the level bounds - it wouldn't address the root cause in other words. The ultimate root cause fix is to simply do what the PC version (and 3DO version) do and add bounds checking for blockmap operations. Concerning the Wiki link, I found the following quote interesting in relation to 3DO Doom: I recall when working on Phoenix Doom making the following division by zero fix in the renderer, which happened sometimes when I got super close to walls or was no-clipping through them: https://github.com/BodbDearg/phoenix_doom/commit/baddc11e9e587afccceca6c10f0cc7f6d594e84a Might be the issue the Wiki is talking about, not sure... I'm pretty much doing the same thing as the PC version, just checking the bounds for blockmap operations. Here's one example of where the problem was fixed for comparison: https://github.com/id-Software/DOOM/blob/master/linuxdoom-1.10/p_maputl.c#L379 https://github.com/BodbDearg/PsyDoom/blob/a33e7d6ea40464f4a069baf08c2ef52f484ef051/game/Doom/Game/p_maputl.cpp#L165
  13. intacowetrust

    Help PLEASE!, LZDOOM v3.85 is not working (Mac OS X Catalina)

    Tested it on my MacBook Pro and it seems to be working fine. It's a little tricky to setup because you have to navigate to the '~/Library/Application Support' directory, which is normally hidden in Finder. To get it working, open the 'Terminal' app and input the following commands to make the required 'lzdoom' folder, and then open it in finder: mkdir ~/Library/Application\ Support/lzdoom open ~/Library/Application\ Support/lzdoom Copy any IWADS (DOOM2.WAD etc.) into the folder now showing in the open Finder window and LZDoom should be able to detect them. Also, if you want to show the 'Library' folder permanently and be able to click into it (along with other hidden folders on MacOS) you can enter the terminal commands shown in this guide: https://setapp.com/how-to/show-hidden-files-on-mac#:~:text=See hidden files on Mac via Finder&text=In Finder%2C open up your,2 to hide them again! Hope that helps.
  14. intacowetrust

    PsyDoom 0.4.0 - PSX Doom port (reverse engineered) for PC

    Good callout!
  15. intacowetrust

    PsyDoom 0.4.0 - PSX Doom port (reverse engineered) for PC

    Looks like the bug (or feature, depending on your POV) is caused by some new logic that was added for Doom II to 'PIT_CheckThing' which was not carried over to the PlayStation's Jaguar/Doom-1 derived codebase. It probably got missed because it wasn't in one of the new Doom 2 functions and wasn't causing very obvious problems in most cases. The logic just adds a special case for Baron and Hell Knight missiles and treats missile hits between the two species as if they were the same species - causing the missile to explode but no damage being applied. I'd wager this was probably an oversight for regular PSX Doom given the rarity of these two enemies being in close proximity at the same time. For D64 however it does sound like they deliberately decided to keep this difference and thought it more confusing if Barons and Hell Knights were treated as the same types of enemy. Only the original team would know for sure however...
×