for a self developed project in 1998? easily superior to the ROTT the engine in terms of using spites as physical layers and what not - I'm very impressed!
for a self developed project in 1998? easily superior to the ROTT the engine in terms of using spites as physical layers and what not - I'm very impressed!
When the moon hits your eye like a big pizza pie - that's an extinction level impact event.
If only I had Internet back then
So much time spent on trivial things like figuring how to make Sound Blaster work
The idea stuck me in 1995. I made a simple demo of projecting spruce sprites in pseudo 3d and I thought: it could work!using spites as physical layers and what not - I'm very impressed!
Sadly, without knowledge and understanding of texel fillrate 386 SX 40 proved to be too slow to draw a large castle at acceptable fill rate. I thought it'd run Ok on a 486 DX 100... But no.
Only P 266 and up proved to be enough. But by then it was too late for such technologies.
Because, without a depth buffer all sprites have to be drawn in order, back-to-front, and with sprites for horizontal surfaces having about 12 variations for various angles, and each different sprite requiring an EMS page switch... Yeah.
BECAUSE ALL OF THEM ARE 128x128 BECAUSE I WAS TOO LAZY TO PROGRAM NORMAL compression algorithms sprites like DooM uses.
On the other hand, when you have to exit the IDE to try anything you changed and each honest mistake necessitates a reboot (no try..except in Turbo Pascal) How I even did what I did?
Last edited by Chebmaster; 15-08-2017 at 05:08 AM.
I must say that software rasterization is the one aspect of 3D graphics coding that I have very little experience with - I've made a simple ray tracer to learn about some concepts but hardcore fast routines on lower spec hardware? I'm all but oblivious!
I've watched some talks by Romero and Carmack about the development of doom and they did touch on a few aspects but I guess I've been spoiled by 3D hardware :\
I've been toying with an interesting concept of late - similar to the 'imposter' technique - basically rendering distant objects to buffers every other frame with the frame in the middle being a translated drawing of the frame before - I already claw back some cycles with things such as rendering skydomes - only updating them at 15fps etc
i'm heading towards using such a technique for rendering distant terrain - I suspect I might be able to find a sweet spot between movement speed and rendering updates for distant geometry that looks acceptable.
So in the middle frame I render half of the geometry to a different cube map - and then render the previous buffer, with the new camera translation - next frame I render the other half of the cube map and then swap the new buffer with the old and render the new buffer.
That way I'm spreading the load across two frames - surely such techniques have been done before but I'm currently unaware of any commercial application - hopefully that doesn't mean I'm wasting my time
When the moon hits your eye like a big pizza pie - that's an extinction level impact event.
I could see benefits of this when you have pretty much constant movement speed. But I don't think it will work well when your movement speed varies a lot. But then again I'm not an expert in graphical rendering. So I might be wrong.Originally Posted by phibermon
I've been toying with an interesting concept of late - similar to the 'imposter' technique - basically rendering distant objects to buffers every other frame with the frame in the middle being a translated drawing of the frame before - I already claw back some cycles with things such as rendering skydomes - only updating them at 15fps etc
i'm heading towards using such a technique for rendering distant terrain - I suspect I might be able to find a sweet spot between movement speed and rendering updates for distant geometry that looks acceptable.
So in the middle frame I render half of the geometry to a different cube map - and then render the previous buffer, with the new camera translation - next frame I render the other half of the cube map and then swap the new buffer with the old and render the new buffer.
That way I'm spreading the load across two frames - surely such techniques have been done before but I'm currently unaware of any commercial application - hopefully that doesn't mean I'm wasting my time
I don't think distant terrain would work well. There'd be tearing and cracking and all sorts of nasty artifacts.
Distant objects, on the other hand...
Every other frame is too often! Impostors really shine when you redraw at rates from from 6 to 1 FPS.
So: impostors are best used for static objects like rocks, trees or even buildings (preferrably with a depth component so they can be blended flicker-free into the scene, like they were 3d). Slowly moving creatures as well.
But! A modern impostor must be made using multi-target render, to consist of, at least, color, specular, normal, glow and depth textures so deferred lighting could be applied to it.
Also, you need a sophisticated manager that decides which objects are rendered normally and which use impostors, how much texture memory each one uses (hello, fbo space manager). And, if you think of it, lots of impostors require lots of texture space.
To summarize, the best application where impostors shine would be a dense forest.
Posting Permissions
Reply With Quote
Bookmarks