Bryed 3d (1998) postmortem

[Chebmaster]

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)

[phibermon]

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! :)

[Chebmaster]

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?

[phibermon]

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 :P

[SilverWarior]

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 :P

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.

[Chebmaster]

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.

[Rodrigo Robles]

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.

[farcodev]

Interesting postmortem! Thanks for the share! :)

[Ñuño Martínez]

Awesome. I would like to play this game.

[Akira13]

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!​)

[SilverWarior]

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!

The fact that these techniques are from early 90's doesn't mean that they shouldn't be used. Does it?
BTW how many early 90's techniques that originate from early Pascal dialects are you still using today? ;D

Any way have you ever asked yourself why do people nowadays still use glBegin/glEnd technique?
Perhaps it is because most OpenGL tutorials for pascal teach this approach. In fact I don't remember ever seeing OpenGL tutorial for Pascal that doesn't use such approach. If you know for one please do share. And if not you are welcome to write one on your own. I will be glad to read it either way.

[phibermon]

The fact that these techniques are from early 90's doesn't mean that they shouldn't be used. Does it?

It's not a matter of 'technique' - it's not like they're language features or some timeless algorithmic process such as a quick sort.

They are from a very old API that can't make full use of the graphics hardware that has existed for many years now.

You absolutely should not be using immediate mode GL anymore (glbegin/glend etc) not only is it slow but there's no guarantee that hardware vendors will even continue to support it and if they do you can forget about using your hardware to anything like its potential.

Immediate mode GL on any GPU of the past 10 years is like running DOS on brand new 8 core computer. Yes its possible but nobody in their right mind would seriously run it day to day let alone invest their time in long term programming projects for the DOS platform.

If you're using GL 1.x or GL 2.x in an immediate style (or later revisions of GL in compatibility mode) to develop games then just be aware that you're shooting yourself in the foot.

Knowing both the old and the new styles? the new style is easier anyway for anything but drawing the most primitive of shapes - it forces you to manage your data in an efficient and logical manner which will quickly become second nature.

[Chebmaster]

In fact I don't remember ever seeing OpenGL tutorial for Pascal that doesn't use such approach.
Very sad, this situation is.

We should state whenever possible that even Quake 3 uses glBegin/glEnd either as a compatibility fallback option or to render single textured quads.
This technique is *that* fresh :(

[Ñuño Martínez]

the new style is easier anyway for anything but drawing the most primitive of shapes. Doh! :S

[Chebmaster]

Don't forget that the old style API is capped very hard at about 20k vertices, which is infinitesimal in today videocards terms. Go over that and performance drops like a stone.

[Chebmaster]

I managed finding a moderately broken version with asset building tools included (from October 1999). So i can finally present this project, incomplete (sigh) with bad porn removed:

English version (text messages translated by editing the EXE in Notepad++) http://chebmaster.com/downloads/bryed_3d_English.zip
Original (Russian only) version http://chebmaster.com/downloads/bryed_3d.zip

Lifted assets galore (doom2, duke nukem, blood) and general lack of sanity, as expected from a college student during the lawless Great Depression of the 90s. (I recently stumbled on an VHS tape with a movie recorded from TV, from that time period. Gratuitous rape scenes with tits flashing, live pigs doused in gasoline and set on fire... Oft interrupted with ads of lawnmowers, beer or luxury cars. No ratings, no limitations, only separated from Chip&Dale Rescue Rangers by time slots. A generation of kids grew watching this)

Someone's speedrun @ YouTube: https://www.youtube.com/watch?v=Ggt_U2-bldI

At first, I just covered all tits with black bars. I then realized it was lowest of hypocrisy as bad porn interaction was still there. I rebuilt all maps removing all porn actors and hastily re-uploaded. I then realized there's a not-so-rare glitch that makes a dead ogre flicker through the entire sprite atlas. And also sprites could be seen in FAR because they are uncompressed. I hastily rebuilt the pak file replacing even censored hentai with empty spaces and re-uploaded again.

Sorry, still no sources because sources of code and art are intermixed and removing all porn from these is a *much* harder task.

Cave entrances/exits not showing in game
http://chebmaster.com/_share/missingnoes.png
Interestingly, those are items, map generator raises them by 100cm so that you pick them up without crouching, while render routine places their sprite 130cm below origin.

Map editing:
http://chebmaster.com/_share/g-editing.png

code sample (note integer = smallint)
init:

New( SqrtTable );
for i:=0 to 1023 do
SqrtTable^[i]:=Round(Sqrt(i)*2048);
New(ST);
For c:=0 to 1024 do
ST^[c]:=Round(32767*Sin(c*2*Pi/1024));
New(CT);
For c:=0 to 1024 do
CT^[c]:=Round(32767*Cos(c*2*Pi/1024));
New(AT);
For c:=0 to 1024 do
AT^[c]:=Round(Arctan((c/512)-1)*32767/Pi);

usage:

Function Angle(x1,y1,x2,y2: integer): integer;
var x,y: LongInt;
begin
x:=x1-x2; if x=0 then x:=1;
y:=y1-y2; if y=0 then y:=1;
If abs(x)>abs(y) then
If x>0 then Angle:=AT^[512+((y shl 9) div x)]
else Angle:=word(32767)+word(AT^[512+((y shl 9) div x)])
else
If y>0 then Angle:=16384-AT^[512+((x shl 9) div y)]
else Angle:=49152-AT^[512+((x shl 9) div y)];
end;
Procedure SinCos(var s,c: integer; rasst, angle: integer);
begin
S:=(longint(ST^[angle shr 6]) * Rasst) div 32767;
C:=(longint(CT^[angle shr 6]) * Rasst) div 32767;
end;
type
STable = array[0..1023] of Word;

var
SqrtTable: ^STable;
i: Word;

function KOREN( S: LongInt ): Word; assembler;
asm
db 66h; xor si, si { xor esi, esi }
les si, dword ptr SqrtTable
db 66h; mov bx, word ptr S { mov ebx, S }
mov dx, 11
db 66h, 0Fh, 0BDh, 0CBh { bsr ecx, ebx }
sub cx, 9; jle @less
shr cx, 1
adc cx, 0
sub dx, cx
shl cx, 1
db 66h; shr bx, cl { shr ebx, cl }
@less:
db 26h, 67h, 8Bh, 04h, 5Eh { mov ax, es:[esi+ebx*2] }
mov cx, dx
shr ax, cl
end;
All coordinates are in centimeters, speeds in centimeters per tick (1/25 s), angle is the full SmallInt range is 360 degrees. With overflows exploited to loop it.

[Jonax]

I watched the video. Nice touch with the mushrooms.. And impressive work. Definitely beats what I did back then..

[Jonax]

And beats anything I've done since too.

[Jonax]

Any new projects ongoing?

[Chebmaster]

I *am* busy making a new engine since then. Never really stopped. The main thread at freepascal.ru is 50 pages and 8 years long. And yet, I can't even show a rotating cube: my works (behold them and despair, ye mighty) are in deep refactoring since, I think, 2018.
Targets Raspberry Pi and Windows XP with DX9 class gpus.
It even has a thread here https://www.pascalgamedevelopment.com/showthread.php?32636-Cheb-s-project-will-be-here , which is an empty stub as I don't currently have anything to show.

There was a small side-quest, modifying Quake 2 Delphi into using Lanczos upsampling https://www.pascalgamedevelopment.com/showthread.php?4312-My-visulally-enhanced-renderer-for-Quake2

..a sad date approaches, 20 years since the tragic death of the guy who introduced me into using OpenGL with Delphi. I shall not forget post a tread for it in 3 days.

[Jonax]

Sad to learn about that OpenGL guy. Nice you made a post about him.

Raspberry Pi is an interesting target for one man hobby programmers (like me). Limited hardware but out of necessity one man projects tend to be simpler and demanding less from the system. At least for those of us who dabble on less ambitious projects.

I managed to buy a Raspberry Pi 4 this winter and installed the new PiOS. Turns out it is possible to install the Lazarus on PiOS but I must be doing something wrong because I get tons of warnings. From what I read elsewhere the installation of Lazarus really is tricky. Still I managed to compile and run one simple game (the Grayout) on Raspberry but I've not made that one downloadable. For some reason Raspberry-Lazarus doesn't accept the code from my current Linux/WIndows project.

Have you happend to install Lazarus on Raspberry? Do you run other pascal software?

[Chebmaster]

I have installed Lazarus, and I succeeded building an executable and rendering stuff via GL ES 2 -- BUT my project is Lazarus-independent (I only use the IDE as a convenient code editor) and I had to fiddle with code options in my build.sh to get a working executable
Also, Lazarus ran *monstrously* slow back then due to horribly inefficient text rendering (SynEdit is based on WinAPI calls which are emulated in Linux -- badly, with horrible performance). But that was several years ago and a RPi 2.

Sample (i don't know if this is correct any more, haven't tested in years)

LIN_T=$(uname -m)

CODE_OPTIONS=" -O3 -OpPentiumM -CfSSE2"
CGE_OPTIONS="-vq -gl -gs -gp -Xi -XX -dcge -dnotlaz -Sh -Sc -Mobjfpc -Rintel ${CODE_OPTIONS}"

if [ "${LIN_T}" == "armv7l" ]
then
#works with RPi 3 / raspbian 9 / fpc 3.0.0
CODE_OPTIONS=" -O3 -CaEABIHF -CpARMV7R"

#worked with RPi 2 / raspbian 8 / fpc 2.6.4
#CODE_OPTIONS=" -O3 -CaEABIHF -CpARMV6 -Cfvfpv2"

CGE_OPTIONS="-vq -gl -gs -gp -Xi -dcge -dnotlaz -Sh -Sc -Mobjfpc ${CODE_OPTIONS}"
fi

[Jonax]

Thanks Chebmaster. RPi 2 and years ago and emulations. I can imagine monstrously slow.

For my part I'm glad to be able make something at all for the Pi but the platform is very interesting and worth trying, I think.
I figure if a program runs on a Pi it can run smoothly on almost any PC ( if successful compilation on both platforms ).

I hope the Lazarus team one day creates some neat solution for installing their software on Raspberry too.

[Ñuño Martínez]

I've saw the video and I'm really impressed. The use of sprites and fog really make it look 3D! I want to play it.