SoA Source Code - Bugfixes

Continuied from: das POX datei format

Zitat von Rucksacksepp

If the new pox-viewer will have an export-option, this would be an advantage. The old ones had a problem with exporting all frames. The first one was skipped evertime. Only solution: Screenshot of the first frame, select a rectancle with the same height and width as the other frames and then save it. Well... Makeable, but laborious.

Reminds me a little bit of the problem with the rectancle and diamond-tiles in relation to the source code from github which I could solve.

Export into what format(s)? multiple single images or spritesheets? BMPs, JPGs or PNG? Full set or per "action"?

Could you elaborate on the problem rectangle/diamond-tiles - did I forget/miss something? (again )

Thanks

GitHub Source Code: https://github.com/SteveNew/Siege-of-Avalon-Open-Source

Sorry about that, will take a look. And the export.

Edit:

Zitat von Rucksacksepp

That was something I mentioned a time ago: The first frame of the first Rectancle such as diamond-tile on each map wasn't displayed (just transparent). At this date I solved it: (Post #12) HD und FullHD Version zu Siege of Avalon (aus dem Source Code mit Delphi 4) (Post #12)

Yes, remember now - we also had a PM on that - I left the two lines in question from gondurs fork as comments - but I think the cause is something different - since assuming both index numbers are positive a mod would not return negative - and otherwise expecting negative result would then be very dependent on implementation of the programming language itself. The second line in question would always evaluate to false - but will see if I can reproduce the "bug" - I have not seen the "transparent" or any pink bug - after I fixed the menu quick. So I do not think my fork of the repo has these issues.

Bmp export done btw. Curious on the need for the export - since I have no experience with SoA modding, I am just asking to learn - would that be for colour manipulation or just to have something as a basis for some new asset?

Perfect - thanks. Have not seen this before - can I have the test map file? And is it only in "HD" mode - since the metrics are different? Is this the gondur fork - or my fork of the code?

/Steve

Zitat von Rucksacksepp

This Code is the original one from Domenique Louis (CartBlanche). This problem existed before I invented HD and FullHD. This Bug is on every map, no exception. But of course I can upload this test-map here.

Oh it seems I am missing:

spriteobject\character\targetable\invistrigger

staticobject\props\campfire

staticobject\props\logbench5

staticobject\props\logbench6

Are they from one of the other chapters? Then I have them somewhere.

Zitat von Rucksacksepp

I forgot to answer your question about exporting the frames from the pox-file. I made a few pox files based on original ones like rubylegplate.pox because there was no leg plate colorized ruby. So I needed the orinignal frames and edit them.

That was what I guessed could be one of the uses - what about having the possibility to change colors - within the POX viewer/editor - then it can be done in one step and not for each exported bmp frame.

Zitat von Rucksacksepp

I think it's Chapter 2 and 4. Anyway... Attachment!

Thanks! I did just test this on two machines - with different graphic cards - Intel and Nvidia - on the source from "my" version of the source code - no error or glitches. See attachments - I did also try in FullHD more on my HighDPI suerface. Converted bmp to jpg to be able to upload.

So - my guess is:

1. Graphic card AMD issue?

2. Or the nasty "magenta" issue - I fixed in connection to the menus. The "transparent" magenta is ( on purpose? ) set a bit off in the original code you use.

I put my money on number 2

This has to me nothing to do with drawing calculation we talked about. I need to run some errands - but will be back with the piece of code that has the "wrong" color code.

Zitat von SteveNew

So - my guess is:

1. Graphic card AMD issue?

2. Or the nasty "magenta" issue - I fixed in connection to the menus. The "transparent" magenta is ( on purpose? ) set a bit off in the original code you use.

I put my money on number 2

This has to me nothing to do with drawing calculation we talked about. I need to run some errands - but will be back with the piece of code that has the "wrong" color code.

Alles anzeigen

Rucksacksepp I owe you some money (or beer) - you are right the $FC04FC issue was only relevant for the menus - and since you redid those, you did not have the issue.

As you also describe in the thread when you fixed it - this is an calculation error - I would argue that these to lines are sufficient:

X := ( FTileMaxIndex div FTileMaxColumnIndex ) * FMap.FTileWidth ; // fix by rucksacksepp

Y := ( FTileMaxIndex mod FTileMaxColumnIndex ) * FMap.FTileHeight;

And that the condition below in this context always ends up false - so they could just be removed:

if ( ( FTileMaxIndex mod FTileMaxColumnIndex ) < 0 ) and ( FTileMaxIndex > 0 ) then // fix by rucksacksepp

inc( X, FMap.FTileWidth );

I was not able to reproduce the errors myself (is any xref.db involved, I only use the one from chapter 1?) - but I have now included you corrections - as shown above - thanks!!

I should just listen to your experience, and stop arguing. And the prof is that your code fixed the problem - cant argue with that :D.

What did you mean about:

Zitat von Rucksacksepp

Did you already tested some flickering-action from the "bulbs" ingame? Only "none" works everything other get some pink-bug.

- sorry for all the stupid questions - but I lack the years of experience of the game and modding SoA - and a picture might explain better?

BTW: Have you ever seen the use of animated cursors in the game? Some code is included, by seems never to be called - noticed when I redid the cursors in SDL2.

Thanks for moving the thread!

I need to get into what the xref.db is used for - seems to add some "value" (irony applied) - will put it on the list

The variations in the version of the xref.db explains - I would try and actually support both, and adjust the transparent base on need - if doable. I initially use the files that were posted on GitHub (what I meant by Chapter1 - since they were publicly released) - being naive and thinking that they were the latest and greatest.

I will take a look at the bulb issue - hopefully tomorrow.

In regards to the code sample - I will start to argue again

Pos(substring, string) finds the position where substring is found within string - so not found returns 0.

If the idea with the code is to find the XRefDB field index of the field value that contains the "NakedName", then your suggestion will not work, since

Pos( S1, lowercase( S ) ) >= 0

will always evaluate to true and leave(break) the while loop - with XRefIndex=1, so

if XRefDB.FindRecord( 'Base' ) then XRefIndex := 1;

would end up doing the same thing.

Which could be OK - if you are sure the first element is what you want. I ended up with a female character, wearing men's cloths - as I remember it - seems to be the xref.db versions are playing trick on us - again. I use the female character as default. Result with the above change and the GitHub xref.db - when using a female character.

Is this not down to a question of supporting various retail SoA (and Mods) versus released SoAOS files. Then I need to get some test scenarios setup - covering all? Or can we reduce the scenarios?

Zitat von Rucksacksepp

The flickering bug wasn't in the original executeable. I would be interested in your version/executable if there's this bug too. But no rush. There's much time.

Well I did spend much time in Anigrp30.pas - not a place you want to be

Partly solved - and I found the cause - remove the part I put in comments from TAniView.CopyTile:

if ZoneTile is TLightZone then
begin
  if ZoneTile.FullRefresh then
  begin
    if Dest <> lpDDSMap then  // notice I changed this also
    begin
//            if Layer = 1 then
//              Exit;
//
//            DstX := X + FMap.FTileWidth;
//            DstY := Y + FMap.FTileHeight;
//            if Assigned( ClipRect ) then
//            begin
//              if ( X < ClipRect.Left ) then
//                X := ClipRect.Left;
//              if ( DstX > ClipRect.Right ) then
//                DstX := ClipRect.Right;
//              if ( Y < ClipRect.Top ) then
//                Y := ClipRect.Top;
//              if ( DstY > ClipRect.Bottom ) then
//                DstY := ClipRect.Bottom;
//            end;
//            BltFx.dwSize := SizeOf( BltFx );
//            BltFx.dwFillColor := FMap.FColorMatch;
//            pr :=  Rect( X, Y, DstX, DstY );
//            Dest.Blt( @pr, nil, @pr, DDBLT_COLORFILL + DDBLT_WAIT, @BltFx );
//            Exit;
//          end
//          else
//          begin
      Offset := ( TLightZone( ZoneTile ).States - TLightZone( ZoneTile ).State ) * TLightZone( ZoneTile ).TileStateOffset;
      Dec( Index, Offset );
    end;
  end;
end;

There goes the pink rectangle - and the "lighting" is drawn correct - non-animated

Now try to walk into the lighting area - your character is still rendered correct - now turn on x-ray - should match attachment.

The problem is that single tiles are refreshed - apart from when x-ray is turn on - then RefreshRegion (rendering a bigger area) is called, so to fix this nicely:

1. Figure out if any TLightZone is present/visible, calculate the region needed to refresh and call RefreshRegion.

2. The CampFire should behave like a LightZone on the tiles - does behave correctly on characters.

So the "bulb" and the campfire is consistent now - RefreshRegion is only called once - where having x-ray active.

I will leave it with this for now - need to throw some code out before I venture into Anigrp30.pas again.

Zitat von Rucksacksepp

Well I was in there too because of the rectangle and diamond-bug. For me the worst part is when we're going to assembling code (move eax and so on)... No chance.

I know - the worst part is the digiFX stuff - blackbox - with no source for the DLLs. But I hope we are mostly past that bit now. I will transform the asm into pascal - so that we can read it - and don't think it has any mayor impact on performance - mostly color manipulation what I have noticed.

Zitat von Rucksacksepp

Staticobjects are now invisible in that area.

The Staticobjects should only be invisible when x-ray is active - no change there - that I am aware of.

Zitat von Rucksacksepp

Maybe it would be easier to deactivate the re-rendering on lights with Xray-On around the character and enabled re-rendering on staticobjects.Well it's not that important so no need to fix this now.

The whole rendering part in SoA is still mostly uncharted territory on my part - so good idea to leave as-is for now.

Zitat von Rucksacksepp

Btw: In the original executable of SoA, flickering works correctly.

Yes I started out testing the map with DTMain.exe from 2001, I think they removed it due to performance - or pink issues

BTW:

I would like to test how "compatible" a new build is, when I do some changes - what versions of the old .exe should I try to "replace"? The DTMain.exe I used has the stupid thing about a Maps subfolder. And it would be great in the future to include AoA.exe as well - if you do not mind.

Zitat von Rucksacksepp

What do u mean with "version of the old .exe"?
Which maps-subfolder?

I use:

DTMain1.exe version 1.1.2001.1104 - which I guess is from the free Chapter1 from http://soaos.sourceforge.net/

Siege.exe 1.1.2001.409 - which I guess is from the code on sf/github.

...then there are patches applied.

I also have an seal copy of the GameStar set - but I wont open that

MadSc repo build

My own builds

- So the question is - if I want to make my build "compatible" - so that you just can replace the old DTMain1.exe/Siege.exe - what "distributions/versions" do I need to test/support?

One of the above has a bug - were it needs an extra Maps folder to write to.

Zitat von Rucksacksepp

Did I understood you right, that you want to build only one executable with every function in every mod but no swapping. So something like this: Ashes has the option to activate hardmode in a new game and Siege doesn't have.

Yes - most of the settings are controlled by the siege.ini anyway - I did added a few - but if they do not exists, it just works as the original. I had prepared for localized keymapping, your adjusted XP rules and also loading of extra resources/layers - Golem, IceBlock and Tabar - if I remember correct.

I starting throwing a lot of code out - so when reorganizing - I think it could be done fairly flexible - the resources know which layers/actions the have already.

The reason that I eventually would prefer to move down that route, is that we get things fixed in one "engine" - instead of we all have various variations of the engine - the assets, story and data should give the variation. But it is not something that is done by next week