I do not use the old wine files you refer to - Microsoft has done things to break DirectDraw since that version was done - so either get newer ones - or even better use the one I use from : https://github.com/narzoul/DDrawCompat - you only need one .dll to be included with the .exe file. Attached it for convenience. new_ddraw.zip
I will test the scenarios you describe - lets see how it goes 
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.
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?):
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:
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 
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.
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.
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)?
I have now removed the "PartyOfFour" setting, and let it be controlled by whether there are room for 2 or 4 slots on the UI. As pointed out - the HD/FullHD assets done by Rucksacksepp where styled for AoA, so I have done a SoA styled in HD, and FullHD will follow before I commit the whole HD/FullHD build. I also noticed that the german Interface\text.ini included is incomplete - will fix as well.
You are right - for now I will let the number of slots on the UI control the max number of party members - and concentrate on the basic game/engine.
Then you that have been doing the mods - could come forward with what changes you want to see in the engine - either as permanent fixes, or optional settings to support additional features. Otherwise I will do too much guessing based on my too little knowledge about the game it self.
Will add the Language selection in the Option, as was intended - English/German/Spanish based on the existing assets.
Thanks for the feedback and helping me out.
Rucksacksepp Thanks - yes I have included the AdjustedPartyHitPoints setting to either use the "original" (there seems to be two version - the oldest multiplies by NPCList.Count - which is further commented out in your example above) - or your more balanced way.
Did the original not always have max 2 party members? So 4 would only be for HD/FullHD. I also did reply on PM.
An update, if anyone is interested.
I am almost done adding at least three options based on the work done earlier by Rucksacksepp, that should enable to both play the "Original" and the great work that was done with the HD/FullHD (and HitPoint/Party controlled properties) - so when I later this week commit the code, these 3 are added to the INI settings (no UI - yet):
ScreenResolution=FullHD (Original, HD or FullHD)
AdjustedPartyHitPoints=true
PartyOfFour=true
These are non-pretty hacks - but all the old 2003 code is very messy - so my hack is an improvement
Rucksacksepp I did PM you last week - do you mind if I include your HD and FullHD assets in the Repo? Or should I just point to the post here?
The plan is to afterwards - spring clean the the whole repo - keep only a single source directory (since everything is included/merged as options) - and then further heavy refactoring - to clean-up all the nasty copy-paste code.
From there I guess a "Final" DirectDraw release - and then onto SDL - well at least a plan for now.
I do not have any intention on rewriting AI - or breaking the original feel or idea of the engine - that would then be a whole different project.
There is a fair amount of natural code rot, and doing a lot of file I/O on stringlist-driven streams was how it was done. So the AI we should live with - might do adjustment to hp/xp ratios like of things - but I guess since people liked the game - it is balanced well enough.
Coding is just a craft - the knowledge about the game and the assets is what counts to make it work. If you can specify - something that I can understand (this might be the hard part :D) - then it can probably be done.
Is/was there a changelog with the patches/fixes for 1.4 or 1.7? Just to check on the code which issues where fixed?
Rucksacksepp - thanks, yes I noticed in your changes. There also seemed to be other nice adjustment - but I have really not looked at the detail on what was bug-fixes you had added, and what was enhancements. Great of you to mention - and I hope we can collaborate on this - if you do not mind.
I have a lot to learn about the assets, the game and the code - so bear with me.
I have opened up for creations of Issues on GitHub - so I will probably use that as a to-do list - others are welcome to add.
Nitemare - I am down to 0 warnings ( I did set the compiler to ignore the 335 non-critical "Implicit string cast" :D) - they should not be fixed by the bit of casting hell I added. I will redo the file-routines, honoring the file-format of cause.
Did fix a few other things - and did a bit of cleaning - as Rucksacksepp said, the "Registrationcode" was not used - so I removed a reference and now the file is gone. I am in big favor of throwing unused code away.
ChangeLog from the latest push: https://github.com/SteveNew/Si…/blob/master/CHANGELOG.md
You know the deal. 535 warnings in the code, let's fix one, 745 warnings in the code.
Yes that are the rules and conditions we work under 
I agree with you, that a lot of the problems SoA has on modern Computers come from the DirectX implementation and the crashed from ddraw.
Yes - and DirectDraw has been deprecated by Microsofts for years - so it needs to go eventually. Opening for a cross-platform graphics lib sooner than later.
It would also be cool if there was any way to completely remove the registration feature (copy protection) since it still leads to some crashes. Not sure how that would be concerning the legal side though but since it is already open source I doubt it would be a problem.
Yes I stumbled upon this in the code - and thought this makes no sense anymore - but did not remove it at that time - 1 day with the code - because that var not the focus to possible break something I had no clue if had any purpose - but it will go. It is with code under source control, if you do not use it remove it.
Just a heads up: posted a blog post to keep my blogging quota: http://fixedbycode.blogspot.co…ege-of-avalon-lifted.html
Happy to hear the positive reactions so far, see if I can get the 535 warnings in the code removed this weekend - then we are ready to rumble 
I just skimmed through the code in a quick manner but man that'll be one hell of a work to do.
Kudos to you for even trying!
LOL - I have been doing this for a living for many years - and the code is by no means the worst out there But there are a lot of things in there that I would do differently - nowadays. I would say that is the trivial part of the road-map - might take a bit of time - but it is just like eating an elephant - bit by bit - pun intended.
If ChaptEd would be existing in a state where it doesn't crash every 2 missed clicks it would be far more useful for sure.
If the source code is available everything can be fixed - but it might not make sense - rethinking and redoing can also be an option.
Since I am only into the code for two weeks (for a couple of nights) and in the forum for 3 days - I still need to get acquainted with the various modding tools, what is need/used and for what purpose.
Redoing a game on a different platform is not trivial - the cross-platform thing does not worry me - when the code cleanup and feature-fixes are completed, especially if replacing with something that has an abstraction layer. Have to pull the Windows-ism out of the code first.
How important is cross-platform, compared to a working stable "customizabel" game - that then goes cross-platform? And which platforms? Is a poll needed - nice to have or need to haves
Hi,
TL:DR
I am in the process of reviving and fixing of the SoA source - as mentioned in another thread - to enabled more people to easier get into using the code.
Bear with me not writing in German (you can reply in German) and even worse not having completed the game or modded it or having a full overview of the internals of the assets. My focus is very much on the source code and fixing that - and bring that to the table. So my plan/idea is utilize the benefit of having the source available for the game.
My intention/road-map of my fork on GitHub repo:
So any comments, ideas? I would like to get input, ideas and pull request (when the code is in a cleaner state ;))
I haven't read all posts in all threads yet - but there seems to be some gold hidden in there - that could also be compile and added in some form to the repo. Sorry but I am very much in favor of having "asset" information/documentation close to the source code - so if no-one minds I would grab/revise (with reference of cause) some of the documentation and include in the repo?
Would this be helpful in any way - or am I just interfering and raving 
?
Hallo,
Ich habe seit vielen Jahren nicht auf Deutsch geschrieben, deshalb ...do I continue in English
A bit of backstory - when Diablo I was released on GOG a week or two back - I remembered I had the old SoAOS code lying about since it was released back in mid 2003 (PGD) - I never got around to look into at that time. So with the happy memories of old-school gaming - I found the old code and also did a bit of surfing - finding that Dominique had put it on GitHub, and that some crazy people had recently taken up the task - and I also found this cozy forum
I did a fork of gondur GitHub fork - since my motives/priorities seems to be in a different order than the other forks - newest compiler/toolset first, improvements (HD (optional), multi-platform, character selection usw.) later.
Delphi 4 was not the greatest version, so my first goal is to get the original win32 code to compile and run in the currently latest version of Delphi (10.3.1 Rio) - which is now also available as a Free Community Edition - that is not crippled as the earlier Starter Editions - but matches the Pro Edition.
My thinking is that that would also open the possible for others to work on the code - without digging out their old Delphi 4 CD
My fork can be found here: GitHub repo - current state is that it compiles and is playable using Delphi 2007 - added a few missing/corrupt assets. Have 10.2.3 compiling it, but not playable yet.
I have not included any of the great improvements you guys have done - yet. All is done in the win32 part, since the original SoAOS part seemed very half-baked.
Just to let you know - and great that you have keep this game alive.
