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

32 bit software renderer

Recommended Posts

myk said:

The main point in a 32-bit color software engine should be unfiltered graphics with smooth lighting (many people prefer the pixelated graphics over filtered sprites and textures, and it's also beneficial in regard to certain visual effects), plus any other fitting effects such as the ones being tested on the sprites above (which should be optional), that would replace translucency (which alters the sprites directly).



I've made the texture filtering optional, mostly because filtering needs a lot of cpu power. Dynamic lighting does not need so much cpu, and the light effects look good even without filtering:



Just the absence of colormaps and the smooth light transaction give a more...colorful result:


Currently I've implement 5 different detail levels:

Low: classic Doom low resolution
Medium: classic Doom normal resolution.
Normal: Unfiltered textures with dynamic lighting effects (32 bit rendering)
High: Small scale texture filtering with dynamic lighting effects (32 bit)
Ultra: Maximum texture filtering with dynamic lighting effects (32 bit)

Share this post


Link to post
Graf Zahl said:

And let's not forget the speed differences. Hardware accelerated rendering is considerably faster.

LEST WE FORGET
And? should he give up now?

Share this post


Link to post

As already pointed out, the main advantage in a software renderer is the compatibility for vanilla wads exploiting the properties of Doom's column renderer. Especially the way, flats extend into missing texture regions, and middle textures drawn into flats are things, gl-renderers don't reproduce exactly.

Share this post


Link to post

Now I have a question to make:

Yesterday I was taking a quick look in ZDoom 2.17 source code. It seems that uses HI_START and HI_END separators inside WAD files to determine hi resolution flat override. I think that uses 8x resolution textures, I'm not sure, I just picked a fast look.

Now the question:

How can someone make an interface that uses hi resolution textures in Doom Engines?
As far as now I give myseft the following answer:
-Usage of pk3 files (standard zip files with changed extention, same as Quake 3) (or pk4 as Doom3 and Quake4) that stores bitmap/jpg images, just because is an easy way for mod. Just create the hi resolution textures and then place it into a zip file and (optional) change the extension of zip file.
-Theese files are loaded with -file command line parameter. (or -zipfile ??).
-Bitmap files store transparent(masked) textures, non rectangular patches (eg font characters) and sprites. (using RGB(0,0,0) as transparent key, let's make black = RGB(1,0,0) or something like that ) Support for 8 bit color palleted bitmaps (with DIFFERENT pallete than PLAYPAL), 16 bit, 24 bit (and 32 bit????).
-JPG files store flats, rectangular patches (eg TITLEPIC) and the rest. (Maybe initially use only bitmap files, just for easy programming)
-While rendering in 32bit color mode look for the presence in loaded PK3 files for the texture. For example if trying to load FLAT1_1 and exists FLAT1_1.BMP or FLAT1_1.JPG then load the bitmap/jpg.
-No usage of filenames that exceeds 8:3 old dos filename (for compatibility), I mean you you can't have a texture named mytexture0001.jpg, use mtex0001.jpg instead.
-Directory structure inside pk3 files does not matter.
-No R_GenerateComponent support, use the texture name instead to store the texture.
-An (optional) text file with standard name (eg. hires.txt) that holds text information about the scaling of the images. For example:
FLAT1_1=2
FLAT1_2=8
FLAT1_3=4
....
Only 2 4 and 8 scale allowed.
If there isn't present information about scaling about one texture then use default x 1 scale.
-Flat's width and height must be the same.
-No filtering for hi-res textures, use a scale greater than 1 instead.


Well, I need your opinion about my answer, I'm trying to find the easiest way to import hi-resolution / hi-color textures in my engine, and as far as I can think that is good enough, easy to implement for mods and programmaticaly easy(???) to make it happen.

Share this post


Link to post

There was a length discussion by various port authors about a standardised system to support high-resolution and/or high-color textures.

Link: http://forums.newdoom.com/showthread.php?t=28605

Out of that came a draft specification, written by me but with a lot of input from the people involved in that discussion.
See: http://glbsp.sourceforge.net/JointTextureSpec.txt

I believe Doom Legacy has implemented some (all?) of that spec, but I don't know if any other port has. Personally I will add support for it into EDGE after the 1.29 release.

Share this post


Link to post

These are 2 screenshots with real 32bit color textures:




EDIT: Updated url.
Homepage
Mirror download

Currently 32 bit color software rendering is supported via external textures. Bitmaps(*.bmp) and Targa(*.tga) files supported. Support for other image formats (including PNG and JPG) is going to be added. External textures replace floors and wall textures (Patches/sprites currently are not supported) using the same name, to use them either place them in the current folder, or make PK3/ZIP or even (Quake)PAK file and load them with -pakfile command line parameter. Masked textures are supported using black colorkey in external images. For example if you want to replace FLOOR7_1 flat place a bitmap (or targa) image named FLOOR7_1.bmp (FLOOR7_1.tga) in current folder or gather all your textures in a ZIP(PK3) file and load it with the -pakfile command line parameter. Flats can be any size, if they have dimentions greater than 64x64 there will be automatically converted to 128x128 or 256x256 for high resolution rendering. Flats greater than 256x256 are not supported and will be automatically scaled to 256x256. Texture scaling currently is not supported.
32 bit color lighting can be configured with console commands:
-type [SET useransparentsprites (true/false)] to enable/disable transparency.
-type [SET uselightboost (true/false)] to enable/disable dynamic lighting arround standard light sources.
-type [SET lightboostfactor (16..1024)] to adjust the light arround standard light sources.

Share this post


Link to post

The GeoCities web site you were trying to view has temporarily exceeded its data transfer limit.

GeoShities still in XX century

Share this post


Link to post

I noticed some bugs:

Pitchbending in MIDI music seems to be of. Tested with Microsoft Software MIDI.

Disapearing sprites like explosions have random flickering wrong sprite frames in place just before they disapear.

In all 32 bit detail modes, 2-sided middle textures are drawn full bright. For instance in E1M1 the wall at the end of the lift secret and the grates in the room before the exit.

Also in 32 bit color mode, vision goggles have flats drawn like in invulnerability mode instead of just full bright.

Also in 32 bit, barrels appear transparent just before they explode.

And yet another strange thing in 32 bit: blood drops appear with a white glow, which really looks strange.

In Ultimate Doom, it looks for HELP2 after help screen.

And the mouse aiming reacts very sluggish.

Share this post


Link to post

Some doors don't close. I saw this, for example, in the little secret foom from where two Imps pop out in Map01.

Share this post


Link to post
LogicDeLuxe said:

I noticed some bugs:

Pitchbending in MIDI music seems to be of. Tested with Microsoft Software MIDI.

Disapearing sprites like explosions have random flickering wrong sprite frames in place just before they disapear.

In all 32 bit detail modes, 2-sided middle textures are drawn full bright. For instance in E1M1 the wall at the end of the lift secret and the grates in the room before the exit.

Also in 32 bit color mode, vision goggles have flats drawn like in invulnerability mode instead of just full bright.

Also in 32 bit, barrels appear transparent just before they explode.

And yet another strange thing in 32 bit: blood drops appear with a white glow, which really looks strange.

In Ultimate Doom, it looks for HELP2 after help screen.

And the mouse aiming reacts very sluggish.



Disapearing sprites fixed - was an interpolation subsystem bug.
2-sided middle textures fixed.
Vision goggles bug fixed.
Sprite transparency made optional, configurable thru the menus.
Blood drops now appear red.
Looks for correct HELP screens.

myk said:

Some doors don't close. I saw this, for example, in the little secret foom from where two Imps pop out in Map01.

Fixed, now doors close.

Also improved performance, 800x600 in 32 bit color mode gives 80 fps in P4 3GHz.

I've also made some screenshots with all the engine's rendering features: http://delphidoom.sitesled.com/screenshots.html
and a hi resolution texture example: http://delphidoom.sitesled.com/downloads.html (requires latest version 0.8.302)

Share this post


Link to post

eh, the midi is now a key lower. oh well, that's not really what we're looking for in the port and I really don't use the music anyway.

highres textures still make my framerate chop.

OH, and could you change "A secter place was found" to "You Found a Secret Area!" ? :)

Share this post


Link to post
Csonicgo said:

OH, and could you change "A secter place was found" to "You Found a Secret Area!" ? :)


Fixed, thanks.

Share this post


Link to post
jval said:

Also a better 32 bit software renderer should not use z-axis shift
for up/down look, but make render as true 3D engine!! (months of work...)


Latest (experimental) software renderer screenshots:





(Using hi resolution textures]


.....

OK, it's not really 3D, it's a ... fraud, but looks good, maybe better that simple z-axis shift. It has some CPU overhead (fps values are in a P4 2.4 GHz and 640x480 screen resolution, about 20% slower than simple zaxisshift).

Share this post


Link to post
Csonicgo said:

Reminds me of Polymost


???? The Polymost engine used z-axis shift as well. Some years later Ken port it into OpenGL.

Share this post


Link to post
jval said:

OK, it's not really 3D, it's a ... fraud, but looks good, maybe better that simple z-axis shift.

How do you do it? My guess is a post-processing step where you expand or shrink horizontal rows of the rendered scene. Whatever it is, I'm pretty sure no other software port has done it.

Share this post


Link to post
Ajapted said:

How do you do it? My guess is a post-processing step where you expand or shrink horizontal rows of the rendered scene.



You are right, just before rendering the player sprites I make a transform shrinking the rows depending on player up/down lookdir. Needs some work, maybe mmx optimization for speed, apect ratio correction and some code to avoid rendering to cut-off corners, but even without the above looks nice and very easy for every port to implement this programmatically.
I 'll release the source and the executable soon, just after some more tests and adjustments.

Share this post


Link to post
jval said:

You are right, just before rendering the player sprites I make a transform shrinking the rows depending on player up/down lookdir. Needs some work, maybe mmx optimization for speed, apect ratio correction and some code to avoid rendering to cut-off corners, but even without the above looks nice and very easy for every port to implement this programmatically.

I've seen the idea discussed before, but it's pretty cool that someone has actually pulled it off.

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
×