Beiträge von SteveNew

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

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.

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.

yaNasTy sorry for doing this in english - my german writting is too rusty - reading is no problem. If you still have a savegame where the glitch happens please share here or PM to me. Also a happy new year to you.

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.

And Rucksacksepp - a happy new year to you - it has been a while ..and now I hijacked the thread feel free to move.

Well it is worth testing. So we have the Anthology versions and then the last 1.4 patch (from Steve Davis?) as the targets to measure against - correct?

I would like to see the log file, and save game as well. Curious on what causes the difference in the savegames. Would be nice to try and support both original and 1.4 save files.

Have you tried my release from here https://github.com/SteveNew/Siege-of-Avalon-Open-Source - it has been a while since I put up a binary - the replacing of the ddraw.dll is important as Rucksacksepp mentions.

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.

Rucksacksepp great package. I have not digged into it yet, but I did note a few things:

- The Liesmich.txt states that there is two issues with Narzoul ddraw.dll - these have been fixed if you use a newer (experimental - they all are) release, see: https://github.com/narzoul/DDrawCompat/issues/42 - update: I had in the source code compensated for the upside-down/arrow error - but that has been removed again - when the DLL got fixed. Might be that that code is still active in the build you have been using?

- Would it make any sense to actually install data files to %localAppData% - being restricted by the old Digital Tome install path does not makes things easier or correct.

I had be doing some major refactoring and reorg of the code, but had to back-paddle. I have been pushing a few clean-ups.

A bit of status - one and a half month has gone past - and I have not been able to allocate time for this, and various other things I would have loved and enjoyed to do .

I have no idea when I will be able to look into this project and SoAOS again in the near future - but life really get in the way currently.

Take care out there - and best wishes.

Thanks Eustace

1. One frame BMPs and sprite sheet PNG will do?

2. Ini file is created based on how you arrange the frame, by load order and drag/drop. And what is marked as editorframe and action/hitframe.

I have been a bit and forth on this, but ended up with having the 8 directions on the vertical, and then the actions aligned af one another on the horizontal, separated by a colored background. The idea is that you should be able to set the marking color, how many frames and the name of the action. If I add that you can hide some actions, then we could still be within the real estate of the screen, without too much scrolling.

The idea was also that you should be able to delete, clone and insert and append frames.

I will see if I get a bit done during weekend.

I pushed the latest changes to GitHub - that does not include any of the conceptual things - mentioned in #19 and #21. From the changelog below:

Added

- Added support for reading/deflating .AG files (Hero X), into users AppData temp directory as .pox files and read from there. Linked Layered resources is not handle correct since original relative paths are not resolved - yet?

- Honoring the INI datas TransparentColor and EditorImage values.

- Transparent color can be changed.

Changed

- German translation gone for now.

- Zoom/Scaling is now 1-2-4-8.

Will wait a bit and see if there is any feedback on #21, before starting to changing the UI/UX for POXStudio - based on proff of concept and feedback.

This is a follow up on #19. So I did a bit of "concepting" this sunday on basic functionality that in some form should merge into POX Studio - I did a short video, to show:

- a "gallery/browser" (replacing the file dropdown probably)

- a frame/direction/action editor - loading individual bmps and a png spritesheet - that will "pre-generate" the frame INI-data (and write the POX)

Please comment - does the userflow make sense, or do I have it completely wrong - remember I have not done many POX files in my life - and what seems logical to me might not be the fastest/best way to work with the files. The demo is very rough and conceptual - but I hope I get the idea across.

Sorry about the recorder-bar - but I did not want to make the video clip into a project by itself - so "snapshot"

An update - postponed the Siege engine DFX/digifx for now - so I have been playing a bit with ideas on actually making the whole POX Studio useful:

So things on the table are - but nothing final - please come forward with any wishes/comments/ideas.

- A opening "wizard" that lets one decide to: Create a new POX, Open a POX file, Import bmps/sheet (based on POX template (Layered, Tile, Static...) or Resume work.

- A Character Builder - select the "naked" resource, and apply the layers to create a non-layered character.

- A Gallery/Browser - filter by type and search - to replace the current drop down - since a thumbnail of the asset is more useful when selecting.

- Visual ordering of frames per direction by drag-drop frames

Below is just a test on getting the "editorimage (if any)" from each file - for a gallery/browser.

Was able to load a 3d model directly - but without textures - so I will not use any time on that yet. Load, Edit and Save are the key points.

Have done an Hero-X .ag file deflater that I will incorporate in POX Studio - so that resources can be used as well - only current issue is the file names - since their relative path is stored elsewhere (game.ag) - and some refer to the same "gif" name in their ini data. The quality of these seem better and has more frames.

Did also play with the CNV files - will at one point look into those - since editing them today is ..... I also made this last sunday evening as a late Delphi 25th video - should have included voice over

Did just update the POX file documentation, in regards to TransparentColor usage - thanks Eustace.

Hi Eustace,

I will just put a bit info here as well - so again thanks for the file and guide.

Plan is to finish the current work I am doing on deprecating all the DFX/digiFX code/DLL stuff.

Then I will spend time on POXStudio again - and focus on making it more "productive and functional" and less "flashy" - and make BMPWorks and Gif2POX obsolete.

I will probably put support for deflating/inflating .ag files from the Hero-X engine as well - (sorry for mentioning that here - different game - same resources).

The POX resources from Hero-X does contains +1000 frames - so as you mentioned earlier it is the dreadfull BMPWorks/Git2POX duo that is the bottleneck. Below has 1120 frames as an example.

Regarding the transparent color - yes you are right - it does have a function - in the context of BMP to POX/RLE data and vice verse. But in regards to the engine using the POX/RLE data it has no use - since the "transparent" pixels are not include in the RLE picture data.

So we are both right - depending on context But POX Studio should honor or let the user chose what the transparent color is for import and export - so you can stick to the "Chroma green"

BTW: Does PNG import/export make sense?

I will play with Collada 3D model import later - for fun - if that even makes sense.

/Steve

So what did I spend my Sunday on?...well the whole digiFX DFXPxS.DLL hell has been bothering me since the start, so I did a small test application where I draw the rle data - with the 5 different DFX RLE drawing functions used in the game - just to make debugging easier it can both run in Exclusive (fullscreen) and Windowed mode. I have currently only done the Draw and DrawBlend - but it is an implementation of the digifxDrawRLE function, so when done it should not be hard to put into the full engine.

As seem in the picture the 3 figures to the right - drawn by the old DLLs can not handle 32bpp correctly - I have implemented both 16bpp and 32bpp. But the greatest thing is that - when I am done - there is no "cryptic" DLLs hidding anything - so the game can be ported to a different graphics back-end/OS.

I have only spend a bit on optimizing - as an example took the DLLs Draw 60-80 ticks - and mine 350 - 600 - but I should be able to get this further down - and remember a 1/1000 sec has 10.000 ticks. Will not end up as good as the DLLs - but rather portable code than non-portable assembler.

I messed up the colors on when I saved the "background" image - just for testing. But all still work in progress - I was planning to use the test application for simple testing of graphics backend/OS also - after the DLLs are gone. The DirectX Windowing mode is just for debugging - and I do not think I will apply it to the engine - even if I got it wrapped nicely.

..and a bit on .LVL files - and some casting cleanup in the code