SoA wishlist/suggestions/roadmap

    Committed the HD stuff - the new HD assets are a bit of a rush job - feel free to improved them. Screen resolution selection in option dialog - currently needs restart/reactivate - will not fix - since logical resolution in SDL2 will be our friend at that time.


    The menu pink glitch I kept ignoring is also fixed.


    Missing as "promised" in this round:

    - German interface\text.ini - since you all probably have a correct one :)

    - HD is not tested, but is missing hotspot areas on UI

    - Spanish and German HD/FullHD SoA-styled UI assets


    I will probably fix these before I go back to removing code rot - even if that is highest on my list.


    Would it be helpful if I added binary releases - once in a while, so people not interested in building themselves could still get the executable (and need assets)?

    Zitat von Rucksacksepp

    Didn't know taht there was a pink glitch in the menu.

    I think you redid that code for AoA, but in the cleanup of the original code - I changed all the "transparent" to a const = $FF00FF (Fuschia/Magenta). Then looked at the jedi-sdl and noticed that for the menutextbtn bmp the value in code was $FF04FF. Then actually checked the file - and it is actually $FC04FC - so someone was play a prank - not really visible difference.

    Zitat von Rucksacksepp

    I don't think you need to release every new compiled executeable.

    No, I do break too much between commits :) But when I do feel I have release worthy code - at least in the sense that people can try and test it without too frustrated and without having the compiler.

    • Offizieller Beitrag

    That's what I said when I got the code in 2017: Someone did some changes in order to stop others on continuing the work.


    I found something that you may have to change in the anigrp30.pas-file. (Thats from me too, by the way)

    // X := ( ( FTileMaxIndex ) div FTileMaxColumnIndex ) * FMap.FTileWidth ; // from gondurs

    // if ( ( FTileMaxIndex mod FTileMaxColumnIndex ) < 0 ) and ( FTileMaxIndex > 0 ) then // from gondurs

    I wonder if you don't have some problems with the tiles displaying on the ground because you use the buggy code.

    I left it out for now - but I will check the code and effect - I think it actually was the code the compiler notified me about that the condition did not make sense. That is the bonus by moving to a newer tool chain - the old code actually has something like this - that compiled in Delphi 4 (and FPC maybe?):


    Code
    interface
  function X: integer;

implementation

procedure X;
begin
  Result := 4;
end;


    You might have this bug in parts.pas - TPartManager.GetImageFile - where in gondurs fork it was:

    Code
    if Pos( S1, lowercase( S ) ) >= 0 then
  break;

    which will always break out - since not found equals 0 :)


    There were also confusion about whether some arrays were 1 or 0 based.


    Last night I did some cleanup/refactoring on the DirectDraw stuff - that is really a mess - since the code really is a lot of copying around, without going back and fixing the original problem - and very little higher level abstraction. There is so much redundant code - that makes the whole thing terrible to read (and work with).


    I will wrap some more of the DirectDraw stuff that is cluttered everywhere - that will make it "easier" to port to SDL, and also maybe help me understand why it seems so ......


    After that I probably go for the "resource" classes mess - which is very much "oh we need a new spell - let us copy some code - a new monster - lets copy some more".


    Let us see if I break more than I can fix :D

    • Offizieller Beitrag

    Yep. Delphi 4 warns about that too but no negative effect while playing.


    Parts.pas uses a newer Version of xref.db. So I had to write a new one. Well I didn't get it why they changed it. No improvement in my opinion. So I played a little bit with that part of the code. Finally I got the old one working. And again no negative effect if you ignore that warning/hint.


    I recently found a bug somewhere in the Code where I won't be able to fix it because I won't be that lucky this time... Flickering-Type of lights can't be displayed correctly on the ground.

    The tiles where the flickering light should be applyed will be moved to video (movetovideo). So I think somewhere at this part must be a bug.

    What happens in game: The rectangle on the tiles based on the radius from the light source appears to be pink/fuchsia. When I walk towards it with "XRayOn" when around the character the ground is displayed correctly.

    Maybe you can check that too after you're finished with your main work.

    I guess I have already broken the Delphi 4 compatibility - and it will get worse ;)


    I did wonder about the change to the XRayOn - my guess was that it is more preferred to use the key pressed - than the on/off toggle? I really also need to spend some more time on actually playing the game - also makes it easier to fix things, when you have experienced them as broken.

    • Offizieller Beitrag

    Then: Good luck! ^^


    Again: Changed by me!

    I used these 3 .dll-files ( Windows Vista/7/8 Fix bei Grafikproblemen/Slowdowns/Lags ) for more compatiblity espeacially for Win 8 and 10. Thereby there will be 2 bugs unfortunately...

    1. If someone has a "say" above his head and walks out of the screen the game crashes

    2. Walking to the top of a map with XRayOn := true the game crashes.

    I gave it a try to fix the first one by changing the command for the "say-rendering to screen" from lpddsback.bltfast(...); to Drawalpha(...); -> It worked! That was lucky again.

    The second one: No chance for me. So I decided to decrease the amount of crashes. Nobody will forget to switch the Xray off in future because you have to hold down the "X"-key. It's pretty rare that someone will hold down the key while walking on the top of the map. =)

    Zitat von Fliwatt

    I guess releasing one every couple of weeks (or in other words always when it compiles ;) ) would be fine.

    Well it always compiles and runs, before I commit - but it might not work :D

    I will do releases when sufficient changes has been made, so that it makes sense. Having moved more to the GPU - already should be relevant for a release.


    I had hoped I had been able to include some SDL2 stuff by this Easter, but the current code needs a lot more rubbing, before I can start on a migration. I will packaged up a release during Easter - since bugtesting sounds great - I should say that I will primarily focus on fixing stuff that is used with the "open" assets included - so not any issues found using modded content or chapters 2-6 (for now) - I did leave a bit of support AoA stuff in there though :D

    Rucksacksepp noted that when shooting arrows - the arrows were pointing in wrong directions - and I had noted that savefile bmp were upside down (and that I previously had broken the savefiles) - the culprit is the "new" ddraw.dll - so for now I have fixed these cosmetics in the siege.exe file - and submitted an issue to the person who maintains the ddraw.dll.


    And due to the broken save games, did I just upload a new binary release.