SoA Source Code - Bugfixes

Well - I have put a bit of time in again, but the major refactoring I had dug myself into a couple of weeks back, I had to abort - too many changes, without the result I wanted. So now I dug the non-DFX code up again. If that goes well, we have 32bpp and no need for DFX.dlls (which all might seem a bit pointless anyway - when the graphics back-end is changed anyway) - and I did experiment with a "tablet"-mode on Windows - did a blog post on that topic elsewhere. I hope I get a bit done - which others also might find useful - but summer and many other projects also, so do not set any hopes too high - and the code is still terrible to work with

Should rather spend time on SoAOS tools - but that will also come eventually.

________________________________

Continue from: unter Windows 10 Spielen??

15.01.2021:

Thanks for clearing that up.

Also the POX format used in SoA and HeroX - were identical as I remember it.

The only thing I remember where I had to support a dual format were one of the .db files (xref?).

So the version of the code/feature set that is found on my GitHub repo is what is to build on, and does not as such have any know bugs? Because to me it does seem very stable, but I have not put all the gaming hours in as you have done.

But if you have found any - bugs or shortcomings let me know - I like to keep lists - for the dark winter nights

I think I skipped the documentation of the save game format - maybe I should take a brief look at that.

Are we talking about the same here - I just downloaded the 6.5 Mb Siege.exe file and it took less than what is measurable.

I have a Win7 VM somewhere - but I do not think that is the issue - curious on how your installs is setup.

Is your install based on the German Collectors Edition from Blackstar and then patched?

The two things I could think of is savegame format - is it an AOA or SOA save game - in what chapter? and could you post it here. Second issue might be missing player POXs - but I thought I catered for that.

The code does support both xref.db formats - both the retail and the open sourced format.

I would be happy if you would help me identify these errors.

Maybe I should make that list of retail versions I have been lucky enough to pick up on eBay:

Collectors Edition - BlackStar - Jewel CD casing - German

Chapter 1-6 - MarketWay/BlackStar - DVD casing - Spanish

Anthology - GlobalStar/TakeTwo - Cardboard/Jewel CD casing - English (Canada release)

I had the plan to test on these, but why bother? Or..

I do mostly run against the assets that came with the open sourced code - and replaced the missing/corrupt files.

Sorry I just reread this thread since it has been a while - and I lost track. But I guess if we can take it from here one step at the time - that would be very helpful.

BTW. I do have a version that does not need the DFX.dlls - and plays in 16 and 32 bpp - but after a while running around it crashes and there are glitches - so still WIP

I did in #55 claim that I am checking if multiple "players" exists - otherwise there is no left/right arrow on the character - so no changing of player doable.

And I also did use the save games you gave me in earlier in this thread - for the various chapters.

Strange with GitHub download - maybe if not logged in - this punish your bandwidth

Did you mean directX or digiFX/dfx.dll - I have remover all no-directX code. Without the custom ddraw.dll game is unbearable slow.

Just installed German kapitel 1-6 on a win 8.1 machine - still miss patching and ddraw.

The testbuild I have that does not need the digiFX dfx.dll, is fast - my tests showed that my code is faster than the old dll code - but too buggy for release

You are right I wrote my code was 5 times slower than the DLLs - but we were still at 0.04 msec - I did optimizer a bit afterwards and get the remaining stuff to work -1 - but I will put a small video up at sometime. The DLL do not make the difference - the ddraw does

Yes it was the $ifndef directx parts, since that code was using GDI - and the project was always compiled/run with a DIRECTX compiler directive anyway - but I guess the reason what for debugging since DirectX is so possessive of the screen it make debugging painful - unless you use 2 monitors or remote debugginng.

$IFDEF, $IFNDEF and $DEFINE .., are used on compilation, not runtime. So if you code for multiple platforms or only when debugging, you could separate platform specific code like this:

{$IFDEF MSWINDOWS}

...do Windows specific stuff here

{$ENDIF}

{$IFDEF LINUX}

..do Linux stuff stuff

{$ENDIF}

See more here: http://docwiki.embarcadero.com…ional_compilation_(Delphi)

BTW: My WIn 8.1 German Chapter 1-6 install - gives me the joy of spending time on some remote debugging tomorrow - good night

It wanted DirectPlay installed, restart and then nothing, thanks for pointing me into this dark hole

Zitat von Rucksacksepp

So, I tested your Siege.exe many times. First I saw that you extracted the Shadow.bmp, Glow.bmp and Xray.bmp. So I copied them into my folder. Nothing changed. The I added the other player.pox files, nothing... Copied the interface into Interface/English directory, nothing...

The Shadow.bmp and the remaining missing ones are put into the .exe as resources so that I did not need to deploy them separately.

Zitat von Rucksacksepp

The error codes are:

Main.CloseLoad Accessblablabla (=Loading... you don't say...)

Main.WMStartNew Accessblablabla

I just ended at the same point - but there are some issues before.

Zitat von Rucksacksepp

I think it has some problems rendering the Character. I saw that you deleted in Main.WMStartNew those lines: (or rather wrote that in another .pas)

...

with DlgCreation do

begin

shirt[ 1 ] := PartManager.LoadItem( 'TunicBlue', TCharacterResource( Player.Resource ).NakedName );

...

Why?

Alles anzeigen

I can't remember why - it has been a while

But I have a setup now that fails - it stopped working when I added the 0.7 DE Patch - so first conclusion was the save files as you mentioned - but that is not it.

Thanks for your help! - now I can debug and fix

Well that was very helpful - the problem was the 0.7 patched Title.db file - it has double entries - but now I just update the dictionary values for the key - one example was "Meditation" both in line 101 and 152 - my re-implementation expected first col to be unique as it should be.

That also pointed me in the area you had been - which caused undressed character - since none were selected at a list of one - classic

The game can now be played again. But I will just check up on issues I found with the "cache" - is that feature even relevant anymore - on new hardware?

I just pushed my the two small fixes.

Zitat von Rucksacksepp

Hm, interesting. After deleting one in the title.db it worked. Found something in siege.log about that: Parts.Create Duplicates not allowed. Before deleting "medition" in title.db it mentions the same, too.

Yes that is the entry in the Log. I did not bother looking for more duplicates - I just made the code handle it.

Zitat von Rucksacksepp

Cache isn't important anymore. And it can cause more bugs. E.g. sometimes you couldn't finish a quest and after clearing the Cache folder you could continue.

Will put that on my cleanup list.

Zitat von Rucksacksepp

Some bugs I found immediately:

Parts.GetImageFile Access

(=old XRef.db)

TEffect.RenderLocked Access

TCharacter.DoFrame Invalid pointer operation

Spells aren't drawn on the screen.

Alles anzeigen

I have not experienced these - can I have your xref.db and a save game - please.

Thanks great - I was not sure these were the ones you referred to, so I just asked again

The xref.db are not totally identical - you put a dwarf and more in

Anyway I am not sure I see the bug - there is nothing in the log - when load the same game (with your xref.db)

Or was it when the spell is cast... ahh it was, I will be back.