Page 1 of 3 123 LastLast
Results 1 to 10 of 24

Thread: Bryed 3d (1998) postmortem

  1. #1

    Cool Bryed 3d (1998) postmortem

    First, there won't be download for you, ever. Because:
    1. The sources make your eyes bleed. I don't open them anymore for the sake of my own sanity.
    2. There is (bad) porn I cannot remove because see 1.
    3. I forgot how to build the project. Also, see 1.
    4. 80% of the content is stolen. See those ogres? They are retouched Arch-Vile from DooM II.

    Other than that, the game runs just fine in DosBox with specific settings (core=auto).

    Boss fight videos
    http://chebmaster.com/video/goryn_fight.avi (33 Mb)
    http://chebmaster.com/video/goryn_fight2.avi (67 Mb)
    (if the links ever stop working, poke me with a stick)

    Made in: 1996-1998

    Compiler: Turbo Pascal 7.0 + assembler with "db 66h;" injected as a hack to utilize 32-bit operands

    Platform: MS-DOS real mode

    The Cool Feature: multi-threading, physics ran in a separate thread at fixed 25 frames per second using a timer interrupt hack. Well, it did until I butchered the code base trying to find a bug that wasn't. Currently no multi-threaded version is available ...

    Video modes supported: 13h and VESA 320x200x16

    Double buffering format: 16 bit device-independent, a 6 bit fog depth and a 256-color pixel in the standard palette, in system RAM. Flipped by copying into VRAM with table conversion to destination pixel format.

    Memory management: heavily relies on EMS memory paging provided by QUEMM or other memory manager. Runs acceptably @ only 2 Megabytes of memory available, swapping is rather smooth. The physics (map, entities & all) fit into 60 Kilobytes, a save file is 73 kilobytes and contains the entire level (some levels got preserved this way while their sources were lost).

    Level editor: any graphical editor for 256-color images. Employs a complex system of encoding objects in a PCX image using series of adjacent pixels. Very good for copy-pasting and spraying scenery around, literal hell for editing multi-layer buildings and weeding out bugs (see floating mountain on video, intended to be surrounded by smaller rocks).

    Max monsters on map: 62

    Palette / fog settings: 7, overcast (on the video), dense fog, darkness (for caves), bluish moonlit night, greenish fog for jungle, white-out desert (coupled with bright white sky with barely visible yellow mountains on it), reddish fog for volcanic levels. Quicksand and lava support included.

    Cpu requirements: K6-2 266 or higher. *very* poorly optimized considering overdraw and texel rate, because there are NO mip-maps and all sprites are fixed 128x128 size.

    Dropped because of:
    1. Inability to draw so much sprites to make my own monsters by hand.
    2. The !shocking! revelation that Pentiums perform poorly when using bitness switch (that db 66h I mentioned above)

  2. #2
    PGD Staff / News Reporter phibermon's Avatar
    Join Date
    Sep 2009
    Location
    England
    Posts
    524
    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.

  3. #3
    If only I had Internet back then
    So much time spent on trivial things like figuring how to make Sound Blaster work

    using spites as physical layers and what not - I'm very impressed!
    The idea stuck me in 1995. I made a simple demo of projecting spruce sprites in pseudo 3d and I thought: it could work!

    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.

  4. #4
    PGD Staff / News Reporter phibermon's Avatar
    Join Date
    Sep 2009
    Location
    England
    Posts
    524
    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.

  5. #5
    Quote Originally Posted by phibermon View Post
    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 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.

  6. #6
    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.

  7. #7
    It's amazing for the technology of that time! Making games before opengl was a real challenge. It's a pity it was never released.
    Developer of Mundo Project - http://sourceforge.net/projects/gamemundo/

  8. #8
    Interesting postmortem! Thanks for the share!

  9. #9
    Awesome. I would like to play this game.
    No signature provided yet.

  10. #10
    Quote Originally Posted by Rodrigo Robles View Post
    It's amazing for the technology of that time! Making games before opengl was a real challenge. It's a pity it was never released.
    The OpenGL specification was first released in 1993, though.

    (This is part of why it's so embarrassing to see people using glBegin/glEnd in current projects. You are using early 90s rendering techniques, people!​)

Page 1 of 3 123 LastLast

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •