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

Crispy Doom 6.0 (Update: Mar 31, 2023)

Recommended Posts

19 hours ago, Looper said:

Ohhh!! I fixed it! It was based on the amount of demos in the folder! The moment when the demo amount exceeded 64 files, it went inconsistent.

 

At first I thought you were joking, but then realized that it might take a significant non-zero amount of time (especially on Windows) to check for the existance of all the demos with the previous file name suffices. My first instinct was to change the way that file existance is checked [1], but this would have merely shifted the problem away to higher suffix numbers. Instead, I added a static file name suffix counter that starts to check from the next demo name in order [2]. This should mitigate your issue except for the very first run if you pass a file name that already has many suffixed demos.

 

[1] https://stackoverflow.com/questions/12774207/fastest-way-to-check-if-a-file-exist-using-standard-c-c11-c

[2] https://github.com/fabiangreffrath/crispy-doom/commit/ac3bde2d91885ff4778063fc5fadf83fc0c5a43b

 

Also, the "Reload Level" key has been changed to restart demos from the map they were started.

Share this post


Link to post

I have a quick question regarding Heretic, Hexen, and Strife. Do you ever plan on releasing official Crispy versions of all these games, or are those projects dead/abandoned?

Share this post


Link to post

No, I don't have plans to do Crispy Heretic/Hexen/Strife releases myself. I keep the code intact and the binaries compile if you build them, and I even occasionally post them here, but this won't be on a regular basis. There is even an item in the bug tracker to keep track of Crispy Heretic development, but it seems I am a bit picky when it comes to code contributions. :-/

 

https://github.com/fabiangreffrath/crispy-doom/issues/240

 

Share this post


Link to post
9 hours ago, fabian said:

but it seems I am a bit picky when it comes to code contributions. :-/

If someone says they can copy and paste code but not really understand it, then I wouldn't be comfortable accepting their changes either.

Share this post


Link to post
4 hours ago, andrewj said:

If someone says they can copy and paste code but not really understand it

ah, 'cmon. i wrote half of the new code for k8vavoom using this technique -- including stea... using your AJBSP almost intact. ;-)

Share this post


Link to post

Hi! I'm experiencing the same bug Hekksy had a few months ago. I wasn't using speakers either. The music works fine, but the sounds aren't playing right. Some people suggested "change the crispy-config file" which also started a debate in the Choc doom discord server. Is there a bugfix? Because I've tried downloading the daily build, I've turned off pitch shifting, and I even turned on MIDI.
Processor    Intel(R) Core(TM) i5-9400F CPU @ 2.90GHz, 2904 Mhz, 6 Core(s), 6 Logical Processor(s)
GPU: NVIDIA GeForce GTX 1650

This is a demonstration video.


Any fixes?

Edited by Vaguester : I missed a few things.

Share this post


Link to post

Seems like if you start in map01, for example and then you finish the level. You hit the reset button during the intermission screen, and then you leave the intermission screen by using fire/use buttons. You move into map02. Now if you reset in map02, it will throw you into map01 BUT the demofile thinks it is map02. Only that one attempt is affected during the process with wrong map number. All other demos will be just fine.

 

Edit: Seems like it happens after you finish the map, doesn't matter if you hit the reset button during intermission or not.

Share this post


Link to post

Requesting a feature that can be enabled or disabled from a key even during a gameplay:

Everytime the use key is pressed, it prints the time that it was pressed on. So if you hold use key between the frames 74-80, it would only print the time from the 74th frame. Useful, for example in Doom 1 E1M1, when running for the first door and every frame counts. You want to know if you opened the very first door (meaning hit the use key) on the 71st, 72nd, 73rd or 74th frame. The time would be printed for like a second or two, maybe adjustable from the setup, in the center of the screen, somewhere where it is very eays to see.

 

As far as I know, this is not a TAS feature, since you can achieve the same by using the Advanced HUD (introduced in prboom+), and binding "screenshot" and "use" key on the same button, and then just read the exact time from the screenshot.

 

Edit for one tiny thing: once you reset a demo from the reset level/demo button, it doesn't reset the timer even though it should, imo.

Edited by Looper

Share this post


Link to post
On 1/2/2020 at 3:04 PM, Looper said:

Seems like if you start in map01, for example and then you finish the level. You hit the reset button during the intermission screen, and then you leave the intermission screen by using fire/use buttons. You move into map02. Now if you reset in map02, it will throw you into map01 BUT the demofile thinks it is map02. Only that one attempt is affected during the process with wrong map number. All other demos will be just fine.

 

Thanks! I think I just fixed that in GIT, would be appreciated if you could confirm this with a new daily build.

On 1/3/2020 at 2:30 PM, Looper said:

Edit for one tiny thing: once you reset a demo from the reset level/demo button, it doesn't reset the timer even though it should, imo.

 

This one as well, thanks for reporting!

Share this post


Link to post
On 1/3/2020 at 2:30 PM, Looper said:

Requesting a feature that can be enabled or disabled from a key even during a gameplay:

Everytime the use key is pressed, it prints the time that it was pressed on. So if you hold use key between the frames 74-80, it would only print the time from the 74th frame. Useful, for example in Doom 1 E1M1, when running for the first door and every frame counts. You want to know if you opened the very first door (meaning hit the use key) on the 71st, 72nd, 73rd or 74th frame. The time would be printed for like a second or two, maybe adjustable from the setup, in the center of the screen, somewhere where it is very eays to see.

 

Alright, now let's talk about this one. Do you want the game tic to be printed each time you hit the "use" key, or each time you hit the "use" key and it actually opens a door? Only the first time or for each door during the whole run? Gametic or leveltime? Only untagged doors or also tagged doors and switches? Would it be sufficient to display a usual player message or does it need to be centered like e.g. the "secret revealed" message?

Share this post


Link to post

Something like a secret revealed message (without the sound, of course). And it should print it every time the use key is hit (and toggled off/on from some other key if the message gets a bit distracting when spamming the use key.) It would show the current level's level time in tics (for example: 1.34 would be 1 second and 34 frames (= 1.97 seconds)), so identical to the CrispyDoom's in-game timer that is shown during demorecording on top right corner. So the counter should reset when going from map01 to map02.

 

The current in-game timer actually shows the total time of the demo, instead of the current level. That means if you wait a lot of time during intermission, it will be added for example to the map02 time when going for a full movie. At the end of Map02 it shows the time correct for Map02, but then once Map03 being, it adds all the map01+map02+time spent in both intermission screens, which is a slight oversight, I think. It should reset every time the map changes. So it is a bit similar thing to the one you just edited/fixed for the reset level/demo button.

 

Thanks! Easily the best sourceport for speedrunning. Great job, that's all I can say!

Share this post


Link to post
On 1/5/2020 at 6:15 PM, fabian said:

Thanks! I think I just fixed that in GIT, would be appreciated if you could confirm this with a new daily build.

 

On 1/5/2020 at 6:15 PM, fabian said:

This one as well, thanks for reporting!

 

Both fixes are working. Thanks!

Share this post


Link to post

I would like to know if Crispy Doom uses OpenGL. I know that it uses OpenGL for display scaling, but does it use OpenGL for anything else? Also what does it use to render all the other stuff - is it Software, just like in Chocolate Doom or also OpenGL?

Share this post


Link to post
25 minutes ago, xzotikk said:

I would like to know if Crispy Doom uses OpenGL. I know that it uses OpenGL for display scaling, but does it use OpenGL for anything else? Also what does it use to render all the other stuff - is it Software, just like in Chocolate Doom or also OpenGL?

 

Just like Choco, it uses Vanilla Doom's original software renderer to create the game scene and OpenGL (or Direct3D or whatever SDL sees fit) for scaling the framebuffer to screen. 

Share this post


Link to post
45 minutes ago, fabian said:

 

Just like Choco, it uses Vanilla Doom's original software renderer to create the game scene and OpenGL (or Direct3D or whatever SDL sees fit) for scaling the framebuffer to screen. 

And do you think that OpenGL 2.0 would be enough for the OpenGL scaling without damaging my PC? Also are there any official minimum system requirements for Crispy Doom?

Share this post


Link to post

Why don't you just try it out with full boldness and bravity? With near-certain confidence I consider it unlikely that starting Crispy Doom will ever damage your computer. I guess that texture scaling was already part of the first OpenGL spec drafts, so by theory OpenGL 2.0 should be enough to achieve that. And even if you graphics hardware is not capable to do that, there is still the "force_software_renderer" option which, if you use a development snapshot, is even enabled automatically if the video initialization code recognizes it will be necessary. Just go for it, you can make it!

Share this post


Link to post
On 1/6/2020 at 9:43 PM, Looper said:

The current in-game timer actually shows the total time of the demo, instead of the current level.

 

Are you talking about the timer in the top left corner that can be switched Off/In Automap/Always? This is supposed to show the length of the whole Doom session, i.e. the "how long am I already playing" time. If you want precise time per map, you are supposed to use the distinct demo timer during recording.

Share this post


Link to post

Yeah, that one is working perfectly as it is showing the total time perfectly, but there's another timer:

 

On the left of the three pictures, there is Doom2 Map01. I'm about to hit the exit switch. Timer on top right is shown correct.

The timer is correct during the intermission screen too, as it shows the Map01's exact time in seconds and frames. So that is in the center picture.

On the very right picture, one can see that the time is incorrect. I have not been 11 seconds in Map02 because I just started the map. The timer here shows the time from Map01+ time spent during intermission screen in frames + the brief amount of time spent in Map02. I think it should only show Map02's exact time.

crispy_timer.png

Share this post


Link to post
3 hours ago, fabian said:

Why don't you just try it out with full boldness and bravity? With near-certain confidence I consider it unlikely that starting Crispy Doom will ever damage your computer. I guess that texture scaling was already part of the first OpenGL spec drafts, so by theory OpenGL 2.0 should be enough to achieve that. And even if you graphics hardware is not capable to do that, there is still the "force_software_renderer" option which, if you use a development snapshot, is even enabled automatically if the video initialization code recognizes it will be necessary. Just go for it, you can make it!

Well, I was worried that it could stress my PC if I'd have it running for a long time. But since you said that GL 2.0 should be enough, I think that I'm good.

And I'd also like to know if there are any official minimum system requirements for Crispy Doom, so are there any?

Share this post


Link to post
8 minutes ago, fabian said:

No formal system requirements, but let's say it's targeted at lower end systems. 

And for the rendering part, scene rendering is texture, monster and item rendering, right? I'm not quite sure what does it mean.

 

Oh, and formal means 'official'? I'm not a native English speaker, so I'm not sure.

Share this post


Link to post
5 hours ago, xzotikk said:

Oh, and formal means 'official'? I'm not a native English speaker, so I'm not sure.

We don't have any teams testing the software on a variety of hardware to make any reasonable requirement lists, but even then, there isn't a whole lot that Crispy Doom does that demands more computational power than vanilla Doom. You'd be fine on an original Pentium from 1993 and a few megabytes of RAM.

Share this post


Link to post
5 hours ago, xzotikk said:

And for the rendering part, scene rendering is texture, monster and item rendering, right? I'm not quite sure what does it mean.

 

The game scene (walls, items, hud elements, etc.) is rendered on a 320x200 canvas with Doom's software renderer. This canvas is then turned into an OpenGL-texture which is then scaled to your screen's native resolution.

 

5 hours ago, xzotikk said:

Oh, and formal means 'official'? I'm not a native English speaker, so I'm not sure.

 

I am not a native English speaker, neither. Anyway, could we please refrain from turning words upside down and you just go on and try out the game?

Share this post


Link to post
19 hours ago, Looper said:

The timer here shows the time from Map01+ time spent during intermission screen in frames + the brief amount of time spent in Map02. I think it should only show Map02's exact time.

 

Ah, now I see what you mean! You are correct, during recording the demo timer widget shows the accumulated number of recorded tics. I have changed it so that it now shows the leveltime. Thank you again for your input! Is there anything else?

Share this post


Link to post

 I don't think a Pentium will cut it for Crispy, it uses SDL2 and requires at least XP. XP itself requires 128 MB being realistic and then SDL2 will be more demanding. So i'd say at least a Pentium II with 128 MB.

 RUDE for now has lower requirements (it's still on SDL1) and should run on 98 so a Pentium with 32 MB could cut it in theory, but i haven't actually tried.

Share this post


Link to post

Well, I came to the conclusion that trying to run these ports will probably not make my PC explode. Therefore I decided not to worry about the system requirements too much. 

 

PS: I hope I didn't annoy you too much with my questions.

Share this post


Link to post
7 hours ago, drfrag said:

I don't think a Pentium will cut it for Crispy, it uses SDL2 and requires at least XP.

In Windows land perhaps. I bet you could get a modern Linux distro running on a lot less :)

Share this post


Link to post

I have a feature request and bug to report. If these should be submitted to GitHub instead of posting here, please let me know.

 

Feature Request: Would it be possible to implement the ability to toggle between fullscreen and windowed mode while in-game? (If this feature already exists, I have been unable to find it in the documentation or through experimentation.)

 

Bug: Gameplay will sometimes halt on mouse down, but resume where it left off on mouse up or mouse move.1 The music continues to play, but otherwise the game state does not advance. (If this occurs while recording a demo, for example, playback of the demo shows no sign of interruption.) I have not noticed any particular conditions needed to produce this bug (other than maybe when my computer is working harder?).

 

MacBook Pro (15-inch, Mid 2009) / Mac OS X 10.11.6 (El Capitan) / Crispy Doom 5.6.3 (built myself using chocpkg, implementing changes proposed by a-hurst on GitHub, and with slightly modified SDL2 code in order to get it to compile on El Capitan2).

 

Spoiler

 

1 I attempted to reproduce the bug in Chocolate Doom without success (but also without extensive testing).

 

2 I did not save the logs, but attempting to compile SDL2 on OS X 10.11.6 eventually throws an error about a missing NSEvent-something-about-trackpads, which the Apple Developer pages informed me was added in OS X 10.12. The code was looking for a boolean, so I just replaced the whole thing with FALSE. As a result (?) Crispy Doom and its Setup think I am constantly clicking if I so much as touch my trackpad, but this is not a problem because everything works fine with an external mouse. (Chocolate Doom, which I was able to download pre-compiled, has no such problem with the trackpad.) I do not believe this has anything to do with my issue, but I felt I should mention it for full disclosure (or in case I am wrong).

 

 

Thanks for your time, and for creating / maintaining Crispy Doom; it is my favorite source port.

Share this post


Link to post

One other thing: At some point I noticed that a blue square would sometimes quickly flash (for a single frame?) in the bottom right corner of the screen. Initially I assumed this was another bug – some sort of visual artifact – but I recorded my screen and discovered the blue square was actually a diskette. A quick Google search suggests that this is intentional and shows loading or disk activity – is that correct?

 

In any case, I do find it a bit distracting. :/

 

Screenshot of Final Doom's TNT: Evilution running in Crispy Doom with a small blue diskette in the bottom right corner of the image.

Share this post


Link to post

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×