2013-06-23 07:49:34 +00:00
|
|
|
/*
|
|
|
|
** gl_bitmap.cpp
|
|
|
|
** Bitmap class for texture composition
|
|
|
|
**
|
|
|
|
**---------------------------------------------------------------------------
|
|
|
|
** Copyright 2004-2009 Christoph Oelckers
|
|
|
|
** All rights reserved.
|
|
|
|
**
|
|
|
|
** Redistribution and use in source and binary forms, with or without
|
|
|
|
** modification, are permitted provided that the following conditions
|
|
|
|
** are met:
|
|
|
|
**
|
|
|
|
** 1. Redistributions of source code must retain the above copyright
|
|
|
|
** notice, this list of conditions and the following disclaimer.
|
|
|
|
** 2. Redistributions in binary form must reproduce the above copyright
|
|
|
|
** notice, this list of conditions and the following disclaimer in the
|
|
|
|
** documentation and/or other materials provided with the distribution.
|
|
|
|
** 3. The name of the author may not be used to endorse or promote products
|
|
|
|
** derived from this software without specific prior written permission.
|
|
|
|
** 4. When not used as part of GZDoom or a GZDoom derivative, this code will be
|
|
|
|
** covered by the terms of the GNU Lesser General Public License as published
|
|
|
|
** by the Free Software Foundation; either version 2.1 of the License, or (at
|
|
|
|
** your option) any later version.
|
|
|
|
**
|
|
|
|
** THIS SOFTWARE IS PROVIDED BY THE AUTHOR ``AS IS'' AND ANY EXPRESS OR
|
|
|
|
** IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES
|
|
|
|
** OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED.
|
|
|
|
** IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR ANY DIRECT, INDIRECT,
|
|
|
|
** INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT
|
|
|
|
** NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
|
|
|
|
** DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY
|
|
|
|
** THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
|
|
|
|
** (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF
|
|
|
|
** THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
|
|
|
|
**---------------------------------------------------------------------------
|
|
|
|
**
|
|
|
|
*/
|
|
|
|
|
|
|
|
|
|
|
|
#include "v_palette.h"
|
|
|
|
#include "templates.h"
|
|
|
|
#include "gl/renderer/gl_lightdata.h"
|
|
|
|
#include "gl/textures/gl_translate.h"
|
|
|
|
#include "gl/textures/gl_bitmap.h"
|
2014-06-21 10:52:19 +00:00
|
|
|
#include "gl/system/gl_interface.h"
|
2013-06-23 07:49:34 +00:00
|
|
|
|
|
|
|
//===========================================================================
|
|
|
|
//
|
|
|
|
// multi-format pixel copy with colormap application
|
|
|
|
// requires one of the previously defined conversion classes to work
|
|
|
|
//
|
|
|
|
//===========================================================================
|
|
|
|
template<class T>
|
2014-05-11 17:44:19 +00:00
|
|
|
void iCopyColors(unsigned char * pout, const unsigned char * pin, bool alphatex, int count, int step)
|
2013-06-23 07:49:34 +00:00
|
|
|
{
|
|
|
|
int i;
|
|
|
|
|
- decided to restrict the 2.0 beta to OpenGL 4.x with GL_ARB_buffer_storage extension and removed all code for supporting older versions.
Sadly, anything else makes no sense.
All the recently made changes live or die, depending on this extension's presence.
Without it, there are major performance issues with the buffer uploads. All of the traditional buffer upload methods are without exception horrendously slow, especially in the context of a Doom engine where frequent small updates are required.
It could be solved with a complete restructuring of the engine, of course, but that's hardly worth the effort, considering it's only for legacy hardware whose market share will inevitably shrink considerably over the next years.
And even then, under the best circumstances I'd still get the same performance as the old immediate mode renderer in GZDoom 1.x and still couldn't implement the additions I'd like to make.
So, since I need to keep GZDoom 1.x around anyway for older GL 2.x hardware, it may as well serve for 3.x hardware, too. It's certainly less work than constantly trying to find workarounds for the older hardware's limitations that cost more time than working on future-proofing the engine.
This new, trimmed down 4.x renderer runs on a core profile configuration and uses persistently mapped buffers for nearly everything that is getting transferred to the GPU. (The global uniforms are still being used as such but they'll be phased out after the first beta release.
2014-08-01 20:42:39 +00:00
|
|
|
for(i=0;i<count;i++)
|
2013-06-23 07:49:34 +00:00
|
|
|
{
|
- decided to restrict the 2.0 beta to OpenGL 4.x with GL_ARB_buffer_storage extension and removed all code for supporting older versions.
Sadly, anything else makes no sense.
All the recently made changes live or die, depending on this extension's presence.
Without it, there are major performance issues with the buffer uploads. All of the traditional buffer upload methods are without exception horrendously slow, especially in the context of a Doom engine where frequent small updates are required.
It could be solved with a complete restructuring of the engine, of course, but that's hardly worth the effort, considering it's only for legacy hardware whose market share will inevitably shrink considerably over the next years.
And even then, under the best circumstances I'd still get the same performance as the old immediate mode renderer in GZDoom 1.x and still couldn't implement the additions I'd like to make.
So, since I need to keep GZDoom 1.x around anyway for older GL 2.x hardware, it may as well serve for 3.x hardware, too. It's certainly less work than constantly trying to find workarounds for the older hardware's limitations that cost more time than working on future-proofing the engine.
This new, trimmed down 4.x renderer runs on a core profile configuration and uses persistently mapped buffers for nearly everything that is getting transferred to the GPU. (The global uniforms are still being used as such but they'll be phased out after the first beta release.
2014-08-01 20:42:39 +00:00
|
|
|
if (T::A(pin) != 0)
|
2013-06-23 07:49:34 +00:00
|
|
|
{
|
- decided to restrict the 2.0 beta to OpenGL 4.x with GL_ARB_buffer_storage extension and removed all code for supporting older versions.
Sadly, anything else makes no sense.
All the recently made changes live or die, depending on this extension's presence.
Without it, there are major performance issues with the buffer uploads. All of the traditional buffer upload methods are without exception horrendously slow, especially in the context of a Doom engine where frequent small updates are required.
It could be solved with a complete restructuring of the engine, of course, but that's hardly worth the effort, considering it's only for legacy hardware whose market share will inevitably shrink considerably over the next years.
And even then, under the best circumstances I'd still get the same performance as the old immediate mode renderer in GZDoom 1.x and still couldn't implement the additions I'd like to make.
So, since I need to keep GZDoom 1.x around anyway for older GL 2.x hardware, it may as well serve for 3.x hardware, too. It's certainly less work than constantly trying to find workarounds for the older hardware's limitations that cost more time than working on future-proofing the engine.
This new, trimmed down 4.x renderer runs on a core profile configuration and uses persistently mapped buffers for nearly everything that is getting transferred to the GPU. (The global uniforms are still being used as such but they'll be phased out after the first beta release.
2014-08-01 20:42:39 +00:00
|
|
|
pout[0]=T::R(pin);
|
|
|
|
pout[1]=T::G(pin);
|
|
|
|
pout[2]=T::B(pin);
|
|
|
|
pout[3]=T::A(pin);
|
2013-06-23 07:49:34 +00:00
|
|
|
}
|
- decided to restrict the 2.0 beta to OpenGL 4.x with GL_ARB_buffer_storage extension and removed all code for supporting older versions.
Sadly, anything else makes no sense.
All the recently made changes live or die, depending on this extension's presence.
Without it, there are major performance issues with the buffer uploads. All of the traditional buffer upload methods are without exception horrendously slow, especially in the context of a Doom engine where frequent small updates are required.
It could be solved with a complete restructuring of the engine, of course, but that's hardly worth the effort, considering it's only for legacy hardware whose market share will inevitably shrink considerably over the next years.
And even then, under the best circumstances I'd still get the same performance as the old immediate mode renderer in GZDoom 1.x and still couldn't implement the additions I'd like to make.
So, since I need to keep GZDoom 1.x around anyway for older GL 2.x hardware, it may as well serve for 3.x hardware, too. It's certainly less work than constantly trying to find workarounds for the older hardware's limitations that cost more time than working on future-proofing the engine.
This new, trimmed down 4.x renderer runs on a core profile configuration and uses persistently mapped buffers for nearly everything that is getting transferred to the GPU. (The global uniforms are still being used as such but they'll be phased out after the first beta release.
2014-08-01 20:42:39 +00:00
|
|
|
pout+=4;
|
|
|
|
pin+=step;
|
2013-06-23 07:49:34 +00:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2014-05-11 17:44:19 +00:00
|
|
|
typedef void (*CopyFunc)(unsigned char * pout, const unsigned char * pin, bool alphatex, int count, int step);
|
2013-06-23 07:49:34 +00:00
|
|
|
|
|
|
|
static CopyFunc copyfuncs[]={
|
|
|
|
iCopyColors<cRGB>,
|
|
|
|
iCopyColors<cRGBA>,
|
|
|
|
iCopyColors<cIA>,
|
|
|
|
iCopyColors<cCMYK>,
|
|
|
|
iCopyColors<cBGR>,
|
|
|
|
iCopyColors<cBGRA>,
|
|
|
|
iCopyColors<cI16>,
|
|
|
|
iCopyColors<cRGB555>,
|
|
|
|
iCopyColors<cPalEntry>
|
|
|
|
};
|
|
|
|
|
|
|
|
//===========================================================================
|
|
|
|
//
|
|
|
|
// True Color texture copy function
|
|
|
|
// This excludes all the cases that force downconversion to the
|
|
|
|
// base palette because they wouldn't be used anyway.
|
|
|
|
//
|
|
|
|
//===========================================================================
|
|
|
|
void FGLBitmap::CopyPixelDataRGB(int originx, int originy,
|
|
|
|
const BYTE * patch, int srcwidth, int srcheight, int step_x, int step_y,
|
|
|
|
int rotate, int ct, FCopyInfo *inf)
|
|
|
|
{
|
|
|
|
if (ClipCopyPixelRect(&ClipRect, originx, originy, patch, srcwidth, srcheight, step_x, step_y, rotate))
|
|
|
|
{
|
|
|
|
BYTE *buffer = GetPixels() + 4*originx + Pitch*originy;
|
|
|
|
for (int y=0;y<srcheight;y++)
|
|
|
|
{
|
2014-05-11 17:44:19 +00:00
|
|
|
copyfuncs[ct](&buffer[y*Pitch], &patch[y*step_y], alphatex, srcwidth, step_x);
|
2013-06-23 07:49:34 +00:00
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
//===========================================================================
|
|
|
|
//
|
|
|
|
// Paletted to True Color texture copy function
|
|
|
|
//
|
|
|
|
//===========================================================================
|
|
|
|
void FGLBitmap::CopyPixelData(int originx, int originy, const BYTE * patch, int srcwidth, int srcheight,
|
|
|
|
int step_x, int step_y, int rotate, PalEntry * palette, FCopyInfo *inf)
|
|
|
|
{
|
|
|
|
PalEntry penew[256];
|
|
|
|
|
|
|
|
int x,y,pos,i;
|
|
|
|
|
|
|
|
if (ClipCopyPixelRect(&ClipRect, originx, originy, patch, srcwidth, srcheight, step_x, step_y, rotate))
|
|
|
|
{
|
|
|
|
BYTE *buffer = GetPixels() + 4*originx + Pitch*originy;
|
|
|
|
|
2014-05-12 12:45:41 +00:00
|
|
|
// alpha map with 0==transparent and 1==opaque
|
2014-05-11 17:44:19 +00:00
|
|
|
if (alphatex)
|
2013-06-23 07:49:34 +00:00
|
|
|
{
|
- decided to restrict the 2.0 beta to OpenGL 4.x with GL_ARB_buffer_storage extension and removed all code for supporting older versions.
Sadly, anything else makes no sense.
All the recently made changes live or die, depending on this extension's presence.
Without it, there are major performance issues with the buffer uploads. All of the traditional buffer upload methods are without exception horrendously slow, especially in the context of a Doom engine where frequent small updates are required.
It could be solved with a complete restructuring of the engine, of course, but that's hardly worth the effort, considering it's only for legacy hardware whose market share will inevitably shrink considerably over the next years.
And even then, under the best circumstances I'd still get the same performance as the old immediate mode renderer in GZDoom 1.x and still couldn't implement the additions I'd like to make.
So, since I need to keep GZDoom 1.x around anyway for older GL 2.x hardware, it may as well serve for 3.x hardware, too. It's certainly less work than constantly trying to find workarounds for the older hardware's limitations that cost more time than working on future-proofing the engine.
This new, trimmed down 4.x renderer runs on a core profile configuration and uses persistently mapped buffers for nearly everything that is getting transferred to the GPU. (The global uniforms are still being used as such but they'll be phased out after the first beta release.
2014-08-01 20:42:39 +00:00
|
|
|
for (int i = 0; i<256; i++)
|
2013-06-23 07:49:34 +00:00
|
|
|
{
|
- decided to restrict the 2.0 beta to OpenGL 4.x with GL_ARB_buffer_storage extension and removed all code for supporting older versions.
Sadly, anything else makes no sense.
All the recently made changes live or die, depending on this extension's presence.
Without it, there are major performance issues with the buffer uploads. All of the traditional buffer upload methods are without exception horrendously slow, especially in the context of a Doom engine where frequent small updates are required.
It could be solved with a complete restructuring of the engine, of course, but that's hardly worth the effort, considering it's only for legacy hardware whose market share will inevitably shrink considerably over the next years.
And even then, under the best circumstances I'd still get the same performance as the old immediate mode renderer in GZDoom 1.x and still couldn't implement the additions I'd like to make.
So, since I need to keep GZDoom 1.x around anyway for older GL 2.x hardware, it may as well serve for 3.x hardware, too. It's certainly less work than constantly trying to find workarounds for the older hardware's limitations that cost more time than working on future-proofing the engine.
This new, trimmed down 4.x renderer runs on a core profile configuration and uses persistently mapped buffers for nearly everything that is getting transferred to the GPU. (The global uniforms are still being used as such but they'll be phased out after the first beta release.
2014-08-01 20:42:39 +00:00
|
|
|
if (palette[i].a != 0)
|
|
|
|
penew[i] = PalEntry(255, i, 255, 255);
|
|
|
|
else
|
|
|
|
penew[i] = PalEntry(255, 0, 255, 255); // If the palette contains transparent colors keep them.
|
2013-06-23 07:49:34 +00:00
|
|
|
}
|
|
|
|
}
|
2014-05-11 17:44:19 +00:00
|
|
|
else if (translation > 0)
|
2013-06-23 07:49:34 +00:00
|
|
|
{
|
2014-05-11 17:44:19 +00:00
|
|
|
PalEntry *ptrans = GLTranslationPalette::GetPalette(translation);
|
|
|
|
if (ptrans)
|
2013-06-23 07:49:34 +00:00
|
|
|
{
|
2014-05-11 17:44:19 +00:00
|
|
|
for (i = 0; i < 256; i++)
|
2013-06-23 07:49:34 +00:00
|
|
|
{
|
2014-05-11 17:44:19 +00:00
|
|
|
penew[i] = (ptrans[i] & 0xffffff) | (palette[i] & 0xff000000);
|
2013-06-23 07:49:34 +00:00
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
2014-05-11 17:44:19 +00:00
|
|
|
else
|
|
|
|
{
|
|
|
|
memcpy(penew, palette, 256*sizeof(PalEntry));
|
|
|
|
}
|
2013-06-23 07:49:34 +00:00
|
|
|
|
|
|
|
// convert the image according to the translated palette.
|
|
|
|
for (y=0;y<srcheight;y++)
|
|
|
|
{
|
|
|
|
pos=(y*Pitch);
|
|
|
|
for (x=0;x<srcwidth;x++,pos+=4)
|
|
|
|
{
|
|
|
|
int v=(unsigned char)patch[y*step_y+x*step_x];
|
|
|
|
if (penew[v].a!=0)
|
|
|
|
{
|
|
|
|
buffer[pos] = penew[v].r;
|
|
|
|
buffer[pos+1] = penew[v].g;
|
|
|
|
buffer[pos+2] = penew[v].b;
|
|
|
|
buffer[pos+3] = penew[v].a;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|