aliens

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.


Messages - Skybuck

Pages: [1] 2 3 ... 15
1
Help / Re: Strike Carrier Mod
« on: February 23, 2023, 01:14:11 pm »
Great find nooblord !

Thouse the "cruiser" looks a bit boring in some parts, in other parts it looks a bit interesting like the plane section. The front is also interesting with the waves and water splashes.

However to be a true carrier, it needs the icon "chimneys" and "bridge" towards like the lexington carrier and midway carriers had:

Example:

https://en.wikipedia.org/wiki/USS_Lexington_(CV-2)

https://en.wikipedia.org/wiki/Midway-class_aircraft_carrier

Unsure how their internal layouts/corridors would be.

The "deck" seems simple enough to make/model :) just a run way for planes will do ! =D perhaps some white lines on it to "guide the planes" ;)

Some further equipment on the deck would be cool... maybe a mechanical weight lifter of some kind... or some bombs or missiles lieing around... or some humans walking around... perhaps even crashed/destroy plane could be cool... some flames from the attack =D some burning oil or so slowly creeping across the deck lol...

Perhaps human with fire extingisher trying to put out the water, mysteriously surviving the aliens, perhaps later turns into an alien as a nice little nasty surprise ! =D

The internal corridors should probably be make out of steel, perhaps exist ufo tiles/icons could be used for that for now... though new ones would be a bit more cool, maybe with ribbons in em to hold it all together.

There should definetly be some computers in there as well, even though they might have not existed back then or secret computers, maybe old school computers or other electronics these could be re-used from the base invasion tiles/graphics/sprites.

Some beds could also be re-used... the kitchen from houses could also be re-used...

Perhaps chair sprites from ufos for command bridge and such... so this already goes a long way to building it with already made graphics.

Once down, maybe "re-touch" the graphics/sprites to make them look slightly different and fitting... and voila ! ;) =D

Some white bird shit here and there might also be funny, maybe the carrier wasn't "washed" in a few days since the attack ! =D

Maybe birds eating human eye balls to add some horror elements to it all ! HAHA.

To finish it and put the cherry on top, there should be some radars or antennas on top of the bridge or so... like a communication device, that's cool.

Maybe some "sea sounds" for ambience... maybe even some "morse code" sounds sounding out S.O.S. signals ! ;) =D and perhaps other secret morse code messages for the attentive listener ! ;) =D perhaps some sea birds squeeking from time and time, maybe even one or two times loud in the speakers to scare the shit out of x-com soldiers as long as they are on deck on the sea...

Maybe even a flying bird sprite ! HAHA.

Maybe even a sea-dog, on top of the deck, mysteriously, how he got on ? ;) Play tricks with the mind ! =D

A curious whale could even pop-up in front or next to the vessel... perhaps even shooting some water into the air... perhaps even some whale sounds in the music ambience or sound effects, to make it a bit more creepy from time to time ! ;)

Perhaps some metal bonking against the ship, or metal creeking to make it a bit more creepy still ! ;)

Perhaps the occasional metal door slamming ! As aliens sneak around the ship ! ;)

Perhaps some metal fighting sound as the last defending human inside the carrier is killed of by the alien horde/invasion ! Screaming in death/agony as he perishes...

Maybe to make it not too depressing... he was just hurt... bleeding out.... allowing the x-com to find him... only to then dieeeeeeeeeeeeeee....

Forever his appereance, struggle and sacrifice and loss will remain in our memories... foreverrrrrrr...... wondering what would happened to him if we had reach him just a few moments sooner.... ooefff....

Perhaps we can return a "love" message for his wife... could be part of the objective... "retrieval his mail" from the computer system, to download it and return it to his wife and children......... plus additional camera security footage of what went down there in the ship..

The captain's body mysteriously disappeared... possibly a high ranking admiral... abductee for further interrogation by the Aliens.

A follow up mission may have to occur to save him and extract him from the Aliens before he gives in to the horrors of Alien interrogation and torture...

Failing to extract the admiral on time may lead to the Aliens learning the where abouts of X-Com's underwater BASE ! and subsequent alien invasion will take place !

2
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.



3
Programming / Re: I've made some improvements to XCom - anyone interested?
« on: December 16, 2022, 06:28:26 am »
The path to success was messy and lots of crap posted, but here is a short summation:

The path to success was as follows:

1. Determine the date on which NachaZ's code was based.
2. Find the commit hash id in OpenXCom commit log which closely matched this date.
3. Check which code changes were present and which cod echanges were not present in NachaZ's code to fixate on the correct commit hash id.
4. Create a branch based on this commit hash id.
5. Create a worktree for this branch.
6. Extract and overwrite all files on this worktree with NachaZ's patch/full source code/all files.
7. Commit these changes.
8. Add a new branch/tag name for this NachaZ modification.
9. Rebase this branch onto OpenXCom master.
10. Copy over earlier commit comments for NachaZ.

Other things I did even before these steps:
-2. Tried to apply his patch file, but it was incomplete, the full source code contains much more changes and new files and new code.
-1. Create a special branch and copied NachaZ code there to do a simply git diff. Easier than trying to compare git with a folder which complained that it was outside of repository hard to do... used this as an initial investigation to investigate NachaZ
11. Clean this older investigatory branches by deleting them =D

Now building a release version and then more testing and finally a re-upload to my webdrive, and also re-upload to github.
I will simply attach an additional branch to it called NachaZ so earlier links will remaining functioning and that there is some kind of final branch for NachaZ which is this shorter one ! ;)

OK, old NachaZ branch deleted and new NachaZ branch uploaded onto github, LOOKING PRETTY GOOD if I say so myself (my shitty code is not visible in the commit, thank god ! LOL =D):

https://github.com/SkybuckFlying/OpenXcom/tree/NachaZ

I share this with you pre-testing cause I feel pretty confident about it ! WIEEEE ! =D

Release build went fine as well... going to test it now...

I also upload the other tags, like NachaZBase, NachaZReBase and NachaZModificationsOnCorrectBase and finally NachaZRebased to show how it was done, might be usefull in future if any more changes come in ! ;) =D Or maybe might need to make new bases if he bases his future changes on new master base =D

OH SHIT... UNFORTUNATELY THIS "FULL NACHAZ VERSION" SEEMS TO CRASH WHEN THE POP-UP WINDOW IS SUPPOSED TO OCCUR.

HAHAHAHAHA NOW I DELETED THE OTHER BRANCH WHICH KINDA DID WORK SOMEWHAT BUT NOT THAT USEFULL ANYWAY...

Anyway I will let the original executable remain on my server, but I will also upload this new one under OpenXComNachaZFullPossiblyCrashes.exe

Yup tested again as follows:

1. Fight the aliens, wait till soldier is wounded, go back to skyranger, abort mission, look at wounded status, 8 days, skip rest 8 days until time passes, BAM CRASH.

Maybe in future I might debug it, but I am kinda done with it, somebody else may have to debug it... kinda strange !  I have no time for it at the moment I want to spent time on other projects for now, but at least I got you a whole end ! ;) =D

I was just about to abadon it but I did notice something in visual studio... strlen access violation/crash... maybe it's string related... not sure if mods are loaded... done for now.

Maybe it will work sometime, maybe if mods disabled I don't know, but then you can test it yourself.

Well I did my best for now.

NachaZ binary/executable versions will be available here:

http://www.skybuck.org/Games/OpenXCom/

One more time the NachaZ source code, rebased on current master/16-12-2022:

https://github.com/SkybuckFlying/OpenXcom/tree/NachaZ

CU LATER.

4
Programming / Re: I've made some improvements to XCom - anyone interested?
« on: December 16, 2022, 06:09:22 am »
Amazing I can already tell this one works much better for example the kilogram is actually showing in the UFOPedia ! FANTASTIC/MOST INTERESTING ! =D

Testing will commence right now, and after this I will clean everything up, delete some branches... and just get it over with otherwise to much branch and worktree pollution lol.

I don't care too much how I get there... I will leave some branches in like NachaZBase and NachaZModification and NachaZReBase and that will be it.

The other less good version will be removed/deleted... but first testing ! ;)

Stangely enough I heard no music, maybe NachaZ disabled music in his config or maybe my game config is being used... I don't know... this open source game solution confuses me in that regards lol, hard to tell where stuff/loads is coming from =D :P*

I also notice a "drag scroll" instead of a move to sides of screen scroll... hmmm gonna change this in this play through I think...

I ran git status, it does not show any changes after I change game settings... so maybe this some kind of open-x-com default settings... not sure.. maybe changes still in memory and not saved to disk ? hmm will find out of this game short play through ! ;)

First I am going to do a release build of this possibly better version so it runs much faster cause otherwise the frame rate is a bit annoying low, like 20 or 18 fps...

5
Programming / Re: I've made some improvements to XCom - anyone interested?
« on: December 16, 2022, 05:12:12 am »
OK,

Now a special branch can be created where most likely NachaZ based his code on:

$ git branch NachaZBase 80864e0d039e60ebba0f57d8b6efe00a88929bb6

This offers some possiblities to apply his source code on such a branch and then attempt a re-base or so onto latest commit of OpenXCom master =D

Then I copied all the source code into this worktree... not necessary to use a worktree but convenient for me maybe... anyway...

Then commited it, then put a branch name on it, like rebasefromhere.

finally switch to that commited rebasefromhere branch and finally executed:

git rebase master

Seemed to work, it was a bit odd, because it illimates some of my strange/shitty code, but the result looks promising... all of NachaZ code re-based onto OpenXCom master...

An alternative might be to use --onto or something but it doesn't seem necessary, thought seeing my strange code in red is a bit strange... I am going to give it a build try and see what happens ! ;)

The re-based code is in folder:

E:\SourceCode\OpenXCom\NachaZReBase


6
Programming / Re: I've made some improvements to XCom - anyone interested?
« on: December 16, 2022, 04:22:17 am »
Hmmmm... I suspect there might be more source code in the actual source code from NachaZ ! ;) =D

So I will try again, this time I copy all his source code to a new worktree so it's easy comparable with a git diff.

(I couldn't get git diff working directly with an outside of the respository folder, so I do it this way...)

Perhaps the best way to apply NachaZ code is maybe his changes rebased on top of latest source code...

But first I inspect further changes... not sure if they all from NachaZ or already in there...

So far seems to be his work.. hmmm...

Rebasing probably not possible cause NachaZ does not have a commit point hehe... I do see some significant changes in his full source code... hmmm...

Interesting to try and build this... or at least incorporate his changes without losing some minor changes in openxcom, not sure which ones that would be.

For now I am going to leave it as is, do a build... and then upload his full source code patch to github... hmmm

It's helpfull to know at what commit NachaZ based his changes, his patch file gives some idea I think:

diff --git a/src/Basescape/BasescapeState.cpp b/src/Basescape/BasescapeState.cpp
index 4de197eb0..e3a4d5c86 100644

Going to try and find this commit point ! ;)

Hmm git a bit sloppy in this multiple of these indexes...

Now it's getting hard... not only cpp files changed but also some other files...

If NachaZ can remember which commit he downloaded from that be helpfull... hmm otherwise manual changes may have to happen or maybe deepgit can be of some help... hmmm. Deepgit should be able to detect which changes are from openxcom developers and which from nachaz ! ;)

This could be a nice example of how git fails to be a good versioning and tracking change system... now it's a big fat mess... hmmm.... no dates, no versions, nada.

However the original extracted files from rar do contain some dates and that could indicate when this patch was made and possible which commit it was so not all is lost ! =D

Making a branch from around that date could solve the problem somewhat and might make a rebase possible ! ;) =D

MS-DOS to the resque:

dir /O:D /s

Most dates seem to be 12-01-2022, so perhaps the files from around that date. Then some changes on 9-02-2022

It's probably one of these commits, but could still be older:

* commit 94640aab1279ae268e0420a7b5c99cc44eb09473
| Author: Deimos715 <32176134+Deimos715@users.noreply.github.com>
| Date:   Sun Jan 9 13:53:35 2022 +0300
|
|     Update URLs to HTTPS
|
|     This PR changes remaining URLs in README.md to HTTPS for security reasons.
|
* commit 80864e0d039e60ebba0f57d8b6efe00a88929bb6 (DirectionalLighting, DirectionLighting)
| Author: Warboy1982 <neo_nihilist@hotmail.com>
| Date:   Tue Dec 21 21:39:06 2021 +1100
|
|     fix for previous fix, accounting for 3d explosions


I notice his urls not updated to https, so probably from before that date... hmmm...

It seems his code does include this somewhat strange 3d explosion fix:

* commit 80864e0d039e60ebba0f57d8b6efe00a88929bb6 (DirectionalLighting, DirectionLighting)
| Author: Warboy1982 <neo_nihilist@hotmail.com>
| Date:   Tue Dec 21 21:39:06 2021 +1100
|
|     fix for previous fix, accounting for 3d explosions


Code seems to re-align some code:

new@new-PC MINGW64 /e/SourceCode/OpenXCom/NachaZFullSourceCode (NachaZFullSourceCode)
$ git diff 51622230eaf7f09a2f6d7295a80006dfd755f4bc 80864e0d039e60ebba0f57d8b6efe00a88929bb6
diff --git a/src/Battlescape/TileEngine.cpp b/src/Battlescape/TileEngine.cpp
index ad0c56202..8e49fed30 100644
--- a/src/Battlescape/TileEngine.cpp
+++ b/src/Battlescape/TileEngine.cpp
@@ -1324,7 +1324,14 @@ void TileEngine::explode(Position center, int power, ItemDamageType type, int ma
                                                                // power 50 - 150%
                                                                if (bu)
                                                                {
-                                                                       if ((abs(dest->getPosition().x - int(centerX)) < 2 && abs(dest->getPosition().y - int(centerY)) < 2) || dest->getPosition().z > int(centerZ))
+                                                                       if (
+                                                                                       (
+                                                                                               abs(dest->getPosition().x - int(centerX)) < 2
+                                                                                               && abs(dest->getPosition().y - int(centerY)) < 2
+                                                                                               && dest->getPosition().z == int(centerZ)
+                                                                                       )
+                                                                                       || dest->getPosition().z > int(centerZ)
+                                                                               )
                                                                        {
                                                                                // ground zero effect is in effect, or unit is above explosion
                                                                                bu->damage(Position(0, 0, 0), (RNG::generate(min, max)), type);

Not sure how this fixes anything hard to tell...

So my best guess is his code was based on 21 december 2021

7
Programming / Re: I've made some improvements to XCom - anyone interested?
« on: December 14, 2022, 11:56:32 pm »
Hellllooooo,

I'm back. I just watched French defeat Morocco in Worldcup 2022 in Quator and I am thrilled, LIBERTY ! :P* =D

Now I'm looking for something to do... as I listen to...

https://fearofdark.bandcamp.com/album/dr-kobushis-labyrinthine-laboratory-original-soundtrack

To relax and wind-down...

I decided to check on OpenXcom status and forum and such and come across this thread. I almost completely forgot about it.

Maybe I did not even notice the attached RAR file or maybe it was added later, strange (of ME ?:)).

Now that I see it, I can work on it. Maybe I was busy back then and didn't have time on it, or maybe I already tried it out, can't remember, but now I will try it out !

git log -graph NachaZ shows no branch yet in my OpenXcom git repository. So I will call it that... the branch that is.

Now I intend to do the following:

1. Update my local OpenXcom master with the latest remote OpenXcom commits just to try and make sure it's nicely update to date and see how it goes.
2. Create a NachaZ git branch based this updated local master.
3. Extract the rar file and find a way to apply the changes.
4. Test it out in visual studio 2019.
5. Build a version.
6. Play it.
7. If all good and approved my me, upload it to github...

Publish the github link here and maybe also upload some builded executables so others can enjoy this improved version which sounds nice and sweet.

(I would recommend to re-arrange your original posting, so that the screenshots are in between the points, to highlight each new idea/change with a screenshot that is associated and a representation of this idea ! ;) :))

I will update this posting once I know more... standbye...

Next day:

1. NachaZ's patch partially applied:
$ git apply --verbose --reject --whitespace=fix changes..gitpatch

2. Rejected file manually merged with Meld application for windows:
src\Basescape\ManufactureState.cpp

(Some new comparison structure had to be added and git did not know how to do it)

3. Branch NachaZ created, also a worktree for myself to keep these changes on disk.

4. Building OpenXCom Solution (after dep folder copied from master to NachaZ) (5.8 GB RAM machine with roughly 1.8 GB free RAM):
Microsoft Visual Studio Community 2019
Version 16.11.10

So far seems successfull:
1>  UfopaediaSelectState.cpp
1>  UfopaediaStartState.cpp
1>Target Link:
1>  SDLmain.lib(SDL_win32_main.obj) : warning LNK4099: PDB 'SDLmain.pdb' was not found with 'SDLmain.lib(SDL_win32_main.obj)' or at 'E:\SourceCode\OpenXCom\NachaZ\bin\Win32\Debug\SDLmain.pdb'; linking object as if no debug info
1>  OpenXcom.2010.vcxproj -> E:\SourceCode\OpenXCom\NachaZ\bin\Win32\Debug\OpenXcom.exe
1>Done building target "Link" in project "OpenXcom.2010.vcxproj".
1>Target AppLocalFromInstalled:
1>  pwsh.exe wordt niet herkend als een interne
1>  of externe opdracht, programma of batchbestand.
1>  The command "pwsh.exe -ExecutionPolicy Bypass -noprofile -File "E:\SourceCode\vcpkg\scripts\buildsystems\msbuild\applocal.ps1" "E:\SourceCode\OpenXCom\NachaZ\bin\Win32\Debug\OpenXcom.exe" "E:\SourceCode\vcpkg\scripts\buildsystems\msbuild\..\..\..\installed\x86-windows\debug\bin" "E:\SourceCode\OpenXCom\NachaZ\src\..\obj\Win32\Debug\OpenXcom.tlog\OpenXcom.write.1u.tlog" "E:\SourceCode\OpenXCom\NachaZ\src\..\obj\Win32\Debug\vcpkg.applocal.log"" exited with code 9009.
1>Target PostBuildEvent:
1>  E:\SourceCode\OpenXCom\NachaZ\src\..\deps\lib\Win32\libFLAC-8.dll
1>  E:\SourceCode\OpenXCom\NachaZ\src\..\deps\lib\Win32\libjpeg-8.dll
1>  E:\SourceCode\OpenXCom\NachaZ\src\..\deps\lib\Win32\libmikmod.dll
1>  E:\SourceCode\OpenXCom\NachaZ\src\..\deps\lib\Win32\libogg-0.dll
1>  E:\SourceCode\OpenXCom\NachaZ\src\..\deps\lib\Win32\libpng15-15.dll
1>  E:\SourceCode\OpenXCom\NachaZ\src\..\deps\lib\Win32\libtiff-5.dll
1>  E:\SourceCode\OpenXCom\NachaZ\src\..\deps\lib\Win32\libvorbis-0.dll
1>  E:\SourceCode\OpenXCom\NachaZ\src\..\deps\lib\Win32\libvorbisfile-3.dll
1>  E:\SourceCode\OpenXCom\NachaZ\src\..\deps\lib\Win32\libwebp-2.dll
1>  E:\SourceCode\OpenXCom\NachaZ\src\..\deps\lib\Win32\SDL.dll
1>  E:\SourceCode\OpenXCom\NachaZ\src\..\deps\lib\Win32\SDL_gfx.dll
1>  E:\SourceCode\OpenXCom\NachaZ\src\..\deps\lib\Win32\SDL_image.dll
1>  E:\SourceCode\OpenXCom\NachaZ\src\..\deps\lib\Win32\SDL_mixer.dll
1>  E:\SourceCode\OpenXCom\NachaZ\src\..\deps\lib\Win32\smpeg.dll
1>  E:\SourceCode\OpenXCom\NachaZ\src\..\deps\lib\Win32\yaml-cpp.dll
1>  E:\SourceCode\OpenXCom\NachaZ\src\..\deps\lib\Win32\yaml-cppd.dll
1>  E:\SourceCode\OpenXCom\NachaZ\src\..\deps\lib\Win32\zlib1.dll
1>         17 bestand(en) gekopieerd.
1>Target FinalizeBuildStatus:
1>  Deleting file "E:\SourceCode\OpenXCom\NachaZ\src\..\obj\Win32\Debug\OpenXcom.tlog\unsuccessfulbuild".
1>  Touching "E:\SourceCode\OpenXCom\NachaZ\src\..\obj\Win32\Debug\OpenXcom.tlog\OpenXcom.lastbuildstate".
1>
1>Done building project "OpenXcom.2010.vcxproj".
1>
1>Build succeeded.
1>
1>SDLmain.lib(SDL_win32_main.obj) : warning LNK4099: PDB 'SDLmain.pdb' was not found with 'SDLmain.lib(SDL_win32_main.obj)' or at 'E:\SourceCode\OpenXCom\NachaZ\bin\Win32\Debug\SDLmain.pdb'; linking object as if no debug info
1>    1 Warning(s)
1>    0 Error(s)
1>
1>Time Elapsed 00:05:35.29
========== Build: 1 succeeded, 0 failed, 0 up-to-date, 0 skipped ==========

5. Testing can now proceed.

Later I will upload source code to github and make a special executable available on my webdrive so people can try out Nacha's version ! =D

First attempt at testing failed, because of broken laptop gpu, have to switch to full screen in a special way with window mode, somehow that didn't go well, tried to exit openxcom but it would not exit properly, the forced termination of openxcom nuked my sound driver, so had to restart the system, this is a known problem with openxcom and sdl to me, and it's quite annoying, but worth a restart and trying to test it again. I kinda forgot how to switch to full screen on a broken gpu, but it involves setting battlescreen and battlescape to 2x, and then switching from fullscreen to windowed mode. So I will try again and I also still have to do a release build, because so far this is a debug build.

Something else strange happened, visual studio 2019 disappeared from the taskbar ! LOL. Ah developing... lol... also during restart opera auto updated ran, so restarting now without time loss risks ! ;) =D so far so good, 10 minutes wasted not to bad... perhaps I accidently closed visual studio instead of windows explorer, as screen was frozen... no biggie...

OK, correct startup procedure for full screen on broken laptop gpu is:

1. Full screen.
2. Borderless.
3. Exit.
4. Restart game.

Plus ofcourse any scaling for fullsize graphics. The restart will make sure the bordless window is properly covering the entire screen.

Scaling options can be set to original for classic x-com size/feel, or perhaps x2 or 1x1.5 I think this has to be done before starting a game though.
I think 1.5x is best also set resolution to max in my case 1600x900.

Now I try make new game and admire these new changes =D

1. First screenshot verified.
2. Second screenshot unable to verify, need to play game somewhat to produce something
3. Third screenshot unable to verifiy, need to get a soldier wounded and recovered.
4. Fourth screenshot verified, sorting soldiers in craft possible.
5. Fifth screenshot failure, no kilograms displayed ? Feared as much not sure why.

2 out of 5 verified ! Not bad.

Why 5th is not working, I don't know... (yet), maybe feature 5 was removed from patch or something went wrong ? Or it takes a while to take affect though this last reasoning don't make much sense.

So far this patch seems worth it, so now I will produce a release version of it ! =D

OK I feel pretty confident this is going to make some people happy, so while visual studio 2019 is building the release version I will upload the NachaZ branch to github so others can maybe pull it down from me and enjoy it or view it or modify it, or even better/best integrate it into their own versions of OpenXCom ! ;) =D Also feels good to upload in case this laptop crashes and breaks down and dies forever ! LOL.

Here is the NachaZ github branch, part of Skybuck's Flying OpenXCom repository:

https://github.com/SkybuckFlying/OpenXcom/tree/NachaZ


Release build log:

1>  ArticleStateVehicle.cpp
1>  Ufopaedia.cpp
1>  UfopaediaSelectState.cpp
1>  UfopaediaStartState.cpp
1>Target Link:
1>  Generating code
1>  Previous IPDB not found, fall back to full compilation.
1>  All 23919 functions were compiled because no usable IPDB/IOBJ from previous compilation was found.
1>  Finished generating code
1>  SDLmain.lib(SDL_win32_main.obj) : warning LNK4099: PDB 'SDLmain.pdb' was not found with 'SDLmain.lib(SDL_win32_main.obj)' or at 'E:\SourceCode\OpenXCom\NachaZ\bin\Win32\Release\SDLmain.pdb'; linking object as if no debug info
1>  OpenXcom.2010.vcxproj -> E:\SourceCode\OpenXCom\NachaZ\bin\Win32\Release\OpenXcom.exe
1>Done building target "Link" in project "OpenXcom.2010.vcxproj".
1>Target AppLocalFromInstalled:
1>  pwsh.exe wordt niet herkend als een interne
1>  of externe opdracht, programma of batchbestand.
1>  The command "pwsh.exe -ExecutionPolicy Bypass -noprofile -File "E:\SourceCode\vcpkg\scripts\buildsystems\msbuild\applocal.ps1" "E:\SourceCode\OpenXCom\NachaZ\bin\Win32\Release\OpenXcom.exe" "E:\SourceCode\vcpkg\scripts\buildsystems\msbuild\..\..\..\installed\x86-windows\bin" "E:\SourceCode\OpenXCom\NachaZ\src\..\obj\Win32\Release\OpenXcom.tlog\OpenXcom.write.1u.tlog" "E:\SourceCode\OpenXCom\NachaZ\src\..\obj\Win32\Release\vcpkg.applocal.log"" exited with code 9009.
1>Target PostBuildEvent:
1>  E:\SourceCode\OpenXCom\NachaZ\src\..\deps\lib\Win32\libFLAC-8.dll
1>  E:\SourceCode\OpenXCom\NachaZ\src\..\deps\lib\Win32\libjpeg-8.dll
1>  E:\SourceCode\OpenXCom\NachaZ\src\..\deps\lib\Win32\libmikmod.dll
1>  E:\SourceCode\OpenXCom\NachaZ\src\..\deps\lib\Win32\libogg-0.dll
1>  E:\SourceCode\OpenXCom\NachaZ\src\..\deps\lib\Win32\libpng15-15.dll
1>  E:\SourceCode\OpenXCom\NachaZ\src\..\deps\lib\Win32\libtiff-5.dll
1>  E:\SourceCode\OpenXCom\NachaZ\src\..\deps\lib\Win32\libvorbis-0.dll
1>  E:\SourceCode\OpenXCom\NachaZ\src\..\deps\lib\Win32\libvorbisfile-3.dll
1>  E:\SourceCode\OpenXCom\NachaZ\src\..\deps\lib\Win32\libwebp-2.dll
1>  E:\SourceCode\OpenXCom\NachaZ\src\..\deps\lib\Win32\SDL.dll
1>  E:\SourceCode\OpenXCom\NachaZ\src\..\deps\lib\Win32\SDL_gfx.dll
1>  E:\SourceCode\OpenXCom\NachaZ\src\..\deps\lib\Win32\SDL_image.dll
1>  E:\SourceCode\OpenXCom\NachaZ\src\..\deps\lib\Win32\SDL_mixer.dll
1>  E:\SourceCode\OpenXCom\NachaZ\src\..\deps\lib\Win32\smpeg.dll
1>  E:\SourceCode\OpenXCom\NachaZ\src\..\deps\lib\Win32\yaml-cpp.dll
1>  E:\SourceCode\OpenXCom\NachaZ\src\..\deps\lib\Win32\yaml-cppd.dll
1>  E:\SourceCode\OpenXCom\NachaZ\src\..\deps\lib\Win32\zlib1.dll
1>         17 bestand(en) gekopieerd.
1>Target FinalizeBuildStatus:
1>  Deleting file "E:\SourceCode\OpenXCom\NachaZ\src\..\obj\Win32\Release\OpenXcom.tlog\unsuccessfulbuild".
1>  Touching "E:\SourceCode\OpenXCom\NachaZ\src\..\obj\Win32\Release\OpenXcom.tlog\OpenXcom.lastbuildstate".
1>
1>Done building project "OpenXcom.2010.vcxproj".
1>
1>Build succeeded.
1>
1>SDLmain.lib(SDL_win32_main.obj) : warning LNK4099: PDB 'SDLmain.pdb' was not found with 'SDLmain.lib(SDL_win32_main.obj)' or at 'E:\SourceCode\OpenXCom\NachaZ\bin\Win32\Release\SDLmain.pdb'; linking object as if no debug info
1>    1 Warning(s)
1>    0 Error(s)
1>
1>Time Elapsed 00:07:02.42
========== Build: 1 succeeded, 0 failed, 0 up-to-date, 0 skipped ==========




Now that I re-read this thread there are some claims that this functionality was already implemented, I do notice some differences:

1. The weight in storage screen is sorted, this could be nice.
2. Research and manufacture buttons are now purple in base menu, not sure why.
3. Extra sorting options for craft.

Rest will have to be noticed during play.

Now one final thing to do upload this executable to my webdrive so people can try it out, though indeed the difference with original OpenXcom might be minimal, but could still be interesting in case you struggle with wounded soldiers or so... I wish the kg indicator worked in ufopedia, but nope...

Finally here is the release build of NachaZ modifications into OpenXCom:

http://www.skybuck.org/Games/OpenXCom/OpenXcomNachaZ.exe

Just copy this executable to the OpenXCom game folder and then start OpenXcomNachaZ.exe by double clicking on it and such.

Not sure if it's save game safe and such ! =D

Have fun testing and playing it ! =D

Thanks for allowing attachments !

and

Thanks to NachaZ for this patch, might be interesting to play this sometime ! =D

OK, I played this version a bit... I did not see any soldier wounded recovery screen pop-up... I wish I did, so it seems this patch not entirely working as advertised ?!? hihi..

I assume all changes are in the patch file ? Though the RAR did come with all source code... maybe the source code has further changed not in patch file ? hmm...

Or maybe the game changed too much sense then and some of it not working anymore...

Also I do have some mods installed and they worked, I did have to disable the xenoproto mod or something graphics missing ! ;)

cu later ! =D

8
Using attachment is ok but this miss completely point of using git as version control system.

You should publish your changes on GitHub or other similar page (like e.g. GitLab)

Learning git requires time and may be difficult for people to get into, so I can understand he might not be there yet and wants to focus his time attention to other things.

9
Yes, I am interested in your improvements.

Send your source code (in zip or rar or 7zip) to: skybuck 2000 @ hotmail dot com

(without the spaces, also convert dot to .)

Then I will create a git branch on my git account and incorporate your changes.

(Once done I will update this posting to include a link to that git hub branch)

10
Recycle Bin / Re: NEW PLAN: MINI X-COM
« on: June 05, 2022, 05:23:19 pm »
Sunday 5 june 2022 (1 hour 37 mins spent)  jokingly called it 'C++ Appreciation day' but it really is C++ destruction day ! =D
0. Move ufo folder/game files to "C:\Users\new\Documents\OpenXcom", so copy to source code/bin folder is no longer necessary. DONE. SUCCESS.
1. Remove scalars. DONE. SUCCESS. (menu options and some "useScalars32bit" or something code could also still be removed)
2. Remove Flc/Flv player. (This should get rid of the microprose logo which is no longer relevant as far as I am concerned :P*) DONE. SUCCESS.
3. Remove PNG. DONE. SUCCESS. (Additional code for saving voxels, screenshot, F11/F12, etc, could also be removed ).

(All removes commited on seperate branches based of miniXcom)
(All removes integrated into miniXcomV2)
https://github.com/SkybuckFlying/OpenXcom/tree/miniXcomV2

--- ^ This was the easy part ^ ---
https://www.youtube.com/watch?v=TUkicXpyRFo

Perhaps later today, I do some more work on miniXcom... with the more tricky bits...

11
Recycle Bin / Re: Switch to true 24 bit (or 32 bit ) color ?
« on: June 05, 2022, 03:38:29 am »
I was kinda hoping that these changes would be enough. I was hoping the game would automatically create a 32 bit map.cpp. But it doesn't do that.

Trying to set it manually to 32 bit, but modifieing interactive surface, causes arrow->set palette( getpalette something) to crash because the palette is null in map::init.

So same problems as before, but now going through them apperently a step at time, very unfortunately reality.

Screen.cpp has some 'deferredPalette' for setPalette perhaps it can help... perhaps even a generic setPalette with deferred palette could be created to provide a generic solution for these kind of problems.

Or perhaps 5 global variables could be used, where in each the palettes for the game are stored and reference those instead of passing palette pointers around.

Instead each control just has to remember which palette number it should use... However this does not yet account for TFTD and/or mods which might have different palettes...

Futher investigations into how palettes are passed around and loaded initially might be required to shed some more light on this...

12
Recycle Bin / Re: NEW PLAN: MINI X-COM
« on: June 05, 2022, 03:00:52 am »
Saturday 4 june to Sunday 5 june 2022: (11 hours and 30 mins spent) Described new Advanced image processing algorithm idea, and investigated gimp and inkscape software and palette support in gimp, experimented with gradients in gimp. Thought about if it's possible to implement real-time interpolation and even extrapolation for OpenXcom, described potential performance problems and potential solutions. Right now main problem is trying to avoid "T" computation for color interpolation. A fast interpolation method was found for shift values, integer based. It's pretty accurate compared to double computations at least by looking at it with the eye... however, it doesn't solve the problem because a division is needed to convert larger palette index to 8 bit palette index, because column width would be 450, number of entries per palette row basically, which unfortunately is not a power of 2.

So there are a number of possibilities that exist as far as I can see:
1. Either do an expensive division per pixel to convert it from 13 bit down to 8 bit and then calculate interpolation in real time, this would allow even higher bits per component in case 48 bit or 64 bit monitors are used where lookup tables would become to large to fit inside L1 cpu cache

2. Use lookup table, though at a shift value of 5, it would be 7200 x 3 = pretty big look up table. A more conservative value of shift = 4 could be used as well... but I want to stick with 5 for now, hopefully it not be too bad. should still fit in L1 cache.

3. Find a different advanced palette size, where colum count is a power of 2 and where the shift value (= multiplier) inside interpolation routine can also remain a power of 2.

4. Concerning point 3, extrapolation slots/entries could be used in 3 to increase the palette size from 7200 to 8192 to create a new power of 2 palette. This would give 31 extrapolation colors... for example 16 on top and 15 on bottom could be possible, or an different distribution... maybe spent more color slots on top of color range, to extrapolate colors towards white, cause they start quite low on the r,g,b spectrum....

Well time flew... investigating this matter, had quite some fun with gimp and a little bit with inkscape... was worth it a little bit, inkscape is cool software definetly try it out if you have not done so and are a graphics artist ! ;) vector graphics software ! ;)

11 hour session:
https://www.youtube.com/watch?v=UsKswf7BvBQ

(I kinda want to continue (and do something in c/c++ openXcom, some testing) but maybe time for a break, mostly quited because of youtube 12 hour limit and have to go eat)

*Addition*, being not quite statifies, I quickly investigate if map is now 32 bit colors, but unfortunately it is not, and if trying to set it to 32 bit by modifieing interactive surface, the arrow->setPalette( getPalette ) is setting a null pointer and thus game crashes.
So still more work needs to be done, to try and get the game working in 32 bit... would be nice to have a 32 bit map surface...

35 minutes spent, investigating this:
https://www.youtube.com/watch?v=QUzlGdXXTB8

13
Recycle Bin / Re: Switch to true 24 bit (or 32 bit ) color ?
« on: June 03, 2022, 03:54:07 am »
Solution found for OpeXcom main/vanilla master branch (also my miniXcom branch can do it, tested on it, which has geoscape, basescape and ufopedia removed for faster compile times ;)):

(Main problem is zoom.cpp and scalars/SSE/SIMD code and flipWithZoom. Disabling SSE and Disabling flipWithZoom solves the problem for now, but loses some zoom functionality, game can still be run in different resolutions though and zoom options do have some effect on it like original x 2 or full display.)

// change surface to 32 bit in screen.cpp:
Code: [Select]
void Screen::resetDisplay(bool resetVideo)
{
...
...
...
// _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
...
...
...
}



// zoom.cpp: disable this code:
Code: [Select]
bool Zoom::haveSSE2()
{
...
...
...
// return (CPUInfo[3] & 0x04000000) ? true : false;
return false;
}

// screen.cpp: disable this code:
Code: [Select]
// if (getWidth() != _baseWidth || getHeight() != _baseHeight || useOpenGL())
// {
// Zoom::flipWithZoom(_surface->getSurface(), _screen, _topBlackBand, _bottomBlackBand, _leftBlackBand, _rightBlackBand, &glOutput);
// }
// else

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

14
Recycle Bin / Re: NEW PLAN: MINI X-COM
« on: June 03, 2022, 03:49:31 am »
Friday 3 june 2022: (6 hours spent) Modified OpenXcom Palette Analyzer to load palettes directly from original UFO/game folder, also implemented 6 bit to 8 bit converted. Discovered and fixed a bug where R,B,G was being used instead of R,G,B. Wrote a x-com screen loader + background palette loader (+ xcom palette loader). Investigated ideas how to make OpenXcom work with 32 bit screen and/or surfaces. Hypothesized that SSE code was the problem and the cause of bugs/crashes and wrong rendering. Decided to investigate further and disabled SSE in zoom.cpp. This fixes part of the problem. Even the default/sse-less code seems buggy. Disabling zoom code can make the game work well in 32 bit, if bpp set to 32 bit.
In screen.cpp this code would need to be disabled. (Then I ran into an audio chip/driver bug/hang so cannot test the game further right now, but I tested enough to know that most likely the game can run in 32 bit true color. I should still investigate further now (after reboot) or tomorrow, to see if pixelformat is indeed 32 and if gradients render nicely the ultimately test ! ;)):

// change surface to 32 bit in screen.cpp:
Code: [Select]
void Screen::resetDisplay(bool resetVideo)
{
...
...
...
// _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
...
...
...
}



// zoom.cpp: disable this code:
Code: [Select]
bool Zoom::haveSSE2()
{
...
...
...
// return (CPUInfo[3] & 0x04000000) ? true : false;
return false;
}

// screen.cpp: disable this code:
Code: [Select]
// if (getWidth() != _baseWidth || getHeight() != _baseHeight || useOpenGL())
// {
// Zoom::flipWithZoom(_surface->getSurface(), _screen, _topBlackBand, _bottomBlackBand, _leftBlackBand, _rightBlackBand, &glOutput);
// }
// else

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

This is kinda cool, it was ment to be, galactic interference: =D

https://www.theguardian.com/science/2022/jun/02/rare-sight-for-amateur-astronomers-as-five-planets-align

15
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 ! ;)

Pages: [1] 2 3 ... 15