Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.


Topics - Skybuck

Pages: [1] 2 3 ... 5
1
Help / Strike Carrier Mod
« on: December 23, 2022, 02:23:30 am »
I'd like to see some more modern/updated gameplay fitting the UFOlogy of today. Which is nimitz strike carrier group =D

So a mod where a strike carrier is in trouble on the open sea somewhere and X-COM is called in to clean the strike carrier from Aliens ! =D

The skyranger lands on top of the strike carrier.

The X-Com soldiers then have to fight their way down into the strike carrier, multi level map.

(Aliens may or may not have deployed a bomb deep inside the strike carrier and X-Com has to find and disable it before it explodes ! =D)

Alternative story:
The fighting between marines and aliens have caused the nuclear reactor of the strike carrier to become unstable ! X-Com has to reach the reactor to stabilize it, before it explodes and takes down the entire carrier ! =D)

Additional possibilities:

Before the strike carrier can be reached, scout UFOs have to be shot down out of the sky with interceptors.



2
My programming experiences tells me that there is no way that a 2.7 GHz processor can run a 1600x900x32 bit screen at 60 fps.

The computational horse power from the generic x86 and x64 instruction set and cycle count just can't do it (very maybe multi-core if enough cores/hyper threads available)

So I assume that this game can only run in realtime thanks to SSE and SIMD (or other hardware acceleration like GPU)?

This could present a problem for me right now, because I want 32 bit colors and it seems the SSE and SIMD and scalar/zoom functions don't support it or don't support it properly ?

I am considering removing these SSE and SIMD code pieces/scalars because they don't seem to work for 32 bit colors. However then the game would not run in real time anymore ? At first glance this would seem to be a waste of time, but then again, at least I can have a looksy at how a bigger palette would look like.

And it does give a "base" to work from to then try and speed up 32 bit true colors with perhaps SSE/SIMD or maybe some OpenGL software rendering/scalar/zoom functionality so that this game can also run without a gpu or without a working gpu.

I suspect the default software renderer of windows 95 and beyond uses SSE/SIMD internally to speed it up. This is why OpenGL software rendering might be able to run in real time.

Anyway I ask this question anyway: Is it possible to run this game in real time without SSE/SIMD and/or without any other acceleration hardware like GPUs and such, what was your experience during your development days ???

(Are there perhaps compiler conditionals ? and/or other settings to make the game/code fall back to simple software code/generic code without SSE/SIMD/OpenGL/etc ?)

I found a way to disable these problems, in:
engine/zoom.cpp:

bool Zoom::haveSSE2()
{
<snip>
//   return (CPUInfo[3] & 0x04000000) ? true : false;
   return false;
}


Quite interesting ! ;)

3
When surface is set to 32 bits, bpp=32 the following method and code below fails on windows 7 home edition, x64 os:

inline void* NewAligned(int bpp, int width, int height)
{

Code: [Select]

        // of course Windows has to be difficult about this!
buffer = _aligned_malloc(total, 16);
if (!buffer)
{
throw Exception("Failed to allocate surface");
}

It throws some exception.

Why is this alignment necessary ? Is it perhaps an optimization ? (It seems to be related to SSE/Single instruction multiple data ?)

Googling for: sdl aligned buffer

Leads to:

https://wiki.libsdl.org/SDL_SIMDAlloc

Perhaps this is a better method to use ??? Nope: "This function is available since SDL 2.0.10."

4
Zoom::flipWithZoom can run out of memory.

It's the scalers

int Zoom::_zoomSurfaceY(SDL_Surface * src, SDL_Surface * dst, int flipx, int flipy)

down in the code it does this:

   /*
   * Allocate memory for row increments
   */
   if ((sax = (Uint32 *) realloc(sax, (dst->w + 1) * sizeof(Uint32))) == NULL) {
      sax = 0;
      return (-1);
   }
   if ((say = (Uint32 *) realloc(say, (dst->h + 1) * sizeof(Uint32))) == NULL) {
      say = 0;
      //free(sax);
      return (-1);
   }

I find this kind of weird and sloppy. Personally I would move this code out of there and to a special initialization function for these scalers and then call it one time or at least when display is reset, so that the memory allocation is more near each other, and not somewhere in a scaler function. 

This makes it easier for the programmer to understand where and why the memory went out of memory... now it feels more like a scalar bug... while in reality it's an out of memory bug. I think out of memory bugs should be handled seperately from "computational" code... (as much as possible)

It's also possible that this scalar code fails to handle bpp=32. (32 bits per pixel).

Perhaps these scalers were only written with 8 bit in mind ? Or it does 32 bit allocation wrong ? Or it's some kind of weird memory alignment problem ?

5
Hello,

My x-com background screen loader/test program loads the x-com palettes, the x-com background palettes and the screens.

I noticed something peculiar, the menu on the geoscape seems to use different colors than from background palette. So these colors seem to be coming from somewhere else but where ? (I check the original in dos-box-x and also openXcom, both dos-bos-x+original and OpenXcom have a lighter blue menu, than my background screen loader...)

A screenshot below will clearify what I am writing about.

The left side is of my background screen loader test program, and the right side is dos-box-x, openXcom also looks like this.




6
Recycle Bin / 4K Monitor and 10 bit per color component version.
« on: June 01, 2022, 08:50:08 pm »
It would be cool if OpenXcom can be made suited to play on a 4K monitor and even cooler: 10 bit color per R,G,B.

Theoretically it should be possible to scale the colors up towards 10 bit per R,G,B :)

Has anyone already played OpenXcom on a 4 K monitor ? 3840x2160 if I recall the res correctly ?

7
I just noticed the conversion from 0..63 to 0..255 is not perfect.

   for (int i = 0; i < _count && palFile.read((char*)value, 3); ++i)
   {
      // Correct X-Com colors to RGB colors
      _colors.r = value[0] * 4;
      _colors.g = value[1] * 4;
      _colors.b = value[2] * 4;
      _colors.unused = 255;
   }
   _colors[0].unused = 0;

Assuming the original/input palette range is indeed 0..63 then this gives:

63 * 4 = 252

So that means the brighest setting 63 is not using the brighest 255.

To correct this floating point calculation would have to be used with a little bit more exact conversion value.

The conversion value would be:

255 / 63 = 4,047619047619047619047619047619

Anyway, is there a reason why this conversion value is not used ? Is there any adventage of reason to limit it to 0..252 ?

(Perhaps OpenXcom is a little bit darker than the original because of this... not sure...)

(Reminds me of call of duty 4 modern warfare, when changing the gamma value the color range would be limited to 0..232 or something similiar and the developers never noticed it lol... I did tell somebody... I discovered because of a video codec experiments... and simply calculating something resembling a "histogram" over call of duty test images/screenshots).

Now I am going to test this "proper conversion" idea out, to see if I can notice any differences, maybe I make two nice screenshots to compare versions...

Interesting link, explaining some possible conversion formulas:

https://moddingwiki.shikadi.net/wiki/VGA_Palette

I don't believe this part though:

"Performing the multiplication before the division removes the need to use floating point numbers and minimises any rounding errors. "

Easy example:

62 * 255 / 63 = 15810 / 63 = 250,95238095238095238095238095238

I am pretty sure that an integer division would round this down to 250 which is not what I would want because it's closer to 251 ?!?

Would rounding the nearest be bad ? and creating a shift in the palette ? I am not so sure...

8
Recycle Bin / Graphics flow/pipeline.
« on: June 01, 2022, 12:18:13 am »
I could really use a description of/about the graphics pipeline/flow in this game/computer program.

It's kinda hard to see/understand because of "states" and "lists" and all kinds of classes doing all kinds of different things. It's also kinda hard to understand the main structure of this program.

So far from what I can tell, there is this main.cpp and maybe some game loop somewhere where it handles input from keyboard/mouse and then it passes this on to some kind of "state" that is active. It seems to cycle through some list of "states" that might be active/in the list... and then it executes a few of those. This kinda makes it hard to debug, also because it needs to load data first... setting breakpoints is a possibility ofcourse, but first I need to know where to set breakpoints and that is the part that I am struggling with and that is where I could use some kind of description or visual aid of the "graphics pipeline".

In other words what I want to know is:

1. What surface draws on what ? Maybe this is overkill, but what I really want to know is:

2. Which part of the program is responsible for "scaling" the 320x200 to 1600x900.  Depending on some kind of option setting. Perhaps I can search for options since it might be processed/look at somewhere in this scaling code. Depending on "original" or "2x original" or something. Ofcourse I need to find the correct setting because there are also a shitload of filters possible hehe... lot's of SSE code and all kinds of SDL code and ARM code and x86 code and god knows what else so I hope you can see that all these different codes it kinda makes it hard to see which code path is actually followed. Hmmmmmmm...... maybe time to split up this code base into different branches, for opengl/arm/android etc... instead of slamming it all together. Ofcourse I know/understand you want to keep it together to keep it nice and consistent/updated, but it does make analysis a whole lot harder and more confusing...

Thus shining some light on this with some documention or chart... how the "graphics" flow through the game... perhaps even from "load time" and "load functions"...  to surfaces...  then maybe from surfaces to some main surface or map surface and the maybe onto some zoom surface ??? and then onto screen surface and maybe finally onto window surface ????

I need to know this information to understand where to "hack" into the 8 bit color code path and convert some of it into 32 bit code path.... and I kinda want to try and benefit from zooming, want to try and keep that capability.

Plus surfaces and zooming also seems to be associated/restricted/intertwined with cropping code and clipping code and what not.

So if some clipping or cropping information could also be provided in this graphics flow analysis/pipeline info that be great.....

I am trying to "UNDERSTAND IT" with the special tool:

https://www.youtube.com/watch?v=RZc298i_UzE


9
Recycle Bin / Map needs to be 32 bit (and window 32 bit)
« on: May 30, 2022, 11:54:09 pm »
For my color experiments I need map to be 32 bit surface and ofcourse window/screen also 32 bit.

I tried all kinds of methods, but nothing is really working so far.

If one of you guys can make this that would be great.

Currently it's just too complex to get done by me.

I will keep trying, however here is an example of a git merge:
Code: [Select]
Build started...
1>------ Build started: Project: OpenXcom, Configuration: Debug Win32 ------
1>Build started 30-5-2022 22:48:59.
1>Target InitializeBuildStatus:
1>  Touching "E:\SourceCode\OpenXCom\TryMerge\src\..\obj\Win32\Debug\OpenXcom.tlog\unsuccessfulbuild".
1>Target VcpkgTripletSelection:
1>  Using triplet "x86-windows" from "E:\SourceCode\vcpkg\scripts\buildsystems\msbuild\..\..\..\installed\x86-windows\"
1>Target ClCompile:
1>  Map.cpp
1>  PathfindingOpenSet.cpp
1>  PrimeGrenadeState.cpp
1>  Projectile.cpp
1>  ProjectileFlyBState.cpp
1>  PromotionsState.cpp
1>  PsiAttackBState.cpp
1>  ScannerState.cpp
1>  ScannerView.cpp
1>  TileEngine.cpp
1>  UnitDieBState.cpp
1>  UnitFallBState.cpp
1>  UnitInfoState.cpp
1>  UnitPanicBState.cpp
1>  UnitSprite.cpp
1>  E:\SourceCode\OpenXCom\TryMerge\src\Engine\ShaderDrawHelper.h(216,42): error C2065: 'Pixel': undeclared identifier (compiling source file Battlescape\UnitSprite.cpp)
1>  E:\SourceCode\OpenXCom\TryMerge\src\Engine\ShaderDrawHelper.h(216,29): error C2923: 'OpenXcom::helper::CorrectConst': 'Pixel' is not a valid template type argument for parameter 'Pixel' (compiling source file Battlescape\UnitSprite.cpp)
1>  E:\SourceCode\OpenXCom\TryMerge\src\Engine\ShaderDrawHelper.h(216): message : see declaration of 'Pixel' (compiling source file Battlescape\UnitSprite.cpp)
1>  E:\SourceCode\OpenXCom\TryMerge\src\Engine\ShaderDrawHelper.h(216,50): error C2955: 'OpenXcom::helper::CorrectConst': use of class template requires template argument list (compiling source file Battlescape\UnitSprite.cpp)
1>  E:\SourceCode\OpenXCom\TryMerge\src\Engine\ShaderDrawHelper.h(59): message : see declaration of 'OpenXcom::helper::CorrectConst' (compiling source file Battlescape\UnitSprite.cpp)
1>  E:\SourceCode\OpenXCom\TryMerge\src\Engine\ShaderDrawHelper.h(222,55): error C2065: 'Pixel': undeclared identifier (compiling source file Battlescape\UnitSprite.cpp)
1>  E:\SourceCode\OpenXCom\TryMerge\src\Battlescape\UnitSprite.cpp(120,4): error C2065: 'dest': undeclared identifier
1>  E:\SourceCode\OpenXCom\TryMerge\src\Battlescape\UnitSprite.cpp(121,4): error C2562: 'OpenXcom::`anonymous-namespace'::ColorReplace::func': 'void' function returning a value
1>  E:\SourceCode\OpenXCom\TryMerge\src\Battlescape\UnitSprite.cpp(115): message : see declaration of 'OpenXcom::`anonymous-namespace'::ColorReplace::func'
1>  E:\SourceCode\OpenXCom\TryMerge\src\Battlescape\UnitSprite.cpp(125,4): error C2562: 'OpenXcom::`anonymous-namespace'::ColorReplace::func': 'void' function returning a value
1>  E:\SourceCode\OpenXCom\TryMerge\src\Battlescape\UnitSprite.cpp(115): message : see declaration of 'OpenXcom::`anonymous-namespace'::ColorReplace::func'
1>  E:\SourceCode\OpenXCom\TryMerge\src\Battlescape\UnitSprite.cpp(135,9): error C3861: 'loop': identifier not found
1>  E:\SourceCode\OpenXCom\TryMerge\src\Battlescape\UnitSprite.cpp(316,24): error C2653: 'ColorFace': is not a class or namespace name
1>  E:\SourceCode\OpenXCom\TryMerge\src\Battlescape\UnitSprite.cpp(316,35): error C2065: 'Face': undeclared identifier
1>  E:\SourceCode\OpenXCom\TryMerge\src\Battlescape\UnitSprite.cpp(317,24): error C2653: 'ColorFace': is not a class or namespace name
1>  E:\SourceCode\OpenXCom\TryMerge\src\Battlescape\UnitSprite.cpp(317,35): error C2065: 'Hair': undeclared identifier
1>  E:\SourceCode\OpenXCom\TryMerge\src\Battlescape\UnitSprite.cpp(334,16): error C2065: 'ColorFace': undeclared identifier
1>  E:\SourceCode\OpenXCom\TryMerge\src\Battlescape\UnitSprite.cpp(334,5): error C2672: 'ShaderDraw': no matching overloaded function found
1>  E:\SourceCode\OpenXCom\TryMerge\src\Battlescape\UnitSprite.cpp(334,99): error C2974: 'OpenXcom::ShaderDraw': invalid template argument for 'ColorFunc', type expected
1>  E:\SourceCode\OpenXCom\TryMerge\src\Engine\ShaderDraw.h(454): message : see declaration of 'OpenXcom::ShaderDraw'
1>  E:\SourceCode\OpenXCom\TryMerge\src\Battlescape\UnitSprite.cpp(623,18): error C2601: 'OpenXcom::UnitSprite::drawRoutine1': local function definitions are illegal
1>  E:\SourceCode\OpenXCom\TryMerge\src\Battlescape\UnitSprite.cpp(213): message : this line contains a '{' which has not yet been matched
1>  E:\SourceCode\OpenXCom\TryMerge\src\Battlescape\UnitSprite.cpp(782,18): error C2601: 'OpenXcom::UnitSprite::drawRoutine2': local function definitions are illegal
1>  E:\SourceCode\OpenXCom\TryMerge\src\Battlescape\UnitSprite.cpp(213): message : this line contains a '{' which has not yet been matched
1>  E:\SourceCode\OpenXCom\TryMerge\src\Battlescape\UnitSprite.cpp(834,18): error C2601: 'OpenXcom::UnitSprite::drawRoutine3': local function definitions are illegal
1>  E:\SourceCode\OpenXCom\TryMerge\src\Battlescape\UnitSprite.cpp(213): message : this line contains a '{' which has not yet been matched
1>  E:\SourceCode\OpenXCom\TryMerge\src\Battlescape\UnitSprite.cpp(880,18): error C2601: 'OpenXcom::UnitSprite::drawRoutine4': local function definitions are illegal
1>  E:\SourceCode\OpenXCom\TryMerge\src\Battlescape\UnitSprite.cpp(213): message : this line contains a '{' which has not yet been matched
1>  E:\SourceCode\OpenXCom\TryMerge\src\Battlescape\UnitSprite.cpp(1021,18): error C2601: 'OpenXcom::UnitSprite::drawRoutine5': local function definitions are illegal
1>  E:\SourceCode\OpenXCom\TryMerge\src\Battlescape\UnitSprite.cpp(213): message : this line contains a '{' which has not yet been matched
1>  E:\SourceCode\OpenXCom\TryMerge\src\Battlescape\UnitSprite.cpp(1050,18): error C2601: 'OpenXcom::UnitSprite::drawRoutine6': local function definitions are illegal
1>  E:\SourceCode\OpenXCom\TryMerge\src\Battlescape\UnitSprite.cpp(213): message : this line contains a '{' which has not yet been matched
1>  E:\SourceCode\OpenXCom\TryMerge\src\Battlescape\UnitSprite.cpp(1246,18): error C2601: 'OpenXcom::UnitSprite::drawRoutine7': local function definitions are illegal
1>  E:\SourceCode\OpenXCom\TryMerge\src\Battlescape\UnitSprite.cpp(213): message : this line contains a '{' which has not yet been matched
1>  E:\SourceCode\OpenXCom\TryMerge\src\Battlescape\UnitSprite.cpp(1320,18): error C2601: 'OpenXcom::UnitSprite::drawRoutine8': local function definitions are illegal
1>  E:\SourceCode\OpenXCom\TryMerge\src\Battlescape\UnitSprite.cpp(213): message : this line contains a '{' which has not yet been matched
1>  E:\SourceCode\OpenXCom\TryMerge\src\Battlescape\UnitSprite.cpp(1353,18): error C2601: 'OpenXcom::UnitSprite::drawRoutine9': local function definitions are illegal
1>  E:\SourceCode\OpenXCom\TryMerge\src\Battlescape\UnitSprite.cpp(213): message : this line contains a '{' which has not yet been matched
1>  E:\SourceCode\OpenXCom\TryMerge\src\Battlescape\UnitSprite.cpp(1382,18): error C2601: 'OpenXcom::UnitSprite::drawRoutine11': local function definitions are illegal
1>  E:\SourceCode\OpenXCom\TryMerge\src\Battlescape\UnitSprite.cpp(213): message : this line contains a '{' which has not yet been matched
1>  E:\SourceCode\OpenXCom\TryMerge\src\Battlescape\UnitSprite.cpp(1426,18): error C2601: 'OpenXcom::UnitSprite::drawRoutine12': local function definitions are illegal
1>  E:\SourceCode\OpenXCom\TryMerge\src\Battlescape\UnitSprite.cpp(213): message : this line contains a '{' which has not yet been matched
1>  E:\SourceCode\OpenXCom\TryMerge\src\Battlescape\UnitSprite.cpp(1453,18): error C2601: 'OpenXcom::UnitSprite::drawRoutine19': local function definitions are illegal
1>  E:\SourceCode\OpenXCom\TryMerge\src\Battlescape\UnitSprite.cpp(213): message : this line contains a '{' which has not yet been matched
1>  E:\SourceCode\OpenXCom\TryMerge\src\Battlescape\UnitSprite.cpp(1485,18): error C2601: 'OpenXcom::UnitSprite::drawRoutine20': local function definitions are illegal
1>  E:\SourceCode\OpenXCom\TryMerge\src\Battlescape\UnitSprite.cpp(213): message : this line contains a '{' which has not yet been matched
1>  E:\SourceCode\OpenXCom\TryMerge\src\Battlescape\UnitSprite.cpp(1511,18): error C2601: 'OpenXcom::UnitSprite::drawRoutine21': local function definitions are illegal
1>  E:\SourceCode\OpenXCom\TryMerge\src\Battlescape\UnitSprite.cpp(213): message : this line contains a '{' which has not yet been matched
1>  E:\SourceCode\OpenXCom\TryMerge\src\Battlescape\UnitSprite.cpp(1531,18): error C2601: 'OpenXcom::UnitSprite::sortRifles': local function definitions are illegal
1>  E:\SourceCode\OpenXCom\TryMerge\src\Battlescape\UnitSprite.cpp(213): message : this line contains a '{' which has not yet been matched
1>  E:\SourceCode\OpenXCom\TryMerge\src\Battlescape\UnitSprite.cpp(32): fatal error C1075: '{': no matching token found
1>  UnitTurnBState.cpp
1>  UnitWalkBState.cpp
1>  WarningMessage.cpp
1>  Action.cpp
1>  AdlibMusic.cpp
1>  adlplayer.cpp
1>  fmopl.cpp
1>  CatFile.cpp
1>  CrossPlatform.cpp
1>  FastLineClip.cpp
1>  FileMap.cpp
1>  FlcPlayer.cpp
1>  Font.cpp
1>  GMCat.cpp
1>  Game.cpp
1>  InteractiveSurface.cpp
1>  Language.cpp
1>  LanguagePlurality.cpp
1>  LocalizedText.cpp
1>  ModInfo.cpp
1>  Music.cpp
1>  OpenGL.cpp
1>  OptionInfo.cpp
1>  Options.cpp
1>  Palette.cpp
1>  RNG.cpp
1>  hq2x.cpp
1>  hq3x.cpp
1>  hq4x.cpp
1>  init.cpp
1>  scale2x.cpp
1>  scale3x.cpp
1>  scalebit.cpp
1>  xbrz.cpp
1>  Screen.cpp
1>  Sound.cpp
1>  SoundSet.cpp
1>  E:\SourceCode\OpenXCom\TryMerge\src\Engine\ShaderDrawHelper.h(216,42): error C2065: 'Pixel': undeclared identifier (compiling source file Engine\Screen.cpp)
1>  E:\SourceCode\OpenXCom\TryMerge\src\Engine\ShaderDrawHelper.h(216,29): error C2923: 'OpenXcom::helper::CorrectConst': 'Pixel' is not a valid template type argument for parameter 'Pixel' (compiling source file Engine\Screen.cpp)
1>  E:\SourceCode\OpenXCom\TryMerge\src\Engine\ShaderDrawHelper.h(216): message : see declaration of 'Pixel' (compiling source file Engine\Screen.cpp)
1>  E:\SourceCode\OpenXCom\TryMerge\src\Engine\ShaderDrawHelper.h(216,50): error C2955: 'OpenXcom::helper::CorrectConst': use of class template requires template

10
This is what I got so far:

SpecialBlit.h:

Code: [Select]
#pragma once

#include <SDL.h>

int SpecialBlit
(
SDL_Surface *src, SDL_Rect *srcrect,
SDL_Surface *dst, SDL_Rect *dstrect
);

void SpecialGradientTest( SDL_Surface *ParaSurface );

SpecialBlit.cpp

Code copied from SDL and modified:

Code: [Select]
#include "SpecialBlit.h"

// Skybuck: re-use clipping from SDL_UpperBlit

// maybe a custom blitter is possible, but for now it seems a recompile of SDL would be needed.
/** typedef for private surface blitting functions */
// typedef int (*SDL_blit)(struct SDL_Surface *src, SDL_Rect *srcrect,
// struct SDL_Surface *dst, SDL_Rect *dstrect);




/*
 * Set up a blit between two surfaces -- split into three parts:
 * The upper part, SDL_UpperBlit(), performs clipping and rectangle
 * verification.  The lower part is a pointer to a low level
 * accelerated blitting function.
 *
 * These parts are separated out and each used internally by this
 * library in the optimimum places.  They are exported so that if
 * you know exactly what you are doing, you can optimize your code
 * by calling the one(s) you need.
 */
 /*
int SDL_LowerBlit (SDL_Surface *src, SDL_Rect *srcrect,
SDL_Surface *dst, SDL_Rect *dstrect)
{
SDL_blit do_blit;
SDL_Rect hw_srcrect;
SDL_Rect hw_dstrect;

// Check to make sure the blit mapping is valid
if ( (src->map->dst != dst) ||
             (src->map->dst->format_version != src->map->format_version) ) {
if ( SDL_MapSurface(src, dst) < 0 ) {
return(-1);
}
}

// Figure out which blitter to use
if ( (src->flags & SDL_HWACCEL) == SDL_HWACCEL ) {
if ( src == SDL_VideoSurface ) {
hw_srcrect = *srcrect;
hw_srcrect.x += current_video->offset_x;
hw_srcrect.y += current_video->offset_y;
srcrect = &hw_srcrect;
}
if ( dst == SDL_VideoSurface ) {
hw_dstrect = *dstrect;
hw_dstrect.x += current_video->offset_x;
hw_dstrect.y += current_video->offset_y;
dstrect = &hw_dstrect;
}
do_blit = src->map->hw_blit;
} else {
do_blit = src->map->sw_blit;
}
return(do_blit(src, srcrect, dst, dstrect));
}
*/


int SDL_LowerBlitSpecial
(
SDL_Surface *src, SDL_Rect *srcrect,
SDL_Surface *dst, SDL_Rect *dstrect
)
{
int x, y;
int w, h;
int sp, dp;

Uint8 *SrcPointer;
SDL_Color *DstPointer;

Uint8 SrcColor;
SDL_Color DstColor;
// int SrcOffset;
// int DstOffset;
int offset;

w = src->w;
h = src->h;
sp = src->pitch;
dp = dst->pitch;

for (y=0; y<h; y++)
{
for (x=0; x<w; x++)
{
// SrcOffset = y * sp + x;
// DstOffset = y * dp + x * 4;

// pointers below already multiply by data structure width so don't do it in formulas below =D

// SrcOffset = y * w + x;
// DstOffset = y * w + x;
offset = y * w + x;

SrcPointer = (Uint8*) src->pixels;
DstPointer = (SDL_Color*) dst->pixels;

SrcColor = SrcPointer[offset];

if (SrcColor != 0)
{
// test color should be replaced later with palette lookup, I don't think this is the cause of the problems, since width and height seems off.
DstColor.r = SrcColor;
DstColor.g = SrcColor;
DstColor.b = SrcColor;

DstPointer[offset] = DstColor;
}
}
}
return 1;
}

int SpecialBlit
(
SDL_Surface *src, SDL_Rect *srcrect,
SDL_Surface *dst, SDL_Rect *dstrect
)
{
    SDL_Rect fulldst;
int srcx, srcy, w, h;

/* Make sure the surfaces aren't locked */
if ( ! src || ! dst )
{
SDL_SetError("SDL_UpperBlit: passed a NULL surface");
return(-1);
}
if ( src->locked || dst->locked )
{
SDL_SetError("Surfaces must not be locked during blit");
return(-1);
}

/* If the destination rectangle is NULL, use the entire dest surface */
if ( dstrect == NULL )
{
    fulldst.x = fulldst.y = 0;
dstrect = &fulldst;
}

/* clip the source rectangle to the source surface */
if(srcrect)
{
    int maxw, maxh;

srcx = srcrect->x;
w = srcrect->w;
if(srcx < 0)
{
    w += srcx;
dstrect->x -= srcx;
srcx = 0;
}
maxw = src->w - srcx;
if(maxw < w) w = maxw;

srcy = srcrect->y;
h = srcrect->h;
if(srcy < 0)
{
    h += srcy;
dstrect->y -= srcy;
srcy = 0;
}
maxh = src->h - srcy;
if(maxh < h) h = maxh;
   
} else
{
    srcx = srcy = 0;
w = src->w;
h = src->h;
}

/* clip the destination rectangle against the clip rectangle */
{
    SDL_Rect *clip = &dst->clip_rect;
int dx, dy;

dx = clip->x - dstrect->x;
if(dx > 0)
{
w -= dx;
dstrect->x += dx;
srcx += dx;
}
dx = dstrect->x + w - clip->x - clip->w;
if(dx > 0) w -= dx;

dy = clip->y - dstrect->y;
if(dy > 0)
{
h -= dy;
dstrect->y += dy;
srcy += dy;
}
dy = dstrect->y + h - clip->y - clip->h;
if(dy > 0) h -= dy;
}

if(w > 0 && h > 0)
{
    SDL_Rect sr;
    sr.x = srcx;
sr.y = srcy;
sr.w = dstrect->w = w;
sr.h = dstrect->h = h;
return SDL_LowerBlitSpecial(src, &sr, dst, dstrect);
}
dstrect->w = dstrect->h = 0;
return 0;
}


void SpecialGradientTest( SDL_Surface *ParaSurface )
{
int x, y;
int w, h, p, b;
int offset;
SDL_Color color;
SDL_Color *pointer;

h = ParaSurface->h;
w = ParaSurface->w;
p = ParaSurface->pitch;
b = ParaSurface->format->BytesPerPixel;
pointer = (SDL_Color*)(ParaSurface->pixels);

SDL_LockSurface( ParaSurface );

for (y=0; y<h; y++)
{
for (x=0; x<w; x++)
{
offset = y * w + x;

color.r = x & 255;
color.b = y & 255;
color.g = 0;

pointer[offset] = color;

// pointer = (SDL_Color *)ParaSurface->pixels + (y * ParaSurface->pitch + x * ParaSurface->format->BytesPerPixel);
// *pointer = color;
}
}

    SDL_UnlockSurface( ParaSurface );
}

Trying to get OpenXcom surface to convert from 8 to 32 bit when it's encountered:

Code: [Select]
/**
 * Blits this surface onto another one, with its position
 * relative to the top-left corner of the target surface.
 * The cropping rectangle controls the portion of the surface
 * that is blitted.
 * @param surface Pointer to surface to blit onto.
 */
void Surface::blit(Surface *surface)
{
SDL_Surface *SrcSurface;
SDL_Surface *DstSurface;
SDL_Surface *ConvertedSurface;

if (_visible && !_hidden)
{
if (_redraw)
draw();

SDL_Rect* cropper;
SDL_Rect target;
if (_crop.w == 0 && _crop.h == 0)
{
cropper = 0;
}
else
{
cropper = &_crop;
}
target.x = getX();
target.y = getY();

SrcSurface = _surface;
DstSurface = surface->getSurface();

if
(
(SrcSurface->format->BitsPerPixel == 8) &&
(DstSurface->format->BitsPerPixel == 32)
)
{
// do something special
SpecialBlit(_surface, cropper, surface->getSurface(), &target);
} else
{
// assume 8 bits to 8 bits.
SDL_BlitSurface(_surface, cropper, surface->getSurface(), &target);
}
}
}

Tell OpenXcom to use 32 bit surface.

Code: [Select]
void Screen::resetDisplay(bool resetVideo)
{
int width = Options::displayWidth;
int height = Options::displayHeight;
#ifdef __linux__
Uint32 oldFlags = _flags;
#endif
makeVideoFlags();

if (!_surface || (_surface->getSurface()->format->BitsPerPixel != _bpp ||
_surface->getSurface()->w != _baseWidth ||
_surface->getSurface()->h != _baseHeight)) // don't reallocate _surface if not necessary, it's a waste of CPU cycles
{
if (_surface) delete _surface;
// _surface = new Surface(_baseWidth, _baseHeight, 0, 0, Screen::use32bitScaler() ? 32 : 8); // only HQX/XBRZ needs 32bpp for this surface; the OpenGL class has its own 32bpp buffer
_surface = new Surface(_baseWidth, _baseHeight, 0, 0, 32); // only HQX/XBRZ needs 32bpp for this surface; the OpenGL class has its own 32bpp buffer
if (_surface->getSurface()->format->BitsPerPixel == 8) _surface->setPalette(deferredPalette);
}

11
Code: [Select]
void SpecialGradientTest( SDL_Surface *ParaSurface )
{
int x, y;
int w, h, p, b;
int offset;
SDL_Color color;
SDL_Color *pointer;

h = ParaSurface->h;
w = ParaSurface->w;
p = ParaSurface->pitch;
b = ParaSurface->format->BytesPerPixel;
pointer = (SDL_Color*)(ParaSurface->pixels);


for (y=0; y<h; y++)
{
for (x=0; x<w; x++)
{
offset = y * p + x * b;

color.r = x & 255;
color.b = y & 255;
color.g = 0;

pointer[offset] = color;

// pointer = (SDL_Color *)ParaSurface->pixels + (y * ParaSurface->pitch + x * ParaSurface->format->BytesPerPixel);
// *pointer = color;
}
}
}

Quote
*/
void Screen::flip()
{
   if (getWidth() != _baseWidth || getHeight() != _baseHeight || useOpenGL())
   {
      Zoom::flipWithZoom(_surface->getSurface(), _screen, _topBlackBand, _bottomBlackBand, _leftBlackBand, _rightBlackBand, &glOutput);
   }
   else
   {
//      _surface->lock();
//      SpecialGradientTest( _surface->getSurface() );
//      _surface->unlock();

      SDL_BlitSurface(_surface->getSurface(), 0, _screen, 0);
      SpecialGradientTest( _screen );
   }

^ Tried two different things...

Producing access violations ? Why ? both surfaces are set to 32 bits per pixel it shows during debugging...

This code sets it to 32 bits:

Code: [Select]

void Screen::resetDisplay(bool resetVideo)
{
int width = Options::displayWidth;
int height = Options::displayHeight;
#ifdef __linux__
Uint32 oldFlags = _flags;
#endif
makeVideoFlags();

if (!_surface || (_surface->getSurface()->format->BitsPerPixel != _bpp ||
_surface->getSurface()->w != _baseWidth ||
_surface->getSurface()->h != _baseHeight)) // don't reallocate _surface if not necessary, it's a waste of CPU cycles
{
if (_surface) delete _surface;
// _surface = new Surface(_baseWidth, _baseHeight, 0, 0, Screen::use32bitScaler() ? 32 : 8); // only HQX/XBRZ needs 32bpp for this surface; the OpenGL class has its own 32bpp buffer
_surface = new Surface(_baseWidth, _baseHeight, 0, 0, 32); // only HQX/XBRZ needs 32bpp for this surface; the OpenGL class has its own 32bpp buffer

12
Recycle Bin / OpenXcom / github palette folders ?
« on: May 30, 2022, 03:37:25 pm »
https://github.com/MeridianOXC/OpenXcom/tree/oxce-plus/bin/common/Palettes

What is the difference between these folders and what are their purpose ?

UFO-ACT-SAFE
UFO-JASC-SAFE
UFO-JASC
UFO-RIFF-SAFE

(I tried one of the battlescape palettes, forgot which one, probably act-safe. I noticed the first color is set to green, which looks out of whack, seems more like it should be white, but now I understand it was set to green to indicate this is the transparent color. However it could be set to any color because it will be not drawn anyway. (For my purposes, interpolation/extrapolation white seems better, was green actually set by OpenXcom programmer, or did original ufo palette actually set it to a different color ?))

13
Recycle Bin / NEW PLAN: MINI X-COM
« on: May 23, 2022, 07:08:01 pm »
Monday 23 may 2022:

*** Last update: Sunday 5 june 2022 ***
*** Latest miniXcom branch: ***
https://github.com/SkybuckFlying/OpenXcom/tree/miniXcomV2


AFTER THINKING ABOUT ALL THE PROBLEMS THAT I ENCOUNTERED WITH VISUAL STUDIO 2019 AND X-COM I HAVE COME TO THE FOLLOWING NEW PLAN:

MINI X-COM !!!!!!!!!!!!!!!

ALL THAT GARBAGE I DON'T NEED GOING TO BE RIPPED OUT OF IT:

1. GEOSCAPE
2. UFOPEDIA
3. BASESCAPE (not to be confused with BATTLEscape)

AND OTHER CRAP.

IT'S GOING TO BE FOCUSED ON BATTLESCAPE ONLY, SO THAT I CAN WORK ON MY SHADING/LIGHT CASTING BETTER.

AND ONCE THAT IS DONE IT CAN BE RE-INTEGRATED INTO THE BIGGER OPEN-XCOM.

SUCCESS, geoscape, basescape and ufopaedia deleted and game/battlescape still working ! =D

This means 18% of the source code is "cut" away, thus lowering compile time.

github branch
https://github.com/SkybuckFlying/OpenXcom/tree/miniXcom

video:
https://www.youtube.com/watch?v=tqd2vUYe5-Y

14
https://github.com/MeridianOXC/OpenXcom/blob/oxce-plus/src/Battlescape/Map.cpp

1>  E:\SourceCode\OpenXComExtended\PBRT\src\Battlescape\Map.cpp(606,71): warning C4804: '-': unsafe use of type 'bool' in operation

   bool unitFromBelow = false;
   bool unitFromAbove = false;

_camera->convertMapToScreen(unitTile->getPosition() + Position(0,0, (-unitFromBelow) + (+unitFromAbove)), &tileScreenPosition);

I am not sure what the intent of this code is but it's suspect ! =D

negating a booleang is suspect... perhaps use !unitFromBelow ? perhaps code thinks these are integers ?

15
The following two header files are causing a build/compile conflict:

OpenXcom Extended Plus and vanilla OpenXcom engine/logger.h:
https://github.com/MeridianOXC/OpenXcom/blob/oxce-plus/src/Engine/Logger.h

PBRT/util/log.h:
https://github.com/mmp/pbrt-v4/blob/master/src/pbrt/util/log.h

OpenXcom declares/defines a Log macro as follows:

#define Log(level) if (level > Logger::reportingLevel()) { } else Logger().get(level)

However it seems this "macro" is not "confined" to the OpenXcom namespace so it is visible outside of it's name space which is leading to a conflict inside PBRT/util/log.h:

Where a function with the name Log is declared inside a namespace called pbrt
namespace pbrt {

// Logging Function Declarations
PBRT_CPU_GPU
void Log(LogLevel level, const char *file, int line, const char *s);

}

So PBRT is following the official C/C++ language standard. While Macros are not officially part of the C++ language.

Also somebody on stack overflow writes: "No, the preprocessor doesn't care about namespaces at all. ":
https://stackoverflow.com/questions/11791187/is-it-possible-to-place-a-macro-in-a-namespace-in-c

So I blame this conflict on OpenXcom source code base and therefore I am requesting that this gets fixed to prevent conflicts with PBRT and possibly any other library that defines it's own log funtion.

I think the easiest fix would be to replace this define/macro with a function called: Log.

(What would be the side effects ? Maybe slower code because of function being called ?)

This seems to work:

// Skybuck: macro disabled, macros cannot be part of namespaces, this is causing conflict with PBRT/util/log.h Log function inside pbrt namespace.

// #define Log(level) if (level > Logger::reportingLevel()) { } else Logger().get(level)

std::ostringstream& Log( SeverityLevel level )
{
   if (level > Logger::reportingLevel())
   {

   }
   else
   {
      return Logger().get(level);
   }
}

Testing it, gives following warning message:

1>    E:\SourceCode\OpenXComExtended\PBRT\src\Engine\Logger.h(83): warning C4715: 'OpenXcom::Log': not all control paths return a value


*** New Version, which does return an output stream but disables it if it does not match the level requirements, enables it if it does match the level requirements ***:

std::ostringstream& Log( SeverityLevel level )
{
   std::ostringstream& vOutputStream = Logger().get(level);

   if (level > Logger::reportingLevel())
   {
      vOutputStream.setstate( std::ostringstream::failbit );
   }
   else
   {
      vOutputStream.clear();
   }

   return vOutputStream;
}

Testing it now...

Produces errors, which can be surpressed with /FORCE:MULTIPLE

1>Target Link:
1>  BasescapeState.obj : error LNK2005: "class std::basic_ostringstream<char,struct std::char_traits<char>,class std::allocator<char> > & __cdecl OpenXcom::Log(enum OpenXcom::SeverityLevel)" (?Log@OpenXcom@@YAAAV?$basic_ostringstream@DU?$char_traits@D@std@@V?$allocator@D@2@@std@@W4SeverityLevel@1@@Z) already defined in BaseInfoState.obj
1>  BaseView.obj : error LNK2005: "class std::basic_ostringstream<char,struct std::char_traits<char>,class std::allocator<char> > & __cdecl OpenXcom::Log(enum OpenXcom::SeverityLevel)" (?Log@OpenXcom@@YAAAV?$basic_ostringstream@DU?$char_traits@D@std@@V?$allocator@D@2@@std@@W4SeverityLevel@1@@Z) already defined in BaseInfoState.obj
1>  BuildFacilitiesState.obj : error LNK2005: "class std::basic_ostringstream<char,struct std::char_traits<char>,class std::allocator<char> > & __cdecl OpenXcom::Log(enum OpenXcom::SeverityLevel)" (?Log@OpenXcom@@YAAAV?$basic_ostringstream@DU?$char_traits@D@std@@V?$allocator@D@2@@std@@W4SeverityLevel@1@@Z) already defined in BaseInfoState.obj
1>  CraftArmorState.obj : error LNK2005: "class std::basic_ostringstream<char,struct std::char_traits<char>,class std::allocator<char> > & __cdecl OpenXcom::Log(enum OpenXcom::SeverityLevel)" (?Log@OpenXcom@@YAAAV?$basic_ostringstream@DU?$char_traits@D@std@@V?$allocator@D@2@@std@@W4SeverityLevel@1@@Z) already defined in BaseInfoState.obj
1>  CraftEquipmentLoadState.obj : error LNK2005: "class std::basic_ostringstream<char,struct std::char_traits<char>,class std::allocator<char> > & __cdecl OpenXcom::Log(enum OpenXcom::SeverityLevel)" (?Log@OpenXcom@@YAAAV?$basic_ostringstream@DU?$char_traits@D@std@@V?$allocator@D@2@@std@@W4SeverityLevel@1@@Z) already defined in BaseInfoState.obj
1>  CraftEquipmentSaveState.obj : error LNK2005: "class std::basic_ostringstream<char,struct std::char_traits<char>,class std::allocator<char> > & __cdecl OpenXcom::Log(enum OpenXcom::SeverityLevel)" (?Log@OpenXcom@@YAAAV?$basic_ostringstream@DU?$char_traits@D@std@@V?$allocator@D@2@@std@@W4SeverityLevel@1@@Z) already defined in BaseInfoState.obj
1>  CraftEquipmentState.obj : error LNK2005: "class std::basic_ostringstream<char,struct std::char_traits<char>,class std::allocator<char> > & __cdecl OpenXcom::Log(enum OpenXcom::SeverityLevel)" (?Log@OpenXcom@@YAAAV?$basic_ostringstream@DU?$char_traits@D@std@@V?$allocator@D@2@@std@@W4SeverityLevel@1@@Z) already defined in BaseInfoState.obj
1>  CraftInfoState.obj : error LNK2005: "class std::basic_ostringstream<char,struct std::char_traits<char>,class std::allocator<char> > & __cdecl OpenXcom::Log(enum OpenXcom::SeverityLevel)" (?Log@OpenXcom@@YAAAV?$basic_ostringstream@DU?$char_traits@D@std@@V?$allocator@D@2@@std@@W4SeverityLevel@1@@Z) already defined in BaseInfoState.obj
1>  CraftPilotSe

If surpressed still produces many warnings.

Any idea how to fix this better ?

*** New Fix, replace Log with XComLog ***:

Though some Log funtion was replaced, which ig logarithm or something in battlescape, macros are risky ?! (No vs thinks it's Log from PBRT hmm..
 hopefully just intellisense problem)

1>  E:\SourceCode\OpenXComExtended\PBRT\src\Battlescape\BattlescapeState.cpp(3057,17): error C2059: syntax error: 'if'
1>  E:\SourceCode\OpenXComExtended\PBRT\src\Battlescape\BattlescapeState.cpp(3057,17): error C2143: syntax error: missing ';' before '{'
1>  E:\SourceCode\OpenXComExtended\PBRT\src\Battlescape\BattlescapeState.cpp(3057,17): error C2143: syntax error: missing ')' before ';'
1>  E:\SourceCode\OpenXComExtended\PBRT\src\Battlescape\BattlescapeState.cpp(3057,17): error C2181: illegal else without matching if
1>  E:\SourceCode\OpenXComExtended\PBRT\src\Battlescape\BattlescapeState.cpp(3057,17): error C2664: 'std::ostringstream &OpenXcom::Logger::get(OpenXcom::SeverityLevel)': cannot convert argument 1 from 'double' to 'OpenXcom::SeverityLevel'
1>  E:\SourceCode\OpenXComExtended\PBRT\src\Battlescape\BattlescapeState.cpp(3057,17): message : This conversion requires an explicit cast (static_cast, C-style cast or function-style cast)
1>  E:\SourceCode\OpenXComExtended\PBRT\src\Engine\Logger.h(53,22): message : see declaration of 'OpenXcom::Logger::get' (compiling source file Battlescape\BattlescapeState.cpp)
1>  E:\SourceCode\OpenXComExtended\PBRT\src\Battlescape\BattlescapeState.cpp(3057,17): error C2059: syntax error: ')'
1>  E:\SourceCode\OpenXComExtended\PBRT\src\Battlescape\BattlescapeState.cpp(3057,35): error C2059: syntax error: ')'

Pages: [1] 2 3 ... 5