wesleyjohnson
Forum Regular
Posts: 673
Registered: 04-09 |
On the question, what to change to go to 24bit direct draw.
Just did this in DoomLegacy. It is not in the beta or alpha releases but is in the latest SVN system.
You have to finish all the draw routines in r_draw16.c and then make an r_draw24.c and an r_draw32.c. The fuzz draw was not finished in r_draw16.c so that has to be finished. You should also do 32bit draw, because most hardware is going to choose that as native (mine did). The 24 bit draw is slower.
Have to make a generic pixel draw and line draw that can draw in all bpp modes (8bitPAL, 16bpp, 24bpp, and 32bpp).
Have to fix the 16bpp, 24bpp, and 32bpp palettes.
The palette setup call has to be moved because it setup at the wrong time. It should be called after changing video modes.
Must setup a full set of draw routines. The original set for 16bpp does not cover all draw situations like the 8bpp does (the 16bpp draw was not finished, nor was its support).
Have to fix all secondary draws (non-play) to use the generic pixel draw as they are all 8bpp palette based. These are status bar draw, background draw, all v_video.c draw routines, title page and other picture draws, border draw, the fade and falling columns transition draws, and the auto map draw.
The fade draws can only work in 8bpp, and are unnecessarily complicated. Must totally replace with new routines.
Have to add a selection mechanism for the bpp. I have "-bpp n" "-truecolor" "-highcolor" and "-native".
The advantage is that the transparency based draws look much better, as they are done by fast RGB math.
Whenever possible it uses the approach of masking off some low order bits, shifting operands down, and then doing the add.
Anything except averaging of RGB pixel values did not work well.
Even the fog effects are done by picking a fog color and then averaging with it (50%, 50%) (75%,25%) or (87%, 13%).
Also consider that some memcpy (like border draw) assume that the video buffer wraps around from the right edge to the left edge (the copy both right border and left border in one operation). This is not true for some video (like on a Mac), as some video pads the video scan line out to a power of 2 to make the video hardware simpler.
Some cards were known to use the pad space for video card internal variables (so it is a do-not-touch area).
I fixed DoomLegacy to handle such padded buffers, but that is really complicated to describe. One thing it provides is separate variables, vid.width (draw width), vid.bitpp (bits per pixel), vid.bytepp (bytes per pixel) and vid.ybytes (increment to next y line), and a enum based draw mode variable to make bpp draw select statements fast.
Last edited by wesleyjohnson on 04-18-12 at 20:35
|
10-12-11 17:26 
