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

gif of e1m1 rendering?

Recommended Posts

Looking for that gif of e1m1 starting view rendering, like, wall by wall, visplane by visplane, it was fun to look at. Anyone remembers what I'm talking about?

Share this post


Link to post

We take it for granted now but it's crazy to see how many things even processors in the 90's had to do, and faster than we can realistically perceive it since, to us, it's happening all at once.

Share this post


Link to post

Well, that's also true but just to be sure, Doom used a nifty little trick called "double buffering", so you never actually got to see the rendering displayed on your monitor. Each frame was rendered "off screen" so to speak, and the old one was kept on display until the new one was ready, and then they switched places instantly. This is why HOMs had a flickery appearance in vanilla.

Share this post


Link to post
Maes said:

Well, that's also true but just to be sure, Doom used a nifty little trick called "double buffering", so you never actually got to see the rendering displayed on your monitor. Each frame was rendered "off screen" so to speak, and the old one was kept on display until the new one was ready, and then they switched places instantly. This is why HOMs had a flickery appearance in vanilla.

Doom actually used TRIPLE buffering, as can be easily verified by counting the number of different views visible in a vanilla HOM.

Share this post


Link to post
Maes said:

This is why HOMs had a flickery appearance in vanilla.


I always wondered what changed in the engine to make Heretic's HOM not flickery?

Share this post


Link to post
Use3D said:

I always wondered what changed in the engine to make Heretic's HOM not flickery?

Heretic actually uses a different VGA mode than Doom - Doom used a triple buffered "Mode Y", whereas Heretic was just plain (double buffered?) Mode 13h.

Chocolate Doom is actually looking into emulating real vanilla HOMs, and this sort of thing is a real issue. https://github.com/chocolate-doom/chocolate-doom/issues/676

Share this post


Link to post
Linguica said:

Heretic actually uses a different VGA mode than Doom - Doom used a triple buffered "Mode Y", whereas Heretic was just plain (double buffered?) Mode 13h.

Chocolate Doom is actually looking into emulating real vanilla HOMs, and this sort of thing is a real issue. https://github.com/chocolate-doom/chocolate-doom/issues/676

So what was the benefit of using triple buffering in Doom? Why did they go back to mode 0x13 in Heretic?

Share this post


Link to post
Silikone said:

So what was the benefit of using triple buffering in Doom? Why did they go back to mode 0x13 in Heretic?


I'm not certain but I think it was necessary to achieve the screen melt effect in Doom, which Heretic ditched.

Share this post


Link to post
valkiriforce said:

Looks like a really nice screensaver.


I can imagine a screensaver form of SLIGE that visually constructs random levels in front of you, maybe even with AI activated monsters that fight each other or other random things.

Share this post


Link to post
valkiriforce said:

Looks like a really nice screensaver.

A screensaver that prints a static image onto the screen is not a real screensaver.

Share this post


Link to post
scifista42 said:

A screensaver that prints a static image onto the screen is not a real screensaver.

I mean, screensavers that did this tended to rotate images every 20-30 seconds or so, from my recollection, so I expect similar would happen here. Draw a random position/angle from a random Doom map, hold for a few seconds, then blank the screen and draw another.

Share this post


Link to post
MetroidJunkie said:

That's still really cool to think about, that a CPU over two decades ago performed these calculations 35 times a second.


Well, if you take it one step further, it provides an interesting metric: there are 64,000 pixels to update in VGA mode 13h for each tic, or 2,240,000 every second at 35 fps.

Considering that in order to get such a consistent framerate/pixel output back in the day you needed at least a 486DX2/66, and that the 486 was the first Intel CPU to execute on average 1 instruction per clock cycle, you get the interesting figure that behind each rendered "pixel" there are at least 30 CPU instructions of "thinking".

Of course that's a very optimistic lower point, but it serves as a best-case yardstick to predict performance and portability. In practice you'd need to consider at least double that amount if you wanted a really rock-solid 35 fps framerate under all vanilla levels, so an entry-level Pentium or a very highly clocked 486 (>100 MHz).

Interestingly, that metric (30 CPU instructions per pixel) maps quite closely to what the GBA version (the first one, using the real Doom engine) achieves, taking into account its resolution and frame rate.

Share this post


Link to post

Would it be possible to slow down the drawing process so that you could walk around the level and see parts of it loading in real time like when in virtual reality films things start getting buggy or whatever?

Share this post


Link to post
kuchitsu said:

Would it be possible to slow down the drawing process so that you could walk around the level and see parts of it loading in real time like when in virtual reality films things start getting buggy or whatever?


That would require to draw at least a black background before anything else, and essentially turn all textures and floor flats into conditionally animated textures, with the column drawers being limited by the current timer's position, and the timer would need to start ticking since a particular sidedef was made visible. Quite a major change to the engine.

Share this post


Link to post

I think kuchitsu's idea would better be implemented this way: Render the scene into a dummy buffer every tic, while keeping track of the order in which particular pixels were drawn into the buffer, then once the entire screen was drawn, split the pixel sequence into N sections of equal size, only take the pixels belonging to a particular one of these sections (determined by the current tic's index modulo N) and copy these pixels into the real screen buffer, and the rest of the screen would remain non-updated, like a HOM.

Share this post


Link to post

And what would happen if the player shifted his view ever so slightly? All this pixel sequence information that you mentioned, would be invalidated, as it would be valid only for a particular player x,y position and angle.

The player would see the slowed-down rendering sequence only if they didn't move or turn.

Share this post


Link to post

I've got an impression that kuchitsu didn't want this to observe slowed down rendering, but to make the game look deliberately buggy as he's moving around the map.

Share this post


Link to post

If one just wants glitchy rendering, that can be achieved with minor tweaks, like e.g. "forgetting" to render some walls, skipping some pixels randomly when rendering some columns, or even fucking around with the sprites' rendering in order to produce disturbing and grotesque deformations.

However, in order to produce a visually pleasing "slow rendering" that would be independent of player movements, an internal timer would need to be added to each rendered element, and the drawing functions modified accordingly.

Silikone said:

So what was the benefit of using triple buffering in Doom? Why did they go back to mode 0x13 in Heretic?


There's an archived Usenet discussion with John Carmack here:

https://groups.google.com/forum/m/?hl=en#!msg/alt.games.doom/3tMB2UmEBK0/m1VR6LiJRQMJ

Essentially, "fake Mode X" allowed to output up to 4 pixels at once with a single write, which speeded up Low Detail mode (2 pixels per write). It also came with triple buffering "by default".

Share this post


Link to post
Maes said:

There's an archived Usenet discussion with John Carmack here:

https://groups.google.com/forum/m/?hl=en#!msg/alt.games.doom/3tMB2UmEBK0/m1VR6LiJRQMJ

Essentially, "fake Mode X" allowed to output up to 4 pixels at once with a single write, which speeded up Low Detail mode (2 pixels per write). It also came with triple buffering "by default".

This makes me want to compare the frame rates directly between Doom and Heretic, and see how consistently this 10-15% performance gain applies.

Share this post


Link to post
Silikone said:

This makes me want to compare the frame rates directly between Doom and Heretic, and see how consistently this 10-15% performance gain applies.


I'd expect that this complicated VGA access scheme's overhead pretty much gobbled up any advantage gained by adopting it. Probably they overestimated the utility of Low Detail mode to begin with, if they designed this whole shebang around it.

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
×