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

[Dark Pulse]

9 hours ago, intacowetrust said:

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

Must've missed it then. I'll see you Tuesday for my confession.

 

In the meanwhile, don't forget to play a videogame, Taco-man.

[fenderc01]

@intacowetrust Do you have any plans to implement a save function?

[intacowetrust]

17 hours ago, fenderc01 said:

@intacowetrust Do you have any plans to implement a save function?

 

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 :)

[intacowetrust]

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!

[seed]

Only "hope" we enjoy? Of course we do, naturally, this is getting only better and better :3.

[Gez]

48 minutes ago, intacowetrust said:

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.

PAL has a refresh rate of 25 Hz (trading a slower refresh rate for improved color fidelity and higher vertical resolution, compared to NTSC), so could it be that the PAL version had 25 tics per second instead of 30?

[Vic Vos]

56 minutes ago, intacowetrust said:

Implemented fully uncapped framerates, allowing the game to run at 60 Hz, 120 Hz, 144 Hz etc.

56 minutes ago, intacowetrust said:

Added mouse controls.

56 minutes ago, intacowetrust said:

Added a configuration file system (similar to Phoenix Doom) for configuring the game.

 

oh this gon b gud

^{inb4 i get another warn}

 

Saving and Final Doom support is all I need now.

[Dark Pulse]

Tacoman delivers yet again, and it's finally getting to the point where I'll be more than happy to check it out. :)

 

Hopefully that Final Doom support comes soon, as Erick has said that pretty much with Final Doom reversed, he's given me the green light to do E1M8B to Final Doom specs. Meaning I'll be cutting a LOT less lines out of the map... but yeah, will need support for that version of the engine to play it, as well as some things like his texture height tiling/stretching fix. :)

 

EDIT: Update your OP! It hard-links to 0.30. Link it to https://github.com/BodbDearg/PsyDoom/releases instead of a specific release. This way you don't have to update the actual link and can just update the number... like you TRIED to do, but failed due to the link to a specific version :)

Edited June 26, 2020 by Dark Pulse

[intacowetrust]

7 hours ago, Gez said:

PAL has a refresh rate of 25 Hz (trading a slower refresh rate for improved color fidelity and higher vertical resolution, compared to NTSC), so could it be that the PAL version had 25 tics per second instead of 30?

 

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.

 

6 hours ago, Dark Pulse said:

EDIT: Update your OP! It hard-links to 0.30. Link it to https://github.com/BodbDearg/PsyDoom/releases instead of a specific release. This way you don't have to update the actual link and can just update the number... like you TRIED to do, but failed due to the link to a specific version :)

 

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

[Impboy4]

@intacowetrust I noticed the music is bugged when it tries to pitch bend in the video.  Maybe you can look into that for the next release?

[Dark Pulse]

Gave it a quick playthrough and noticed the music was quite poppy and stuttery, and CD-DA audio didn't play at all.

 

Also, definitely would be a good time to get key binding in :)

[Uroboros87]

Nice. I'm always looking forward to seeing updates on this. I can't wait to try it out after work!

[intacowetrust]

1 hour ago, Impboy4 said:

@intacowetrust I noticed the music is bugged when it tries to pitch bend in the video.  Maybe you can look into that for the next release?

 

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?

 

1 hour ago, Dark Pulse said:

Gave it a quick playthrough and noticed the music was quite poppy and stuttery

 

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.

 

2 hours ago, Dark Pulse said:

CD-DA audio didn't play at all.

 

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.

 

2 hours ago, Dark Pulse said:

Also, definitely would be a good time to get key binding in :)

 

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 :)

[Lollie]

It is so good to finally have a version of PlayStation Doom with mouse support, and that unlocked framerate is butter-smooth. And no more PSXDOOM.EXE dependency! Nice work! I personally haven't experienced any audio issues with this release, but my system is relatively higher-mid range, and I am using a single-bin+cue.

 

The documentation in the .ini config files so far is really nice and detailed, but it is admittedly funny to see settings split up into multiple files when there's currently only one or two settings in each file. How granular do you expect these settings to be when the config files are fully fleshed-out? (And how much of it will be configurable in-game?)

[Dark Pulse]

12 hours ago, intacowetrust said:

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.

CPU is pretty old (Core i7-2600K) at 60 Hz but that should still be more than powerful enough to run this just fine (and indeed, it's not like the framerate was awful at all). However, it's definitely older than yours. (Hopefully won't be the case for too much longer - I do plan to upgrade this system to something much more modern. Would've done it a few years ago were it not for some incredible stupidity that threw me heavily into debt about two years ago, but that's another tale for another time.)

 

Maybe have a user-configurable sound buffer, as it's definitely better to have it be something that could be adjusted as opposed to a hardcoded value. The closer this gets to being more suited for the public, the more you want flexibility and less hardcoded stuff after all. :)

 

12 hours ago, intacowetrust said:

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.

That's definitely me - my ISO is ripped into individual tracks.

 

What you might want to consider doing as a potential stretch thing is to have it so that a user could theoretically have a music file override as part of the map? I mean realistically, with PSX Doom reversed, GEC having a decent level design toolchain, and so on, there's going to wind up being a small subset of folks who actually develop levels FOR PSX Doom.

 

Right now one major thing we lack is really a MIDI Editor and soundfont to be able to make custom music tracks. There's plenty of MIDI editors though, and I vaguely recall having a soundfont, but being able to turn them into custom songs is still missing. I'd love to try my hand at this personally, just give me a soundfont and a MIDI editor, and some way to put it back into the game. But that's obviously a job more for Erick, not for you.

 

You're just more a case of where a user could potentially somehow define a way to play external music files. Perhaps something like "Looks for internal soundfiles and plays those if found, if none found look for external sound files of same name, if none found music is silent" or something. As long as it supports seamless looping via metadata, really any decent audio format (Ogg, FLAC, Opus) will work well.

 

12 hours ago, intacowetrust said:

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 :)

Please do! Most of the mapping work I did for the GEC project is actually Final Doom levels (TNT's Hanger, TNT's Open Season, Plutonia's Neurosphere, Master Levels' Bloodsea Keep - also a solid level to test that floor fix on). I'd love to see you suffer and die to them again and again and again more feedback on those levels, as I feel like I did some really good work on them, and nobody's really put videos of them up on Youtube. (Indeed, most of the playthroughs I find when looking for GEC Master Edition are for the PC version of Master Edition/the eventual DZDoom - annoying!)

 

Also because with Erick now saying some more limits are going to be relaxed, with maps being converted to the Final Doom version of the engine and some other fixes like the aforementioned vertical texture tiling/stretching fix effectively relaxing the height limit, I am definitely going to go back and look into stuff like restoring heights if it doesn't tank framerate too much on the actual PSX version. (Obviously yours will run it flawlessly in terms of framerate.)

[intacowetrust]

On 6/26/2020 at 11:01 PM, Lollie said:

The documentation in the .ini config files so far is really nice and detailed, but it is admittedly funny to see settings split up into multiple files when there's currently only one or two settings in each file. How granular do you expect these settings to be when the config files are fully fleshed-out? (And how much of it will be configurable in-game?)

 

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.

 

On 6/27/2020 at 3:10 AM, Dark Pulse said:

CPU is pretty old (Core i7-2600K) at 60 Hz but that should still be more than powerful enough to run this just fine

 

Yeah I used to have this CPU also, it's still pretty decent and probably faster overall than the MBP I tested with.

 

On 6/27/2020 at 3:10 AM, Dark Pulse said:

The closer this gets to being more suited for the public, the more you want flexibility and less hardcoded stuff after all. :)

 

Yep, absolutely. It'll get there eventually - not to worry...

 

On 6/27/2020 at 3:10 AM, Dark Pulse said:

What you might want to consider doing as a potential stretch thing is to have it so that a user could theoretically have a music file override as part of the map? I mean realistically, with PSX Doom reversed, GEC having a decent level design toolchain, and so on, there's going to wind up being a small subset of folks who actually develop levels FOR PSX Doom.

 

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.

 

On 6/27/2020 at 3:10 AM, Dark Pulse said:

But that's obviously a job more for Erick, not for you.

 

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.

[Dark Pulse]

8 hours ago, intacowetrust said:

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.

I know I've done some chats with him on it, but ideally, the goal is to be able to make music tracks that could (at least in theory) be burned back onto a customized ISO and played on the real hardware too if it comes down to it.

 

So stuff like needing to manage the PS1's SPU RAM (512KB) also becomes important, since of course, you need enough room for both all the game SFX/Monster sounds/etc. as well as the samples needed for the music track.

[Devalaous]

the video with the speedy framerate, those projectiles still look pretty choppy. Hard to believe thats what it was always like (I grew up on the PS1 version and migrated to PC later)

[Dark Pulse]

37 minutes ago, Devalaous said:

the video with the speedy framerate, those projectiles still look pretty choppy. Hard to believe thats what it was always like (I grew up on the PS1 version and migrated to PC later)

He did say logic stuff is still rolling at 15 Hz and isn't interpolated yet, so I'd imagine that's on the list of things to fix. :P

[fenderc01]

1 hour ago, Dark Pulse said:

He did say logic stuff is still rolling at 15 Hz and isn't interpolated yet, so I'd imagine that's on the list of things to fix. :P

 

It's in his to-do list:

Quote

- Investigate interpolation for sprites and sectors in addition to player view.

https://github.com/BodbDearg/PsyDoom/blob/master/docs/todolist.txt

 

 

@intacowetrust I noticed when switching with the number keys, if you try to switch too fast, you can't immediately go back to the weapon you were just on. You also can't switch back when the game is paused.

[intacowetrust]

2 hours ago, fenderc01 said:

4 hours ago, Dark Pulse said:

He did say logic stuff is still rolling at 15 Hz and isn't interpolated yet, so I'd imagine that's on the list of things to fix. :P

 

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.

 

4 hours ago, Dark Pulse said:

So stuff like needing to manage the PS1's SPU RAM (512KB) also becomes important, since of course, you need enough room for both all the game SFX/Monster sounds/etc. as well as the samples needed for the music track.

 

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.

 

2 hours ago, fenderc01 said:

@intacowetrust I noticed when switching with the number keys, if you try to switch too fast, you can't immediately go back to the weapon you were just on. You also can't switch back when the game is paused.

 

Thanks for reporting, I will investigate.

[Dark Pulse]

14 minutes ago, intacowetrust said:

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.

Definitely will need to make sure that there's some warnings in whatever fork of a level editor is used in order to do this then.

 

Either that or rewrite WESS so it uses less SPU RAM somehow, but I'd imagine most of the use is on sounds rather than the engine/sequence data.

[intacowetrust]

On 6/30/2020 at 10:27 AM, Dark Pulse said:

Either that or rewrite WESS so it uses less SPU RAM somehow, but I'd imagine most of the use is on sounds rather than the engine/sequence data.

 

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.

[Dark Pulse]

5 hours ago, intacowetrust said:

 

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.

Huh. So even Final Doom's music can be made more richly complex than the original's. That's something.

 

What irks me is that there's at least two music tracks (Vexation and Demon Drone) that, for some reason, don't loop. I know I used one of them (Demon Drone) on one of my maps (TNT MAP06: Open Season). I need to remind Erick about setting up a loop for that somehow, because otherwise, you won't have any music after about six minutes. :P

 

Though MAYBE that's a bug? I don't know, feels really weird there's two tracks that just... don't loop. Maybe you could shine some light on it, O Taco God?

[Erick194]

2 hours ago, Dark Pulse said:

Though MAYBE that's a bug? I don't know, feels really weird there's two tracks that just... don't loop. Maybe you could shine some light on it, O Taco God?

I have repeated it several times, it is not a mistake, they should not be repeated, like the music of level 7 in Doom64

[Lollie]

Out of curiosity, because I couldn't find an older explanation about these songs... (I tried searching the PSX Doom Master Edition thread but couldn't find answers, sorry!)

 

Do these two songs lack a "loop" command at the end, and this is why they shouldn't loop? (Of course, this would mean that every other song has a "loop" command. If none of the songs have this sort of command, then this is obviously not the answer.)

 

Or, is there something in the music-player code that says certain songs should not loop? (A programmer would need to add this rule, so this would be obviously intentional and not a mistake.)

[intacowetrust]

3 hours ago, Lollie said:

Do these two songs lack a "loop" command at the end, and this is why they shouldn't loop? (Of course, this would mean that every other song has a "loop" command. If none of the songs have this sort of command, then this is obviously not the answer.)

 

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!

 

[seed]

Hm, yes, one of my favorite PSX Master Levels I see.

 

"Damn, I'm looking good." - PsyDoom probably.

[Dark Pulse]

3 hours ago, intacowetrust said:

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.

This is kind of my point behind it all really. It feels like something that just... shouldn't be right. Like they SHOULD loop. To have every other track in the game at least loop end-to-end but not those ones feels like some strange oversight.

 

But well, that's kind of what I'm relying on you guys to find out. All I know is that it kind of sucks for me if that track doesn't loop - I had it *ON* loop while I was making the level (something I do for all the levels I make, actually), and so now I can't picture the level without it. At the same time, while many people won't take more than six minutes or so to finish it, for the ones that do, they're just greeted with silence, and that just feels wrong.

[Redneckerz]

1 hour ago, Dark Pulse said:

This is kind of my point behind it all really. It feels like something that just... shouldn't be right. Like they SHOULD loop. To have every other track in the game at least loop end-to-end but not those ones feels like some strange oversight.

 

But well, that's kind of what I'm relying on you guys to find out. All I know is that it kind of sucks for me if that track doesn't loop - I had it *ON* loop while I was making the level (something I do for all the levels I make, actually), and so now I can't picture the level without it. At the same time, while many people won't take more than six minutes or so to finish it, for the ones that do, they're just greeted with silence, and that just feels wrong.

Doom equivalent of Blonde person here, but if a track does not loop like it should, could it be that there is an issue with the audio buffer that is either not working correctly in its native implementation, or still relies on emulated calls?

 

Just a pie in the sky comment, but whenever i hear about tracks that do not loop, i associate that with the audio buffer (especially on PSX).

 

If this is nothing, then i am a blonde, just so we are clear :)