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

Doom floppy disk icon. Doom nostalgia thread.

Recommended Posts

Does anyone else remember this flashing on the screen during play on your 486sx33 with 4 MiB of RAM? I remember it clearly. The disk access icon is not seen anymore with computers having quad-core CPU chips, multi gigabytes of RAM and 7200RPM SATA2 drives, but this is a very nostalgic memory I have of DOOM. And the fear you felt when walking down the hallway to the lift in E1M8.

http://www.youtube.com/watch?v=A163LjAYpmQ

Share this post


Link to post

Eternity still shows the flashing disk icon ;) And yeah, it was flashing especially ominously when the Cyberdemon was hearing me in E2M8 (I didn't have ANY sound back then).

Share this post


Link to post

Chocolate Doom supports the disk icon under some very limited circumstances. Unfortunately it's a feature that's actually quite difficult to do on modern hardware.

Share this post


Link to post
fraggle said:

Chocolate Doom supports the disk icon under some very limited circumstances. Unfortunately it's a feature that's actually quite difficult to do on modern hardware.

Yeah. On some systems, Macs in particular, EE's flashing disk slows the system down to a crawl for some reason. The OpenGL backend doesn't support it all, as it would screw with the page flipping and PBO asynchronous updates.

Share this post


Link to post
fraggle said:

Unfortunately it's a feature that's actually quite difficult to do on modern hardware.


*looks at CDoom's code* Hmm...doesn't look that hard. It's practically a patch drawn on the screen whenever the W_ReadLump function is called (then another I_Readsomething function is called). Any port re-enabling it must implement this feature from scratch, as it's not documented anywhere in the linuxdoom code.

Now, I admit that CDoom's implementation is awkward and kludgy, yeah, but not as difficult as you make it sound.

Share this post


Link to post

Well, the flashing disk would require a possible total screen refresh (if your current interface can't update certain rectangles) which would slow things down considerably.

Share this post


Link to post
GhostlyDeath said:

Well, the flashing disk would require a possible total screen refresh (if your current interface can't update certain rectangles) which would slow things down considerably.


CDoom does this by keeping a sort of "flashing floppy timer" which is simply drawn at the end of each frame in the main loop, just like e.g. menus or other widgets. In terms of rendering hierarchy, it comes even after menus.

The timer has a value of 8 tics: if non-zero, a single floppy frame is rendered on top of everything else (uses patch_t rendering code just like menus) and the timer is decreased by one tic. If it's zero, nothing is drawn. A call to any of the W_CacheLumpXXX functions, if it results in an uncached call and thus a call to W_ReadLump, actually sets this timer to 8.

Share this post


Link to post
Maes said:

CDoom

Um, CDoom is a DOS port. That's why I said "on modern hardware". It's easy under DOS where you have direct access to the screen hardware :)

Main problem is that on some systems, screen updates are done using a page-flip style mechanism, which means you can only update the entire screen at a time. Given that the disk popup potentially happens while the screen is updating, it's not really going to work.

I guess one nostalgia-restoring way to get it to "work" might be to apply the disk at the end of a frame if I_BeginRead() has been called since the last frame was drawn. That might then produce a similar effect, but it won't really be working the same as the original.

Share this post


Link to post
fraggle said:

I guess one nostalgia-restoring way to get it to "work" might be to apply the disk at the end of a frame if I_BeginRead() has been called since the last frame was drawn. That might then produce a similar effect, but it won't really be working the same as the original.


That's exactly what CDoom does. However it does so in an ugly way, by sticking the call to V_DrawPatch in I_BeginRead, rather than at the end of D_Display. There's no "direct" access to video memory after the image buffer is "finalized", if that's what you meant.

As for "access to video hardware"...all software rendered ports I know of use a byte* array which is written directly to by column functions, drawpatch operations etc., regardless of what the video hardware will ultimately use (e.g. ARGB, HiColor etc.). That's just one step below actual hardware, and entirely sufficient to draw one extra patch per frame, I think ;-)

Are there any clues indicating that doom.exe did this in a more convoluted way and during buffer-to-VGA planar screen writes, rather than during normal in-memory patch drawing?

Share this post


Link to post
fraggle said:

I guess one nostalgia-restoring way to get it to "work" might be to apply the disk at the end of a frame if I_BeginRead() has been called since the last frame was drawn. That might then produce a similar effect, but it won't really be working the same as the original.


I, for one, would more than happily take the alternative version over nothing at all.

Any chance for this ever happening for Chocolate Doom? the flashing floppy disk icon is one of the many little details in the game that add to it's character, and to me Doom will never look "complete" without it.

Share this post


Link to post
Maes said:

As for "access to video hardware"...all software rendered ports I know of use a byte* array which is written directly to by column functions, drawpatch operations etc., regardless of what the video hardware will ultimately use (e.g. ARGB, HiColor etc.). That's just one step below actual hardware, and entirely sufficient to draw one extra patch per frame, I think ;-)

Yeah, but that isn't a direct pointer into VGA video RAM, though - under DOS, you can get a direct pointer and modify the video buffer directly. Under modern systems there's typically an extra level of indirection - SDL for example just gives you a pointer to a buffer that only gets pushed to the screen when you call SDL_UpdateRect or SDL_Flip.

Are there any clues indicating that doom.exe did this in a more convoluted way and during buffer-to-VGA planar screen writes, rather than during normal in-memory patch drawing?

I'm pretty sure that's what I_BeginRead / I_EndRead did - they were hooks in the WAD code that displayed the disk icon to the screen when a read from disk was being performed.

Share this post


Link to post

I'm on a 2008 dual-core computer right now and the blue flashing disk icon in the lower right corner appears prominently in Eternity very often, especially when I start it up. Maybe you can look in Eternity how it's done?

Share this post


Link to post

the only way I know how to see it (also on a 2008 dual-core) is by running dosbox at like 5% speed, and it's still barely noticable.

Fwiw, I don't recall seeing the floppy disk icon in my early days of Doom in the mid-90s. So it doesn't hold much nostalgia to me.

Share this post


Link to post
chungy said:

the only way I know how to see it (also on a 2008 dual-core) is by running dosbox at like 5% speed, and it's still barely noticable.

Fwiw, I don't recall seeing the floppy disk icon in my early days of Doom in the mid-90s. So it doesn't hold much nostalgia to me.

I'm also having very little RAM, which means that there's probably some swapping going on while Eternity starts, if it helps.

Share this post


Link to post

I find the floppy disk icon to be quite nostalgic. :)
I remember being quite amused seeing it in EE. If I created a port, I'd definitely fake its inclusion somehow.

Doesn't it change to a CD icon with the correct command switch in vanilla? I remember being very proud of myself for figuring that out.

Share this post


Link to post

If we're talking about the real thing, then the diskette may still flash for a tic during level warping in vanilla Doom under DOSBox.

Share this post


Link to post
Siggi said:

I find the floppy disk icon to be quite nostalgic. :)
I remember being quite amused seeing it in EE. If I created a port, I'd definitely fake its inclusion somehow.

Doesn't it change to a CD icon with the correct command switch in vanilla? I remember being very proud of myself for figuring that out.

-cdrom - This command line was for running the games off the CD without installing them to your HD, and is also the reason for the existence of the C:\DOOMDATA folder.

Share this post


Link to post

I liked how Wolfenstein 3D was played from a harddisk, but Doom was played from a floppy. :p

Share this post


Link to post

Shrouded in secrecy and littered with mystique... when will it re-appear...? ^^

Share this post


Link to post
Gez said:

I liked how Wolfenstein 3D was played from a harddisk, but Doom was played from a floppy. :p

I've always found Wolf3d's menu display more advanced than Doom's afterthought-like overlay.

Share this post


Link to post

Maybe, but the fact that pressing Escape on the main menu doesn't close it but asks you if you want to quit the game drives me nut. Doom's menu behavior is saner.

I'm not sure what's more advanced about Wolf's menu, really. It plays different music on different screens; but beyond that?

Share this post


Link to post
Quasar said:

-cdrom

I thought so. I remember spending hours trying to figure out if -cdrom had any other effect on the game. I guess when you're young you can't help but hope that there's another secret level or weapon or something in the game if you look hard enough.

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
×